Коротка відповідь: програмне забезпечення, яке працює з медичними даними, підпадає під дію чотирьох груп правил одночасно. Захист даних визначає, що ви можете робити з персональними медичними даними: Стаття 9 GDPR в ЄС, HIPAA та сукупність законів штатів у США. Правила системи охорони здоров'я визначають, як дані мають переміщуватися та обмінюватися: European Health Data Space (EHDS) в ЄС, TEFCA, USCDI та правила щодо блокування інформації в США. Безпека продукції застосовується, коли програмне забезпечення виконує медичні функції: Medical Device Regulation (MDR) та In Vitro Diagnostic Regulation (IVDR) в ЄС, правила FDA в США, а також IEC 62304 та ISO 13485 як інженерні стандарти та стандарти якості, що стоять за ними. Безпека встановлює базовий рівень, якого повинні дотримуватися всі: ISO 27001 та 27799, NIS2 для критично важливих секторів, HIPAA Security Rule. Ідентифікація (eIDAS та EU Digital Identity Wallet, NHS login, національні посвідчення особи) охоплює всі чотири сфери.
Карта
Карта регулювання медичних даних групує правила для програмного забезпечення, яке обробляє медичні дані, за категоріями: захист даних (Стаття 9 GDPR, HIPAA, закони штатів США), правила системи охорони здоров'я (EHDS, Cures Act, TEFCA), безпека продукції (MDR, IVDR, FDA), інженерні та якісні стандарти (IEC 62304, ISO 13485), безпека (ISO 27001, ISO 27799, NIS2, Правило безпеки HIPAA) та ідентифікація (eIDAS 2).
| Група | Правило | Застосовується до | Що вимагається |
|---|---|---|---|
| Захист даних | GDPR, Ст. 9 та Ст. 35 | Будь-хто, хто обробляє медичні дані мешканців ЄС | Правова підстава згідно зі Ст. 9(2), DPIA, DPO для масштабної обробки, права, повідомлення про порушення протягом 72 годин |
| Захист даних | HIPAA (Правила конфіденційності, безпеки, порушень) | Американські суб'єкти, що підпадають під дію правил, та їхні ділові партнери | Дозволені види використання, заходи безпеки, повідомлення про порушення; не охоплює більшість споживчих додатків |
| Захист даних | Закони штатів США (CCPA/CPRA, Washington My Health My Data…) | Компанії, що обробляють дані мешканців | Згода на використання медичних даних споживачів, права на видалення, обмеження продажу |
| Система охорони здоров'я | EHDS, Регламент (ЄС) 2025/327 | Системи EHR, програми для здоров'я, що претендують на взаємодію, власники даних, органи доступу до медичних даних | Доступ пацієнта та портативність у європейському форматі обміну, обов'язковий MyHealth@EU, дозволи на вторинне використання |
| Система охорони здоров'я | 21st Century Cures Act, правила ONC HTI, TEFCA | Сертифіковані медичні ІТ-системи США, постачальники, мережі | API FHIR, дані USCDI, відсутність блокування інформації, загальнонаціональний обмін |
| Безпека продукції | MDR 2017/745, IVDR 2017/746 | Програмне забезпечення з медичним призначенням для пацієнтів ЄС | Класифікація, оцінка відповідності, клінічна оцінка, постринковий нагляд, маркування CE |
| Безпека продукції | FDA (21 CFR 820/QMSR, 510(k), De Novo, PMA) | Програмне забезпечення як медичний виріб для США | Шлях до виходу на ринок за класами, система якості, документація з кібербезпеки |
| Інженерія | IEC 62304, IEC 82304-1, ISO 14971 | Команди розробників програмного забезпечення для медичних виробів | Життєвий цикл програмного забезпечення за класом безпеки, управління ризиками |
| Якість | ISO 13485 | Виробники медичних виробів | Система управління якістю, що охоплює проєктування, виробництво, скарги |
| Безпека | ISO/IEC 27001, ISO 27799, ISO 27701 | Будь-яка організація; специфічні рекомендації для охорони здоров'я | Система управління інформаційною безпекою, заходи безпеки в охороні здоров'я, розширення конфіденційності |
| Безпека | NIS2, Директива 2022/2555 | Постачальники медичних послуг, виробники медичних виробів, постачальники хмарних та цифрових послуг, що перевищують порогові значення розміру | Заходи ризику, повідомлення про інциденти протягом 24/72 годин, відповідальність керівництва |
| Безпека | HIPAA Security Rule | Американські суб'єкти, що підпадають під дію правил, та ділові партнери | Адміністративні, фізичні та технічні заходи безпеки; аналіз ризиків |
| Ідентифікація | eIDAS 2 та EU Digital Identity Wallet | Служби, що перевіряють ідентичність громадян ЄС | Прийняття гаманця для надійної ідентифікації з 2026–2027 років |
Хто підпадає під дію чого
Які правила щодо медичних даних застосовуються, залежить від того, що робить програмне забезпечення. Споживчий додаток без медичних заяв підпадає під дію Статті 9 GDPR, DPIA та практики безпеки; додавання інтерпретації робить його медичним виробом згідно з MDR; платформа FHIR є обробником даних згідно з GDPR, а іноді й згідно з NIS2; лікарня несе відповідальність за все це, плюс NIS2 як важлива організація.
- Споживчий додаток для здоров'я без медичних заяв (щоденник симптомів, запис результатів лабораторних досліджень): GDPR Стаття 9 з явною згодою, DPIA, практика безпеки на рівні ISO 27001 та маркування програм для здоров'я EHDS, якщо він претендує на підключення до систем EHR. Не є медичним виробом, доки його призначене використання залишається немедичним. У США: правила FTC та закони штатів про конфіденційність медичних даних, а не HIPAA.
- Той самий додаток з функцією інтерпретації («ваш результат свідчить…»): медичний виріб згідно з Правилом 11 MDR, зазвичай клас IIa, з підтримкою IEC 62304 та ISO 13485. Див. Чи є додаток для здоров'я медичним виробом? та Класи SaMD.
- Постачальник платформи або інтеграції FHIR: GDPR як обробник (контракти за Статтею 28), ISO 27001, можливо NIS2 як постачальник цифрової інфраструктури або ІКТ-послуг, зобов'язання EHDS, коли він є частиною системи EHR, HIPAA як діловий партнер у США.
- Лікарня: все вищезазначене як контролер та оператор, плюс NIS2 як основний суб'єкт, національні закони про медичні записи та терміни EHDS для підключення до національної інфраструктури.
- Дослідницька платформа: GDPR Стаття 9(2)(j) та Стаття 89, розділ EHDS про вторинне використання (дозволи від органу доступу до медичних даних, безпечні середовища обробки) та стандарти анонімізації. Див. Вторинне використання медичних даних.
У якому порядку
Додатків до вимог щодо медичних даних найкраще підходити у фіксованому порядку: спочатку напишіть про передбачуване призначення, оскільки воно визначає, чи є програмне забезпечення медичним виробом; потім захист даних (правова підстава, DPIA, контракти з обробником); потім базовий рівень безпеки відповідно до ISO 27001; потім вимоги до сумісності, такі як FHIR та EHDS або USCDI; потім шлях медичного виробу, якщо такий є; нарешті, транскордонні питання.
- Визначте призначене використання в письмовій формі. Це визначає, чи є ви медичним виробом, і все інше випливає з цього.
- Спочатку захист даних: правова підстава, DPIA, контракти з обробниками, DPO. Це необхідно до першого реального користувача, у будь-якому сценарії. Див. GDPR Стаття 9 для медичних даних та DPIA для додатка для здоров'я.
- Базовий рівень безпеки: ISMS відповідно до ISO 27001, зіставлений із заходами безпеки в охороні здоров'я згідно з 27799; це також відповідає більшості вимог NIS2 та HIPAA Security Rule. Див. ISO 27001 проти ISO 27799 та NIS2 для лікарень та постачальників.
- Вимоги до взаємодії: FHIR та формат обміну вашого ринку (EHDS, USCDI/US Core), щоб продукт не був виключений з національної інфраструктури. Див. Пояснення USCDI та Пояснення TEFCA.
- Шлях медичного виробу, якщо є: класифікація, система якості, життєвий цикл, шлях до повідомленого органу або FDA. Заплануйте рік.
- Міжнародний рівень: відмінності HIPAA та GDPR при обслуговуванні обох ринків (HIPAA проти GDPR), механізми передачі, місце розміщення.
Позиція Anpheros
Anpheros Daily – це особистий медичний запис із заявленим немедичним призначенням: він зберігає, відображає та ділиться даними, але не інтерпретує та не надає рекомендацій. Anpheros Platform – це бекенд FHIR R4, запропонований клінікам та розробникам як обробник відповідно до Статті 28 GDPR, з контрольованою пацієнтом згодою та журналами доступу. Сторінки з нормативними актами в цьому кластері описують правила, як вони застосовуються до будь-якого продукту такого типу; сторінка про прозорість описує, як Anpheros застосовує їх до себе.
Ця сторінка пояснює нормативні акти для команд з розробки продуктів та інженерії. Це не юридична консультація; тексти, посилання на які наведено в розділі «Джерела», є авторитетними, і ваш співробітник з питань захисту даних, повідомлений орган або юрисконсульт приймають рішення у вашому випадку. Останній перегляд: жовтень 2026 року.
Пов'язані сторінки
- Чи є додаток для здоров'я медичним виробом? EU MDR Правило 11
- Ваші медичні дані в ЄС: GDPR, EHDS та ваші права
- GDPR Стаття 9 для медичних даних
- DPIA для додатка для здоров'я
- HIPAA проти GDPR
- NIS2 для лікарень та постачальників медичних технологій
- Стандарти взаємодії в охороні здоров'я: карта
- GDPR для розробників (сайт розробника)
- Національні електронні медичні записи в Європі та США
- MyHealth@EU та транскордонна медична картка пацієнта
- EU AI Act та ШІ в охороні здоров'я
- Вторинне використання медичних даних
- Безпека та ідентифікація в додатках для здоров'я
Джерела
- Регламент (ЄС) 2016/679 (GDPR), EUR-Lex
- Регламент (ЄС) 2025/327 (European Health Data Space), EUR-Lex
- Регламент (ЄС) 2017/745 (MDR), EUR-Lex
- Регламент (ЄС) 2017/746 (IVDR), EUR-Lex
- Директива (ЄС) 2022/2555 (NIS2), EUR-Lex
- HHS: HIPAA для професіоналів
- ASTP/ONC: Trusted Exchange Framework and Common Agreement
- ISO/IEC 27001:2022
Поширені запитання
Чи застосовується GDPR до американської компанії з користувачами з ЄС?
Так, відповідно до Статті 3(2), як тільки вона пропонує послуги особам в ЄС або відстежує їхню поведінку, незалежно від того, де розташовані сервери. Тоді їй потрібен представник в ЄС, правова підстава згідно зі Статтею 9 та механізм законної передачі даних.
Чи є HIPAA суворішим за GDPR?
Жоден з них не є суворо суворішим. HIPAA має вужчий обсяг (тільки суб'єкти, що підпадають під дію правил, та ділові партнери) і більш конкретний щодо заходів безпеки; GDPR є ширшим (будь-хто, хто обробляє дані мешканців ЄС), базується на правах і вимагає правової підстави для кожного використання. Продукт, що працює на обох ринках, повинен відповідати обом.
Чи замінює EHDS GDPR для медичних даних?
Ні. EHDS базується на GDPR і додає зобов'язання для систем EHR, доступу пацієнтів, транскордонного обміну та вторинного використання. GDPR залишається основою для кожної операції обробки.
З чого почати, якщо у мене немає команди з питань відповідності?
Напишіть призначене використання, проведіть DPIA за шаблоном, прийміть базовий рівень безпеки в стилі ISO 27001 та використовуйте FHIR з профілями вашого ринку. Ці чотири кроки охоплюють більшість того, що запитає перший аудит або перший клієнт-лікарня.
Спробуйте безкоштовно в пісочниці
Перший запит FHIR за 5 хвилин. API стандарту HL7 FHIR R4 з вбудованою згодою пацієнта: спробуйте в пісочниці, а потім підключіть власну програму чи клінічну систему.
Безкоштовно · 30 синтетичних пацієнтів · без картки
Anpheros створює медичну карту, яку пацієнт контролює та може ділитися з будь-якою клінікою, на платформі HL7 FHIR R4, розташованій в ЄС. Ці посібники допоможуть вам зрозуміти та організувати своє здоров'я; вони не замінюють вашого лікаря.
Про Anpheros →