Adatvédelmi hatásvizsgálat (DPIA) egészségügyi alkalmazáshoz

Rövid válasz: az adatvédelmi hatásvizsgálat (DPIA) az a dokumentum, amelyben leírja az adatkezelési műveletet, igazolja annak szükségességét és arányosságát, felméri az adatfelhasználókra jelentett kockázatokat, és rögzíti azokat az intézkedéseket, amelyek csökkentik ezeket a kockázatokat. Az GDPR 35. cikke kötelezővé teszi, ha az adatkezelés valószínűsíthetően magas kockázattal jár, és megemlíti a különleges kategóriák, köztük az egészségügyi adatok nagyméretű kezelését mint esetet. A gyakorlatban minden, néhány felhasználónál több személyt érintő egészségügyi alkalmazásnak és minden egészségügyi adatplatformnak szüksége van rá az adatkezelés megkezdése előtt, és az adatkezelés változásakor felül kell vizsgálni. Az alábbi sablon a 35. cikk (7) bekezdését és az európai irányelveket követi; töltse le a végén.

Mikor szükséges

Az adatvédelmi hatásvizsgálatot (DPIA) az GDPR 35. cikke írja elő, amennyiben az adatfeldolgozás valószínűsíthetően magas kockázattal jár. Az egészségügyi adatokhoz hasonló különleges kategóriák nagymértékű feldolgozása automatikus kiváltó ok. Az Európai Adatvédelmi Testület (EDPB) kritériumai alapján egy egészségügyi alkalmazás általában több feltételnek is megfelel (érzékeny adatok, nagymértékű feldolgozás, kiszolgáltatott személyek), ezért szinte minden egészségügyi alkalmazásnak szüksége van rá az adatfeldolgozás megkezdése előtt.

A 35. cikk (3) bekezdése három automatikus kiváltó okot sorol fel: szisztematikus és kiterjedt profilalkotás jelentős hatásokkal; különleges kategóriák (9. cikk) vagy büntetőjogi adatok nagyméretű kezelése; nyilvános területek szisztematikus nagyméretű megfigyelése. Az Európai Adatvédelmi Testület (EDPB) kritériumai (a korábbi 29. cikk szerinti Munkacsoporttól) további hatot adnak hozzá; ha kettő vagy több vonatkozik, végezzen DPIA-t: értékelés vagy pontozás; automatizált döntések jogi vagy hasonló hatással; szisztematikus megfigyelés; érzékeny adatok; nagyméretű; adatkészletek összevetése vagy kombinálása; sérülékeny személyekre vonatkozó adatok (a betegek ide tartoznak); technológia innovatív használata; személyek jogainak vagy szolgáltatások igénybevételének megakadályozása. Egy egészségügyi alkalmazás tipikusan érinti az érzékeny adatokat, a nagyméretű kezelést, a sérülékeny személyeket és gyakran az innovatív technológiát. A nemzeti hatóságok listákat is közzétesznek az adatkezelésekről, amelyek mindig DPIA-t igényelnek (35. cikk (4) bekezdés); legtöbbjük tartalmazza az egészségügyi alkalmazásokat és a csatlakoztatott eszközöket.

Az ellenőrző lista

Az egészségügyi alkalmazások DPIA-jának ellenőrző listája az GDPR 35. cikk (7) bekezdésének négy elemét követi: az adatfeldolgozás leírása (célok, adatok, szereplők, technológia), a szükségesség és arányosság értékelése (jogi alap, minimalizálás, jogok, adatfeldolgozók, megőrzés), az adatok felhasználásával érintett személyek kockázatainak értékelése, valamint az ezeket a kockázatokat kezelő intézkedések, ezt követi a konzultáció, jóváhagyás és időszakos felülvizsgálat.

1. Az adatkezelés leírása (35. cikk (7)(a))

Célok, egyenként: a személy nyilvántartásainak tárolása; megosztás egy klinikával; emlékeztetők; anonimizált statisztikák; AI funkciók.
Adatkategóriák célonként, az egészségügyi adatok megjelölésével; források (a személy, klinikák, viselhető eszközök, dokumentumok); címzettek; megőrzési idő kategóriánként; az EU-n kívüli továbbítások és azok mechanizmusa.
Szereplők: adatkezelő(k), adatfeldolgozók (hosting, analitika, támogatási eszközök, AI szolgáltatók) szerződéseikkel; az adatvédelmi tisztviselő (DPO).
Technológia: architektúra, az adatok tárolási helye, titkosítás, azonosítás, naplózás. Egy adatfolyam diagram a leggyorsabb módja annak, hogy megtalálja, mit felejtett el.

2. Szükségesség és arányosság (35. cikk (7)(b))

Jogalap a 6. cikk és a 9. cikk (2) bekezdésének kivétele alapján, célonként (GDPR 9. cikk magyarázata).
Adatminimalizálás: minden adat elem esetében, miért szükséges; mit döntött, hogy nem gyűjt be.
Tájékoztatás a személyeknek (13–14. cikk) és hogyan gyakorolhatók a jogok (hozzáférés, helyesbítés, törlés, hordozhatóság, tiltakozás, hozzájárulás visszavonása) a termékben, nem pedig e-mailben a támogatásnak.
Adatfeldolgozók: 28. cikk szerinti szerződések megléte; alvállalkozók felsorolása; auditálási jogok.
Megőrzés és törlés: konkrét időszakok és az azokat érvényesítő mechanizmus.

3. Kockázatok a személyekre nézve (35. cikk (7)(c)) Mérje fel az esélyt és a súlyosságot mindhárom klasszikus eseményre, minden célra:

Jogosulatlan hozzáférés (adatvédelmi incidens, belső hozzáférés, túl széles körű megosztás, egy klinika a jóváhagyottnál többet lát);
Nem kívánt módosítás (hibás adat egy olyan nyilvántartásban, amelyre egy orvos támaszkodik, szinkronizációs hibák, egy AI funkció ír a nyilvántartásba);
Eltűnés (egy olyan nyilvántartás elvesztése, amelyre a személy támaszkodik; fiókátvétel; egy szolgáltató leállása). Majd az egészségügyi specifikus kockázatok: "anonim" statisztikák újraazonosítása; feltételezések a viselkedésből a betegségekről; diszkrimináció, ha az adatok biztosítókhoz vagy munkáltatókhoz jutnak; károk a gyermekek adataiból; tartózkodási hely adatok klinikák környékéről; az alkalmazásban lévő harmadik féltől származó SDK-k, amelyek adatokat küldenek reklámhálózatoknak (ez a leggyakoribb megállapítás az egészségügyi alkalmazások szabályozási auditjain).

4. Intézkedések (35. cikk (7)(d)) Minden kockázatra, a kontrollra és a fennmaradó kockázatra: titkosítás tároláskor és átvitelkor; erős hitelesítés; hozzáférés a hozzájárulás és az idő alapján korlátozva, naplókkal, amelyeket a személy elolvashat; álnévképzés az analitikában és a naplókban; nincs harmadik féltől származó reklám vagy követő SDK; külön környezetek és szintetikus adatok fejlesztéshez; biztonsági mentések tesztelt visszaállítással; szolgáltatói felülvizsgálat; incidenskezelés a 72 órás határidővel; biztonságos fejlesztési gyakorlatok; személyzeti képzés és titoktartás; adat exportálás és törlés a termékben; egy "kill-switch" az integrációkhoz.

5. Konzultáció

Az adatvédelmi tisztviselő tanácsa rögzítésre kerül (35. cikk (2) bekezdés); a személyek vagy képviselőik véleményét kérik, ahol releváns (35. cikk (9) bekezdés), például felhasználói panelen vagy betegszervezeten keresztül.
Ha magas fennmaradó kockázat marad, az adatkezelés előtt konzultáljon a felügyeleti hatósággal (36. cikk). A legtöbb jól szabályozott egészségügyi alkalmazás nem jut el idáig; a több klinikát kiszolgáló platformok néha igen.

6. Jóváhagyás és felülvizsgálat

Az adatkezelő vezetése által jóváhagyott; keltezett; verziószámozott.
Felülvizsgálatra kerül, amikor a célok, adatok, technológia vagy címzettek változnak, és legalább kétévente vagy évente (35. cikk (11) bekezdés).

Tipikus megállapítások az egészségügyi alkalmazások DPIA-iban

Az egészségügyi alkalmazások DPIA-iban a leggyakoribb megállapítások az elemző és összeomlás-jelentő SDK-k, amelyek azonosítókat kapnak egészségügyi kontextussal együtt, a lezárási képernyőn betegségeket felfedő push értesítések, a korlátlan adatbázis-hozzáféréssel rendelkező ügyfélszolgálati munkatársak, az EU-n kívüli biztonsági mentések, a fiók lezárása után megőrzött adatok, a célokat összekötő hozzájárulási képernyők, valamint az embereket még mindig azonosítani képes "anonimizált" adatkészletek.

Mindegyikre létezik konkrét megoldás, és a DPIA az a hely, ahol a megoldást rögzítjük.

A sablon

Az ezen az oldalon található DPIA sablon egy kitölthető Markdown dokumentum egy egészségügyi alkalmazáshoz, amely hat szakaszra tagolódik (az adatfeldolgozás leírása, szükségesség és arányosság, a személyekre háruló kockázatok, intézkedések, konzultáció, jóváhagyás és felülvizsgálat) egy kockázati táblázattal és egy intézkedési táblázattal. Az GDPR 35. cikk (7) bekezdését és az EDPB kritériumait követi, és egy kiinduló struktúra, nem jogi tanács.

Töltse le a DPIA sablont. Bármilyen dokumentumkezelő eszközbe importálható; az adatvédelmi tisztviselője (DPO) alakítja át.

Az Anpheros-nál

Az Anpheros fenntart egy DPIA-t az Anpheros Daily és egyet az Anpheros Platform számára adatfeldolgozóként, a fenti struktúrával, és a hozzájuk vezető döntések láthatók a termékben: célonkénti hozzájárulás, hatókörrel és naplózással ellátott hozzáférés, nincsenek reklám SDK-k, EU-s tárhely, export és törlés az alkalmazásban. Lásd: Egészségügyi átláthatóság.

Ez az oldal a termék- és mérnöki csapatok számára szóló szabályozást magyarázza el. Nem jogi tanács; a Források alatt linkelt szövegek az irányadók, és az Ön adatvédelmi tisztviselője, bejelentett szerve vagy ügyvédje dönt az Ön esetében. Utolsó felülvizsgálat: 2026. október.

Kapcsolódó oldalak

Források

Gyakori kérdések

Szükségem van DPIA-ra egy kis, kevés felhasználóval rendelkező alkalmazáshoz?

Ha egészségügyi adatokat kezel, szinte mindig igen: az érzékeny adatok és a sérülékeny személyek már megfelelnek a két kritériumú tesztnek, és több nemzeti lista is kifejezetten megemlíti az egészségügyi alkalmazásokat. Egy kis alkalmazás DPIA-ja egyszerűen rövidebb.

Ki írja a DPIA-t?

Az adatkezelő a felelős; a gyakorlatban a terméktulajdonos és a mérnöki vezető írja az adatvédelmi tisztviselő tanácsával, mert ők ismerik az adatfolyamokat. Teljes kiszervezése olyan dokumentumot eredményez, amelyet senki sem tud naprakészen tartani.

A DPIA-t közzé kell tenni?

Nem. Ez egy belső elszámoltathatósági dokumentum, amelyet kérésre be kell mutatni a felügyeleti hatóságnak. Sok szervezet tesz közzé összefoglalót; az EHDS és egyes nemzeti szabályok megkövetelik az átláthatóságot bizonyos adatkezelésekkel kapcsolatban.

Miben különbözik a DPIA az ISO 27001 szerinti kockázatértékeléstől?

Az ISO értékelés a szervezet kockázatait vizsgálja; a DPIA az adatokat kezelő személyek kockázatait vizsgálja. Közös kontrollokat és bizonyítékokat használnak, és egy jó biztonsági program táplálja a DPIA intézkedésekkel foglalkozó részét.

Anpheros Platform

Próbálja ki ingyen a sandboxban

Az első FHIR-hívás 5 perc alatt. Egy HL7 FHIR R4 API, amely tartalmazza a beteg beleegyezését: próbáld ki a sandboxban, majd csatlakoztasd saját alkalmazásodat vagy klinikai rendszeredet.

Ingyenes sandbox létrehozása Olvasd el a fejlesztői útmutatókat →

Ingyenes · 30 szintetikus beteg · kártya nélkül

Ez az útmutató tájékoztató jellegű, és nem helyettesíti az orvosi tanácsot. Az egészségeddel kapcsolatos döntésekhez beszélj az orvosoddal. Vészhelyzetben hívja a helyi segélyhívó számot (Európában 112).

Szerző:

Az Anpheros csapata

Az Anpheros egy olyan egészségügyi nyilvántartást épít, amelyet a beteg irányít, és megoszthat bármelyik klinikával, egy EU-ban működő HL7 FHIR R4 platformon. Ezek az útmutatók segítenek megérteni és rendszerezni az egészségügyi adataidat; nem helyettesítik az orvosodat.

Tudj meg többet az Anpherosról →