Обезличивание, вторичное использование и аналитика медицинских данных

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

Кратко

Медицинские данные, привязанные к конкретному человеку, – специальная категория персональных данных (ст. 10 152-ФЗ), а если речь о медицинской помощи, то ещё и врачебная тайна (ст. 13 323-ФЗ). Из контура, где их законно обрабатывают, они могут выйти тремя путями: к подрядчику по поручению оператора (данные остаются медданными, получатель работает в России и в целях клиники), по письменному согласию пациента на конкретную цель или через обезличивание – действия, после которых без дополнительной информации нельзя определить, кому принадлежат данные (ст. 3 п. 9 152-ФЗ). Закрытого списка «идентификаторов» в законе нет: IP-адрес, URL, идентификатор устройства и время приёма, привязанные к пациенту, – уже медданные. Поэтому обычный пиксель или SDK аналитики в телемедицинском приложении почти всегда означает передачу данных третьему лицу без основания, а если сервер за рубежом, то ещё и нарушение локализации (до 6 млн ₽, повторно до 18 млн ₽) и трансграничную передачу. При этом обезличивание не решает всех проблем: для данных о здоровье закон не даёт общего «исследовательского» основания, с 1 сентября 2025 года по 233-ФЗ обезличенные данные по требованию Минцифры передаются в ГИС министерства, а хэш телефона или СНИЛС восстанавливается перебором. Рабочая схема: событийная аналитика на случайных суррогатных идентификаторах внутри контура медданных, в России и по поручению, а наружу – только агрегаты с подавлением малых ячеек. В статье – схема конвейера, расчёты и чек-лист.

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

Любое продуктовое решение (на каком экране пациенты уходят до первой консультации, какой шаг онбординга увеличивает отток, сократил ли новый зал ожидания число неявок) опирается на аналитику, а любое аналитическое событие в телемедицине изначально относится к медданным. Большинство команд подключают тот же стек, что и в прошлом проекте: счётчик веб-аналитики, рекламный пиксель для атрибуции, запись пользовательских сессий (session replay), облачный краш-репортер. В медицине такой стек по умолчанию означает неправомерную передачу врачебной тайны, которую просто ещё никто не заметил. А с 2025 года цена такой незамеченной ошибки выросла: оборотные штрафы за утечки, прямой запрет зарубежных баз данных, согласие отдельным документом. Статья для основателя, продакт-менеджера и ответственного за обработку ПДн, которым нужны продуктовые метрики без риска для всего бизнеса. Разберём, когда данные можно считать обезличенными, что на самом деле говорят 152-ФЗ и 233-ФЗ, как использовать медданные для аналитики и обучения ИИ и как построить аналитический конвейер, который выдержит проверку Роскомнадзора.

Почему аналитика и медданные сталкиваются лбами

Индустрия продуктовой аналитики исходит из того, что поведенческие данные можно собирать свободно. Вы вставляете JavaScript-сниппет или мобильный SDK (software development kit – готовый код вендора внутри вашего приложения), и он собирает всё: каждый URL, каждое касание экрана, IP-адрес, идентификаторы устройства и постоянный user ID, связывающий сессии. Бизнес-модель таких инструментов предполагает, что вендор хранит эти данные, обогащает их, а иногда использует в собственных целях, нередко на серверах за пределами России.

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

Почти все упускают деталь, которая меняет всё: в телемедицинском продукте сам факт, что человек – пациент, уже врачебная тайна. Событие appointment_booked с user ID и IP-адресом – это сведения о том, что определяемый человек обратился за медицинской помощью, и часто к какому именно специалисту, а вовсе не безобидная «продуктовая телеметрия». То, что диагноза в событии нет, ничего не меняет. Как только такое событие уходит вендору без поручения, вы передали медданные третьему лицу без основания; если сервер вендора за рубежом, вы ещё и записали данные россиян в зарубежную базу (ст. 18 ч. 5) и совершили трансграничную передачу (ст. 12).

Есть и хорошая новость, о которой пугающие статьи молчат: закон не запрещает аналитику. Клиника-оператор вправе анализировать работу собственного сервиса в целях, ради которых данные собраны: закон требует лишь, чтобы обработка не была несовместима с целями сбора и не была избыточной (ст. 5 152-ФЗ). Контроль качества и безопасности медицинской деятельности прямо назван среди случаев, когда сведения, составляющие врачебную тайну, предоставляются без согласия пациента (ст. 13 ч. 4 п. 10 323-ФЗ). Платформа, обрабатывающая данные по поручению клиники, может строить воронки, кривые удержания и дашборды качества звонка, если такая цель прописана в поручении, а расчёты идут внутри контура медданных: на вашей инфраструктуре в России или у подрядчика по поручению. Нарушением становится не сам анализ, а то, кто получает данные, где они хранятся и что получателю разрешено с ними делать.

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

Три выхода за границу медданных

Представьте контур медданных – все системы и подрядчиков, которым законно доверено хранить данные пациентов (подробно он описан в обзорной статье о 152-ФЗ и врачебной тайне), – в виде здания с тремя выходами. Любой байт данных пациента, покидающий здание, проходит через один из них.

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

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

Выход 3 – обезличивание и агрегаты. Данные преобразуются так, что без дополнительной информации нельзя определить, кому они принадлежат (ст. 3 п. 9 152-ФЗ). Здесь важно не перепутать два состояния. Обезличенные записи – строки о людях без прямых идентификаторов – снижают риск, но юридически остаются в сфере 152-ФЗ: закон прямо говорит об «обработке персональных данных, полученных в результате обезличивания», и разрешает её для ограниченного круга целей (об этом ниже). Агрегаты – числа по группам, где ни одна ячейка не указывает на конкретного человека, – персональными данными не являются: они не относятся ни к какому определяемому лицу. Поэтому третий выход даёт не «полную свободу», как часто думают, а право выпустить наружу статистику, и требования тем строже, чем подробнее выпускаемые данные.

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

Обезличивание по 152-ФЗ: что говорит закон

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

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

Косвенные идентификаторы тоже учитываются. Персональные данные – всё, что относится к человеку «прямо или косвенно». IP-адрес, URL, идентификатор устройства, точное время приёма, населённый пункт, редкий диагноз в маленьком городе по отдельности могут не указывать на человека, но вместе нередко указывают на него однозначно.

Требования и методы задаёт Правительство. После 233-ФЗ обезличивание данных для передачи в государственную систему ведётся по требованиям, методам и порядку, которые устанавливает Правительство по согласованию с федеральным органом в области безопасности (ст. 13.1 ч. 3 152-ФЗ); они действуют с 1 сентября 2025 года, вместе с основными нормами закона. Ссылаться на конкретную методику в регламентах продукта стоит только после сверки с актуальной редакцией; здесь мы описываем инженерные подходы, а не официальную методику.

Обезличено – не значит «можно всё»

152-ФЗ разрешает обработку «в статистических или иных исследовательских целях» без согласия – «при условии обязательного обезличивания персональных данных» (ст. 6 ч. 1 п. 9). Хочется прочитать это как общее разрешение для аналитики. Но для данных о здоровье действует более строгая ст. 10: среди исключений её ч. 2 статистических и исследовательских целей нет, а отдельная ч. 2.1 (в редакции 233-ФЗ) допускает обработку обезличенных данных о состоянии здоровья лишь для повышения эффективности государственного и муниципального управления по ст. 13.1 и в целях, предусмотренных законами об экспериментальных правовых режимах (123-ФЗ об ИИ в Москве и 258-ФЗ о цифровых инновациях). Вывод осторожный, но ясный: коммерческому продукту не стоит строить вторичное использование медданных только на обезличивании записей. Собственная аналитика идёт через выход 1 (цели оператора или цели, названные в поручении), исследования и обучение моделей – через выход 2 (согласие), а наружу выходят только агрегаты.

233-ФЗ: обезличенные данные для ГИС Минцифры

С 1 сентября 2025 года операторы по требованию Минцифры обязаны обезличивать персональные данные и передавать их в государственную информационную систему министерства (ст. 13.1 152-ФЗ); в требовании указываются перечень данных и сроки. Из полученных данных министерство формирует составы данных – наборы, сгруппированные по определённому признаку. Для архитектора медплатформы важны три нормы:

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

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

Хэш – это не обезличивание

Самая частая ошибка – «мы же захэшировали». SHA-256 от номера телефона, email или СНИЛС даёт значение, вычисленное из самого идентификатора. Вариантов таких идентификаторов немного: и российских мобильных номеров, и номеров СНИЛС порядка миллиарда, и перебор всех вариантов на обычной видеокарте занимает минуты. А любой, у кого есть исходный идентификатор (рекламная система, партнёр, чужая утёкшая база), сопоставит хэш за одну операцию. Соль защищает только от перебора и только пока остаётся секретной, то есть пока это та же дополнительная информация, которую нужно хранить отдельно. Правильная конструкция – случайный суррогатный ключ, сгенерированный независимо от данных пациента и связанный с ним только в защищённой таблице соответствий с отдельным доступом и журналом. Это псевдонимизация, и она полезна, но называть её обезличиванием можно, только если таблица соответствий физически недоступна получателю.

Таблица 1. Что SDK аналитики собирает по умолчанию, с точки зрения 152-ФЗ. Большая часть этих данных указывает на пациента прямо или косвенно.

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

Оценка риска повторной идентификации: статистический подход

Правила вида «удалить ФИО, СНИЛС и телефон, заменить ID, обобщить даты до месяца» – хорошая отправная точка, но они не отвечают на главный вопрос: сможет ли конкретный получатель определить человека? Ответ зависит от того, кто получает набор, с какими данными может его сопоставить и что на этом выиграет. Поэтому опытные команды добавляют второй инструмент – оценку риска повторной идентификации. Это инженерная работа, а не юридическая процедура, и её результат – документ, который вы покажете проверяющему, когда он спросит, почему вы считаете набор обезличенным.

О ней стоит заранее знать четыре вещи.

Во-первых, универсального порога нет. Риск оценивается в контексте: один и тот же набор может быть безопасным для внутренней BI-команды без доступа к журналу записи и опасным для партнёра, у которого есть своя база пациентов того же города.

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

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

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

Почему обезличивание ненадёжно и что это значит для видео

Обезличивание снижает риск, но не до нуля, а внешний мир не стоит на месте. Ключевое исследование на эту тему – Rocher, Hendrickx и de Montjoye (Nature Communications, 2019). С помощью генеративной модели авторы оценили, что по 15 демографическим признакам можно правильно повторно идентифицировать 99,98% жителей целой страны. Хуже того для привычной практики: даже сильно прореженные, неполные наборы («мы выпустили только 1% строк») защищают куда слабее, чем подсказывает интуиция. Вывод авторов: подход «выпустил и забыл» не работает, когда данных вокруг так много.

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

Записи сессий нельзя обезличить как медиафайлы. На видеоконсультации видно лицо и слышен голос пациента, а разговор полон имён, дат, мест и уникальных деталей. Размытие лица и изменение тембра не помогут: преобразование голоса частично обратимо, а содержание разговора само по себе указывает на человека. (Видеосвязь при этом не считается биометрической идентификацией: распознавать пациента по лицу можно только через Единую биометрическую систему или аккредитованную систему по 572-ФЗ. Но для обезличивания это неважно: человек на записи определяем и без распознавания.) Честный инженерный вывод: обезличенного телемедицинского видео не бывает, бывают обезличенные производные от него. Метрики качества звонка, длительность, число переподключений, коды жалоб из очищенного транскрипта могут выйти через выход 3. Сама запись остаётся внутри контура и подчиняется правилам из статьи о записи клинических сессий: сопутствующие материалы консультации хранятся 1 год (193н, п. 49–51).

Транскриптам нужна и очистка, и оценка риска. Автоматическое удаление имён, дат и адресов из свободного текста (сегодня это обычно NLP-модель, развёрнутая внутри контура) необходимо, но недостаточно: это техническая операция, а не юридический статус. Очищенный транскрипт можно считать обезличенным, только если вы измерили долю пропусков модели на размеченной выборке и оценили риск того, что осталось.

Обучение ИИ – такое же вторичное использование, как любое другое. Разрешить разработчику модели обучаться на данных ваших пациентов можно через выход 1 (поручение, где обучение модели прямо названо целью клиники, – в типовых поручениях его нет), через выход 2 (письменное согласие пациента на эту цель) или выдав наружу обезличенный набор с оценкой риска, помня об ограничениях ст. 10 для данных о здоровье. Если «вендор пообещал обезличить данные на своей стороне», значит, вы сначала передали медданные третьему лицу без основания, а обезличивание случилось уже потом. Если вендор – зарубежный ИИ-API, добавьте трансграничную передачу специальной категории и конфликт с локализацией; российские модели и варианты с развёртыванием у себя (on-prem) разобраны в статье о слое комплаенса клинического ИИ. Разработчик модели – либо обработчик по поручению, либо получатель по согласию; обезличивать на стороне получателя уже поздно.

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

Теперь вопрос, который на самом деле волнует каждую команду: «Так можно оставить счётчик веб-аналитики и пиксель?» Проверим его по трём выходам.

Типичный внешний сервис аналитики или рекламный пиксель не подписывает поручение с клиникой-оператором и обрабатывает данные в собственных целях: выход 1 закрыт. Согласия каждого пациента на передачу данных о визитах рекламной системе у вас нет и не будет: выход 2 закрыт. А данные, которые инструмент собирает по умолчанию (IP, URL, идентификаторы устройств, точное время, постоянные ID), не обезличены (таблица 1): выход 3 тоже закрыт. Если серверы сервиса за рубежом, к этому добавляются запрет зарубежных баз данных и трансграничная передача (подробно – в статье о локализации и трансграничной передаче). По той же причине внутри аутентифицированного приложения не подходят пиксели социальных сетей и рекламных систем, большинство SDK рекламной атрибуции и облачные сервисы session replay. Инструменты не плохие – просто данные не могут законно до них дойти.

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

Таблица 2. Во что обходится аналитика без законного основания. Нумерацию частей ст. 13.11 КоАП перед публикацией сверяйте с действующим текстом: источники нумеруют их по-разному.

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

Таблица 3. Аналитические инструменты; главное – средняя колонка. «Да» означает «можно, если вы сами обеспечили основание, хранение в России и защиту», а не «инструмент сертифицирован».

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

Аналитический конвейер, который выдержит проверку

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

Зона 1 – внутри контура медданных. Приложение отправляет события по TLS на собственный эндпоинт сбора на вашем домене, а не в скрипт вендора. Схема событий задаёт allowlist – белый список: каждое событие и каждое свойство зарегистрировано, проверено на ревью и типизировано, а всё, чего нет в списке, отбрасывается на входе. В свойствах передаётся случайный суррогатный ID, связанный с пациентом только в защищённой таблице соответствий, и никогда – хэш телефона или email. IP нужен для маршрутизации и защиты от перебора, но до сохранения усекается или отбрасывается; точное время остаётся – внутри контура это допустимо. Хранилище событий (например, ClickHouse) и продуктовая аналитика работают на серверах в России, в аттестованном облаке или на своих, и покрыты поручением клиники с явно названной целью «анализ и улучшение качества сервиса». Здесь, на полной детализации, считается всё: воронки, когорты, дашборды качества звонка – время подключения, переподключения, потери пакетов и другие метрики качества восприятия (quality of experience, QoE), без которых видеоплатформе не обойтись. Доступ – по ролям и с журналированием; подробнее об этом в статье о журналах аудита и контроле доступа.

Зона 2 – снаружи контура. Событийные данные границу не пересекают. Задача агрегации по расписанию публикует только числа: недельную активную аудиторию, конверсии, кривые удержания, NPS по когортам, причём каждая ячейка посчитана по достаточному числу людей, чтобы никого нельзя было определить. Стандартный приём – подавление малых ячеек: любая ячейка, где меньше k человек, скрывается или объединяется с соседними. Конкретного k закон не задаёт: выберите его (например, 10), обоснуйте в модели угроз и проверяйте автоматически в самой задаче агрегации, а не полагайтесь на внимательность аналитиков. Маркетинговая атрибуция получает количество конверсий – серверной выгрузкой агрегатов после подавления, но никогда не события отдельных пользователей с идентификаторами.

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

Посчитаем, от чего защищает этот конвейер. Возьмём типичный телемедицинский продукт: 40 000 активных пациентов, маркетинг добавил один конверсионный пиксель зарубежной рекламной системы на страницу подтверждения записи. Каждое подтверждение отправляет пиксель с IP, URL (в котором закодирована специальность врача) и идентификатором устройства:

«40 000 пациентов × 1 передача = 40 000 сведений о факте обращения в чужой базе за рубежом. Локализация: до 6 млн ₽ (ч. 8 ст. 13.11 КоАП), при повторном нарушении – до 18 млн ₽ (ч. 9). Если передачу квалифицируют как утечку специальной категории: 10–15 млн ₽ (ч. 16), повторную – 1–3% выручки, но не менее 25 млн ₽ (ч. 18). Не уведомили Роскомнадзор в течение 24 часов – ещё 1–3 млн ₽ (ч. 11). Итого при первом нарушении теоретический размер штрафов – от 11 млн ₽ (10 + 1: нижние границы ч. 16 и ч. 11, без локализации) до 24 млн ₽ (6 + 15 + 3: верхние границы всех трёх составов). Плюс отток пациентов после новости «сервис передавал данные о ваших записях к врачу рекламной системе»: в медицине доверие и есть продукт.»

И всё из-за одного пикселя. Двухзонный конвейер стоит один-два спринта работы, а альтернатива – миллионы рублей и скандальные новости.

«Классическая ошибка: «обезличено» как заклинание. Слово «обезличено» (или «анонимизировано») встречается в презентациях вендоров, тикетах и разборах инцидентов так, будто, произнеся его, вы что-то изменили. Набор без ФИО, но с датами визитов, населённым пунктом и хэшем телефона – персональные данные. Поток событий, «обезличенный» удалением колонки email при сохранённом ID устройства, – персональные данные. «Полностью анонимная» запись сессии – это лицо и голос пациента. Если описание вашего конвейера не отвечает на вопросы, какая дополнительная информация нужна для повторной идентификации, где она хранится и у кого к ней доступ, значит, данные всё ещё медданные, и обращаться с ними нужно соответственно.»

Ещё одно бесплатное правило, которое предотвращает большинство регрессий: проверяйте allowlist событий на ревью, как схему API. Новое аналитическое событие добавляется через pull request, ревьюер сверяет свойства с таблицей 1, а маркетинговые теги публичных страниц хранятся в отдельном контейнере тег-менеджера, который в аутентифицированном приложении физически не загружается. Требования к защите ПДн – модель угроз, учёт всех компонентов системы, оценка эффективности мер (подробно – в статье о требованиях к защите ПДн в 2026 году) – ведут к тому же: вы должны знать каждый скрипт в своём приложении и каждое направление, куда уходят данные. Большинство провалов из статьи о частых ошибках защиты медданных начинаются с тега, который никто не проверил.

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

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

Главное

• Медданные покидают контур тремя путями: подрядчик по поручению (в России), письменное согласие пациента на конкретную цель, обезличивание; из-под режима ПДн по-настоящему выходят только агрегаты.
• Закон не даёт списка идентификаторов: IP, URL, ID устройств, точное время, голос и лицо в связке с пациентом – медданные; то, что SDK собирает по умолчанию, не обезличено.
• Хэш телефона, email или СНИЛС – не обезличивание; используйте случайные суррогатные ключи и храните таблицу соответствий отдельно.
• Для данных о здоровье нет общего «исследовательского» основания: ст. 10 152-ФЗ строже ст. 6; по 233-ФЗ обезличенные данные по требованию передаются в ГИС Минцифры, поэтому обезличивание должно быть воспроизводимой функцией конвейера.
• Без поручения и хранения в России – никаких потоков событий: внешние счётчики и пиксели допустимы только на публичных страницах, зарубежные сервисы – нигде.
• Идентифицированная аналитика – внутри контура; наружу – только агрегаты с подавлением малых ячеек.

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

• Поручение обработки ПДн и договоры с подрядчиками – выход 1 в деталях: что писать в поручении, кто его подписывает, как проверить подрядчика.
• Согласие пациента, запись и хранение данных – выход 2: согласие отдельным документом, согласие на запись и сроки хранения данных, которые вы анализируете.
• Частые ошибки в защите медданных при разработке телемед-продуктов – типичные провалы, от которых защищает конвейер из этой статьи.