Эталонная архитектура телемедицинского видео: полная картина

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

Кратко

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

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

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

Что такое эталонная архитектура и почему в её центре видео

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

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

Перед картой – одно определение, на котором держится всё остальное. Медданные в этой статье – это персональные данные о здоровье, специальная категория по ст. 10 152-ФЗ, и сведения, составляющие врачебную тайну по ст. 13 323-ФЗ: имя с диагнозом, лицо на видеозвонке, запись приёма, сам факт записи к психиатру. Врачебная тайна – уже сам факт обращения за помощью. Дальше всё измеряется медданными: каждый блок архитектуры проверяется одним вопросом – касается он медданных или нет? Подробно о том, что сюда попадает, – в статье 152-ФЗ и врачебная тайна простым языком.

Десять компонентов целиком

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

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

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

3. Медиасервер (SFU). Когда звонок соединился, видео обычно не идёт напрямую между устройствами. Оно идёт через медиасервер, почти всегда – Selective Forwarding Unit (SFU), который принимает видео каждого участника один раз и раздаёт всем, кому оно нужно. SFU – телефонистка звонка и блок, который несёт основную нагрузку. Почему SFU предпочтительнее альтернатив и как он ведёт себя на приёме один на один и в группе, разобрано в статье P2P, SFU и MCU для клиники; здесь это просто сердце схемы.

4. TURN-релей. Иногда два устройства не могут найти прямой путь друг к другу: мешает межсетевой экран клиники или домашний роутер прячет устройство за несколькими слоями трансляции адресов. Тогда медиа уходит на запасной путь – TURN-сервер (Traversal Using Relays around NAT), релей, до которого достают обе стороны и который пересылает их медиа. TURN похож на почтовое отделение, через которое идёт посылка, если передать её из рук в руки не получается. В закрытых больничных сетях заметная доля звонков идёт через TURN, поэтому это полноправный компонент, а не дополнение «на всякий случай». Сетевая механика – STUN, ICE и обход NAT – разобрана в разделе о видеостриминге, в статье NAT, STUN, TURN и ICE.

5. Конвейер записи. Когда приём записывают, что-то должно захватить потоки, свести их и записать на диск. Это одна из самых чувствительных частей системы: запись – долговечные медданные, которые лежат в хранилище ещё долго после звонка, и она плохо сочетается со сквозным шифрованием. Приказ Минздрава 193н не обязывает записывать консультации, но если запись сделана, она относится к сопутствующим материалам, которые хранятся один год (п. 49–51). Все сложности темы – в статье о записи клинических сессий.

6. Слой хранения. Записи, файлы, снимки анализов и переписка в чате должны где-то храниться – это шифрованное объектное хранилище и базы данных. Здесь лежит большая часть медданных платформы, и именно за ними охотятся злоумышленники: живой звонок – движущаяся цель, хранилище – сейф. С 1 июля 2025 года ст. 18 ч. 5 152-ФЗ прямо запрещает хранить персональные данные граждан РФ в зарубежных базах, поэтому слой хранения размещают в российском облаке; несколько провайдеров (Yandex Cloud, Cloud.ru, Selectel, MWS) имеют аттестаты для систем с уровнем защищённости УЗ-1. Подробнее – в статье о локализации данных и о том, где хранятся медданные.

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

8. Оплата. За визит кто-то платит: пациент картой или через СБП, страховая компания по полису ДМС, в части случаев ОМС. Платёжный тракт – это эквайринг (ЮKassa, CloudPayments, Т-Касса и другие) плюс онлайн-касса, потому что при оплате в интернете по 54-ФЗ нужен электронный чек. Задача архитектуры – держать данные карт и как можно больше деталей оплаты вне границы медданных: наименование услуги в чеке и назначение платежа формулируйте без диагноза.

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

10. Слой аудита. Последний слой не передаёт видео, но следит за всем, что происходит с данными: журнал аудита фиксирует, кто открыл какую сессию или запись, когда и откуда. Это журнал посетителей для данных о пациентах. И это не украшение: регистрация событий безопасности – отдельная группа мер в приказе ФСТЭК № 21, а приказ Минздрава 209н требует журналировать доступ к электронным медицинским документам.

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

Линия, которая важнее всего: граница медданных

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

Внутри границы действуют три правила. Это разные требования, хотя новички их постоянно смешивают.

Первое правило – договор. Каждый подрядчик, чей сервис стоит внутри границы, работает по поручению оператора – условию договора с медорганизацией по ст. 6 ч. 3 152-ФЗ: перечень данных и действий с ними, цели, обязанность соблюдать конфиденциальность, требования к защите по ст. 19 и обязанность сообщать оператору об инцидентах. Поручение – подписанное обещание, которое каждый подрядчик должен дать, прежде чем получит ключ от здания. Облако, TURN-провайдер, хранилище записей, транскрибация, покупной видеослой – каждый становится обработчиком по поручению, как только может коснуться медданных. Перед пациентом за них отвечает оператор, а подрядчик отвечает перед оператором (ч. 5 ст. 6). Мы придерживаемся консервативной позиции: оформлять поручение с каждым, через чьи серверы проходят медданные, даже если он видит их только в зашифрованном виде. Условия договоров разобраны в статье о поручении обработки ПДн и договорах с подрядчиками.

Второе правило – шифрование, и оно не заменяет первое. Каждый переход, который пересекает границу или переносит медданные внутри неё, должен быть зашифрован. WebRTC – технология, которой браузеры пользуются для видео реального времени, – шифрует медиа по умолчанию через DTLS-SRTP (IETF RFC 3711 и RFC 5763/5764); сигналинг идёт поверх TLS; данные в хранилище шифруются при хранении. Там, где модель угроз требует сертифицированных средств криптографической защиты (СКЗИ, приказ ФСБ № 378), на каналах между площадками и к государственным системам добавляют ГОСТ-TLS. Подробный разбор – в статье о шифровании для телемедицины. Для схемы важно другое: шифрование необходимо, но недостаточно. Поток может быть идеально зашифрован и всё равно нарушать закон, если подрядчик, который его передаёт, работает без поручения. Шифрование отвечает на вопрос «может ли кто-то подслушать?», а поручение – на вопрос «вправе ли этот подрядчик вообще касаться данных?».

Третье правило – территория. Всё, что хранит медданные, стоит в России: базы, объектное хранилище, бэкапы, журналы. За нарушение локализации по ч. 8 ст. 13.11 КоАП юрлицу грозит штраф до 6 млн ₽, за повторное – до 18 млн ₽. Медиасервер и TURN, через которые медданные только проходят, тоже держите в российском облаке: передача сведений о здоровье на зарубежный сервер – трансграничная передача спецкатегории ПДн, о которой нужно уведомить Роскомнадзор до её начала (ст. 12), и в видеотракте её проще вовсе не допускать.

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

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

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

Эту структуру задают 152-ФЗ и 323-ФЗ, а не мы

Граница – не правило Фора Софт: её форму диктуют закон и подзаконные акты. Статья 19 152-ФЗ обязывает оператора принимать правовые, организационные и технические меры для защиты персональных данных от неправомерного или случайного доступа, уничтожения, изменения, блокирования, копирования и распространения. Постановление Правительства № 1119 задаёт уровни защищённости УЗ-1…УЗ-4 (для данных о здоровье, специальной категории, уровень зависит от актуальных угроз и объёма), а приказ ФСТЭК № 21 перечисляет меры для каждого уровня. Эти меры почти один к одному ложатся на компоненты выше, поэтому хорошая архитектура и архитектура, соответствующая требованиям, выглядят одинаково.

Основную работу делают шесть групп мер из приказа № 21, и их полезно читать как архитектуру, а не как юридический текст. Идентификация и аутентификация субъектов доступа и управление доступом – это слой идентификации и доступа: к сессии получают доступ только те, кому положено. Регистрация событий безопасности – слой аудита: система фиксирует, что происходило с медданными. Обеспечение целостности информационной системы и персональных данных – резервные копии и защита записей в хранилище от неправомерного изменения. Обеспечение доступности – резервирование, переключение на запасную площадку и пул SFU, который выдерживает пик. Защита информационной системы, её средств, систем связи и передачи данных – шифрование на каждом переходе, те самые DTLS-SRTP и TLS. При таком прочтении меры – это просто блоки с рисунка 2; ещё одну группу, защиту среды виртуализации, во многом закрывает аттестованное облако на своём уровне.

Ещё два акта объясняют части схемы, которые выглядят как эксплуатация, а не безопасность. Приказ Минздрава 209н, действующий с 1 сентября 2026 года, требует для электронных медицинских документов подписи УКЭП, резервного копирования, журналирования доступа и хранения всех версий при исправлении. Поэтому резервированное хранилище и версионирование – часть архитектуры, а не довесок. А то, что доступность – одна из обязательных групп мер, объясняет, почему пул SFU проектируют с расчётом на масштабирование; это разобрано в статье о масштабировании клинического видео. Для государственных клиник с 1 марта 2026 года действует приказ ФСТЭК № 117 вместо № 17, а информационные системы медорганизаций включены в перечень типовых объектов критической информационной инфраструктуры (распоряжение № 360-р от 26.02.2026).

За изменениями в регулировании стоит следить. 24 июля 2026 года ФСТЭК опубликовала проект приказа на замену № 21 (regulation.gov.ru, № 169583). Он вводит показатель зрелости защиты, оценку защищённости до начала обработки, раз в три года и после каждого инцидента, меры для ИИ, контейнеров и API и отдельные требования к обработчикам. Для оценки «до начала обработки» понадобится ровно такая схема, как в этой статье. На 24 сентября 2026 года проект не подписан: считайте его ориентиром, а не законом, и проверьте статус, прежде чем ссылаться на сроки. Как это отражается на видео, мы отслеживаем в статье о требованиях к защите ПДн в 2026 году.

Три маршрута данных по схеме

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

Живой приём. Пациент входит через ЕСИА, врач – через SSO клиники; платформа заранее сверила врача с ФРМР. Клиент пациента включает камеру и микрофон и просит сигналинг-сервис установить звонок. Через сигналинг стороны обмениваются сетевыми кандидатами и ключами шифрования, медиа соединяется – в идеале напрямую с SFU, а если сеть не позволяет, через TURN-релей. SFU передаёт поток пациента врачу, а поток врача – пациенту. Каждое плечо зашифровано DTLS-SRTP, каждый сервер на пути стоит в российском облаке, внутри границы. Пока ничего не хранится: в этом сценарии данные только движутся.

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

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

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

Бюджет задержки по шагам

Архитектура должна ещё и ощущаться мгновенной, а у «мгновенного» есть число. Разговор в реальном времени ломается, когда задержка в одну сторону (время от события перед одной камерой до его появления на другом экране) становится слишком большой: люди начинают перебивать друг друга, и клиническая беседа теряет ритм. По широко используемому инженерному ориентиру, рекомендации ITU-T G.114, потолок для естественного общения – примерно 150 миллисекунд (мс) в одну сторону. Архитектура должна расходовать этот бюджет с умом. Сложим его для удачно размещённого звонка.

Захват + кодирование (клиент)   ≈  30 мс
Сеть до SFU                     ≈  40 мс   (пациент рядом с SFU)
Раздача на SFU                  ≈  10 мс
Сеть от SFU                     ≈  40 мс   (врач рядом с SFU)
Декодирование + показ (клиент)  ≈  20 мс
---------------------------------------------
Итого в одну сторону            ≈ 140 мс   (внутри бюджета 150 мс)

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

Свой, готовый или сборка – форма архитектуры та же

Резонный вопрос на этом этапе – строить всё самому или покупать. Ответ: форма архитектуры от этого решения не меняется, меняется лишь то, кто эксплуатирует каждый блок. Можно развернуть SFU самостоятельно на open-source проекте – mediasoup, Janus, LiveKit или Jitsi – в российском облаке: для медплатформ это основной путь. Можно взять готовый видеослой у российского вендора – Voximplant, SaluteJazz SDK, TrueConf (в том числе в варианте на собственных серверах), VK Звонки или Яндекс Телемост через их API. Подробно этот выбор разобран в статье Свой или CPaaS: строить видеослой или взять готовое решение. Но в любом случае эталонная архитектура требует одного: каждый компонент, который вы не эксплуатируете сами, всё равно должен стоять по правильную сторону границы. Управляемый сервис, который не работает по поручению или хранит записи и журналы за рубежом, не может находиться внутри вашей границы медданных, а значит, через него нельзя проводить приёмы.

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

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

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

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

Главное

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

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

• Архитектура комплаенса: как встроить требования 152-ФЗ и 323-ФЗ в видеостек
• Свой или CPaaS: строить видеослой на mediasoup/Janus/LiveKit или взять готовое решение
• Масштабирование клинического видео: регионы, мощности и пики нагрузки