Безпека та ідентифікація в медичних додатках: карта

Коротка відповідь: безпека в медичному додатку відповідає на чотири запитання, по черзі. Хто це? Ідентифікація: перевірений користувач (пацієнт, лікар, система) через OpenID Connect, а для лікарів – національний професійний ідентифікатор; рівень перевірки важливіший за складність пароля. Що вони можуть робити? Авторизація: токени OAuth 2.0 (перехід на 2.1) зі скоупами в синтаксисі 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; національні ID (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; гранти, обмежені метою та часом; відкликання; "break-the-glass" з обґрунтуванням та сповіщенням	Пацієнт як джерело кожної авторизації	Платформа згоди пацієнта, Запити на доступ від клініки
Підзвітність	Журнали доступу до кожного запису, видимі пацієнту; 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, описують, наскільки надійно була перевірена особа під час реєстрації, тоді як багатофакторна автентифікація та passkeys описують кожен вхід. Лікарі ідентифікуються через професійні посвідчення, які анулюються після їх звільнення.

Додаток для пацієнта, який показує повну історію хвороби, повинен знати, що спілкується саме з цим пацієнтом. Рівні гарантії ідентифікації (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 для точнішого контролю. "Break-the-glass" (екстрений доступ без згоди) є окремим, аудитованим шляхом з обов'язковим обґрунтуванням та сповіщенням пацієнта, ніколи не є стандартним. Див. Платформа згоди пацієнта.

Підзвітність: журнал, який читає пацієнт

Підзвітність у медичному додатку означає, що кожен доступ до запису, ким, коли, що і за якою згодою було здійснено, записується до журналу лише для додавання, який пацієнт може переглядати у своєму додатку, та до організаційного журналу аудиту у форматі 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 для додатків та асиметрична автентифікація клієнта для бекендів; згода за метою та тривалістю як джерело доступу кожної клініки, з відкликанням та без мовчазного "break-the-glass"; журнал доступу до кожного запису в додатку особи; шифрування під час зберігання та передачі, хостинг в ЄС, жодних SDK для реклами; ISMS відповідно до 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 →