152-ФЗ и врачебная тайна простым языком для продуктовых команд

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

Кратко

Медицинский цифровой продукт в России регулируют два закона. 152-ФЗ «О персональных данных» определяет, на каком основании обрабатывать данные пациента, как их защищать и что делать при утечке. 323-ФЗ «Об основах охраны здоровья граждан» относит сведения о факте обращения, здоровье и диагнозе к врачебной тайне (ст. 13) и выделяет телемедицину в отдельно регулируемый вид помощи (ст. 36.2 и приказ Минздрава 193н). Сведения о здоровье – специальная категория персональных данных (ст. 10 152-ФЗ). По умолчанию их обрабатывать нельзя; исключения составляют медицинские цели у лиц, обязанных хранить врачебную тайну, и письменное согласие, которое с 1 сентября 2025 года оформляется отдельным документом. Продуктовая команда почти всегда оказывается либо оператором (своя медорганизация), либо, гораздо чаще, лицом, обрабатывающим данные по поручению клиники. Во втором случае нужны договор-поручение, базы в России (ст. 18 ч. 5) и меры по ПП 1119 и приказу ФСТЭК № 21. Закон не сертифицирует продукты, но за утечку данных о здоровье юрлицо заплатит 10–15 млн ₽ (ч. 16 ст. 13.11 КоАП), за повторную – до 500 млн ₽, а Роскомнадзор нужно уведомить в течение 24 часов.

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

Для телемедицинского продукта 152-ФЗ и врачебная тайна – не сноска для юристов. От них зависят архитектура, список подрядчиков, страна, где стоят серверы, и дата запуска. Большинство объяснений – либо юридическая проза, либо вендорские чек-листы «152-ФЗ за один день», в которых нет как раз того, за что штрафуют. Здесь мы разбираем реальные требования законов и переводим их в продуктовые решения. Это базовая статья блока о комплаенсе: материалы о требованиях к защите ПДн в 2026 году, поручении обработки и договорах с подрядчиками и шифровании опираются на введённые здесь понятия. После неё разговоры с юристом и безопасником станут заметно короче.

Два закона – один вопрос

152-ФЗ «О персональных данных» принят 27 июля 2006 года, 323-ФЗ «Об основах охраны здоровья граждан в Российской Федерации» – 21 ноября 2011 года. Нормы, важные для продуктовой команды, появлялись волнами. В 2018 году 323-ФЗ дополнили статьёй 36.2 о телемедицине. В 2022 году 266-ФЗ расширил требования к поручению обработки, а с 1 марта 2023 года ввёл уведомительный порядок трансграничной передачи. С 30 мая 2025 года действуют оборотные штрафы за утечки, с 1 июля 2025-го – прямой запрет хранить персональные данные россиян в зарубежных базах, с 1 сентября 2025-го – согласие отдельным документом и новый порядок телемедицины (приказ Минздрава 193н). После этой волны защита медданных стала заботой не только клиник, но и каждого ИТ-подрядчика, который с ними работает.

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

Что считается медданными

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

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

Закрытого списка «идентификаторов» 152-ФЗ не даёт. Критерий один: можно ли связать данные с человеком прямо или косвенно. Обезличивание закон определяет как действия, после которых без дополнительной информации нельзя определить, кому принадлежат данные (ст. 3). Если читать это определение глазами инженера, всплывают три вещи, на которых регулярно спотыкаются продукты. IP-адрес в связке с учётной записью пациента – косвенно идентифицирующие данные. URL вида /booking/dermatology-biopsy-followup, привязанный к пользователю, – сведения о здоровье определённого человека и о факте его обращения. Идентификатор устройства работает так же. Поэтому сырая телеметрия телемедицинского приложения, отправленная в стороннюю аналитику, означает передачу медданных третьему лицу без основания, а если SDK зарубежный, то ещё и трансграничная передача. Подробно эта ловушка разобрана в типичных ошибках защиты медданных, а правила обезличивания (в том числе по 233-ФЗ) описаны в статье об обезличивании и аналитике.

Есть и ещё одна граница: одна и та же запись в одном контексте составляет врачебную тайну, а в другом нет. Пульс в фитнес-приложении, которое человек скачал сам, врачебной тайной не является, потому что медицинской помощи нет. Но 152-ФЗ от этого не перестаёт действовать: если данные описывают состояние здоровья, это спецкатегория, и оператору приложения нужно письменное согласие. Какие именно метрики считать «сведениями о здоровье», решают юристы; с инженерной точки зрения безопаснее считать их таковыми. Тот же пульс в системе дистанционного наблюдения, которую врач назначил после очного приёма (193н, п. 43–46), – одновременно спецкатегория и врачебная тайна. Данные не изменились, изменились контекст и роль того, у кого они хранятся. Отсюда главный вопрос всего комплаенса.

Оператор или обработчик: кто из них ваш стартап?

152-ФЗ распределяет обязанности между двумя ролями.

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

Лицо, обрабатывающее данные по поручению оператора (на практике его называют обработчиком), работает по договору с оператором и в его целях (ст. 6 ч. 3). Договор-поручение подрядчик подписывает до того, как получит доступ к данным. В нём перечислены данные и действия с ними, цели, обязанность соблюдать конфиденциальность, требования к защите по ст. 19, обязанность уведомлять оператора об инцидентах и по запросу предоставлять документы о соблюдении требований. Обработчику не нужно собственное согласие пациента (ч. 4), но он отвечает перед оператором (ч. 5). Если обработчик – иностранное лицо, перед пациентом отвечают и оператор, и обработчик (ч. 6).

Врачебная тайна добавляет ещё одно условие: её нельзя разглашать тем, кому она стала известна при исполнении обязанностей (ст. 13 ч. 2 323-ФЗ). Инженер поддержки подрядчика, увидевший имя пациента в логе, – как раз такое лицо, поэтому обязательство о неразглашении входит и в договор, и в документы команды.

Для продуктовой команды раскладка обычно такая:

«Не медорганизация» не означает «нерегулируемый». 152-ФЗ применяется к любому, кто обрабатывает персональные данные; меняется только набор оснований. Медицинская цель по ст. 10 ч. 2 п. 4 доступна лишь тем, кто занимается медицинской деятельностью и обязан хранить врачебную тайну. Остальным нужно письменное согласие (ст. 9 ч. 4; электронная форма с электронной подписью приравнивается к письменной). Так что выбирать приходится между основаниями, свободы от регулирования нет ни у кого.

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

Разберём цепочку на примере. Сеть клиник заказывает у ООО «ТелеКонсилиум» видеоприёмы; платформа работает в российском облаке и пишет записи сессий в объектное хранилище. Сеть клиник – оператор. «ТелеКонсилиум» обрабатывает данные по её поручению: это договор № 1. Облачный провайдер, в инфраструктуре которого лежат записи, – следующее звено. Договор с ним должен содержать условия обработки и защиты, а сама цепочка должна быть согласована с оператором (договор № 2). Если платформа отправляет аудио в API распознавания речи, с вендором API нужен договор № 3. Каждый узел, где медданные попадают на чужую инфраструктуру, требует своих договорных условий. Звено за рубежом нарушает сразу два требования: о локализации и о трансграничной передаче. Как устроено поручение, что в нём писать и кто его не подписывает, мы разбираем в отдельной статье.

Три слоя требований в том порядке, в каком с ними сталкиваются

Требования к медданным удобно разложить на три слоя. Каждый касается своей части продукта.

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

Основания и врачебная тайна: кто может видеть медданные и делиться ими

Первый слой – система разрешений. По умолчанию действует запрет: обработка специальных категорий не допускается, кроме случаев из ст. 10 ч. 2 152-ФЗ. Главное исключение – медицинские цели у лица, которое профессионально занимается медицинской деятельностью и обязано хранить врачебную тайну; поэтому врач ведёт карту без отдельной подписанной формы. 323-ФЗ дополняет картину: без согласия пациента сведения можно передавать, например, при обмене между медорганизациями (в том числе через медицинские информационные системы) для оказания помощи и в целях контроля качества (ст. 13 ч. 4 п. 8 и 10). Почти для всего остального (маркетинг, публикации, передача третьим лицам в иных целях) нужно письменное согласие пациента (ст. 13 ч. 3). С 1 сентября 2025 года согласие на обработку персональных данных оформляется отдельно от оферт, политик и договоров.

Два понятия из этого слоя сразу превращаются в задачи продуктового бэклога.

Минимизация. Объём обрабатываемых данных не должен быть избыточным по отношению к целям (ст. 5 152-ФЗ), а тем, кто узнал врачебную тайну по работе, разглашать её нельзя (ст. 13 ч. 2 323-ФЗ). В софте это означает ролевой доступ, узкие ответы API и выгрузки без лишних полей: инженеру поддержки, который разбирается с проблемой видео, нужны метрики качества звонка, а не карта пациента. Как перевести это в модель доступа, рассказано в статье о журналах аудита и контроле доступа.

Права пациента. Человек вправе получить сведения о своих персональных данных и потребовать их уточнения, блокирования или уничтожения (ст. 14). Ответить оператор обязан в течение 10 рабочих дней с даты запроса; срок можно продлить не более чем на 5 рабочих дней, направив мотивированное уведомление (ст. 20). Если платформа хранит клинические записи, функция «выгрузить данные пациента» нужна не для удобства: через неё ваши клиенты-клиники выполняют обязанность с жёстким сроком (а также права пациента на медицинскую документацию по 323-ФЗ и приказу 209н).

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

Отдельная оговорка на 2026 год. Экспериментальный правовой режим по телемедицине (ПП 1164) с 1 августа 2023 года разрешал 28 частным организациям, в частности, идентифицировать пациента альтернативными способами: по данным мобильного оператора или по банковскому идентификатору. Режим установлен на три года, и на дату проверки мы не нашли в открытых источниках решения о его продлении после августа 2026-го. Хороший пример того, почему у материалов о комплаенсе всегда должна стоять дата: правила меняются в обе стороны.

Безопасность: как должны быть защищены медданные

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

Детали содержатся в двух подзаконных актах. ПП 1119 задаёт четыре уровня защищённости: от УЗ-1 (самый строгий) до УЗ-4. Уровень зависит от типа актуальных угроз, категории данных и объёма. Для телемед-платформы со сведениями о здоровье пациентов расклад такой. При угрозах 3-го типа (не связанных с недекларированными возможностями системного и прикладного ПО) – УЗ-3, если пациентов меньше 100 000, и УЗ-2, если больше. При угрозах 2-го типа – УЗ-2 и УЗ-1 соответственно; при угрозах 1-го типа – всегда УЗ-1. Рост базы сам по себе меняет требования, поэтому уровень стоит планировать под целевой объём, а не под пилот. Чем выше уровень, тем больше обязательств: от утверждённого перечня лиц с доступом (УЗ-4) и ответственного за безопасность (УЗ-3) до автоматической регистрации изменений полномочий и отдельного подразделения по защите (УЗ-1). Контроль выполнения требований проводится не реже раза в три года (п. 17).

Приказ ФСТЭК № 21 делит меры на 15 групп: от идентификации и аутентификации (ИАФ), управления доступом (УПД) и регистрации событий (РСБ) до защиты среды виртуализации, систем связи и передачи данных (ЗИС) и реагирования на инциденты. Меры выбирают в четыре шага: базовый набор для вашего уровня, адаптация (исключаются меры для технологий, которых у вас нет), уточнение под актуальные угрозы, дополнение мерами из других актов (п. 9).

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

Если поддерживать в актуальном состоянии только один документ, пусть это будет модель угроз (ст. 19 ч. 2 п. 1). От неё зависят тип угроз, уровень защищённости, набор мер и ответ на первый вопрос любого проверяющего. Оценку эффективности мер оператор проводит сам или с лицензиатом ФСТЭК, не реже раза в три года (п. 6 приказа № 21).

Разработчиков обычно удивляют две особенности этого слоя. Первая: требования в основном технологически нейтральны. Они формулируют задачи («идентифицировать и аутентифицировать», «регистрировать события») и не называют шифр, протокол или продукт. Исключение одно, но важное: средства защиты должны пройти оценку соответствия, а там, где защита держится на криптографии, нужны средства криптографической защиты информации (СКЗИ), сертифицированные ФСБ; их классы для персональных данных задаёт приказ ФСБ № 378. Вторая: требования долго оставались стабильными. ПП 1119 действует с 2012 года, приказ № 21 – с 2013-го. В июле 2026 года ФСТЭК опубликовала проект замены приказа № 21 с показателем «уровень зрелости», переоценкой после каждого инцидента и требованиями к обработчикам; на 24 сентября 2026 года он не подписан. Стройте систему сразу с учётом проекта: всё, что в нём есть, давно стало стандартной практикой. Подробный разбор – в статье о требованиях к защите ПДн в 2026 году.

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

Инциденты: когда защита не сработала

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

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

С момента выявления начинают идти сроки, и они жёсткие:

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

Посчитаем на примере. «24 часа» звучит как «завтра», но часы идут подряд, выходные не исключаются. Допустим, дежурный инженер находит открытый бакет с записями консультаций в пятницу, 3 апреля 2026 года, в 18:40; это момент выявления. Через 24 часа, в субботу, 4 апреля, в 18:40, истекает срок первичного уведомления Роскомнадзора. Ещё через 48 часов, то есть через 72 от выявления, в понедельник, 6 апреля, в 18:40, нужно направить результаты внутреннего расследования. В это окно, которое приходится на выходные, надо уложить закрытие доступа, оценку вреда и поиск причин. Успевают те, у кого регламент реагирования на инциденты был готов заранее. Неуведомление Роскомнадзора – отдельное нарушение со штрафом 1–3 млн ₽ (ч. 11 ст. 13.11 КоАП).

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

Чего в 152-ФЗ нет

Чтобы уверенно ориентироваться в 152-ФЗ, полезно знать, чего в нём нет. Вот пять вещей, которые команды регулярно ему приписывают.

Технологии он почти не называет. В нём нет ни AES-256, ни версии TLS, ни длины пароля, ни выбора между облаком и своим сервером. Требования задают задачи, а механизмы определяются моделью угроз. Ближе всего к технологиям закон подходит в одном месте: средства защиты должны пройти оценку соответствия, а там, где нейтрализация угроз держится на криптографии, нужны сертифицированные СКЗИ. Где именно они нужны в телемедицине, рассказано в статье о шифровании, ГОСТ и СКЗИ.

Сертификата «соответствует 152-ФЗ» не существует. Сертифицируют средства защиты (ФСТЭК, ФСБ), аттестуют информационные системы, у облаков бывают аттестаты на УЗ-1, и всё это полезные доказательства. Но аттестат облака распространяется на инфраструктуру провайдера, а не на ваше приложение, а значок «соответствует 152-ФЗ» на сайте вендора юридической силы не имеет. Соответствие зависит от вашей организации, документов и рабочей конфигурации; его нельзя получить один раз, как наклейку.

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

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

Жаловаться пациент может не только регулятору. Он вправе обжаловать действия оператора в Роскомнадзор или в суд (ст. 17), а моральный вред от нарушения его прав возмещается независимо от возмещения имущественного вреда (ст. 24). Кроме того, есть уголовная ответственность за незаконные использование, передачу, сбор и хранение компьютерной информации с персональными данными (ст. 272.1 УК РФ, с 11 декабря 2024 года). Так что после утечки претензии могут прийти не только от Роскомнадзора.

Сколько стоят нарушения: цифры 2026 года

Штрафы по ст. 13.11 КоАП в редакции 420-ФЗ действуют с 30 мая 2025 года. Суммы для юридических лиц:

К таблице нужны две оговорки. Закон предусматривает смягчение оборотного штрафа для компаний, которые три года подряд тратили на информационную безопасность не менее 0,1% выручки. А скидка 50% за быструю оплату к этим штрафам не применяется. Для медицинской платформы главная строка – ч. 16: утечка данных о здоровье выделена в отдельный состав с одной из самых высоких вилок.

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

Где телемедицинское видео пересекается с 152-ФЗ и 323-ФЗ

Всё сказанное выше относится к любому медицинскому софту. У видео есть свои уязвимые места, поэтому в Фора Софт Learn есть этот раздел и статья о том, почему видео в телемедицине сложнее обычного звонка.

Видеоконсультация – обработка спецкатегории с первого кадра. Порядок 193н добавляет к 152-ФЗ конкретики. Участники идентифицируются через ЕСИА (п. 7), врач должен быть в регистре медработников (ФРМР), организация – в регистре медорганизаций (ФРМО) (п. 9). На сайте или в приложении пациенту раскрывают, в том числе, оператора информационной системы и место хранения материалов (п. 37), так что архитектура хранения становится публичной информацией. Записывать консультации 193н не обязывает, но если запись сделана, аудио- и видеозаписи, сообщения и изображения хранятся как сопутствующие материалы 1 год (п. 49–51). Само видео при этом не является биометрической идентификацией: распознавать пациента по лицу можно только через Единую биометрическую систему или аккредитованную систему (572-ФЗ). Как устроить вход, рассказано в статье об идентификации через ЕСИА, SSO и регистрах ФРМР/ФРМО.

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

Условия зависят от вендора, продукта и тарифа; прежде чем пускать медданные, получите письменное подтверждение. Выбор «строить или покупать», который стоит за этой таблицей, разобран в статье свой видеослой или готовое решение.

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

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

Эта диаграмма – отправная точка для полной архитектуры (сегментация сети, управление ключами, журналирование), которую мы разбираем в статье об архитектуре соответствия 152-ФЗ и 323-ФЗ; в контексте всей системы её показывает анатомия телемед-платформы.

Что делать на практике

Если свести три слоя к списку дел продуктовой команды, он окажется куда короче самих законов:

1. Определите роль: оператор, обработчик по поручению или самостоятельный оператор без медицинской лицензии. От этого зависит всё остальное (рис. 1; если сомневаетесь, спросите юриста).
2. Составьте карту медданных: каждая система, подрядчик, лог и бэкап, куда могут попасть данные пациентов, и страна, где они физически лежат. Карта нужна для модели угроз и для проверки локализации.
3. Закрепите основания: поручение от клиники-оператора; письменное согласие отдельным документом там, где вы сами оператор без медицинской лицензии (ст. 9, 10); правила раскрытия врачебной тайны (ст. 13).
4. Сделайте модель угроз и определите уровень защищённости (ст. 19, ПП 1119). Этот документ проверяющие запрашивают первым, и именно его чаще всего нет.
5. Замкните цепочку поручений: договорные условия обработки на каждом узле, где третья сторона имеет дело с медданными. Если поручения нет или подрядчик за рубежом, медданных у него быть не должно: меняйте подрядчика или обезличивайте поток.
6. Внедрите меры приказа ФСТЭК № 21 для вашего уровня: шифрование в канале и при хранении (СКЗИ там, где на криптографии держится нейтрализация угроз), уникальные учётные записи, второй фактор для персонала и администраторов, ролевой доступ, журнал событий, контроль целостности, таймауты сессий.
7. Подготовьте уведомления и план действий при утечке: уведомление Роскомнадзора о начале обработки (ст. 22) для оператора; сценарий «выявление → оценка → РКН за 24 и 72 часа» с прописанным сроком уведомления от подрядчиков. Отрабатывайте его на учениях так же, как переключение на резервный контур.
8. Документируйте и обучайте: политика и локальные акты, ответственный, внутренний контроль, ознакомление сотрудников (ст. 18.1), обязательства о неразглашении врачебной тайны (ст. 13 323-ФЗ), оценка эффективности мер не реже раза в три года. Чего нет на бумаге, того для проверяющего не существует.

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

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

Фора Софт разрабатывает видеософт с 2005 года. Среди 250+ выпущенных проектов есть телемедицинские платформы, и требования 152-ФЗ и врачебной тайны мы закладываем в архитектуру с первой диаграммы, а не дорабатываем потом. На практике мы вместе с вами очерчиваем границу медданных до выбора подрядчиков, проектируем цепочку поручений параллельно со схемой системы, размещаем видеослой и записи в российской инфраструктуре. Доказательную базу для модели угроз и оценки эффективности (шифрование, контроль доступа, журнал событий) мы собираем как часть поставки, а не в спешке перед проверкой. Наши команды делали видеоконсультации, запись сессий с получением согласий и интеграции с медицинскими информационными системами. Если продукт работает с данными пациентов, дешевле всего провести границу правильно до первого спринта.

Главное

• Два закона: 152-ФЗ (основания, безопасность, инциденты) и 323-ФЗ (врачебная тайна, телемедицина по ст. 36.2 и приказу 193н).
• Данные о здоровье – спецкатегория (ст. 10); врачебной тайной является даже факт обращения; IP, URL и идентификатор устройства в связке с пациентом тоже относятся к медданным.
• Большинство продуктовых команд – обработчики по поручению: договорные условия на каждом узле с медданными, базы в России, ответственность перед оператором.
• Закон почти не называет технологий и ничего не сертифицирует; он требует модель угроз, уровень защищённости по ПП 1119, меры приказа ФСТЭК № 21 и сертифицированные средства там, где без них не обойтись.
• Утечка данных о здоровье обойдётся в 10–15 млн ₽, повторная – до 500 млн ₽; Роскомнадзор уведомляют за 24 и 72 часа.
• Проект замены приказа ФСТЭК № 21 (июль 2026) не подписан, но строить систему лучше сразу с учётом него.

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

• Требования к защите ПДн в 2026 году: ПП 1119, приказы ФСТЭК и что это значит для видео
• Поручение обработки ПДн и договоры с подрядчиками: контракт, на котором держится весь стек
• Шифрование для телемедицины: при передаче, при хранении, сквозное. Где нужны ГОСТ и СКЗИ