Требования к данным
152-ФЗ для клиники: что включить в ТЗ на разработку
Какие данные передавать из МИС, кому открывать доступ и как проверить подрядчика: конкретные требования к ТЗ и примеры приёмки для клиники.
Допустим, клиника заказывает личный кабинет пациента. В смете есть интеграция с МИС, уведомления и хранение результатов. В ТЗ — одна строка: «Система должна соответствовать 152-ФЗ». По ней нельзя понять, получит ли сервис рассылок диагноз, сможет ли сотрудник поддержки открыть анализы и что произойдёт с копией базы после тестирования.
До оценки разработки эти вопросы стоит перевести в требования, которые можно проверить. Ниже — разбор подготовки ТЗ для ИТ-заказчика; правовые основания обработки и необходимые меры защиты определяют для конкретной системы вместе с ответственными за персональные данные и информационную безопасность.
Сначала опишите, зачем системе каждое поле
Статья 5 152-ФЗ связывает состав и объём данных с заранее определёнными целями обработки. Для ТЗ это означает простую работу: разобрать отдельно запись, напоминание, выдачу результатов и обращение в поддержку. У каждого сценария будет свой набор полей.
Попросите подрядчика перечислить, что новый сервис читает из МИС, что сохраняет у себя и что передаёт дальше. Для каждого поля должен быть понятен ответ на вопрос: какое действие без него невозможно? Если аргумент звучит как «понадобится потом», поле пока остаётся за пределами согласованного обмена.
Рядом укажите срок или основание хранения. Не назначайте один срок сразу медицинской документации, незавершённой записи и техническим журналам. У этих данных разные задачи и применимые требования. Также договоритесь, какая система хранит актуальную запись и как исправление в МИС попадёт в личный кабинет.
Источники: 152-ФЗ: понятие оператора и принципы обработки, статьи 3 и 5.
Права доступа проверяют через экран, API и выгрузку
Сведения о здоровье относятся к специальным категориям персональных данных: основания их обработки предусмотрены статьёй 10. Название проекта «для клиники» само по себе не определяет основание для каждой операции и каждого получателя.
Составьте матрицу реальных ролей: пациент, администратор записи, врач, руководитель, техническая поддержка. Напротив каждой роли укажите разрешённые действия с документами и полями, а также с чьими записями можно работать. Например, роль «пациент» не даёт доступа к документам всех пациентов. Возможность увидеть расписание, скачать результаты и массово выгрузить пациентов — три разных права.
Уточните, кто выдаёт доступ, когда его пересматривает и как отзывает при увольнении или завершении работ. Для сопровождения опишите порядок временного доступа к рабочей системе. Общая учётная запись «для разработчиков» затруднит проверку того, кто и зачем открывал данные.
Источники: 152-ФЗ: конфиденциальность и сведения о здоровье, статьи 7 и 10.
Нарисуйте маршрут данных до последнего сервиса
Часть 5 статьи 18 в редакции № 23-ФЗ, действующей с 1 июля 2025 года, запрещает при сборе данных граждан РФ перечисленные в ней операции с использованием баз за пределами России, кроме установленных законом исключений. Адрес основного сервера — только одна часть проверки архитектуры.
В схеме нужны база приложения, очереди обмена, резервные копии, почта, сервис уведомлений и сборщик ошибок. Укажите данные, получателя и место обработки для каждого перехода. Зарубежные получатели требуют отдельной проверки применимых правил, включая трансграничную передачу.
Особенно внимательно разберите служебные инструменты. Ошибка интеграции может содержать весь ответ МИС, хотя разработчику нужен только код сбоя. Заранее решите, какие сведения допустимы в диагностике, кому доступны журналы и как долго они сохраняются.
Источники: 152-ФЗ: локализация и меры защиты, статьи 18 и 19; Федеральный закон от 28.02.2025 № 23-ФЗ: официальная публикация.
Зафиксируйте, что подрядчик делает с рабочими данными
Разработка на искусственных карточках и сопровождение с доступом к рабочей базе — разные условия проекта. Выясните это до договора. Когда обработку поручают другому лицу, статья 6 требует определить её содержание и обязанности обработчика; одна оговорка о конфиденциальности этого не описывает.
Согласуйте перечень данных, операции, цели, требования защиты, подтверждение принятых мер и порядок сообщения об инцидентах. В рабочих приложениях к договору удобно назначить ответственных за выдачу доступа, расследование сбоев и завершение поручения.
Попросите описать завершение работ: какие доступы отзываются, какие материалы передаются клинике и что происходит с тестовыми выгрузками. Вопрос «у кого осталась копия базы» должен иметь ответ и после ухода конкретного разработчика из команды.
Источники: 152-ФЗ: обработка по поручению, статья 6.
Согласуйте меры защиты и проверьте восстановление
Статья 19 предусматривает определение угроз и оценку эффективности мер до ввода системы в эксплуатацию. Уровень защищённости по постановлению № 1119 зависит от данных, угроз и других характеристик системы. Поэтому универсальный набор «пароль, шифрование, резервная копия» не заменяет выбор необходимых мер.
Для заказчика полезный результат этой работы — требования с ответственными и способом проверки. В частности, согласуйте допустимую потерю данных при сбое, время восстановления и процедуру проверки копий. Значения выбирают с учётом работы клиники; произвольные «24 часа» не становятся требованием 152-ФЗ.
Источники: 152-ФЗ: локализация и меры защиты, статьи 18 и 19; Постановление Правительства от 01.11.2012 № 1119: уровни защищённости.
Что приложить к ТЗ перед оценкой разработки
Соберите согласованные решения в несколько приложений: состав данных, схему обмена, матрицу доступа и сценарии приёмки. Ниже — рабочие примеры для обсуждения с командой. Проверки проводят на искусственных данных, а спорные условия разрешают до передачи рабочих доступов.
| Требование | Как проверить |
|---|---|
| Согласован состав обмена с МИС | Сопоставить перечень полей с запросами, ответами и сохраняемыми данными. |
| Права действуют для всех способов доступа | Проверить роли и доступ к конкретным пациентам через экран, API и экспорт. |
| Описаны получатели и места обработки | Сверить схему с настройками баз, копий и внешних сервисов. |
| Состав журналов ограничен согласованной задачей | Проверить обычную операцию и ошибку интеграции на тестовых карточках. |
| Восстановление укладывается в согласованные условия | Восстановить тестовую копию, сверить записи и измерить время. |