Запуск телемед-платформы: что проверить заранее

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

Кратко

Чек-лист запуска – единый документ, по которому команда проходит перед выходом в прод. В нём шесть разделов: комплаенс и право, безопасность, надёжность видео в реальном времени, интеграции, доступность и эксплуатация. Относитесь к запуску как к набору проверок «прошёл/не прошёл», а не как к дате в календаре: если хоть одна проверка не пройдена, запуск откладывается, потому что в здравоохранении пропущенный контроль – это риск для пациента или юридическая проблема, а не просто баг. В России самые дорогие ошибки запуска не технические: лицензия, в которой нет нужной специальности, врач, которого нет в ФРМР, неподключённая ЕСИА, протоколы, не доходящие до РЭМД, неподписанное поручение с подрядчиком, база с персональными данными за рубежом или SDK аналитики, который незаметно видит медданные. В статье – пошаговый чек-лист по разделам, от лицензии и ЕГИСЗ до 152-ФЗ, раскрытия информации по п. 37 приказа 193н, договора по ПП 659 и чеков по 54-ФЗ, его одностраничная PDF-версия и первоисточник за каждым пунктом. Тогда день запуска станет контролируемым событием, а не лотереей.

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

Вы построили платформу, протестировали её и провели пилот. Последний шаг перед тем, как от неё начнут зависеть реальные пациенты, – самый рискованный: всё, что было теорией (настоящие 24 часа на уведомление Роскомнадзора, настоящая проверка, настоящий пациент со скринридером), становится реальностью одновременно. Статья – для основателя, продакт-менеджера или техлида, которому нужен один надёжный документ, чтобы ответить на вопрос «мы действительно готовы?» и отстоять это решение перед советом директоров, клиникой-партнёром или проверяющим. Это завершающая статья курса «Телемедицина и медицинское видео»: она сводит готовность по 152-ФЗ и 323-ФЗ, аудит доступности, обеспечение надёжности и ранбук эксплуатации в одну последовательность действий перед выходом в прод. Если всё сделать правильно, запуск пройдёт скучно, а для клинического ПО это высшая похвала.

Что такое чек-лист запуска и чем он не является

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

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

На двух понятиях держится вся статья, поэтому определим их сразу.

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

Второе – поручение обработки: договор, по которому подрядчик обрабатывает персональные данные от имени и в целях оператора (ст. 6 ч. 3 152-ФЗ). В поручении – перечень данных и действий, цели, обязанность хранить конфиденциальность, требования к защите по ст. 19 и обязанность сообщать оператору об инцидентах. Это письменные обязательства подрядчика, принятые до того, как он получит ключи от здания. Третьего не дано: подрядчик, который может увидеть медданные, либо работает по подписанному поручению, либо не должен их видеть. Варианта «почти оформлено» нет.

Запуск – по готовности, а не по дате

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

Правильный запуск идёт поэтапно, а не одним щелчком. Вы движетесь от внутреннего теста к небольшому пилоту с реальными пациентами под пристальным наблюдением, затем к ограниченному запуску и к общему доступу. Между этапами – точка решения go/no-go, и на случай, если этап пошёл не так, есть отрепетированный откат. Поэтапный процесс разобран в статье о пилотах, клинической валидации и внедрении; чек-лист запуска вы проходите перед первым реальным пациентом и снова, в облегчённом виде, перед каждым кольцом расширения.

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

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

Раздел 1. Комплаенс и право

Этот раздел срывает больше запусков, чем любой другой, и почти никогда по техническим причинам. В России он длиннее, чем во многих зарубежных чек-листах, потому что телемедицина здесь – отдельно регулируемый вид медицинской помощи (ст. 36.2 323-ФЗ, приказ Минздрава 193н), завязанный на государственные системы.

Роли определены письменно. Кто медицинская организация – лицензиат, чьи врачи консультируют, и оператор медданных, а кто ИТ-компания, обрабатывающая данные по её поручению? От ответа зависит всё остальное: чья лицензия, чьё уведомление в Роскомнадзор, кто подписывает поручения. Как определить роли – в статье о 152-ФЗ и врачебной тайне.

Лицензия покрывает то, что вы продаёте. Отдельной «лицензии на телемедицину» нет: консультации с применением телемедицинских технологий оказываются только по работам и услугам, включённым в лицензию на медицинскую деятельность (п. 4 193н; ПП 852). Критерий: каждая специальность, которую предлагает продукт, есть в лицензии, у каждого врача – аккредитация специалиста (ПП 852 п. 5 «в»).

ФРМР и ФРМО. Врач-консультант должен быть в Федеральном регистре медицинских работников, организация – в Федеральном реестре медицинских организаций (п. 9 193н); это и лицензионное требование (ПП 852 п. 5 «ж»). Критерий: сверка выполнена для каждого врача до того, как он получит слоты в расписании.

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

ЕГИСЗ и РЭМД. Протокол телемедицинской консультации и запрос на неё передаются в федеральную электронную регистратуру ЕГИСЗ в течение 1 рабочего дня, сведения об электронных медицинских документах регистрируются в РЭМД тоже за 1 рабочий день (Положение о ЕГИСЗ, ПП 140). Частные клиники – такие же поставщики сведений, как государственные: размещение сведений в ЕГИСЗ входит в лицензионные требования (ПП 852 п. 6 «е»), а Минздрав в письме от 23.08.2023 подтвердил обязанность частных клиник передавать СЭМД в РЭМД. Критерий: передача протокола работает от начала до конца через выбранный канал – МИС, региональную систему или иную информационную систему.

152-ФЗ. Медорганизация обрабатывает медданные в медицинских целях без отдельного согласия (ст. 10 ч. 2 п. 4), но немедицинскому оператору платформы нужно письменное согласие пациента, и с 1 сентября 2025 года оно оформляется отдельно от оферты и политики. Критерии: уведомление Роскомнадзора о начале обработки подано (ст. 22; за неуведомление – 100–300 тыс. ₽, ч. 10 ст. 13.11 КоАП); поручение подписано с каждым подрядчиком, который может увидеть медданные; все базы с персональными данными – в России (ст. 18 ч. 5, с 1 июля 2025 года); модель угроз, уровень защищённости по ПП 1119 и меры приказа ФСТЭК № 21 задокументированы. Подробно о договорах – в статье о поручении обработки ПДн.

Реагирование на утечку готово заранее. Если данные пациентов утекли, по 152-ФЗ начинается отсчёт: уведомить Роскомнадзор нужно в течение 24 часов, а итоги внутреннего расследования сообщить в течение 72 часов с момента выявления инцидента – оператором, Роскомнадзором или иным заинтересованным лицом (ст. 21 ч. 3.1). Подрядчик по поручению обязан сообщить оператору об инциденте – пропишите в договоре срок в часах, а не в днях. Критерий – не «была ли у нас утечка», а «если она случится в 2 часа ночи в первый же день, расписано ли в письменном отрепетированном плане, кто и что делает?». Подробно – в статье о реагировании на инциденты и уведомлении об утечках.

Посчитаем на примере: эти сроки команды обычно недооценивают. Допустим, алерт о публично доступном хранилище записей сработал в пятницу, 13 ноября 2026 года, в 21:30 – это момент выявления. Первичное уведомление Роскомнадзора нужно подать до субботы, 21:30; итоги расследования – до понедельника, 16 ноября, 21:30. Это 72 календарных, а не рабочих часа: выходные отсчёт не останавливают. Если ту же утечку вы «выявили» лишь в понедельник утром, потому что письмо исследователя пролежало все выходные, вы не выиграли три дня, а оказались в невыгодной позиции в споре о моменте выявления. За неуведомление юрлицу грозит 1–3 млн ₽ (ч. 11 ст. 13.11 КоАП), за саму утечку данных о здоровье – 10–15 млн ₽ (ч. 16).

Пациенту раскрыто всё, что требует 193н. На сайте или в приложении до консультации опубликованы (п. 37 193н): лицензия; ФИО, образование, стаж и категория консультанта; оператор информационной системы и место хранения материалов; порядок получения информированного добровольного согласия и согласия на обработку ПДн; порядок идентификации через ЕСИА; стоимость; возможность анонимной или псевдонимизированной платной консультации. Это единственный пункт, который любой желающий проверит без доступа к вашим системам.

Договор и оплата. С 1 сентября 2026 года платные медицинские услуги регулируют правила ПП 659. Они прямо разрешают заключать договор дистанционно на сайте или в мобильном приложении медорганизации и требуют до подписания раскрыть пациенту ОГРН, ИНН, сведения о лицензии, порядок и способы оплаты и адрес для претензий; смета может быть твёрдой или приблизительной (п. 25). Онлайн-оплата требует применения контрольно-кассовой техники и электронного чека (54-ФЗ, ст. 1.2), обычно через облачную кассу. Если клиника участвует в ОМС, телемедицина оплачивается по отдельному тарифу из тарифного соглашения (ПГГ, ПП 2188); ДМС работает по договорам со страховщиками. Подробно – в статье об оплате телемедицины.

Клинические ограничения встроены в продукт. В режиме «врач – пациент» без очного приёма поставить диагноз нельзя: заключение может содержать только рекомендации по обследованию перед очным приёмом (п. 40 193н). Скорректировать лечение и выписать рецепт в форме электронного документа можно, только если диагноз поставлен и лечение назначено на очном приёме по данному обращению (п. 38–39; рецепты – по приказу 1094н, с УКЭП врача). Дистанционное наблюдение назначается только после очного приёма (ч. 4 ст. 36.2). Критерий: эти правила заложены в модель данных и интерфейс, а не только в памятку для врачей. Подробно – в статье о лицензии, аккредитации и рецептах.

Раздел 2. Безопасность

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

Шифрование при передаче и хранении. Каждый участок, по которому идут медданные, зашифрован, а хранимые записи, документы и поля БД зашифрованы при хранении. Медиа в WebRTC шифруется по стандарту (DTLS-SRTP). Нужны ли сертифицированные ФСБ средства криптографической защиты (СКЗИ) и ГОСТ-алгоритмы, определяют модель угроз и уровень защищённости (приказ ФСБ № 378); см. статью о шифровании и том, где нужны ГОСТ и СКЗИ.

Аутентификация и контроль доступа. Пациенты и врачи подтверждают личность до того, как получат доступ к медданным; многофакторная аутентификация включена для каждой учётной записи врача и администратора. Доступ – по минимуму: каждая роль видит только то, что ей нужно (группы мер ИАФ и УПД приказа ФСТЭК № 21).

Журнал регистрации событий ведётся и разбирается. Система записывает, кто, когда и к данным какого пациента обращался (ст. 19 ч. 2 п. 8 152-ФЗ; меры РСБ), и кто-то действительно разбирает эти записи. Пустой или непрочитанный журнал хуже, чем никакой: он создаёт видимость контроля, которого нет. См. журналы аудита и контроль доступа.

Эксплуатационные логи не содержат медданных. Этот пункт проваливают незаметно. Краш-отчёты, трейсы и события аналитики очищены: только непрозрачные ID, без ФИО, диагнозов и номеров полисов в URL и текстах ошибок (неизбыточность, ст. 5 ч. 5 152-ФЗ), а весь стек мониторинга развёрнут в России.

Эффективность мер оценена до ввода в эксплуатацию. Это прямо названо в законе: оценка эффективности мер по обеспечению безопасности персональных данных проводится до ввода информационной системы в эксплуатацию (ст. 19 ч. 2 п. 4 152-ФЗ). На практике – внешний скан уязвимостей и пентест, серьёзные находки закрыты, облако имеет аттестат под ваш уровень защищённости. Для систем государственных медорганизаций с 1 марта 2026 года действует приказ ФСТЭК № 117. См. тестирование клинического видео.

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

Раздел 3. Надёжность видео в реальном времени

Телемед-звонок – не обычный видеозвонок. Когда он зависает, врач может пропустить симптом, а недоступность платформы – тоже вопрос защиты данных: 152-ФЗ требует защищать персональные данные и от блокирования (ст. 19 ч. 1), а приказ 193н задаёт сроки консультаций, для экстренной – от 30 минут до 2 часов (п. 19). Поэтому надёжность – требование не только инженерное, но и юридическое.

Клиническая планка держится в плохих условиях. Тестируйте качество звонка не на офисном Wi-Fi, а в сетях, которыми реально пользуются пациенты: слабый домашний интернет, мобильная связь в райцентре, старый ноутбук. Планка задана в статье о задержке, качестве и клинической планке «достаточно хорошо». Критерий: консультация остаётся клинически пригодной и на плохой сети, а не только на идеальной.

Переподключение и плавная деградация работают. Сети рвутся. Звонок должен сам восстанавливаться, когда пациент переходит с Wi-Fi на мобильную сеть, и деградировать плавно – отключая видео раньше аудио, – а не падать. См. надёжность соединения, реконнект и деградацию.

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

Запись, если вы её предлагаете, законна. Записи – это медданные. Их делают только по согласию, хранят в России в зашифрованном виде, доступ к ним ограничен. 193н не обязывает записывать консультации, но если запись сделана, она относится к сопутствующим материалам и хранится 1 год (п. 49–51). Подробно – в статьях о записи клинических сессий и эталонной архитектуре телемед-видео.

Раздел 4. Интеграции

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

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

Обмен клиническими данными идёт по стандарту и проверен на реалистичных данных. Электронные медицинские документы для РЭМД – СЭМД, XML на базе HL7 CDA R2; там, где МИС или интеграционная платформа это поддерживает (например, N3.Health), – HL7 FHIR. Критерий – не «интеграция собирается», а «документ тестового пациента проходит весь путь, включая ошибки и повторную отправку». Механика – в статье об HL7 FHIR, СЭМД и интеграции с МИС.

Чек и уведомления не раскрывают лишнего. Чек проходит через оператора фискальных данных, SMS и push – через провайдеров рассылок. Формулировку услуги в чеке согласуйте с юристом, а текст уведомлений делайте нейтральным: «Ваш приём подтверждён», а не «Ваш приём у психиатра подтверждён».

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

Раздел 5. Доступность

Доступность – не «приятное дополнение» на потом. Аудитория телемедицины – пожилые пациенты, люди со слабым зрением и слухом, пациенты с маленькими экранами – делает её обязательным минимумом.

Ориентир – ГОСТ Р 52872-2019 «Интернет-ресурсы и другая информация, представленная в электронно-цифровой форме. Приложения для стационарных и мобильных устройств, иные пользовательские интерфейсы. Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности». Он построен на международных Web Content Accessibility Guidelines (WCAG) 2.1 с уровнями A, AA и AAA. Стандарт добровольный, но 181-ФЗ закрепляет общую обязанность обеспечивать людям с инвалидностью доступность услуг, а уровень AA – общепринятая планка для удобного цифрового продукта.

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

Раздел 6. Эксплуатация

С первого дня платформа должна быть готова к эксплуатации, а не просто работать на демо.

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

Дежурства и эскалация налажены. Кто-то получает вызов, когда визиты начинают срываться; дежурство покрывает время, когда пациенты реально пользуются продуктом (вечера, ночи, 11 часовых поясов). Поток данных дистанционного наблюдения, где врач задал пороги и обязан реагировать (п. 43–46 193н), и путь при кризисе к 112, 103 и телефонам доверия имеют собственные мониторы высшего приоритета, отказ которых не может пройти незамеченным.

Обнаружение инцидентов связано со сроками Роскомнадзора. Мониторинг – первая линия выявления утечек. Момент, когда должен был сработать алерт, может стать моментом выявления, поэтому алерт запускает задокументированную цепочку «выявить – сдержать – оценить – уведомить за 24 часа – отчитаться за 72», а не письмо, которое никто не читает.

Откат отрепетирован. У вас есть проверенный способ откатить неудачный релиз, и вы его репетировали. Откат, который ни разу не запускали, – надежда, а не план.

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

Подрядчики, которые могут заблокировать запуск: сводная таблица

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

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

Частая ошибка: незаметная утечка медданных

Классическая ошибка, которая всплывает в последний момент, – не падение системы. Это бесплатный SDK веб-аналитики с записью сессий, добавленный в приложение пациента несколько месяцев назад. Он незаметно записывает экран – визит, чат, диагноз – и отправляет запись третьей стороне без поручения, а если её серверы за рубежом, то ещё и в зарубежную базу вопреки ст. 18 ч. 5. На демо всё выглядит нормально, платформа «зашифрована», но в момент, когда ею пользуется реальный пациент, это уже нарушение: зашифрованные данные, отправленные без основания, всё равно переданы без основания. Чек-лист запуска ловит такие случаи, потому что заставляет проверить каждый исходящий поток данных и для каждого ответить «да» или «нет», а не полагаться на то, что очевидные подрядчики – единственные.

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

Фора Софт с 2005 года строит продукты с видео в реальном времени – видеоконференции, стриминг, видеонаблюдение, e-learning и телемедицину, – поэтому клинический запуск для нас прежде всего событие комплаенса и лишь затем релиз. Мы помогаем командам пройти именно эту проверку: развести роли медорганизации и ИТ-подрядчика, подключить ЕСИА и передачу документов в ЕГИСЗ, замкнуть цепочку поручений и держать все базы в российской инфраструктуре. А также убедиться, что видео держится в сетях, которыми реально пользуются пациенты, интерфейс соответствует WCAG 2.1 AA и ГОСТ Р 52872-2019, а наблюдаемость и обнаружение утечек подключены до того, как соединится первый пациент. Сначала требования, потом функциональность.

Главное

• Чек-лист запуска – единая проверка готовности по шести разделам; запуск определяет она, а не дата.
• Хоть один красный раздел – no-go: в здравоохранении пропущенный контроль – юридический риск или риск для пациента.
• Самые дорогие блокеры нетехнические: лицензия без нужной специальности, врач вне ФРМР, неподключённая ЕСИА, протоколы не в РЭМД, неподписанное поручение, база за рубежом.
• Пациенту до консультации раскрыто всё по п. 37 193н, договор – по ПП 659, чек – по 54-ФЗ; поставить диагноз без очного приёма продукт не позволяет.
• До запуска свяжите обнаружение инцидентов со сроками Роскомнадзора: 24 часа на уведомление, 72 – на итоги, отсчёт с момента выявления.
• Запускайте кольцами с точками go/no-go и отрепетированным откатом.

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

• Чек-лист готовности по 152-ФЗ и 323-ФЗ и подготовка к проверкам
• Пилоты, клиническая валидация и развёртывание
• Наблюдаемость и эксплуатация живой телемед-платформы