Команда телемед-продукта: кто нужен и когда

Это инженерные рекомендации, а не юридическая консультация. Уточняйте детали у квалифицированного юриста.

Кратко

Команда телемед-продукта – не обычная команда приложения, к которой в конце «подключили врача». Это кросс-функциональная группа, где роли, о которых чаще всего забывают, – медицинский эксперт, понимающий, как на самом деле устроена помощь, и люди, отвечающие за защиту медданных, – весят не меньше инженеров. Две из этих ролей обязательны по закону. 152-ФЗ требует, чтобы оператор-юрлицо назначил ответственного за организацию обработки персональных данных (ст. 18.1 и 22.1), а ПП 1119 начиная с третьего уровня защищённости требует назначить ответственного за безопасность ПДн в информационной системе (п. 14). Если ваша компания обрабатывает данные по поручению клиники, поручение всё равно обязывает её соблюдать ст. 18.1. Не все роли нужны в первый день: они подключаются волнами за 6–9 месяцев разработки, а часть из них – медэксперт, ответственный за ПДн, специалист по ИБ, даже специалист по видео – поначалу заняты частично. В статье – каждая роль, момент её подключения, ориентиры по зарплатам в рублях и то, как решить, кого нанимать в штат, кого брать через партнёра, а кого привлекать на часть времени.

Зачем это читать

Большинство телемед-проектов спотыкаются не на видеозвонке, а на оргструктуре. Основатель нанимает трёх фулстек-разработчиков, получает рабочее демо и только потом обнаруживает, что за защиту медданных никто не отвечает, никто не может сказать, совпадает ли сценарий с реальным приёмом и порядком телемедицины, и никто не знал, что видео в реальном времени – отдельная специальность. Статья – для основателя, руководителя продукта или руководителя медорганизации, которым нужно собрать команду (или выбрать партнёра, который её соберёт) для продукта, который можно законно запустить. Состав команды предопределяет всё остальное: неправильная команда сделает красивое приложение, которое нельзя выпустить к пациентам, а исправлять это после разработки куда дороже, чем сразу нанять правильных людей.

Из чего состоит телемед-команда

Начнём с общей схемы. Команда потребительского приложения – это в основном продукт, дизайн и инженеры, всё остальное второстепенно. У телемед-команды тот же инженерный костяк, но есть ещё две опоры, без которых продукт не устоит: медицинская экспертиза и защита медданных. Удобнее представлять команду не одним списком, а четырьмя группами.

Первая группа – продукт и клиника: те, кто решает, что строить и совпадает ли это с реальной помощью. Вторая – инженеры, которые в телемедицине делятся на прикладных разработчиков и как минимум одного специалиста по видео в реальном времени. Третья – защита ПДн и информационная безопасность – опора, которой у потребительских команд нет вовсе. Четвёртая – качество: здесь проверяют не только то, что функции работают, но и то, что продукт достаточно надёжен для клинической ситуации и доказуемо правильно обращается с медданными. Каждая роль ниже относится к одной из этих групп.

Нажмите, чтобы увеличить

Продукт и клиника: что строить

Продакт-менеджер (или владелец продукта). Превращает «хотим видеоприёмы» в приоритизированный и выполнимый план и отвечает за компромиссы между объёмом, стоимостью и сроками. В телемедицине у него есть задача, которой нет у продакт-менеджера потребительского продукта: следить, чтобы каждое решение по функциям учитывало ограничения по медданным, порядок телемедицины и правила оплаты – ОМС, ДМС, платные услуги, – а дорожная карта не обещала функцию, которую нельзя законно запустить. Продакт-менеджер приходит на проект первым и остаётся до конца.

Медицинский эксперт (или медицинский директор). Роль, о которой забывают, и забывать о ней дорого. Медэксперт – практикующий или недавно практиковавший врач нужной вертикали – объясняет, как на самом деле оказывается помощь: как принимается решение о маршрутизации, что врачу нужно видеть на экране во время приёма, где сценарий, который хорошо выглядит в демо, сломается в реальной клинике. В России он же следит за соблюдением порядка телемедицины: в режиме «врач – пациент» допустимы профилактика, сбор жалоб и анамнеза, оценка эффективности лечения, наблюдение и решение об очном приёме, а поставить диагноз дистанционно без очного приёма нельзя (ч. 2 ст. 36.2 323-ФЗ, п. 40 приказа 193н) [5][6]. Без медэксперта команда строит приём, каким его себе представляет, а не тот, который ведут врачи и разрешает закон, и разрыв всплывает только на пилоте. Медэксперт обычно занят частично – несколько часов в неделю или по консультационному договору. Сидеть рядом с инженерами ему не нужно, но участвовать в оценке объёма работ, обсуждении дизайна и пилоте – обязательно. Подключайте его на этапе анализа, до разработки первой функции.

Медэксперт помогает и с регуляторной границей, о которой стоит подумать заранее. Если в дорожной карте есть функция, которая сама интерпретирует клинические данные для диагностики, а не просто помогает врачу, она может оказаться медицинским изделием с регистрацией в Росздравнадзоре по ПП 1684, а ПО с ИИ по классификации приказа Минздрава 4н от 06.06.2012 относится к классу риска 3 [10]. Это отдельный большой блок работ по испытаниям и регистрации. Медэксперт часто первым замечает, что функция переходит эту границу; где она проходит, подробно разбирает статья о том, где ИИ встраивается в телемед-продукт.

Защита ПДн и ИБ: без этого не обойтись

Главное, что нужно знать об этой группе: две роли в ней требует закон, это не просто хорошая практика. Сведения о здоровье – специальная категория персональных данных (ст. 10 152-ФЗ), и обрабатывать их без назначенных ответственных нельзя.

Первая роль – ответственный за организацию обработки персональных данных. Оператор – юридическое лицо обязан его назначить (ст. 18.1 ч. 1 и ст. 22.1 152-ФЗ) [1][2]. Ответственный получает указания напрямую от руководителя организации и подотчётен ему, а его обязанности перечислены в законе: внутренний контроль соблюдения законодательства о ПДн, в том числе требований к защите; доведение до работников положений закона, локальных актов и требований к защите; организация приёма и обработки обращений и запросов субъектов, то есть пациентов. Назначайте его до начала обработки медданных, а не перед проверкой.

Вторая – ответственный за обеспечение безопасности ПДн в информационной системе. ПП 1119 требует назначить такое должностное лицо, начиная с третьего уровня защищённости (п. 14), а для первого уровня – создать структурное подразделение, ответственное за безопасность ПДн, или возложить эти функции на одно из подразделений (п. 16) [3]. Какой уровень у вашей системы, определяют модель угроз и объём данных; подробно – в статье о требованиях к защите ПДн в 2026 году.

Если ваша компания не клиника, а разработчик, который обрабатывает данные по поручению клиники, вопрос всё равно остаётся: поручение должно обязывать исполнителя соблюдать требования ч. 5 ст. 18 и ст. 18.1 152-ФЗ и по запросу оператора подтверждать это документами (ч. 3 ст. 6) [2]. А для персональных данных собственных сотрудников вы в любом случае оператор.

Нажмите, чтобы увеличить

Ответственный за ПДн – юридическая роль. Отвечает за политику обработки ПДн и локальные акты, согласия пациентов (с 1 сентября 2025 года согласие на обработку оформляется отдельным документом) [12], цепочку поручений с каждым подрядчиком, который видит медданные, уведомления Роскомнадзора – об обработке и, при утечке, в течение 24 и 72 часов (ч. 3.1 ст. 21) [1] – и ответы на запросы пациентов. Обычно это юрист или комплаенс-менеджер, который понимает продукт; на старте роль часто частичная или на аутсорсе. Подробнее о его зоне ответственности – в статье о 152-ФЗ и врачебной тайне для продуктовых команд.

Специалист по ИБ – инженерная роль. Строит модель угроз и определяет уровень защищённости, выбирает меры по приказу ФСТЭК № 21 – управление доступом, регистрацию событий безопасности, защиту каналов, обеспечение доступности, – решает, где нужны сертифицированные средства защиты и криптографии, и готовит документацию для проверки [4]. Оценку эффективности принятых мер приказ № 21 требует проводить не реже одного раза в три года – силами оператора или с привлечением организации с лицензией на техническую защиту конфиденциальной информации (п. 6) [4], поэтому в стартапе специалиста по ИБ нередко дополняет внешний лицензиат. И ответственный за ПДн, и специалист по ИБ должны участвовать в проекте с этапа анализа: защита данных определяет модель данных и архитектуру, её нельзя добавить отдельным слоем на этапе тестирования.

Часть защиты – задача не одного человека, а всей команды. Ст. 18.1 152-ФЗ требует ознакомить работников, которые обрабатывают ПДн, с законодательством, требованиями к защите и локальными актами и (или) обучить их [1], а сведения о факте обращения, здоровье и диагнозе – врачебная тайна, которую не вправе разглашать и те, кому она стала известна при исполнении трудовых и иных обязанностей (ст. 13 323-ФЗ) [7]. Для телемед-команды это значит, что каждый инженер, дизайнер и тестировщик с доступом к медданным должен пройти ознакомление под подпись и дать обязательство о неразглашении.

Требования к этой группе скоро могут ужесточиться. 24 июля 2026 года ФСТЭК опубликовала проект приказа на замену № 21: показатель зрелости защиты, оценка до начала обработки, раз в три года и после каждого инцидента, меры для ИИ, контейнеров и API – и отдельные требования к обработчикам [8]. На 24 сентября 2026 года он не подписан, но планируйте роли защиты так, будто требования вырастут прямо во время разработки.

Инженеры: разработка и отдельная специальность – видео

Бэкенд-разработчики. Строят серверную часть: аккаунты, расписание, модель данных для хранения протоколов и записей, API и журналы событий безопасности. В телемедицине бэкенд несёт основную нагрузку по защите данных: именно там хранятся медданные и именно там работают управление доступом и журналирование.

Инженер видео реального времени. Вторая роль, которую недооценивают. Видеосвязь в телемед-продукте построена на WebRTC – браузерной технологии для аудио и видео в реальном времени, – и сделать её надёжной на плохих сетях, разных устройствах и при переподключении – настоящая специальность, которую фулстек-разработчик не освоит за спринт. Реальных вариантов два: нанять или привлечь по договору специалиста по видео либо арендовать видеослой у российского вендора, который держит медиа в России и работает по поручению, и поручить интеграцию прикладному разработчику. Это решение «строить или покупать» для видеослоя, и оно прямо меняет состав команды: при покупке выделенный WebRTC-инженер может вовсе не понадобиться. Выбор видеослоя разбирает это решение; сам протокол – в объяснении WebRTC в курсе Video Streaming.

Фронтенд- и мобильные разработчики. Делают то, с чем работают пациенты и врачи: веб, приложения для iOS и Android или всё сразу. Специфика телемедицины здесь – доступность и устойчивость: пациенты, которым телемедицина нужнее всего, часто пожилые, слабовидящие или на плохой связи. ГОСТ Р 52872-2019 на базе WCAG 2.1 – стандарт добровольный, но он задаёт понятную планку, а 181-ФЗ устанавливает общую обязанность обеспечивать доступность услуг [11], так что фронтенд второстепенным быть не может; подробнее – в статье о WCAG 2.1 AA и ГОСТ Р 52872-2019 для телемед-видео.

DevOps-инженер. Отвечает за облако, в котором работает продукт, а в телемедицине это российское облако с аттестованным сегментом под нужный уровень защищённости и договором, где прописаны условия обработки ПДн (Yandex Cloud, Cloud.ru, Selectel, MWS и другие) [9]. На нём развёртывание, мониторинг, резервное копирование и восстановление – это меры обеспечения доступности из приказа ФСТЭК № 21 [4]. В малой команде эти обязанности поначалу часто совмещает бэкенд-разработчик; ближе к запуску и эксплуатации нужна отдельная роль.

Инженер интеграций (часто специализация, а не отдельный человек). Телемед-продукту в России без интеграций не обойтись: идентификация участников через ЕСИА обязательна, а запросы и протоколы телемедконсультаций передаются в ЕГИСЗ – напрямую или через МИС клиники, – где электронные медицинские документы описаны в формате СЭМД на базе HL7 CDA R2; интеграционные платформы вроде N3.Health работают по HL7 FHIR. Добавьте МИС клиники, лаборатории, электронный рецепт и онлайн-кассу. Во многих командах этим занимается бэкенд-разработчик, а в продуктах с большим числом интеграций нужна отдельная роль. Число интеграций – один из главных факторов объёма работ, как показано в статье об объёме работ и оценке телемед-проекта, а сами стандарты описывает статья HL7 FHIR, СЭМД и реальность интеграции с МИС.

Качество: когда сбой становится клинической проблемой

UX/UI-дизайнер. В телемедицине от дизайна зависит, будет ли врач спокойно вести приём или бороться с интерфейсом, пока ждёт пациент. Дизайнер отвечает за клинический сценарий на экране и требования доступности. Подключайте его на этапе анализа вместе с медэкспертом, чтобы сценарий сразу проектировался с учётом клинической практики, а не дорабатывался задним числом.

QA-инженер. В потребительском приложении ошибка раздражает; в телемедицине оборванный звонок может стать клинической проблемой, а ошибка в обработке данных – утечкой, о которой нужно уведомить Роскомнадзор. Поэтому тестирование здесь шире, чем проверка «работают ли функции»: тесты в плохих сетях, на матрице устройств и браузеров, поведение при переподключении, нагрузочные тесты на пиковый трафик и – что характерно именно для медицины – тесты защиты данных, которые проверяют, что управление доступом и журналы работают так, как требуют правила. Это настолько самостоятельная дисциплина, что тестированию клинического видео посвящена отдельная статья. Нагрузка на QA растёт по мере появления функций и максимальна перед пилотом и запуском.

Все роли в одной таблице

Когда подключать каждую роль

Нанимать всех в первый день не нужно, и попытка сделать это – отдельная ошибка. Разработка телемед-продукта проходит узнаваемые фазы за реалистичные 6–9 месяцев, и роли подключаются волнами.

Анализ (первые недели). Минимальная группа: продакт-менеджер, медэксперт, дизайнер и ответственный за ПДн вместе со специалистом по ИБ. Это сделано намеренно: роли, которые обычно откладывают, участвуют с самого начала, потому что клинический сценарий и архитектура защиты определяются именно сейчас, а менять их позже – самая дорогая переделка.

Основная разработка (самая длинная фаза). Инженеры подключаются в полном составе: бэкенд, фронтенд и мобильные, видеослой (специалист или интегрированный вендор). Продакт-менеджер, дизайнер и медэксперт продолжают участвовать; защита данных идёт параллельно, и меры внедряются по мере разработки функций, а не после.

Защита ПДн и интеграции (накладывается на конец разработки). Самый загруженный период ответственного за ПДн и специалиста по ИБ: документы, поручения, оценка эффективности мер, подключение к ЕСИА и ЕГИСЗ. В это же время растёт нагрузка на DevOps.

Пилот (до полного запуска). QA работает в полную силу, медэксперт снова выходит на первый план и наблюдает, как реальные врачи пользуются продуктом, а команда исправляет неожиданные проблемы сценария, которые всплывают только в реальной работе.

Запуск и эксплуатация. Команда переходит от разработки к эксплуатации. DevOps и QA становятся постоянной дежурной службой; ответственный за ПДн и специалист по ИБ переходят в режим поддержки: внутренний контроль, обращения пациентов, реагирование на инциденты.

Нажмите, чтобы увеличить

Пример: минимальная команда

Разберём на цифрах. Представьте стартап, который делает первый телемед-продукт на арендованном российском видеослое, то есть без выделенного WebRTC-инженера. Реалистичный костяк на время разработки: один продакт-менеджер, два бэкенд-разработчика, два фронтенд- или мобильных разработчика и один дизайнер – шесть человек на полной занятости. Вокруг костяка – частичные роли: медэксперт, скажем, 4 часа в неделю, ответственный за ПДн и специалист по ИБ – 1–2 дня в неделю на двоих, плюс внешний лицензиат для оценки эффективности мер. QA начинает на полставки во время разработки и выходит на полную занятость к пилоту.

Посчитаем порядок фонда оплаты труда. Медианные зарплаты разработчиков «на руки» в 2026 году по данным Хабр Карьеры – junior 97 тыс., middle 178 тыс., senior 304 тыс., lead 380 тыс. ₽ в месяц, а медиана по IT в первом полугодии 2026 года – 191 тыс. ₽ [13]. Четыре разработчика уровня middle–senior – от 4 × 178 тыс. ≈ 0,7 млн до 4 × 304 тыс. ≈ 1,2 млн ₽ в месяц; продакт-менеджер и дизайнер по медиане IT – ещё 2 × 191 тыс. ≈ 0,4 млн ₽. Итого костяк – порядка 1,1–1,6 млн ₽ в месяц на руки; НДФЛ, страховые взносы и рабочие места – сверху. Частичные роли вместе добавляют примерно половину ставки, но на них лежат две важнейшие и обязательные по закону зоны ответственности. Самые маленькие по часам роли – не самые маленькие по значению. Команда, которая наняла шестерых разработчиков и сэкономила на половине ставки медицинской экспертизы и защиты данных, доходит до пилота и обнаруживает, что построила не тот сценарий и неправильно обрабатывает данные.

Это плановые цифры для иллюстрации структуры, а не смета: реальные числа зависят от объёма работ, который вы определите по статье об объёме работ и оценке телемед-проекта и переведёте в бюджет с помощью модели стоимости телемед-платформы.

Штат, партнёр или гибрид

Собрать эту команду можно тремя способами, и большинство приходит к третьему.

Своя команда – каждая роль в штате. Это максимум контроля, и знания остаются внутри, но собрать команду со специалистом по видео в реальном времени и людьми, которые разбираются и в 152-ФЗ, и в медицине, долго и дорого: таких специалистов трудно найти. Подходит организациям, которые будут развивать телемед-продукт годами и хотят держать компетенции у себя.

Партнёр – компания-разработчик, у которой вся команда, включая дефицитных специалистов по видео и защите данных, уже собрана и сработалась. Это самый быстрый путь к законному запуску без проблем с наймом. Цена – часть прямого контроля и необходимость найти партнёра, который действительно разбирается в здравоохранении, а не только в приложениях.

Гибрид – самый частый вариант: в штате остаются роли, которые отвечают за видение продукта и клиническое знание, – обычно продакт-менеджер и медэксперт, – а дефицитные разработчики и часто экспертиза по защите данных приходят от партнёра. Вы определяете, что и зачем делать, а партнёр отвечает за то, как это сделать, и даёт дефицитных специалистов. Это частный случай более широкого выбора из статьи свой, покупной или гибрид для телемедицины.

Нажмите, чтобы увеличить

Важно для всех трёх моделей: кто бы ни писал код, обязанность назначить ответственных и отвечать перед пациентом остаётся за оператором – организацией, которая работает с пациентом, обычно клиникой (ч. 5 ст. 6 152-ФЗ) [2]. Партнёр может выполнить большую часть работы по защите и даже предоставить для неё людей, а поручение обязывает его соблюдать ст. 18.1, но передать на аутсорс назначение и ответственность оператора нельзя. До начала разработки зафиксируйте письменно, кто какое поручение подписывает и кто занимает обязательные роли.

Частая ошибка: клиника и защита данных как «довески»

Самая дорогая ошибка найма в телемедицине – сначала собрать инженерную команду, а медэксперта и ответственных за защиту данных «подключить позже». От их решений – совпадает ли сценарий с реальной помощью и порядком 193н, обрабатываются ли данные по закону – зависит устройство продукта: дизайн и модель данных. Если подключить этих людей после разработки, построенное придётся переделывать. «Покажем врачу перед запуском» и «защиту ПДн добавим в конце» – две фразы, с которых начинается большинство переделок телемед-продуктов.

Смежная ловушка – считать, что один сильный фулстек-разработчик сделает всё, включая видео в реальном времени. Надёжное видео в реальных сетях – отдельная специальность: прикладной разработчик хорошо интегрирует российский видео-SDK, но видеослой, написанный с нуля без такой экспертизы, даёт звонки, которые обрываются как раз в тех условиях, в которых находятся пациенты. Решите заранее, покупаете вы видеослой или строите сами: от этого зависит, нужен ли в команде такой специалист вообще.

Где здесь Фора Софт

Фора Софт разрабатывает ПО для видео в реальном времени с 2005 года, в том числе телемед-платформы, и устроена именно так, как описано в этой статье: специалисты по видео, для которых WebRTC – основная работа, а не побочная задача, работают вместе с людьми, отвечающими за защиту данных и качество, которых требует медицинский продукт. Поскольку речь о медицине, мы начинаем с требований: защита медданных и клинический сценарий учитываются с этапа анализа, а не дорабатываются перед запуском. В гибридной модели мы даём недостающих разработчиков и специалистов, а продуктом и медицинской частью руководит команда клиента; это самый частый и обычно самый выгодный формат. Мы также работаем с видеоконференциями, стримингом, e-learning и видеонаблюдением, поэтому видео в реальном времени, на котором спотыкаются команды прикладных разработчиков, для нас привычная задача.

Главное

• У телемед-команды есть две опоры, которых нет у потребительских: медицинская экспертиза и защита медданных.
• Закон требует назначить ответственного за организацию обработки ПДн (ст. 18.1, 22.1 152-ФЗ) и – с УЗ-3 – ответственного за безопасность ПДн в ИС (п. 14 ПП 1119); обработчика по поручению ст. 18.1 тоже касается.
• Медэксперт, ответственный за ПДн и специалист по ИБ обычно заняты частично: часов немного, но значение большое.
• Видео в реальном времени – отдельная специальность; российский видеослой по поручению может заменить выделенного WebRTC-инженера.
• Костяк из шести человек – порядка 1,1–1,6 млн ₽ в месяц на руки по медианам Хабр Карьеры.
• Большинство выбирают гибрид: продукт и медэкспертиза – в штате, дефицитные специалисты – у партнёра.

Что читать дальше

• Свой, покупной или гибрид для телемедицины – от этого решения зависит, какую часть команды нанимать, а какую привлекать со стороны.
• Объём работ и оценка телемед-проекта – как превратить состав команды и объём работ в обоснованную оценку.
• 152-ФЗ и врачебная тайна простым языком для продуктовых команд – за что на деле отвечают ответственные за ПДн и ИБ.