Медичні дані під GDPR: особливості застосування статті 9

Заборона як відправна точка: медичні дані та стаття 9

Медичні дані займають особливе місце в архітектурі GDPR не випадково. 

Вони не просто описують окремі факти про людину, вони здатні розповісти про її вразливості, хронічні стани, психічне здоров’я, спосіб життя та навіть майбутні ризики. Саме тому GDPR відносить інформацію, що стосується здоров’я, до спеціальних категорій персональних даних і встановлює для неї окремий, посилений режим захисту центральним елементом якого є стаття 9 GDPR.

На відміну від статті 6 GDPR, яка дозволяє обробку персональних даних за наявності однієї з правових підстав, стаття 9 починається з прямої заборони. Тобто дані про здоров’я не можна обробляти за замовчуванням. Контролер має не просто обґрунтувати свою діяльність, а спочатку зняти цю заборону, довівши, що конкретна обробка підпадає під один із чітко визначених винятків.

На практиці це означає просту річ: стаття 9 це не просто додаткова формальність, а базовий фільтр, без проходження якого будь-яка обробка вважається незаконною.

Законна обробка медичних даних: “подвійна” правова підстава

Однією з ключових особливостей обробки даних, що стосуються здоров’я, є вимога наявності так званої “подвійної” правової підстави. Це означає, що контролер повинен одночасно виконати дві кумулятивні умови:

• визначити загальну правову підставу відповідно до статті 6 GDPR;
• застосувати один із винятків, передбачених статтею 9(2) GDPR, який дозволяє обробку спеціальних категорій персональних даних.

Саме на цьому етапі на практиці виникає найбільше помилок. Стаття 9 GDPR не містить таких правових підстав, як “виконання договору” або “законний інтерес”. Відповідно, посилання лише на договір із пацієнтом або проведення LIA саме по собі не легалізує обробку медичних даних.

У практиці бізнесу та медичних організацій обробка даних про здоров’я найчастіше ґрунтується на таких винятках:

1. Явна згода суб’єкта даних. 

Йдеться не про “звичайну” згоду у розумінні статті 6 GDPR. Хоча вона має відповідати загальним вимогам (бути вільно наданою, конкретною, поінформованою та однозначною), для медичних даних застосовуються підвищені стандарти через їх чутливість. Зокрема, Європейська рада із захисту даних (EDPB) у Guidelines 05/2020 наводить приклади форм отримання явної згоди, серед яких:

• письмова форма з власноручним підписом;
• заповнення електронної форми;
• надсилання електронного листа;
• завантаження сканованої копії підписаного документа;
• використання окремого “екрану згоди” з чітким вибором “Так / Ні”.  

Попри популярність цього винятку, на практиці його застосування є обмеженим. Він зазвичай релевантний для опційних сервісів або функціональності, маркетингових активностей, аналітики чи вторинних цілей, але рідко є стабільною підставою для основних медичних процесів.

2. Цілі медицини, діагностики, лікування та управління системами охорони здоров’я.

Саме цей виняток лежить в основі повсякденної діяльності більшості медичних закладів. Водночас його застосування можливе лише за умови, що обробка здійснюється на підставі права ЄС, права держави-члена або договору з медичним працівником, який підпадає під обов’язок збереження професійної (лікарської) таємниці. За відсутності такого нормативного або договірного “якоря” покладатися на цей виняток не можна.

3. Публічний інтерес у сфері охорони здоров’я

Типовими прикладами є епідеміологічний нагляд, реагування на транскордонні загрози здоров’ю, а також забезпечення якості та безпеки лікарських засобів і медичних виробів. Простір для автономії контролера тут мінімальний: рамки обробки зазвичай чітко й детально визначаються законодавством держав-членів.

4. Наукові та статистичні дослідження

Для науково-дослідних установ цей виняток може виглядати як відносно простий шлях виходу з загальної заборони, однак він супроводжується додатковими вимогами. Зокрема, стаття 89 GDPR зобов’язує контролерів впроваджувати посилені гарантії захисту, такі як псевдонімізація, мінімізація доступу та суворі організаційні й технічні заходи безпеки. 

Що потрібно мати, щоб Article 9 працювала не лише на папері?

Правильно обраний виняток зі статті 9(2) це лише “вхідний квиток”. Далі контролер має довести, що організаційно й технічно здатен обробляти дані про здоров’я. 

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

Як мінімум очікується:

• модель ролей і доступів (RBAC), побудована на функціях і процесах, а не на формальних посадах; 
• формалізовані процедури онбордингу та оффбордингу, які гарантують, що доступ надається лише після авторизації та автоматично відкликається при зміні ролі або звільненні;
• посилена автентифікація для доступу до систем із медичними даними, зазвичай у формі багатофакторної автентифікації, з окремими вимогами для привілейованих облікових записів;
• реалізація принципів “least privilege” та “need to know” не лише на рівні політики, а й у технічних налаштуваннях систем.

Кейс: штраф HagaZiekenhuis показовий саме тим, що AP прямо прив’язала порушення до відсутності достатнього контролю внутрішніх доступів (у т.ч. слабка автентифікація) та слабкого нагляду за тим, хто і навіщо переглядає медичні картки.

На практиці це означає:

• журнали доступу, які дають змогу встановити, хто саме, коли, до яких конкретних записів або файлів, з якого середовища та в якому контексті здійснював доступ;
• процедури регулярного аналізу логів, із визначеними відповідальними особами, періодичністю перевірок і критеріями, за якими доступ визнається підозрілим або несанкціонованим;
• механізми реагування на аномалії, коли результати аналізу логів запускають подальші дії зокрема внутрішнє розслідування, обмеження доступу або інцидент-менеджмент.

Кейс: у вищезгаданій справі HagaZiekenhuis, серед іншого, AP прямо вказала, що лікарня має регулярно перевіряти, хто який файл/досьє переглядає, щоб вчасно виявляти несанкціонований доступ.

Типово увага приділяється таким аспектам:

• контрольовані процедури міграції та експорту даних, які включають мінімізацію обсягу, обмежений час зберігання, використання тимчасових сховищ і автоматичне видалення після завершення операцій;
• шифрування даних у стані зберігання та під час передачі, із належним управлінням ключами та обмеженням доступу до них;
• сегментація середовищ і доступів, зокрема розмежування продуктивних, тестових і адміністративних середовищ, а також контроль доступу до системного адміністрування;
• регулярне тестування та оцінка ефективності заходів безпеки, включно з технічними перевірками, аудитами та переглядом ризиків.

Кейс: CNIL проти Dedalus Biologie є класичним прикладом, де відсутність базових технічних та організаційних заходів (зокрема безпечних процедур міграції даних, шифрування, автоматичного видалення, обмеження доступу, моніторингу) призвела до витоку медичних даних сотень тисяч осіб і штрафу 1,5 млн євро.

Для належного управління очікується:

• DPA, який не є шаблонним, а відображає конкретні цілі обробки, категорії даних, ролі сторін і фактичні технічні та організаційні заходи;
• механізми контролю дотримання інструкцій контролера, включно з правами на перевірку та отримання підтверджень виконання заходів;
• управління субпроцесорами, з чітким порядком їх залучення, інформування та оцінки ризиків;
• due diligence та контроль трансферів, особливо у випадках передачі даних за межі ЄС.

Кейс: у CNIL проти Dedalus Biologie окремо відмічені порушення, що стосуються обробки як процесора, зокрема недотримання інструкцій контролера, а також дефекти договірного оформлення відносин.

Ефективний DPIA має:

• фіксувати рішення щодо мінімізації даних;
• описувати моделі доступу та зберігання;
• враховувати інциденти, залучення третіх сторін і трансфери;
• слугувати робочим інструментом для подальшого управління ризиками, а не разовою вправою.

Мінімальний рівень очікувань включає:

• внутрішню процедуру управління інцидентами, з чітко визначеними ролями та відповідальністю;
• критерії кваліфікації інцидентів, які дозволяють швидко визначити, чи є подія витоком персональних даних і чи виникає обов’язок повідомлення;
• підготовлені шаблони повідомлень, визначені канали комунікації та журнал прийнятих рішень;
• регулярне навчання персоналу, оскільки перший реальний інцидент найчастіше виявляє слабкі місця саме в людському факторі.

Національні особливості: як держави-члени доповнюють правила щодо медичних даних

GDPR не є єдиним та вичерпним законом для обробки медичних даних. Стаття 9(4) прямо дозволяє державам-членам запроваджувати додаткові умови або обмеження щодо обробки генетичних, біометричних та даних про здоров’я. У результаті відповідність GDPR у цій сфері майже завжди має національний вимір, який неможливо ігнорувати без комплаєнс-ризиків.

На практиці це означає, що навіть коректно обраний виняток за статтею 9(2) і формальна відповідність GDPR можуть бути недостатніми, якщо контролер не виконав додаткові вимоги національного законодавства.

Нижче наведені типові приклади того, як держави-члени “ущільнюють” правила для обробки медичних даних.

• Німеччина (BDSG §22): німецький закон не лише дозволяє обробку спеціальних категорій даних у визначених випадках, а й прямо встановлює перелік обов’язкових гарантій. Серед них: суворе обмеження доступу, технічні та організаційні заходи безпеки, псевдонімізація, шифрування та внутрішні процедури контролю. 
• Франція (Law No. 78-17): для низки обробок у сфері охорони здоров’я закон вимагає або попередньої авторизації CNIL, або чіткої відповідності затвердженим “référentiels” / “méthodologies de référence”. Відсутність такої авторизації або вихід за межі референталу розглядається як самостійне порушення, незалежно від того, чи дотримано GDPR у широкому сенсі. Показовим є кейс Cegedim Santé, де серед підстав для санкції фігурувала саме відсутність належної авторизації CNIL для обробки медичних даних.

Ці приклади добре ілюструють закономірність: у сфері медичних даних GDPR встановлює рамку, але правила гри остаточно формуються на національному рівні.

Для транскордонних продуктів або платформ, що працюють одразу в кількох державах-членах, це означає, що один універсальний GDPR-комплаєнс майже завжди буде неповним. Без системного аналізу локального законодавства та практики національних DPA ризик порушення виникає навіть тоді, коли загальноєвропейські вимоги формально виконані.

Хто може допомогти з побудовою комплаєнс-системи для роботи з медичними даними за GDPR? 

Legal IT Group мають глибоку експертизу у сфері захисту медичних персональних даних у контексті GDPR та супроводжують медичні заклади, телемедичні платформи й MedTech-компанії у вибудові комплаєнс-систем відповідно до статей 6 і 9 GDPR, практики національних наглядових органів ЄС та рекомендацій EDPB.

Команда працює з повним циклом обробки даних про здоров’я: від визначення коректної “подвійної” правової підстави, підготовки форм явної згоди та політик приватності до розробки внутрішніх порядків обробки, моделей управління доступом, логування, DPIA та планів реагування на інциденти. Юристи Legal IT Group також допомагають структурувати відносини з процесорами, підготувати DPA, NDA та вибудувати контроль за субпроцесорами і трансферами даних.

Такий системний підхід дозволяє не лише формально відповідати вимогам статті 9 GDPR, а й побудувати керовану, доказову та стійку комплаєнс-модель, здатну витримати перевірки національних DPA та регуляторні розслідування.