Безопасность и идентификация в медицинских приложениях: карта

Краткий ответ: безопасность в приложении для здоровья отвечает на четыре вопроса, по порядку. Кто это? Идентификация: проверенный пользователь (пациент, врач, система) через OpenID Connect, а для врачей — национальный профессиональный идентификатор; уровень проверки важнее надежности пароля. Что они могут делать? Авторизация: токены OAuth 2.0 (переход на 2.1) с областями действия (scopes) в синтаксисе SMART on FHIR, основанные на согласии пациента на определенную цель и срок, применяемые на уровне данных. Что они сделали? Подотчетность: журнал доступа, который пациент может прочитать, и FHIR AuditEvent для организации. Безопасны ли данные при хранении, передаче и в резервных копиях? Защита: шифрование, управление ключами, сегментация, проверенные восстановления. Вокруг них: основа ISO 27001 и 27799, NIS2 и Правило безопасности HIPAA, а также специфические угрозы для медицинских данных (внутренний просмотр, неправильное внесение данных, программы-вымогатели).

Карта

Безопасность и идентификация в медицинском приложении состоят из семи уровней: идентификация через OpenID Connect и национальные или профессиональные удостоверения, авторизация через OAuth 2.0 и области действия SMART on FHIR, согласие как источник каждого разрешения, подотчетность через журналы доступа и FHIR AuditEvent, защита через шифрование и резервное копирование, базовый уровень ISO 27001, ISO 27799, NIS2 и HIPAA, а также обмен данными по инициативе пациента.

Уровень	Стандарт или практика	Что это дает	Страница
Идентификация	OpenID Connect; национальные идентификаторы (eIDAS, NHS login, GesundheitsID); профессиональные идентификаторы (eHBA, CPS, UZI)	Проверенный субъект с уровнем подтверждения	SMART App Launch объяснение
Авторизация	OAuth 2.0 и 2.1 (PKCE обязательно, без неявных или парольных предоставлений); области действия SMART on FHIR (patient/Observation.rs); серверные службы с асимметричной аутентификацией клиента	Токены, связанные с пользователем, контекстом пациента и областью действия	SMART App Launch объяснение, SMART on FHIR серверная часть
Согласие	FHIR Consent; предоставления, ограниченные целью и временем; отзыв; экстренный доступ с обоснованием и оповещением	Пациент как источник каждой авторизации	Платформа согласия пациента, Запросы на доступ в клинике
Подотчетность	Журналы доступа к каждой записи, видимые пациенту; FHIR AuditEvent; защита от несанкционированного доступа; хранение	Кто, что, когда видел, почему	Кто просматривал мою медицинскую карту?
Защита	TLS 1.2+, шифрование при хранении с управляемыми ключами, шифрование на уровне полей для идентификаторов, изолированные среды, резервные копии с проверенным восстановлением	Конфиденциальность и доступность	ISO 27001 против ISO 27799
Основа	Система менеджмента информационной безопасности ISO 27001, элементы управления для здравоохранения ISO 27799, меры NIS2, Правило безопасности HIPAA, национальные схемы (HDS, DSPT, C5)	Что ожидают больницы, аудиторы и регуляторы	NIS2 для больниц и поставщиков, HIPAA против GDPR
Обмен данными	SMART Health Links и Cards; проверяемые учетные данные	Обмен данными по инициативе пациента с помощью ссылки или QR-кода, с возможностью отзыва	SMART Health Links объяснение

Идентификация: подтверждение вместо паролей

Идентификация в медицинском приложении зависит от степени подтверждения, а не от сложности пароля: уровни подтверждения личности, такие как NIST IAL, eIDAS substantial и high, или NHS login P9, описывают, насколько надежно человек был проверен при регистрации, в то время как многофакторная аутентификация и парольные ключи описывают каждый вход в систему. Медицинские работники идентифицируются через профессиональные удостоверения, которые отзываются при их увольнении.

Приложение для пациента, отображающее полную историю болезни, должно быть уверено, что общается именно с этим пациентом. Уровни подтверждения личности (IAL NIST, существенный и высокий уровень eIDAS, NHS login P9) описывают, насколько надежно личность была проверена при регистрации; надежность аутентификации (многофакторная, passkeys) описывает каждый вход в систему. Больницы и национальные системы все чаще требуют подтвержденные личности из признанных схем вместо самостоятельной регистрации, а EU Digital Identity Wallet станет общепринятым средством. Для врачей профессиональный идентификатор (и его отзыв при увольнении) является основной записью о том, кто вообще может действовать как врач.

Авторизация: согласие становится областями действия

Авторизация в записи, контролируемой пациентом, переводит согласие пациента, например, разрешение клинике читать результаты лабораторных исследований и диагнозы в течение 90 дней, в области действия OAuth и контекст пациента в токене, в синтаксисе SMART on FHIR, таком как patient/Observation.rs, применяемое на уровне данных при каждом запросе и отзываемое, когда пациент отзывает согласие. Режим «Break-the-glass» — это отдельный, аудируемый путь.

В системе, управляемой пациентом, согласие пациента является политикой: эта клиника может читать мои результаты анализов и диагнозы в течение 90 дней. Система преобразует его в области действия OAuth и контекст (какой пациент, какие ресурсы, какие операции) в токене, который получает система клиники, применяет их к каждому запросу на уровне данных и отзывает при отзыве пациентом. Синтаксис областей действия SMART on FHIR (patient/Observation.rs, patient/Condition.rs) является универсальным языком для этого; гранулированные области действия (по категориям или кодам) существуют в SMART v2 для более точного контроля. Экстренный доступ (доступ в чрезвычайной ситуации без согласия) — это отдельный, аудируемый путь с обязательным обоснованием и оповещением пациента, никогда не являющийся стандартным. См. Платформа согласия пациента.

Подотчетность: журнал, который читает пациент

Подотчетность в медицинском приложении означает, что каждый доступ к записи, кем, когда, к чему и по какому согласию, записывается в журнал только для добавления, который пациент может прочитать в своем приложении, и в организационный журнал аудита в формате FHIR AuditEvent. Стандарт ISO 27799 рассматривает это как обязательное требование, а видимый журнал является самым сильным сдерживающим фактором для несанкционированного доступа со стороны инсайдеров.

Каждый доступ к записи, кем, когда, что, на основании какого согласия, записывается в неизменяемый журнал, который пациент может прочитать в своем приложении, и в организационный журнал аудита (FHIR AuditEvent) для групп безопасности. ISO 27799 рассматривает это как обязательное для медицинской информации; принцип прозрачности GDPR и права пациентов EHDS указывают в том же направлении; самая сильная реальная сдерживающая сила против внутреннего просмотра — это видимый журнал. См. Кто просматривал мою медицинскую карту?.

Защита: инженерная основа

Инженерная основа для защиты медицинских данных включает TLS везде, шифрование при хранении с управляемыми, сменяемыми ключами, отдельное шифрование или токенизацию для прямых идентификаторов, изолированные среды с синтетическими данными вне производственной среды, доступ с наименьшими привилегиями с многофакторной аутентификацией для администраторов, управление секретами и уязвимостями, зашифрованные резервные копии, протестированные восстановлением против программ-вымогателей, и реагирование на инциденты в рамках сроков GDPR и NIS2.

TLS везде, с современными шифрами и закреплением сертификатов в приложениях, где это уместно; шифрование при хранении с ключами в управляемой службе ключей и их ротацией; отдельное шифрование или токенизация для прямых идентификаторов; разделение производственной среды от среды разработки, с синтетическими данными вне производственной среды; доступ по принципу наименьших привилегий для персонала, отсутствие общих учетных записей, многофакторная аутентификация для всего административного доступа; управление секретами; управление зависимостями и уязвимостями с раскрытием информации; зашифрованные резервные копии, проверенные восстановлением и защищенные от программ-вымогателей, которые неоднократно поражали больницы и лаборатории (WannaCry в 2017 году, больница в Дюссельдорфе в 2020 году, Change Healthcare и Synnovis в 2024 году). Реагирование на инциденты с 72-часовыми сроками GDPR и 24-часовыми сроками NIS2 в одном плане действий.

Угрозы, специфичные для медицинских данных

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

Внутренний просмотр записей знакомых или публичных лиц: доступ на основе отношений и видимые журналы.
Неправильное внесение данных между пациентами: сопоставление личности и происхождение данных, а не только контроль доступа.
Чрезмерно широкое предоставление доступа: клиника, получившая доступ ко "всему" на год; области действия и сроки с разумными значениями по умолчанию.
Приложения с рекламными SDK: никаких сторонних трекеров в чем-либо, обрабатывающем медицинские данные.
Внедрение через документы в функции ИИ: контент — это данные, а не инструкции (RAG для медицинских карт).
Длительное хранение: записи хранятся десятилетиями; ключи, форматы и правила доступа должны пережить персонал и поставщиков.

В Anpheros

Anpheros применяет карту безопасности к себе с помощью OAuth 2.0 с PKCE для приложений и асимметричной аутентификации клиентов для серверных систем, согласия по назначению и продолжительности как источника доступа каждой клиники, журнала доступа к каждой записи в приложении пользователя, шифрования при хранении и передаче, размещения серверов в ЕС, отсутствия рекламных SDK и ISMS в соответствии со стандартами ISO 27001 и 27799.

Anpheros применяет эту карту к себе: OAuth 2.0 с PKCE для приложений и асимметричную аутентификацию клиента для серверных служб; согласие по цели и сроку как источник доступа каждой клиники, с возможностью отзыва и без скрытого экстренного доступа; журнал доступа к каждой записи в приложении пользователя; шифрование при хранении и передаче, размещение в ЕС, отсутствие рекламных SDK; система менеджмента информационной безопасности по ISO 27001 с элементами управления для здравоохранения ISO 27799. На сайте для разработчиков документированы аутентификация, согласие и безопасность.

Связанные страницы

Источники

Частые вопросы

Чем OAuth 2.1 отличается от 2.0?

OAuth 2.1 объединяет 2.0 с лучшими практиками безопасности: PKCE требуется для всех клиентов, неявные и парольные предоставления удалены, URI перенаправления должны точно совпадать, а токены обновления для общедоступных клиентов должны быть связаны или ротированы. SMART on FHIR v2 уже требует большинства из этого.

Что такое экстренный доступ (break-the-glass)?

Экстренный доступ к записи без предварительного согласия пациента, осуществляемый врачом, который указывает обоснование. Это должно быть редким явным действием, регистрироваться, проверяться и сообщаться пациенту; это никогда не является стандартным путем доступа.

Почему пациенты должны видеть журнал доступа?

Потому что это самая сильная мера против ненадлежащего доступа и самое четкое выражение контроля: человек видит, какая клиника, что и когда просмотрела, и может отозвать доступ. ISO 27799 и EHDS указывают в том же направлении.

Нужна ли мне отдельная система аудита?

Вам нужен неизменяемый журнал аудита (FHIR AuditEvent или эквивалент), который приложение не может изменить, хранимый в соответствии с политикой, и основанное на нем представление для пациента. Является ли это отдельной системой или защищенным хранилищем внутри платформы — это выбор реализации.

Anpheros Platform

Попробуйте бесплатно в песочнице

Первый запрос FHIR за 5 минут. API HL7 FHIR R4 с встроенным согласием пациента: попробуйте в песочнице, затем подключите свое приложение или систему клиники.

Создать бесплатную песочницу Читать руководства для разработчиков →

Бесплатно · 30 синтетических пациентов · без карты

Это руководство носит информационный характер и не заменяет консультацию врача. Решения о своём здоровье принимайте вместе с врачом. В экстренной ситуации звоните по местному номеру экстренной помощи (112 в Европе).

Автор

Команда Anpheros

Anpheros создает медицинскую карту, которую пациент контролирует и может делиться с любой клиникой, на платформе HL7 FHIR R4, базирующейся в ЕС. Эти руководства помогут вам понять и организовать свое здоровье; они не заменяют вашего врача.

О Anpheros →