Частые ошибки в защите медданных при разработке телемед-продуктов

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

Кратко

Чаще всего медданные в телемедицине утекают не из-за взломов, а из-за обычных инженерных и организационных решений, которые незаметно переносят данные пациента туда, где им быть нельзя: хелпдеск с серверами за рубежом, диагноз в URL, запись консультации в открытом бакете, расшифровка приёма через зарубежный ИИ-API, согласие, спрятанное в оферте. Российское право оценивает эти ошибки вполне конкретно: утечка сведений о здоровье обойдётся юрлицу в 10–15 млн ₽ (ч. 16 ст. 13.11 КоАП), повторная – в 1–3% выручки, но не меньше 25 млн ₽, хранение данных россиян в зарубежной базе – до 6 млн ₽, неуведомление Роскомнадзора об утечке – 1–3 млн ₽. Каждая из десяти ошибок нарушает конкретную норму (152-ФЗ «О персональных данных», ст. 13 и 36.2 323-ФЗ о врачебной тайне и телемедицине или приказ Минздрава 193н), и для каждой есть известное инженерное решение. По каждой ошибке разобрано, как она выглядит в реальном продукте, какую норму нарушает, во что обходится и как её исправить; в конце – одностраничный чек-лист аудита для вашего стека.

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

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

Утечки, которые команда создаёт сама

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

Теперь главное определение. Инцидент по ст. 21 ч. 3.1 152-ФЗ – это установленный факт неправомерной или случайной передачи (предоставления, распространения, доступа) персональных данных, повлёкшей нарушение прав субъектов. Обратите внимание: умысла в этой формулировке нет. Для инцидента не нужны хакер, вор или мотив. URL, который уносит диагноз в стороннюю аналитику, – это передача. Запись в бакете, который может прочитать кто угодно, – доступ. И неважно, что виновата настройка по умолчанию.

Теперь о том, что следует за инцидентом. Об утечке оператор уведомляет Роскомнадзор дважды: в течение 24 часов – о факте, предполагаемых причинах, вреде и принятых мерах, в течение 72 часов – о результатах внутреннего расследования (порядок – приказ Роскомнадзора № 187). Отсчёт идёт с момента выявления (вами, регулятором или посторонним исследователем, который нашёл ваш бакет), а не с момента, когда ошибку исправили. Как считать эти сроки, мы разбирали в статье «152-ФЗ и врачебная тайна простым языком».

Дальше в дело вступает КоАП. Штрафы ст. 13.11 в редакции 420-ФЗ действуют с 30 мая 2025 года; вот составы, которые чаще всего встречаются в этой статье:

Таблица 1. Штрафы за ошибки из этой статьи. Для оборотных штрафов закон предусматривает смягчение, если компания три года тратила на информационную безопасность не менее 0,1% выручки; скидка 50% за быструю оплату к ним не применяется.

Кроме того, с 11 декабря 2024 года действует ст. 272.1 УК РФ: уголовная ответственность за незаконные использование, передачу, сбор и хранение компьютерной информации с персональными данными.

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

«Утечка сведений о здоровье (ч. 16): 10–15 млн ₽ – вилка не зависит от числа записей. Неуведомление в срок (ч. 11): + 1–3 млн ₽. База за рубежом (ч. 8): + до 6 млн ₽. Итого: до 24 млн ₽ возможных штрафов за первый эпизод.»

Если утечка спецкатегорий повторится, применяется ч. 18. Для компании с выручкой 2 млрд ₽ в год:

«2 000 млн ₽ × 1% = 20 млн ₽, это меньше минимума, поэтому штраф поднимается до 25 млн ₽; 2 000 млн ₽ × 3% = 60 млн ₽. Вилка: 25–60 млн ₽ – за одну повторную утечку.»

Как суд квалифицирует составы и соотнесёт их между собой, оценивают юристы; расчёт показывает порядок величин, а не прогноз. К этому добавляются расходы, о которых КоАП молчит: расследование, требования о компенсации морального вреда (ст. 24 152-ФЗ), замороженные переговоры с сетями клиник и страховщиками ДМС.

И последний элемент рамки. Договор, по которому подрядчик законно обрабатывает данные пациентов по заданию клиники, называется поручением оператора на обработку персональных данных (ст. 6 ч. 3 152-ФЗ); подрядчик подписывает его до того, как получит доступ к данным. Есть ли поручение – первый вопрос с ответом «да» или «нет». Второй – где физически лежит база: с 1 июля 2025 года базы с данными россиян за рубежом прямо запрещены (ст. 18 ч. 5). Половина ошибок ниже сводится к одному: медданные попали в систему, которая либо ничего не подписывала, либо находится не в той стране.

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

Первая группа: данные не в той стране

Ошибка 1. Зарубежные SaaS с данными пациентов

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

С 1 июля 2025 года это прямой запрет: запись, систематизация, накопление, хранение, уточнение и извлечение персональных данных граждан России с использованием баз данных за рубежом не допускаются (ст. 18 ч. 5 152-ФЗ в редакции 23-ФЗ; узкие исключения – п. 2, 3, 4 и 8 ч. 1 ст. 6). Штраф – до 6 млн ₽, повторно – до 18 млн ₽ (ч. 8 и 9 ст. 13.11 КоАП). Если данные всё же уходят за границу, это ещё и трансграничная передача: до её начала оператор уведомляет Роскомнадзор и оценивает получателя, а регулятор вправе передачу запретить или ограничить (ст. 12). Плюс ст. 6 ч. 6: если обработчик – иностранное лицо, перед пациентом отвечают и оператор, и обработчик.

Решение. Составьте перечень всех внешних сервисов, куда хоть что-то уходит из продукта, причём по исходящему трафику, а не по памяти команды. Для каждого задайте два вопроса: попадают ли туда медданные (включая IP, URL и ID в связке с пациентом) и где лежит база. Всё, что касается медданных, должно оставаться в российском контуре: аттестованные облака (Yandex Cloud, Cloud.ru, Selectel, MWS – с аттестатами на УЗ-1), open-source-стек на своих серверах (Prometheus и Grafana для метрик, собственный стек логов и трекер ошибок) или российский сервис по поручению, условия которого подтверждены письменно. Исходящий трафик продукта ограничьте белым списком адресов, чтобы новый SDK не мог без ревью отправлять данные своему разработчику. Подробно о том, что всё-таки можно отправлять за рубеж, – в статье о локализации и трансграничной передаче.

Ошибка 2. Личные мессенджеры для общения с пациентами

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

Ошибка нарушает сразу три требования. Первое – локализация и трансграничная передача: серверы большинства популярных мессенджеров находятся за рубежом, и медданные там хранятся вне контроля оператора (ст. 18 ч. 5 и ст. 12). Второе – врачебная тайна (ст. 13 323-ФЗ): переписка хранится на личном телефоне, в облачной резервной копии, на общем семейном планшете, и клиника не может ни ограничить к ней доступ, ни удалить её. Третье – требования к самой телемедицине. Консультация с применением телемедицинских технологий требует идентификации участников через ЕСИА и документирования с усиленной квалифицированной электронной подписью (УКЭП) медработника (ч. 6–7 ст. 36.2 323-ФЗ, п. 7 и 48 приказа 193н), а сопутствующие материалы (сообщения, изображения, записи) хранятся год (п. 49–51). Переписка в личном мессенджере не обеспечивает ничего из этого: это не телемедицинская консультация, а разговор, который нельзя ни подтвердить, ни защитить.

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

Ошибка 3. Медданные в зарубежных ИИ-API

Новая ошибка 2025–2026 годов. Команда подключает ИИ-скрайба: аудио консультации уходит в зарубежный API распознавания речи, транскрипт – в зарубежную большую языковую модель, которая пишет черновик протокола. Или чат-бот на сайте собирает жалобы и отправляет их в зарубежную модель для маршрутизации. На демо всё выглядит впечатляюще. Юридически же это трансграничная передача специальной категории персональных данных (ст. 12) провайдеру, у которого нет ни поручения, ни базы в России, а если провайдер хоть что-то сохраняет, то и нарушение локализации (ст. 18 ч. 5). К тому же крупнейшие зарубежные провайдеры языковых моделей официально недоступны в России, и заключить с ними договор с условиями обработки не получится.

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

Есть и другая сторона. Если функция ставит диагноз или подсказывает его врачу, она может оказаться медицинским изделием: программное обеспечение регистрируется в Росздравнадзоре по правилам ПП 1684, а ПО с искусственным интеллектом по классификации Минздрава (приказ 4н от 06.06.2012, п. 15.1.1) всегда относится к классу 3. Приказ 193н прямо допускает системы поддержки принятия врачебных решений на базе ИИ в отложенных консультациях, но только зарегистрированные как медизделия (п. 15–17).

Решение. ИИ-функции с медданными стройте на российских провайдерах по поручению и с данными в России – GigaChat, Alice AI в Yandex AI Studio, SaluteSpeech, Yandex SpeechKit (в том числе в on-prem-варианте) – или на open-source-моделях (Whisper и другие) на ваших серверах, где данные вообще не покидают контур. Так уже работают: в поликлиниках Москвы ИИ-помощник расшифровывает разговор и заполняет протокол приёма, а врач проверяет и подписывает результат. Где кончается помощь в документировании и начинается диагноз, решите до первой строки кода; подробно – в статье о слое комплаенса и безопасности клинического ИИ.

Вторая группа: медданные там, где им не место

Ошибка 4. Медданные в URL, логах, аналитике и уведомлениях

Самая «инженерная» ошибка, причём сразу в четырёх каналах. Механизм везде один: медданные попадают в систему, которую никто не проектировал как хранилище медданных.

URL. Диплинк на приём – /visit?patient=ivanova&clinic=onkologiya, страница результатов – /results?test=hiv&outcome=positive, приглашение в календарь содержит ?dx=F32.1 (код депрессивного эпизода по МКБ-10). Приложение работает, демо проходит отлично. Но URL, который инженеры считают просто адресом, теперь стал клинической записью. А это самая копируемая строка в интернете: она оседает в истории браузера на общем семейном компьютере, в access-логах веб-сервера и CDN, в заголовке Referer, который уходит любому стороннему скрипту на следующей странице, в событиях аналитики и на скриншоте, который пациент прикладывает к обращению в поддержку. Одно нажатие – пять копий, и ни одну нельзя удалить по требованию.

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

Логи, краш-репорты и тестовые копии. Привычка «логируй всё, при отладке пригодится» порождает строки вида POST /api/messages patient=88321 body="У меня суицидальные мысли", потому что сервис чата при ошибке пишет тела запросов. Краш-репортер сериализует объекты из памяти, а в телемед-приложении объекты в памяти – это пациенты. Рядом стоит копия рабочей базы в тестовой среде, сделанная, «чтобы тестирование было как в жизни»: общие пароли, открытые отладочные эндпоинты, доступ у каждого подрядчика. Логи и тестовые копии с медданными – такие же информационные системы персональных данных, как основная база: на них распространяются модель угроз, уровень защищённости и меры по ПП 1119 и приказу ФСТЭК № 21. Принцип минимизации (ст. 5 152-ФЗ) запрещает обрабатывать данные, избыточные для цели, а для отладки текст жалобы не нужен. Удалённая колонка с ФИО – ещё не обезличивание: время приёмов, свободный текст и ссылки на записи определяют человека не хуже имени.

Аналитика. Стандартный маркетинговый набор (веб-аналитика, рекламные пиксели, запись сессий) по самой своей природе передаёт данные вендору. В телемед-продукте эти данные выглядят так: «пользователь X, опознанный по IP, ID устройства и cookie, смотрел страницу препаратов от тревожности и записался к психиатру». Это передача медданных третьему лицу без основания, а если вендор зарубежный, ещё и трансграничная передача. Нарушение заложено уже в настройках по умолчанию: исследование в JAMA Network Open (2019) по 36 популярным приложениям для помощи при депрессии и отказа от курения показало, что 29 из них передавали данные сторонним сервисам аналитики и рекламы, а раскрывали это лишь 12.

Push, SMS и письма. Push-уведомление появляется на экране блокировки, и его видит любой, кто взглянул на телефон на кухонном столе или больничной тумбочке. «Результаты теста на ВИЧ готовы». «Пора продлить рецепт на литий». «Сеанс психотерапии через 15 минут». Каждое такое уведомление раскрывает врачебную тайну всем, кто оказался рядом, и делает это ваш продукт, потому что так он спроектирован. Инфраструктура добавляет проблем: уведомление проходит через push-сервисы платформ (APNs у iOS, FCM у Android), то есть через зарубежных посредников, которые ничего вам не обещали. Письмо «Психиатрия, повторный приём, четверг 15:00» раскрывает факт обращения каждому, кто заглянул через плечо или администрирует почтовый сервер, а SMS передаётся открытым текстом через сеть оператора и SMS-агрегатора.

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

Решение – по одному правилу на канал. URL: считайте адреса публичными. Идентификаторы в путях – непрозрачные (/visit/9f3k2x), клинический контекст – в телах POST или аутентифицированных ответах API, диплинки – через короткоживущие подписанные токены, на каждой закрытой странице – Referrer-Policy: no-referrer. Проверка в CI, которая ищет в описаниях маршрутов параметры с именами вроде dx, diagnosis, test, med, пишется за час и закрывает целый класс утечек.

Логи: пишите ссылки, а не содержимое: ID пользователя и сессии, имя события, код результата; сами данные сотрудник с правом доступа смотрит в исходной системе (правило из статьи о журналах аудита). Второй уровень защиты – middleware, который вырезает известные чувствительные поля, третий – стек логов и трекер ошибок внутри российского контура. В тестовых средах – синтетические пациенты, а там, где нужна структура реальных данных, – корректно обезличенная выгрузка с описанным методом (правила – в статье об обезличивании и аналитике).

Аналитика: внешние счётчики и пиксели стоят только на публичном маркетинговом сайте, где пациент ещё не вошёл в систему, и отключаются после входа. Внутри продукта – собственный конвейер событий в российском контуре (например, на ClickHouse) с событиями без клинического контекста: имена событий и непрозрачные ID, без свободного текста и без свойств, выдающих диагноз.

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

Ошибка 5. Записи консультаций в открытых бакетах

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

Нормы здесь уже знакомые. Публично доступный файл – это «случайный доступ» в смысле ст. 21 ч. 3.1, то есть инцидент со сроками 24 и 72 часа с момента выявления, причём выявить его может кто угодно, включая исследователя, который ищет открытые бакеты автоматически. Утечка сведений о здоровье – ч. 16 ст. 13.11 КоАП, 10–15 млн ₽. Меры ст. 19 ч. 2 (правила доступа, регистрация всех действий с данными, учёт носителей, обнаружение несанкционированного доступа) – как раз то, чего у «временного» бакета нет. А п. 37 193н требует раскрыть пациенту на сайте или в приложении оператора информационной системы и место хранения материалов: архитектура хранения становится публичной, и бакет «не в том месте» сразу заметен.

Решение. Записи хранятся в объектном хранилище аттестованного российского облака и шифруются ключами под вашим управлением (KMS). Публичный доступ к бакетам закрыт и политикой, и запретом на уровне аккаунта или организации, чтобы разработчик не мог открыть отдельный бакет. Доступ – только через короткоживущие подписанные ссылки от вашего API, никогда через долгоживущие: долгоживущая ссылка – тот же пароль в адресной строке, то есть повторение ошибки 4. Каждое чтение регистрируется в журнале. Сроки хранения определены письменным графиком: запись, которую больше не требуется хранить, несёт только риск. Правила согласия и сроков – в статье о согласии, записи и хранении, шифрование – в статье о шифровании, ГОСТ и СКЗИ.

Третья группа: документы, без которых обработка незаконна

Ошибка 6. Согласие, спрятанное в оферте

Привычный экран регистрации: одна галочка «Принимаю условия оферты, политики конфиденциальности и даю согласие на обработку персональных данных». До осени 2025 года так делали почти все. С 1 сентября 2025 года согласие на обработку персональных данных оформляется отдельно от иных документов – оферт, политик, договоров (ст. 9 ч. 1 в редакции 156-ФЗ). Для данных о здоровье есть второе требование. Если у вас нет медицинского основания – обработки медицинскими работниками, обязанными хранить врачебную тайну, в медицинских целях (ст. 10 ч. 2 п. 4), – нужно согласие в письменной форме с обязательным содержанием по ст. 9 ч. 4; электронный документ с электронной подписью приравнивается к письменному.

Цена ошибки – не только штраф по ст. 13.11 КоАП. Главная цена в том, что всё собранное по «согласию» внутри оферты оказывается собранным без надлежащего основания. Исправлять приходится задним числом: заново запрашивать согласие у всей базы, а у тех, кто не ответил, прекращать обработку. Частый вариант той же ошибки – одно согласие «на всё»: на консультации, рассылки, аналитику и обучение моделей сразу.

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

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

Ошибка 7. Нет уведомления Роскомнадзора о начале обработки

Стартап рассуждает так: «мы маленькие», «мы просто софт», «медорганизации, кажется, освобождены». Все три довода не работают. Оператор обязан уведомить Роскомнадзор до начала обработки персональных данных (ст. 22 ч. 1); с сентября 2022 года исключения сузились до узких случаев вроде обработки без средств автоматизации, а медорганизации от уведомления не освобождены. Даже если по данным пациентов вы работаете как обработчик по поручению клиники, у вас почти наверняка есть данные, по которым вы сами оператор: свои пользователи-врачи, заявки с сайта, сотрудники. Неуведомление – ч. 10 ст. 13.11 КоАП, 100–300 тыс. ₽. Сведения из уведомлений попадают в реестр операторов Роскомнадзора, и крупные клиенты нередко проверяют его перед подписанием договора.

Инженерная сторона ошибки – в содержании уведомления. В нём описываются цели, меры защиты по ст. 18.1 и 19 (включая сведения о средствах шифрования), наличие трансграничной передачи и место нахождения базы данных с персональными данными граждан России (ст. 22 ч. 3). Значит, уведомление – снимок архитектуры. Переехали в другое облако, подключили подрядчика за рубежом, поменяли шифрование – сведения нужно обновить не позднее 15-го числа месяца, следующего за месяцем изменений (ст. 22 ч. 7). Уведомление, поданное один раз при запуске и забытое, через год описывает систему, которой уже нет.

Решение. Подайте уведомление до запуска и привяжите его к процессу изменений: пункт «затрагивает ли изменение уведомление РКН?» стоит в шаблоне архитектурного ревью рядом с «затрагивает ли модель угроз?». Владелец процесса – ответственный за организацию обработки персональных данных (ст. 18.1 и 22.1).

Ошибка 8. Нет поручений с подрядчиками

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

Поручение – не формальность: его обязательное содержание перечислено в законе (ст. 6 ч. 3). Это перечень персональных данных и действий с ними, цели, обязанность соблюдать конфиденциальность, требования к защите по ст. 19, обязанность уведомлять оператора об инцидентах и по запросу предоставлять документы о соблюдении требований. Обработчику не нужно собственное согласие пациента (ч. 4), но перед пациентом отвечает оператор, а обработчик – перед оператором (ч. 5); если обработчик – иностранное лицо, отвечают оба (ч. 6). Каждое звено, где медданные оказываются на чужой инфраструктуре, требует своих договорных условий, а людям подрядчика, которые могут увидеть врачебную тайну, нужны обязательства о её неразглашении (ст. 13 ч. 2 323-ФЗ).

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

Решение. Соберите реестр поручений по карте потоков данных: каждая стрелка из вашего кода в систему подрядчика – строка реестра с ответами на четыре вопроса. Касается ли подрядчик медданных? Лежат ли данные в России? Подписано ли поручение, когда и что оно покрывает? Каков срок уведомления об инцидентах в часах? Каждую строку с ответом «нет» закройте одним из двух способов: подпишите поручение или перепроектируйте поток так, чтобы подрядчик никогда не видел медданных. Что писать в договоре и кто его не подпишет – в статье о поручении обработки и договорах с подрядчиками.

Четвёртая группа: клиника и процессы

Ошибка 9. Диагноз по видео без очного приёма

Эта ошибка не про утечку, а про сам продукт. Команда, вдохновлённая зарубежными телемед-сервисами, проектирует сценарий «первичная онлайн-консультация → диагноз → электронный рецепт» – а в России так нельзя. Консультация «врач – пациент» допускается для профилактики, сбора жалоб и анамнеза, оценки эффективности лечения, наблюдения и решения о необходимости очного приёма (ч. 2 ст. 36.2 323-ФЗ). Скорректировать лечение дистанционно лечащий врач может, только если диагноз поставлен и лечение назначено им на очном приёме (ч. 3). Если очного приёма не было, заключение может содержать лишь рекомендации по обследованию перед очным приёмом: поставить диагноз дистанционно нельзя (п. 40 193н). Электронный рецепт по итогам телемедконсультации возможен только при коррекции лечения после очного приёма по данному обращению (п. 38–39).

Ошибка не только медицинская, но и инженерная, потому что правило реализуется в коде. Если шаблон заключения содержит поле «диагноз» в любой консультации, а кнопка «выписать рецепт» доступна всегда, продукт сам подталкивает врача к нарушению и тиражирует его на тысячи приёмов. Отвечать придётся медорганизации: телемедицина оказывается только по работам и услугам из её лицензии (п. 4 193н), Росздравнадзор проводит лицензионный контроль, а за нарушение лицензионных требований предусмотрена ответственность по ст. 14.1 ч. 3–4 КоАП. Послабления экспериментального правового режима по ПП 1164 не в счёт: режим установлен на три года с 1 августа 2023-го, и решения о его продлении после августа 2026 года мы в открытых источниках не нашли.

Решение. Заложите требования 193н в модель данных и интерфейс. У консультации есть тип и связь с обращением; признак «очный приём по этому обращению состоялся» приходит из медицинской информационной системы (МИС), а не из галочки врача. Без него в шаблоне заключения нет поля диагноза, только рекомендации по обследованию, а кнопка рецепта появляется лишь в сценарии коррекции лечения. Перед консультацией – идентификация через ЕСИА (п. 7), врач – в ФРМР, организация – в ФРМО (п. 9), заключение подписывается УКЭП. Подробно – в статьях о лицензии, аккредитации и рецептах и об электронных рецептах.

Ошибка 10. Нет плана реагирования на 24 и 72 часа

Любую из технических ошибок выше многократно усугубляет один процессный провал: утечка случилась, а никто не знает, что делать. Сроки ст. 21 ч. 3.1 отсчитываются с момента выявления, выходные не в счёт: 24 часа на первичное уведомление Роскомнадзора, 72 – на результаты внутреннего расследования. Параллельно идёт информирование ГосСОПКА: операторы с соглашением о взаимодействии сообщают в НКЦКИ в течение 24 часов, остальные – через Роскомнадзор (ст. 19 ч. 12, приказ ФСБ № 77). Если система медорганизации – значимый объект критической информационной инфраструктуры (КИИ), сообщить в НКЦКИ нужно не позднее 3 часов (приказ ФСБ № 547, с 30 января 2026 года). Неуведомление об утечке – отдельный состав: 1–3 млн ₽ (ч. 11 ст. 13.11).

Типичный провал выглядит так: открытый бакет нашёл исследователь в пятницу вечером, письмо пришло на общий ящик поддержки, его прочитали в понедельник, а клиника-оператор узнала о проблеме от журналиста. К понедельнику срок первичного уведомления в 24 часа давно истёк, а от 72-часового окна почти ничего не осталось.

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

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

Привычный стек и чем его заменить

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

Таблица 2. Типичный стартап-стек под аудитом. «Можно» – условие необходимое, но не достаточное: подписанное поручение не исправит события с лишними данными, публичные бакеты и шаблоны уведомлений с диагнозом.

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

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

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

Фора Софт разрабатывает видеософт с 2005 года. Среди 250+ выпущенных проектов в видеоконференциях, стриминге, видеонаблюдении, e-learning и OTT есть телемедицинские платформы, и наши медицинские проекты начинаются с комплаенса: карта потоков медданных и реестр поручений по подрядчикам появляются до первого спринта, а не после первого инцидента. На практике проверки из этой статьи заложены в архитектуру: видеослой, записи и логи в российском контуре, URL с непрозрачными идентификаторами, логи со ссылками вместо содержимого и с очисткой, шаблоны push и напоминаний без клинического контекста, отзыв доступа при увольнении. Если клиент приходит с готовым продуктом, мы начинаем с аудита: проверяем кодовую базу и договоры на все десять ошибок и составляем план исправлений, понятный проверяющему.

Главное

• Большинство утечек медданных команды создают сами, без всякого взлома: зарубежные SaaS, URL, логи, бакеты, SDK и уведомления пропускают данные уже в настройках по умолчанию.
• Утечке не нужен умысел: «случайный доступ» – тоже инцидент по ст. 21 ч. 3.1, со сроками уведомления 24 и 72 часа и штрафом 10–15 млн ₽ за сведения о здоровье.
• К каждой системе два вопроса: есть ли поручение и где лежит база; зарубежные SaaS, мессенджеры и ИИ-API не проходят второй.
• В push, SMS и письмах нет ничего клинического; содержимое приложение загружает после входа.
• Согласие – отдельный документ с 1 сентября 2025 года; уведомление Роскомнадзора – до начала обработки и с актуальной архитектурой.
• Диагноз без очного приёма поставить нельзя (п. 40 193н), и это правило должно быть заложено в код, а не держаться в памяти врача.

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

• Архитектура комплаенса: как встроить требования 152-ФЗ и 323-ФЗ в видеостек – устройство контура, которое закрывает все эти ошибки разом.
• Поручение обработки ПДн и договоры с подрядчиками: контракт, на котором держится весь стек – простая проверка, которая стоит за половиной ошибок.
• Чек-лист готовности по 152-ФЗ и 323-ФЗ и подготовка к проверкам – комплект документов, который закрывает ошибки 6–10 до первого запроса.