Regulacje

Ocena skutków ochrony danych (DPIA) dla aplikacji zdrowotnej: lista kontrolna i szablon do wypełnienia

Ocena skutków ochrony danych (DPIA) dla aplikacji zdrowotnych: kiedy wymagana, art. 35 RODO, lista kontrolna, ryzyka, zabezpieczenia, konsultacje z organem nadzorczym. Pobierz szablon Markdown.

autor Opublikowano 7 min czytania

Krótka odpowiedź: ocena skutków ochrony danych (OSOD) to dokument, w którym opisujesz operację przetwarzania, wykazujesz jej niezbędność i proporcjonalność, oceniasz ryzyko dla osób, których dane są wykorzystywane, oraz dokumentujesz środki, które to ryzyko zmniejszają. Artykuł 35 RODO wymaga jej, gdy przetwarzanie może powodować wysokie ryzyko, i wymienia przetwarzanie na dużą skalę szczególnych kategorii danych, w tym danych o stanie zdrowia, jako taki przypadek. W praktyce każda aplikacja zdrowotna z więcej niż kilkoma użytkownikami i każda platforma danych o stanie zdrowia potrzebuje jej przed rozpoczęciem przetwarzania, z przeglądem przy zmianie przetwarzania. Poniższy szablon jest zgodny z art. 35 ust. 7 RODO i wytycznymi europejskimi; można go pobrać na końcu.

Kiedy jest wymagana

Ocena skutków dla ochrony danych (DPIA) jest wymagana na mocy art. 35 RODO, gdy przetwarzanie danych prawdopodobnie spowoduje wysokie ryzyko. Masowe przetwarzanie szczególnych kategorii danych, takich jak dane dotyczące zdrowia, jest automatycznie traktowane jako taki przypadek. Zgodnie z kryteriami Europejskiej Rady Ochrony Danych (EROD), aplikacja zdrowotna zazwyczaj spełnia kilka warunków (dane wrażliwe, przetwarzanie na dużą skalę, osoby szczególnie narażone), dlatego prawie każda aplikacja zdrowotna wymaga DPIA przed rozpoczęciem przetwarzania danych.

Artykuł 35 ust. 3 wymienia trzy automatyczne wyzwalacze: systematyczne i obszerne profilowanie o znaczących skutkach; przetwarzanie na dużą skalę szczególnych kategorii danych (art. 9) lub danych o charakterze kryminalnym; systematyczne monitorowanie na dużą skalę miejsc dostępnych publicznie. Kryteria Europejskiej Rady ds. Ochrony Danych (z byłej Grupy Roboczej ds. Ochrony Danych Osobowych na mocy Artykułu 29) dodają sześć kolejnych; jeśli zastosowanie mają dwa lub więcej z nich, przeprowadź OSOD: ocena lub scoring; zautomatyzowane decyzje o skutkach prawnych lub podobnych; systematyczne monitorowanie; dane wrażliwe; przetwarzanie na dużą skalę; dopasowywanie lub łączenie zbiorów danych; dane dotyczące osób wrażliwych (pacjenci się liczą); innowacyjne wykorzystanie technologii; uniemożliwianie osobom korzystania z prawa lub usługi. Aplikacja zdrowotna zazwyczaj dotyka danych wrażliwych, przetwarzania na dużą skalę, osób wrażliwych i często innowacyjnej technologii. Władze krajowe publikują również wykazy przetwarzania, które zawsze wymaga OSOD (art. 35 ust. 4); większość z nich obejmuje aplikacje zdrowotne i urządzenia połączone.

Lista kontrolna

Lista kontrolna DPIA dla aplikacji zdrowotnej obejmuje cztery elementy określone w art. 35 ust. 7 RODO: opis przetwarzania (cele, dane, podmioty, technologia), ocena konieczności i proporcjonalności (podstawa prawna, minimalizacja danych, prawa osób, podmioty przetwarzające, okres przechowywania), ocena ryzyka dla osób, których dane są wykorzystywane, oraz środki zaradcze, a następnie konsultacje, zatwierdzenie i okresowy przegląd.

1. Opis przetwarzania (art. 35 ust. 7 lit. a)

  • Cele, jeden po drugim: przechowywanie danych osoby; udostępnianie klinice; przypomnienia; anonimowe statystyki; funkcje AI.
  • Kategorie danych na cel, z zaznaczeniem danych o stanie zdrowia; źródła (osoba, kliniki, urządzenia noszone, dokumenty); odbiorcy; okres przechowywania na kategorię; transfery poza UE i ich mechanizm.
  • Podmioty: administrator(zy), podmioty przetwarzające (hosting, analityka, narzędzia wsparcia, dostawcy AI) wraz z ich umowami; IOD.
  • Technologia: architektura, lokalizacja danych, szyfrowanie, tożsamość, logowanie. Schemat przepływu danych to najszybszy sposób na znalezienie tego, czego zapomniano.

2. Niezbędność i proporcjonalność (art. 35 ust. 7 lit. b)

  • Podstawa prawna na mocy art. 6 i wyjątek z art. 9 ust. 2, na cel (Artykuł 9 RODO wyjaśniony).
  • Minimalizacja danych: dla każdego elementu danych, dlaczego jest potrzebny; czego zdecydowano się nie zbierać.
  • Informacje dla osób (art. 13–14) i sposób realizacji praw (dostępu, sprostowania, usunięcia, przenoszenia, sprzeciwu, wycofania zgody) w produkcie, a nie przez e-mail do wsparcia.
  • Podmioty przetwarzające: umowy z art. 28; podwykonawcy wymienieni; prawa do audytu.
  • Przechowywanie i usuwanie: konkretne okresy i mechanizm, który je egzekwuje.

3. Ryzyko dla osób (art. 35 ust. 7 lit. c) Oceń prawdopodobieństwo i dotkliwość dla każdego z trzech klasycznych zdarzeń, dla każdego celu:

  • Nieuprawniony dostęp (naruszenie, dostęp wewnętrzny, nadmierne udostępnianie, klinika widząca więcej niż zatwierdzono);
  • Niepożądana modyfikacja (błędne dane w rekordzie, na którym polega lekarz, błędy synchronizacji, funkcja AI zapisująca do rekordu);
  • Zniknięcie (utrata rekordu, od którego osoba zależy; przejęcie konta; zamknięcie działalności przez dostawcę). Następnie specyficzne dla zdrowia: ponowna identyfikacja "anonimowych" statystyk; wnioskowanie o schorzeniach na podstawie zachowania; dyskryminacja, jeśli dane trafią do ubezpieczycieli lub pracodawców; szkody z danych dzieci; dane lokalizacyjne wokół klinik; zewnętrzne zestawy SDK w aplikacji wysyłające dane do sieci reklamowych (najczęstsze ustalenie w audytach regulacyjnych aplikacji zdrowotnych).

4. Środki (art. 35 ust. 7 lit. d) Dla każdego ryzyka, kontrola i ryzyko szczątkowe: szyfrowanie w spoczynku i w tranzycie; silne uwierzytelnianie; dostęp ograniczony przez zgodę i czas, z logami dostępnymi dla osoby; pseudonimizacja w analizach i logach; brak zewnętrznych zestawów SDK do reklam lub śledzenia; oddzielne środowiska i dane syntetyczne do rozwoju; kopie zapasowe z przetestowanym przywracaniem; przegląd dostawców; reagowanie na incydenty z 72-godzinnym zegarem; bezpieczne praktyki programistyczne; szkolenie personelu i poufność; eksport i usuwanie danych w produkcie; wyłącznik awaryjny dla integracji.

5. Konsultacje

  • Opinia IOD jest rejestrowana (art. 35 ust. 2); poglądy osób lub ich przedstawicieli są zasięgane w odpowiednich przypadkach (art. 35 ust. 9), na przykład poprzez panel użytkowników lub stowarzyszenie pacjentów.
  • Jeśli pozostaje wysokie ryzyko szczątkowe, przed przetwarzaniem należy skonsultować się z organem nadzorczym (art. 36). Większość dobrze kontrolowanych aplikacji zdrowotnych nie osiąga tego punktu; platformy przetwarzające dla wielu klinik czasami tak.

6. Zatwierdzenie i przegląd

  • Zatwierdzone przez kierownictwo administratora; datowane; wersjonowane.
  • Przeglądane przy zmianie celów, danych, technologii lub odbiorców, a co najmniej raz na rok lub dwa lata (art. 35 ust. 11).

Typowe ustalenia w OSOD aplikacji zdrowotnych

Najczęstsze ustalenia w DPIA aplikacji zdrowotnych to: zestawy SDK do analityki i raportowania awarii, które odbierają identyfikatory wraz z kontekstem zdrowotnym; powiadomienia push ujawniające schorzenia na ekranie blokady; personel wsparcia z nieograniczonym dostępem do bazy danych; kopie zapasowe przechowywane poza UE; dane usuwane po zamknięciu konta; ekrany zgody łączące wiele celów; oraz zbiory danych „zanonimizowane”, które nadal pozwalają na identyfikację osób.

Każdy z tych problemów ma konkretne rozwiązanie, a DPIA jest miejscem, w którym zobowiązujemy się do jego wdrożenia.

Szablon

Szablon DPIA dostępny na tej stronie to wypełnialny dokument w formacie Markdown przeznaczony dla aplikacji zdrowotnej. Jest on podzielony na sześć sekcji (opis przetwarzania, konieczność i proporcjonalność, ryzyko dla osób, środki zaradcze, konsultacje, zatwierdzenie i przegląd) wraz z tabelą ryzyka i tabelą środków. Szablon jest zgodny z art. 35 ust. 7 RODO i kryteriami EROD, stanowi strukturę wyjściową, a nie poradę prawną.

Pobierz szablon DPIA. Można go zaimportować do dowolnego narzędzia do edycji dokumentów; Twój inspektor ochrony danych (DPO) dostosuje go.

W Anpheros

Anpheros utrzymuje OSOD dla Anpheros Daily i jedną dla Anpheros Platform jako podmiot przetwarzający, zgodnie z powyższą strukturą, a wybory, do których doprowadziły, są widoczne w produkcie: zgoda na cel, dostęp ograniczony i rejestrowany, brak zestawów SDK do reklam, hosting w UE, eksport i usuwanie w aplikacji. Zobacz Przejrzystość zdrowotna.

Ta strona wyjaśnia przepisy dla zespołów produktowych i inżynieryjnych. Nie jest to porada prawna; teksty podane w sekcji Źródła są autorytetem, a Twój inspektor ochrony danych, organ notyfikowany lub doradca decyduje w Twojej sprawie. Ostatnia aktualizacja: październik 2026.

Powiązane strony

Źródła

Najczęstsze pytania

Czy potrzebuję OSOD dla małej aplikacji z niewielką liczbą użytkowników?

Jeśli przetwarza dane o stanie zdrowia, prawie zawsze tak: dane wrażliwe plus osoby wrażliwe już spełniają kryterium dwóch kryteriów, a kilka krajowych list wymienia aplikacje zdrowotne wprost. OSOD dla małej aplikacji jest po prostu krótsza.

Kto pisze OSOD?

Odpowiedzialny jest administrator; w praktyce właściciel produktu i kierownik ds. inżynierii piszą ją z poradą IOD, ponieważ znają przepływy danych. Zlecenie jej w całości skutkuje dokumentem, którego nikt nie jest w stanie utrzymać aktualnym.

Czy OSOD musi być publikowana?

Nie. Jest to wewnętrzny dokument rozliczalności przedstawiany organowi nadzorczemu na żądanie. Wiele organizacji publikuje podsumowanie; EHDS i niektóre przepisy krajowe wymagają przejrzystości w zakresie określonego przetwarzania.

Czym OSOD różni się od oceny ryzyka zgodnie z ISO 27001?

Ocena ISO analizuje ryzyko dla organizacji; OSOD analizuje ryzyko dla osób, których dane są przetwarzane. Dzielą one kontrole i dowody, a dobry program bezpieczeństwa zasila sekcję środków w OSOD.

Anpheros Platform

Wypróbuj za darmo w sandboksie

Pierwsze wywołanie FHIR w 5 minut. API HL7 FHIR R4 z wbudowaną zgodą pacjenta: wypróbuj w piaskownicy, a następnie połącz własną aplikację lub system kliniczny.

Za darmo · 30 syntetycznych pacjentów · bez karty

Ten poradnik ma charakter informacyjny i nie zastępuje konsultacji lekarskiej. Decyzje dotyczące zdrowia podejmuj z lekarzem. W nagłym wypadku zadzwoń pod lokalny numer alarmowy (112 w Europie).
Napisane przez
Zespół Anpheros

Anpheros tworzy dokumentację medyczną, nad którą pacjent ma kontrolę i którą może udostępniać dowolnej klinice, na platformie HL7 FHIR R4, z siedzibą w UE. Te przewodniki pomogą Ci zrozumieć i uporządkować informacje o Twoim zdrowiu; nie zastępują one wizyty u lekarza.

O Anpheros →