DPIA для медичного застосунку: чекліст та шаблон

Коротка відповідь: оцінка впливу на захист даних (DPIA) — це документ, у якому ви описуєте операцію обробки, доводите її необхідність та пропорційність, оцінюєте ризики для людей, чиї дані використовуються, та фіксуєте заходи, які знижують ці ризики. Стаття 35 Загального регламенту про захист даних (GDPR) робить її обов'язковою, коли обробка, ймовірно, призведе до високого ризику, і називає обробку спеціальних категорій даних у великих масштабах, включно з медичними даними, як один із таких випадків. На практиці, кожен додаток для здоров'я з більш ніж кількома користувачами та кожна платформа медичних даних потребують її до початку обробки, з переглядом при зміні обробки. Шаблон нижче відповідає статті 35(7) та європейським рекомендаціям; завантажте його в кінці.

Коли це вимагається

Оцінка впливу на захист даних (DPIA) вимагається згідно зі статтею 35 GDPR, коли обробка, ймовірно, призведе до високого ризику. Масштабна обробка спеціальних категорій даних, таких як дані про здоров'я, автоматично підпадає під цю вимогу. Згідно з критеріями Європейської ради із захисту даних (EDPB), додаток для здоров'я зазвичай відповідає кільком пунктам (чутливі дані, масштабна обробка, вразливі особи), тому майже кожен такий додаток потребує DPIA перед початком обробки даних.

Стаття 35(3) перелічує три автоматичні тригери: систематичне та масштабне профілювання зі значними наслідками; обробка спеціальних категорій (стаття 9) або кримінальних даних у великих масштабах; систематичний масштабний моніторинг громадських місць. Критерії Європейської ради із захисту даних (від колишньої Робочої групи статті 29) додають ще шість; якщо застосовуються два або більше, проведіть DPIA: оцінка або скоринг; автоматизовані рішення з юридичними або подібними наслідками; систематичний моніторинг; конфіденційні дані; великий масштаб; зіставлення або об'єднання наборів даних; дані про вразливих осіб (пацієнти враховуються); інноваційне використання технологій; запобігання особам у здійсненні права або використанні послуги. Додаток для здоров'я зазвичай охоплює конфіденційні дані, великий масштаб, вразливих осіб і часто інноваційні технології. Національні органи також публікують списки обробки, яка завжди вимагає DPIA (стаття 35(4)); більшість з них включають додатки для здоров'я та підключені пристрої.

Чек-лист

Чек-лист для DPIA додатків для здоров'я охоплює чотири елементи статті 35(7) GDPR: опис обробки (цілі, дані, учасники, технології), оцінка необхідності та пропорційності (правова основа, мінімізація даних, права суб'єктів даних, обробники, термін зберігання), оцінка ризиків для осіб, чиї дані використовуються, та заходи для усунення цих ризиків, після чого йде консультація, затвердження та періодичний перегляд.

1. Опишіть обробку (ст. 35(7)(a))

Цілі, одна за одною: зберігання записів особи; обмін з клінікою; нагадування; анонімізована статистика; функції ШІ.
Категорії даних за призначенням, з позначкою медичних даних; джерела (особа, клініки, носимі пристрої, документи); одержувачі; термін зберігання за категорією; передача за межі ЄС та її механізм.
Учасники: контролер(и), обробники (хостинг, аналітика, інструменти підтримки, постачальники ШІ) з їхніми контрактами; інспектор із захисту даних (DPO).
Технологія: архітектура, місце зберігання даних, шифрування, ідентифікація, журналювання. Діаграма потоку даних — найшвидший спосіб виявити те, що ви забули.

2. Необхідність та пропорційність (ст. 35(7)(b))

Правова підстава згідно зі статтею 6 та винятком з пункту 2 статті 9, за призначенням (Пояснення статті 9 GDPR).
Мінімізація даних: для кожного елемента даних — чому він потрібен; що ви вирішили не збирати.
Інформація для осіб (статті 13–14) та як права (доступ, виправлення, видалення, переносимість, заперечення, відкликання згоди) здійснюються в продукті, а не електронною поштою до служби підтримки.
Обробники: наявність контрактів згідно зі статтею 28; перелік субпідрядників; права на аудит.
Зберігання та видалення: конкретні терміни та механізм, який їх забезпечує.

3. Ризики для осіб (ст. 35(7)(c)) Оцініть ймовірність та серйозність для кожної з трьох класичних подій, для кожної мети:

Незаконний доступ (злом, внутрішній доступ, надмірний обмін, клініка, яка бачить більше, ніж дозволено);
Небажані зміни (неправильні дані в записі, на який покладається лікар, помилки синхронізації, функція ШІ, яка записує дані в запис);
Зникнення (втрата запису, від якого залежить особа; захоплення облікового запису; припинення роботи постачальника). Потім специфічні для охорони здоров'я: повторна ідентифікація "анонімної" статистики; виведення висновків про стан здоров'я на основі поведінки; дискримінація, якщо дані потрапляють до страхових компаній або роботодавців; шкода від даних дітей; дані про місцезнаходження поблизу клінік; сторонні SDK у додатку, які надсилають дані рекламним мережам (найпоширеніше виявлення під час регуляторних аудитів додатків для здоров'я).

4. Заходи (ст. 35(7)(d)) Для кожного ризику — контроль та залишковий ризик: шифрування під час зберігання та передачі; надійна автентифікація; доступ, обмежений згодою та часом, з журналами, які особа може читати; псевдонімізація в аналітиці та журналах; відсутність сторонніх рекламних або відстежувальних SDK; окремі середовища та синтетичні дані для розробки; резервні копії з перевіреним відновленням; перегляд постачальників; реагування на інциденти з 72-годинним терміном; практики безпечної розробки; навчання персоналу та конфіденційність; експорт та видалення даних у продукті; кнопка "вимкнення" для інтеграцій.

5. Консультації

Записується порада DPO (ст. 35(2)); думки осіб або їхніх представників запитуються, де це доречно (ст. 35(9)), наприклад, через користувацьку панель або асоціацію пацієнтів.
Якщо залишається високий залишковий ризик, проконсультуйтеся з наглядовим органом перед обробкою (ст. 36). Більшість добре контрольованих додатків для здоров'я не досягають цієї точки; платформи, що обробляють дані для багатьох клінік, іноді досягають.

6. Підписання та перегляд

Затверджено керівництвом контролера; датовано; версіоновано.
Переглядається при зміні цілей, даних, технологій або одержувачів, і щонайменше раз на один-два роки (ст. 35(11)).

Типові висновки в DPIA додатків для здоров'я

Найпоширеніші висновки в DPIA додатків для здоров'я включають SDK для аналітики та звітності про збої, які отримують ідентифікатори разом із контекстом даних про здоров'я; push-сповіщення, що розкривають стан здоров'я на екрані блокування; співробітників служби підтримки з необмеженим доступом до баз даних; резервні копії, що зберігаються за межами ЄС; дані, що зберігаються після закриття облікового запису; екрани згоди, які об'єднують кілька цілей; а також «анонімізовані» набори даних, які все ще дозволяють ідентифікувати осіб.

Кожна з цих проблем має конкретне рішення, і саме в DPIA фіксується зобов'язання щодо його впровадження.

Шаблон

Шаблон DPIA на цій сторінці – це заповнюваний документ у форматі Markdown для додатків для здоров'я, структурований у шість розділів (опис обробки, необхідність та пропорційність, ризики для осіб, заходи, консультація, затвердження та перегляд) із таблицею ризиків та таблицею заходів. Він відповідає статті 35(7) GDPR та критеріям EDPB і є початковою структурою, а не юридичною порадою.

Завантажте шаблон DPIA. Його можна імпортувати в будь-який інструмент для роботи з документами; ваш DPO адаптує його.

В Anpheros

Anpheros підтримує DPIA для Anpheros Daily та одну для Anpheros Platform як обробника, зі структурою вище, і вибір, до якого вони призвели, видно в продукті: згода за призначенням, доступ, обмежений та зареєстрований, відсутність рекламних SDK, хостинг у ЄС, експорт та видалення в додатку. Див. Прозорість у сфері охорони здоров'я.

Ця сторінка пояснює нормативні вимоги для команд продукту та інженерії. Це не юридична консультація; тексти, посилання на які наведено в розділі "Джерела", є авторитетними, і ваш інспектор із захисту даних, повідомлений орган або юрист приймає рішення у вашому випадку. Останній перегляд: жовтень 2026 року.

Пов'язані сторінки

Джерела

Поширені запитання

Чи потрібна мені DPIA для невеликого додатка з кількома користувачами?

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

Хто пише DPIA?

Відповідальність несе контролер; на практиці власник продукту та керівник інженерної команди пишуть його за порадою DPO, оскільки вони знають потоки даних. Повне делегування написання призводить до документа, який ніхто не може підтримувати в актуальному стані.

Чи має DPIA бути опублікована?

Ні. Це внутрішній документ підзвітності, який надається наглядовому органу на запит. Багато організацій публікують резюме; EHDS та деякі національні правила вимагають прозорості щодо певної обробки.

Чим DPIA відрізняється від оцінки ризиків згідно з ISO 27001?

Оцінка ISO розглядає ризики для організації; DPIA розглядає ризики для осіб, чиї дані обробляються. Вони мають спільні засоби контролю та докази, і хороша програма безпеки живить розділ заходів DPIA.

Anpheros Platform

Спробуйте безкоштовно в пісочниці

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

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

Безкоштовно · 30 синтетичних пацієнтів · без картки

Цей посібник призначений для інформаційних цілей і не замінює медичну консультацію. Для прийняття рішень щодо вашого здоров'я зверніться до лікаря. У надзвичайній ситуації телефонуйте на місцевий номер екстреної допомоги (112 у Європі).

Написано

Команда Anpheros

Anpheros створює медичну карту, яку пацієнт контролює та може ділитися з будь-якою клінікою, на платформі HL7 FHIR R4, розташованій в ЄС. Ці посібники допоможуть вам зрозуміти та організувати своє здоров'я; вони не замінюють вашого лікаря.

Про Anpheros →