Анатомия телемед-платформы целиком

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

Кратко

Телемедицинская платформа состоит из десяти связанных подсистем: приложения пациента и врача, идентификация и согласия (ЕСИА, ФРМР, УКЭП), расписание, зал ожидания, ядро видеосвязи реального времени, инструменты внутри звонка, запись и документация, интеграция с МИС и ЕГИСЗ, рецепты, лаборатории и платежи, аналитика, и всё это внутри слоя комплаенса и аудита. У каждой подсистемы есть типовая технология, типичный сбой и ответ на вопрос, от которого зависит объём защиты: есть ли здесь медданные – сведения о здоровье и врачебная тайна? Один 20-минутный визит оставляет устойчивые копии медданных как минимум в семи хранилищах. Поэтому обёртка (хранение в России, шифрование, контроль доступа, журналы, поручения обработки) проходит через всю платформу, а не добавляется отдельной функцией. Статья – карта всего курса: у каждого узла есть свой подробный разбор.

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

Самые дорогие ошибки телемедицинского продукта случаются до первой строчки кода: подсистема, которую никто не заложил в бюджет; подрядчик, который видит данные пациентов без договора-поручения; список функций, скопированный с маркетинговой страницы. Статья даёт основателю, продакт-менеджеру и ИТ-руководителю клиники цельную картину на одной странице: из каких частей состоит платформа, как между ними движутся данные и где к ним привязаны обязанности по 152-ФЗ, 323-ФЗ и приказу 193н. Она опирается на разбор терминов телемедицины, объяснение, почему клиническое видео сложнее обычного звонка, и классификацию трёх способов оказания помощи. После неё каждая следующая статья курса (152-ФЗ, видеоархитектура, МИС и ЕГИСЗ, ИИ) найдёт своё место на карте.

Карта целиком

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

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

На карте повторяются три пометки. Это три вопроса, которые стоит задать о любом компоненте, что бы ни предлагали вендор или инженер:

Если вы встречаете термин впервые: поручение обработки – договор, по которому подрядчик обрабатывает данные пациентов для клиники и отвечает перед ней (ст. 6 ч. 3–5 152-ФЗ) [3]. Подписать его нужно до того, как подрядчик получит доступ к данным. Подробно – в статье о поручении обработки и договорах с подрядчиками; на этой карте пометка «нужно поручение» стоит на каждой стрелке, по которой медданные уходят третьей стороне.

1. Входные двери: приложения пациента и врача

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

Типовая технология: для пациентов – веб-приложение (часто PWA), потому что визит в браузере обходится без установки, а на ней пациенты отсеиваются; мобильные приложения – там, где нужны возможности устройства (Bluetooth-датчики, push-уведомления). Врач обычно работает в десктопном вебе, всё чаще встроенном прямо в его МИС. Доступность закладывают с самого начала: технический ориентир – WCAG 2.1 уровня AA и построенный на нём ГОСТ Р 52872-2019 (стандарт добровольный); статья о доступности разбирает требования к видеоинтерфейсу.

У входной двери есть и обязательная вывеска. Консультирующая организация и оператор информационной системы должны в доступной форме, в том числе на сайте, сообщать пациенту сведения о себе и о консультанте, о порядке получения согласий и идентификации через ЕСИА, о стоимости и условиях получения заключения, о месте хранения материалов (193н, п. 37) [2]. Это экран продукта, и обновлять его нужно вместе с составом врачей и тарифами.

Типичный сбой – одно приложение на две роли: «пациентский» интерфейс, который отнимает у врача весь день, или «врачебный», на первом экране которого теряется пациент. Второй сбой – разрастание списка платформ: каждое поддерживаемое устройство, браузер и версия ОС – постоянная статья расходов на тестирование.

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

2. Идентификация и согласия: кто на приёме и дал ли он согласие

До любого клинического разговора платформа должна уверенно ответить на два вопроса: действительно ли пациент тот, за кого себя выдаёт, и вправе ли врач его консультировать. В России ответ задан законом. Участники телемедицинской консультации проходят идентификацию и аутентификацию через ЕСИА – «Вход через Госуслуги» (ч. 6 ст. 36.2 323-ФЗ; 193н, п. 7) [1][2]. Врач должен быть внесён в федеральный регистр медицинских работников (ФРМР), медорганизация – в федеральный реестр медицинских организаций (ФРМО), а медицинские документы врач подписывает усиленной квалифицированной электронной подписью – УКЭП (ч. 7 ст. 36.2; 193н, п. 9) [1][2]. Sber ID или VK ID удобны для быстрого входа в личный кабинет, но ЕСИА для консультации не заменяют.

Вторая половина подсистемы – согласия, и в медицине каждое из них оформляется документом. Информированное добровольное согласие (ИДС) на медицинское вмешательство по ст. 20 323-ФЗ можно оформить в электронном виде: пациент подписывает его простой электронной подписью через ЕСИА или УКЭП, медработник – УКЭП [5]. Согласие на обработку персональных данных с 1 сентября 2025 года оформляется отдельно от иных документов – оферты, политики, договора (ст. 9 ч. 1 152-ФЗ) [3]. Согласие на запись консультации, если её ведут, – ещё один документ. Для каждого нужны версия текста, время и личность согласившегося, и всё это должно найтись при проверке даже через годы. Статья о ролях, идентификации и согласиях разбирает всех участников – законных представителей, переводчиков, консультантов, – а статья об ЕСИА, SSO и регистрах ФРМР/ФРМО – механику подключения.

Типовая технология: коннектор к ЕСИА (система регистрируется в ЕСИА, запросы подписываются ключом по ГОСТ – сверяйте с методическими рекомендациями), провайдер идентификации для персонала (например, Keycloak) с многофакторной аутентификацией, проверка врача по ФРМР и сервис согласий с версиями документов. Типичный сбой – один чекбокс «согласен со всем», объединяющий оферту, политику и согласие на обработку данных: с сентября 2025 года это прямо противоречит ст. 9.

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

3. Расписание и напоминания: подсистема, которая окупает себя

Расписание кажется типовым софтом, пока в нём не появляются клинические ограничения: специальность и допуск врача, длительность разных типов консультаций, доступность переводчика, буферы между приёмами. Добавляются и внешние системы. Через подсистему ЕГИСЗ «Федеральная электронная регистратура» (ФЭР) граждане записываются на приём и подают запрос на телемедицинскую консультацию с Госуслуг, а сведения о расписании и записях передаются туда в течение одного рабочего дня [7]. Частные клиники получают пациентов и через агрегаторы – ПроДокторов/МедРокет, СберЗдоровье, НаПоправку. Здесь же работают напоминания – самая окупаемая функция на карте: пропущенный визит означает потерянное время врача, а снижение неявок прямо видно в выручке.

Типовая технология: сервис бронирования с движком правил, синхронизация с модулем расписания МИС (обычно платформа работает через него, а не параллельно с ним) и напоминания по SMS, почте или push. Типичный сбой – напоминание, которое говорит лишнее: SMS «Напоминаем: завтра приём в ВИЧ-центре» раскрывает врачебную тайну любому, кто взглянул на телефон, а SMS к тому же не шифруется. В напоминании – только время и ссылка для входа, ничего клинического.

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

4. Зал ожидания: очередь по медицинским правилам

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

У очереди есть и нормативные сроки. Консультация в экстренной форме проводится в срок от 30 минут до 2 часов с момента поступления запроса, в неотложной – от 3 до 24 часов, в плановой – в сроки программы госгарантий (193н, п. 18–20) [2]. Для очереди это SLA с таймером: система обязана измерять время ожидания, а не надеяться уложиться.

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

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

Где здесь медданные: ответы анкеты – самые чувствительные медданные (симптомы, лекарства, причина обращения), собранные ещё до появления врача. Записи очереди (кто ждал, какую услугу, сколько) – тоже медданные, и они попадают в журнал аудита.

5. Ядро видеосвязи: сердце платформы и самая сложная часть

Живой визит работает на WebRTC – стандарте медиасвязи реального времени, встроенном во все современные браузеры; поэтому пациент входит в видеовизит по ссылке, ничего не устанавливая. Вокруг WebRTC – три серверные роли. Сигналинг – управляющий канал, через который устанавливается звонок. TURN – ретранслятор: через него идут медиапакеты, когда сеть больницы или домашняя сеть не пропускает прямое соединение. А когда участников больше двух (законный представитель, переводчик), медиа идёт через SFU (Selective Forwarding Unit) – коммутатор, который принимает поток каждого участника и пересылает его остальным.

Устройство протокола курс заново не разбирает – для этого есть разбор WebRTC и статья о топологиях SFU/MCU в нашем разделе о видеостриминге. Для клиники важнее другое. Задержка должна укладываться в бюджет живого разговора: ITU-T G.114 советует держать одностороннюю задержку звука в пределах 150 мс, а 400 мс считать потолком при планировании [8]. Надёжность важнее качества картинки, потому что оборвавшийся клинический звонок – нежелательное событие, а не просто неудобство. Шифрование заложено в сам стек: медиа WebRTC шифруется в пути по SRTP с ключами, согласованными через DTLS (схема DTLS-SRTP, IETF RFC 5763/5764) [9]. Там, где модель угроз требует сертифицированных средств криптозащиты, на сигнальных и API-каналах появляется ГОСТ-TLS – подробнее в статье о шифровании.

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

Выбор «строить или покупать» сильнее всего сказывается на этом узле: собирать медиаслой на open-source SFU или взять готовый слой как API у CPaaS (Communications Platform as a Service). Для клинического продукта в таблице вариантов решает один столбец: где физически идут медиа и лежат записи и кто за это отвечает по договору.

Условия вендоров меняются – сверяйте их до контракта. Зарубежные видеоплатформы для медданных сразу упираются в локализацию баз (ст. 18 ч. 5 152-ФЗ) и правила трансграничной передачи (ст. 12) [3], поэтому медплатформы в основном строят на open-source SFU в российском облаке.

Типичный сбой – выпустить только сценарий, в котором всё идёт гладко: без запаса ёмкости TURN, без логики переподключения, без плана деградации для пациента на слабом мобильном канале. Второй сбой – договорной: видео-API без поручения обработки или медиа через зарубежные серверы – нарушение, как бы данные ни были зашифрованы. «Зашифровано» не значит «соответствует требованиям». Статья «свой или CPaaS» считает это решение в деньгах, а эталонная архитектура собирает его целиком.

Где здесь медданные: в канале связи. Живая консультация – это медданные в пути, зашифрованные DTLS-SRTP, а запись становится медданными в хранении, как только попадает на диск. Медиасерверы (SFU, TURN) и их операторы – внутри границы: CPaaS, через который идёт видео пациента, – обработчик по поручению со всеми вытекающими обязанностями.

6. Инструменты внутри звонка: визит – больше, чем видео

Одного видео консультации мало. В чате звонка передают ссылки и уточнения; через передачу файлов – фото сыпи или PDF с анализами; демонстрация экрана позволяет врачу пройтись с пациентом по снимку; аннотации рисуют поверх изображения; подключённые датчики передают давление прямо в визит. Всё, чем поделились в клиническом звонке, – медданные.

Типовая технология: data-каналы WebRTC или сервис сообщений для чата, объектное хранилище для файлов, API устройств (Bluetooth LE на мобильных) для датчиков. Электронные рецепты врач обычно выписывает во время визита или сразу после, но технически это интеграция – о ней в разделе 9.

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

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

7. Запись и документация: что остаётся после визита

Когда звонок закончился, начинается главное – документ о визите. Здесь три артефакта. Запись (если её ведут) – сырое аудио и видео сеанса. Транскрипт – её текст. Медицинское заключение или протокол консультации – документ, который попадает в электронную медицинскую карту. Протокол оформляется как электронный медицинский документ (ЭМД) с УКЭП врача; с 1 сентября 2026 года правила электронного документооборота задаёт приказ Минздрава 209н, и он требует при исправлении хранить все версии документа [10]. Протокол телемедицинской консультации передаётся в ФЭР, а сведения о медицинских документах – в реестр ЭМД (РЭМД) ЕГИСЗ в течение одного рабочего дня [7].

Всё чаще черновик заключения готовит ИИ-помощник: в поликлиниках Москвы он расшифровывает разговор и заполняет протокол приёма, а врач проверяет и подписывает; летом 2026 года похожий пилот для клиник запустил «Яндекс Мед» [18]. Распознавать речь с медданными можно только в российском контуре: SaluteSpeech, Yandex SpeechKit (есть on-prem) или open-source модели вроде Whisper на своих серверах. Работу с моделями разбирает плейбук нашего ИИ-раздела, а клиническую обвязку – согласие, договор с вендором модели, место хранения транскриптов – статья об ИИ-скрайбе.

Включать запись – осознанное решение, а не настройка по умолчанию. Обязанности записывать консультации в 193н нет, но если запись сделана, её как сопутствующий материал нужно хранить один год (п. 49–51) [2]. Запись – самый крупный объект медданных на платформе, и с ней возникает вопрос согласия всех участников; когда записывать, а когда нет, разбирает статья о записи. Если записываете, посчитайте объём:

«20-минутный визит, записанный на 1,5 Мбит/с: 1,5 Мбит/с ÷ 8 = 0,1875 МБ в секунду. 0,1875 МБ/с × 1 200 с = 225 МБ на визит. При 1 000 записываемых визитов в месяц это ~225 ГБ новых медданных в хранении ежемесячно, а при сроке хранения в год архив стабилизируется на уровне 12 × 225 ГБ = ~2,7 ТБ – зашифрованных, с контролем доступа и удалением по расписанию, когда основания для хранения отпадают.»

Типовая технология: запись на стороне SFU в зашифрованное объектное хранилище в российском облаке, распознавание речи для транскриптов и МИС как основная система для хранения заключения. Типичный сбой – запись или транскрипт у подрядчика без поручения, в зарубежном облаке или в зарубежном API распознавания: пусть даже зашифрованные, они всё равно не соответствуют требованиям.

Где здесь медданные: во всей подсистеме – в записях, транскриптах, черновиках заключений и конвейере ИИ-помощника.

8. Интеграция с МИС и ЕГИСЗ: где визит встречается с медицинской картой

Телемедицинский визит, который не дошёл до медицинской карты, создаёт опасную вещь – вторую, параллельную медкарту. Медицинская информационная система (МИС) – Медиалог, 1С:Медицина, ЕЦП.МИС, ЕМИАС, MEDODS, Renovatio, Инфоклиника и другие – основная учётная система клиники, и интеграционная подсистема передаёт данные в обе стороны: перед визитом забирает историю и назначения, после – отдаёт заключение, назначения и метаданные визита.

Над МИС есть второй, государственный слой – ЕГИСЗ. Медорганизации, включая частные, обязаны передавать в неё сведения (п. 44 «к» Положения о ЕГИСЗ; это и лицензионное требование – п. 6 «е» ПП 852) [7]. Структурированные медицинские документы (СЭМД) передаются в РЭМД в формате XML на базе HL7 CDA R2 [11]. Передавать данные клиника может через свою МИС, региональную систему (РЕГИЗ) или иную информационную систему; интеграционные платформы вроде N3.Health работают по стандарту HL7 FHIR, а сообщество HL7 FHIR Россия развивает профиль RuCore [11]. Справочники Минздрава (НСИ) доступны по REST API. Статья о FHIR, СЭМД и интеграции с МИС разбирает стек, а статья о Медиалоге, 1С:Медицине и ЕЦП.МИС – конкретные системы.

Для планирования важно, как устроен рынок. Медиалог работает более чем в 1 000 клиник, ЕЦП.МИС – в 29 регионах и примерно 2,8 тыс. медорганизаций, ЕМИАС – московский контур, а интеграционная шина МедФлекс заявляет более 24 тыс. клиник и 152 МИС [12]. Если ваши покупатели – государственные клиники конкретного региона, интеграция с его МИС и РЕГИЗ – половина успеха продажи. Если частные клиники, то при таком разнообразии МИС выгоднее подключаться через агрегатор. Гид по решению об интеграции считает в деньгах варианты «напрямую, через агрегатор или iframe».

Типичный сбой – недооценить сроки: договор с вендором МИС, согласование форматов СЭМД и подключение к региональным системам занимают месяцы, а не спринты. Второй сбой – относиться к МИС как к зеркалу и синхронизировать всё в обе стороны, пока конфликты не подорвут доверие к карте. Решите заранее, чем владеет МИС (медицинской картой), а чем – вы (визитом).

Где здесь медданные: всё, что пересекает эту границу, – медданные по определению.

9. Рецепты, лаборатории, платежи: визит превращается в назначения и деньги

Три группы интеграций выводят результат визита за пределы платформы.

Электронные рецепты. Рецепт в форме электронного документа оформляется по приказу Минздрава 1094н: УКЭП медработника, врач в ФРМР, организация в ФРМО и подключение к государственной информационной системе субъекта РФ; по просьбе пациента выдаётся бумажный дубликат [13]. После телемедицинской консультации рецепт возможен только при коррекции лечения, если диагноз поставлен и лечение назначено на очном приёме по данному обращению (193н, п. 38–39) [2]. Для наркотических и психотропных препаратов действуют особые правила, а практика электронных рецептов на них различается по регионам. Весной 2026 года Минздрав и Росздравнадзор заявили о подготовке законопроекта о продаже рецептурных препаратов только по электронному рецепту, так что за этим узлом стоит следить: статья об электронных рецептах отслеживает сроки.

Лаборатории. Назначения уходят наружу, результаты возвращаются. С Инвитро, Гемотестом, Хеликсом, KDL или ЦМД интеграции, как правило, договорные – через лабораторные модули МИС, N3.Health и региональные системы ОДЛИ; на публичный API заранее не рассчитывайте. Продуктовый вопрос здесь – сценарий: результату, пришедшему после визита, нужны очередь на разбор и способ уведомить пациента, иначе он станет «результатом, который никто не увидел». Разбор лабораторных заказов и результатов – отдельно.

Платежи и оплата. Деньги приходят из трёх источников. Платные услуги: правила ПП 659 с 1 сентября 2026 года разрешают заключать договор дистанционно – на сайте или в приложении, раскрыв до подписания ОГРН, ИНН, лицензию, условия оплаты и адрес для претензий [14]; оплата идёт через эквайринг (ЮKassa, CloudPayments, Т-Касса, Robokassa; СБП и «Мир»), а электронный чек по 54-ФЗ – через облачную кассу вроде АТОЛ Онлайн, КОМТЕТ или Orange Data. ДМС: гарантийные письма, реестры и счета по договору со страховщиком. ОМС: отдельный тариф на телемедицину в тарифном соглашении региона (ПП 2188) и реестры счетов через страховые медицинские организации [15]. Типичный сбой здесь архитектурный: тарифы и правила зашивают в код, хотя они меняются каждый год и должны лежать в конфигурации. Подробнее – в статье о платежах, ДМС, ОМС и фискализации и статье об оплате телемедицины.

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

10. Аналитика и наблюдаемость: смотреть на платформу, не подсматривая за пациентом

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

Правовые рамки здесь чёткие. С 1 июля 2025 года хранить персональные данные граждан России в базах за рубежом прямо запрещено (ст. 18 ч. 5 152-ФЗ; штраф до 6 млн ₽, повторно до 18 млн ₽) [3][6], а о трансграничной передаче нужно заранее уведомить Роскомнадзор (ст. 12). Сторонний SDK, отправляющий события на зарубежные серверы, нарушает оба правила. На практике: никаких сторонних пикселей внутри личного кабинета; внешние аналитические сервисы получают только обезличенные данные, а всё остальное идёт в собственный конвейер в России (например, на ClickHouse). Статья об обезличивании и аналитике показывает, как его построить.

Типовая технология: конвейер событий с фильтром медданных на входе, собственное аналитическое хранилище и стандартный стек наблюдаемости (например, Prometheus и Grafana), который видит инфраструктуру, а не пациентов; чтобы так и оставалось, вычищайте идентификаторы из логов. Типичный сбой – SDK с настройками по умолчанию: мобильная аналитика или сборщик отчётов о сбоях (crash reporting) отправляет идентификаторы устройств, названия экранов («PsychiatryVisitScreen») и IP-адреса из медицинского приложения на чужие серверы.

Где здесь медданные: везде, где событие связывает личность с клинической информацией. Каждое событие нужно отнести к медданным, обезличенным данным или инфраструктурным метрикам и направить по своему маршруту.

Обёртка: слой комплаенса и аудита

Ни одна подсистема не соответствует требованиям сама по себе. Статья 19 152-ФЗ требует определить угрозы и принять меры защиты, ПП 1119 задаёт уровни защищённости (для данных о здоровье как специальной категории уровень зависит от типа угроз и объёма), а приказ ФСТЭК № 21 перечисляет меры по группам [3][19]. Пять групп мер ложатся на конкретные подсистемы карты:

Оговорка: приказ № 21 не требует «шифровать всё» – это набор мер, которые выбирают под модель угроз и уровень защищённости и обосновывают документами. Требования ужесточаются: в июле 2026 года ФСТЭК опубликовала проект замены приказа № 21 с показателем зрелости защиты, регулярной оценкой, мерами для ИИ, контейнеров и API и требованиями к обработчикам. На 12.10.2026 это проект: закладывайтесь на него как на вероятное будущее, но не ссылайтесь на него как на действующую норму [19]. МИС государственных больниц подчиняются отдельному режиму – приказу ФСТЭК № 117, который с 1 марта 2026 года заменил приказ № 17. Статья о требованиях к защите ПДн в 2026 году следит за нормотворчеством, а статья об архитектуре соответствия превращает обёртку в эталонную схему.

Есть у обёртки и сроки. Об утечке персональных данных оператор уведомляет Роскомнадзор в течение 24 часов, а итоги расследования сообщает в течение 72 часов (ст. 21 ч. 3.1 152-ФЗ) [3]. Ставки измеряются миллионами: за утечку данных о здоровье юрлицу грозит 10–15 млн ₽ (ч. 16 ст. 13.11 КоАП), за повторную – от 1 до 3% выручки, но не менее 25 млн ₽ и не более 500 млн ₽, за неуведомление об утечке – 1–3 млн ₽ [6]. С декабря 2024 года действует и уголовная ст. 272.1 УК о незаконном использовании и передаче компьютерной информации с персональными данными. Порядок действий – в статье о реагировании на инциденты.

Карта как инвентаризация медданных

Вот упражнение, которое превращает карту в рабочий инструмент. Возьмите один обычный 20-минутный визит и посчитайте, где сохраняются его медданные:

«1 запись о приёме (расписание) + 1 запись анкеты и очереди (зал ожидания) + 1 переписка с файлами (инструменты звонка) + 1 запись визита (225 МБ, если записываете) + 1 транскрипт + 1 протокол консультации (ЭМД в МИС и сведения в РЭМД) + 1 чек и строка реестра счёта (платежи) = 7 устойчивых хранилищ медданных с одного визита – плюс медданные в пути через сигналинг, TURN/SFU и интеграционные API, плюс записи журнала о каждом доступе.»

Семь хранилищ – это семь решений о шифровании, семь списков доступа, семь сроков хранения (у записи – год по 193н, у ЭМД – сроки из справочника НСИ по 209н) и поручение на каждого подрядчика. Проверяющий, безопасник клиники и чек-лист готовности по 152-ФЗ и 323-ФЗ пойдут именно по этому списку. Пройдите упражнение для своей архитектуры с рабочим листом ниже – раньше, чем это сделает кто-то другой.

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

От карты к списку функций: как определить объём MVP

Маркетинговые страницы продают функции, а платит за них архитектура. Каждая «обязательная функция телемед-приложения» из вендорского списка – это узел или стрелка на карте, и оценить функцию – значит оценить подсистемы, которые она затрагивает:

Разумный MVP продукта с плановыми консультациями – обычно подсистемы 1–5 плюс документация (7), с упрощённой оплатой и минимальной интеграцией с МИС: на таком продукте клиника уже может работать. Но передачу протоколов в ФЭР и сведений в РЭМД отложить нельзя – это обязанность клиники, и с первого дня её должен кто-то выполнять: ваша платформа, МИС клиники или агрегатор. Консультации по запросу не обойдутся без очереди и триажа; DTC-продукт редко может отложить платежи. А обёртку не может отложить никто: ЕСИА, хранение в России, шифрование, журналы и поручения входят в MVP с первого дня, потому что встраивать соответствие требованиям задним числом дороже, чем сразу разрабатывать в этих рамках; модель стоимости даёт цифры для обоих путей.

Типичная ошибка. Команды оценивают квадратики и забывают про стрелки. Видимые функции – видео, чат, запись на приём – отлично смотрятся на демо уже к шестой неделе. А стрелки – синхронизация с МИС, переживающая конфликты; СЭМД, проходящие проверку в РЭМД; напоминания, не выдающие диагноз; записи в российском хранилище с таймерами удаления – вот на что на самом деле уходит бюджет телемед-проектов, и там же кроются частые ошибки в защите медданных. Если в вашей оценке посчитаны только квадратики, удвойте её: стрелки обойдутся не дешевле.

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

Насколько велик этот рынок на самом деле

Несколько цифр для масштаба. По данным Smart Ranking, выручка телемедицинского сегмента в 2025 году составила 21 млрд ₽ (+17,6%), это 35% выручки 70 крупнейших медтех-компаний [20]. Выручка клиник от дистанционных консультаций, по оценке BusinesStat, выросла с 5,6 млрд ₽ в 2020 году до 15,8 млрд ₽ в 2024-м [21]. В ДМС, по опросу брокера Remind среди 11 страховщиков, телемедициной в 2025 году пользовались 25% застрахованных против 12% в 2022-м [22]. Рост пережил пандемию, и держится этот сегмент на платформах, где визит, документ, счёт и комплаенс-обёртка спроектированы вместе, как один продукт.

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

Фора Софт делает видеософт с 2005 года; среди 250+ выпущенных проектов – телемедицинские платформы, видеоконференции, стриминг, видеонаблюдение, e-learning и OTT. В телемедицинских проектах мы отвечаем ровно за эту карту: ядро WebRTC с запасом ёмкости TURN/SFU под клиническую надёжность в российском облаке; инвентаризация медданных с шифрованием и журналами с первого спринта; ЕСИА, УКЭП и интеграционное кольцо – МИС, ЕГИСЗ, рецепты, платежи – с реалистичными сроками подключения. «Комплаенс прежде всего» для нас означает: сначала требования (какие данные относятся к медданным, с какими подрядчиками нужно поручение, что должен доказывать журнал), затем – быстрый и удобный продукт внутри этих рамок.

Главное

• Телемед-платформа – это десять подсистем и комплаенс-обёртка вокруг них.
• Три вопроса к каждому компоненту: типовая технология, типичный сбой, есть ли здесь медданные.
• Один 20-минутный визит оставляет медданные в семи хранилищах; каждому нужны шифрование, контроль доступа, срок хранения и поручение.
• Видеоядро – WebRTC с DTLS-SRTP в российском облаке; надёжность важнее качества картинки, а допустимость решения определяет договор с оператором медиа.
• Обязательные российские блоки: ЕСИА, ФРМР/ФРМО, УКЭП, ФЭР и РЭМД ЕГИСЗ, рецепты по 1094н, чек по 54-ФЗ.
• Закладывайте бюджет не только на квадратики, но и на стрелки: синхронизация, СЭМД, хранение и аудит – главные статьи расходов.

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

• 152-ФЗ и врачебная тайна простым языком для продуктовых команд – правила, на которых держится обёртка.
• WebRTC для телемедицины – клинические подводные камни видеоядра.
• Модель стоимости телемед-платформы – во что эта карта обходится в разработке и эксплуатации.