Evaluarea impactului asupra protecției datelor

Pe scurt: o evaluare a impactului asupra protecției datelor (EIPD) este documentul în care descrieți o operațiune de prelucrare, demonstrați că este necesară și proporțională, evaluați riscurile pentru persoanele ale căror date sunt utilizate și înregistrați măsurile care reduc aceste riscuri. Articolul 35 din GDPR o face obligatorie acolo unde prelucrarea este susceptibilă să genereze un risc ridicat și menționează prelucrarea la scară largă a categoriilor speciale de date, care include datele de sănătate, ca un caz. În practică, fiecare aplicație de sănătate cu mai mult de câțiva utilizatori și fiecare platformă de date de sănătate are nevoie de una, înainte de începerea prelucrării, revizuită atunci când prelucrarea se modifică. Șablonul de mai jos urmează Articolul 35(7) și ghidurile europene; descărcați-l la final.

Când este necesară

O evaluare a impactului asupra protecției datelor (EIPD) este necesară conform Articolului 35 din GDPR ori de câte ori prelucrarea datelor este susceptibilă să genereze un risc ridicat, iar prelucrarea la scară largă a unor categorii speciale de date, cum ar fi datele de sănătate, este menționată ca un declanșator automat. Conform criteriilor Comitetului European pentru Protecția Datelor (CEPD), o aplicație de sănătate îndeplinește, de obicei, mai multe condiții (date sensibile, scară largă, persoane vulnerabile), prin urmare, aproape fiecare aplicație de sănătate necesită o EIPD înainte de începerea prelucrării.

Articolul 35(3) enumeră trei declanșatoare automate: profilarea sistematică și extinsă cu efecte semnificative; prelucrarea la scară largă a categoriilor speciale de date (Articolul 9) sau a datelor penale; monitorizarea sistematică la scară largă a zonelor publice. Criteriile Comitetului European pentru Protecția Datelor (din fostul Grup de Lucru Articolul 29) adaugă încă șase; dacă se aplică două sau mai multe, efectuați o EIPD: evaluare sau scorare; decizii automate cu efect juridic sau similar; monitorizare sistematică; date sensibile; scară largă; potrivirea sau combinarea seturilor de date; date despre persoane vulnerabile (pacienții contează); utilizare inovatoare a tehnologiei; împiedicarea persoanelor să își exercite un drept sau să utilizeze un serviciu. O aplicație de sănătate atinge în mod tipic date sensibile, scară largă, persoane vulnerabile și adesea tehnologie inovatoare. Autoritățile naționale publică, de asemenea, liste de prelucrări care necesită întotdeauna o EIPD (Articolul 35(4)); majoritatea includ aplicații de sănătate și dispozitive conectate.

Lista de verificare

O listă de verificare pentru EIPD-ul unei aplicații de sănătate urmează cele patru elemente ale Articolului 35(7) din GDPR: o descriere a prelucrării (scopuri, date, actori, tehnologie), o evaluare a necesității și proporționalității (temei legal, minimizarea datelor, drepturi, procesatori, păstrare), o evaluare a riscurilor pentru persoanele ale căror date sunt utilizate și măsurile care abordează aceste riscuri, urmate de consultare, aprobare și revizuire periodică.

1. Descrieți prelucrarea (Art. 35(7)(a))

Scopuri, unul câte unul: stocarea dosarelor persoanei; partajarea cu o clinică; memento-uri; statistici anonimizate; funcționalități AI.
Categorii de date per scop, cu datele de sănătate marcate; surse (persoana, clinici, dispozitive purtabile, documente); destinatari; păstrare per categorie; transferuri în afara UE și mecanismul acestora.
Actori: controlor(i), procesatori (găzduire, analiză, instrumente de suport, furnizori AI) cu contractele lor; DPO.
Tehnologie: arhitectură, unde se află datele, criptare, identitate, jurnalizare. Un diagramă de flux de date este cel mai rapid mod de a găsi ceea ce ați uitat.

2. Necesitate și proporționalitate (Art. 35(7)(b))

Bază legală conform Articolului 6 și excepția Articolului 9(2), per scop (Articolul 9 GDPR explicat).
Minimizarea datelor: pentru fiecare element de date, de ce este necesar; ce ați decis să nu colectați.
Informarea persoanelor (Articolele 13–14) și modul în care drepturile (acces, rectificare, ștergere, portabilitate, obiecție, retragere a consimțământului) sunt exercitate în produs, nu prin e-mail către suport.
Procesatori: contracte Articolul 28 în vigoare; sub-procesatori listați; drepturi de audit.
Păstrare și ștergere: perioade concrete și mecanismul care le impune.

3. Riscuri pentru persoane (Art. 35(7)(c)) Evaluați probabilitatea și severitatea pentru fiecare dintre cele trei evenimente clasice, pentru fiecare scop:

Acces nelegitim (breșă, acces intern, partajare prea largă, o clinică care vede mai mult decât este aprobat);
Modificare nedorită (date greșite într-un dosar pe care un clinician se bazează, erori de sincronizare, o funcționalitate AI care scrie în dosar);
Dispariție (pierderea unui dosar de care persoana depinde; preluarea contului; un furnizor care se închide). Apoi cele specifice sănătății: re-identificarea statisticilor "anonime"; inferența condițiilor din comportament; discriminare dacă datele ajung la asigurători sau angajatori; prejudicii din datele copiilor; date de locație în jurul clinicilor; SDK-uri terțe în aplicație care trimit date către rețele de publicitate (cea mai frecventă constatare în auditurile de reglementare ale aplicațiilor de sănătate).

4. Măsuri (Art. 35(7)(d)) Pentru fiecare risc, controlul și riscul rezidual: criptare în repaus și în tranzit; autentificare puternică; acces limitat prin consimțământ și timp, cu jurnale pe care persoana le poate citi; pseudonimizare în analiză și în jurnale; fără SDK-uri de publicitate sau urmărire terțe; medii separate și date sintetice pentru dezvoltare; backup-uri cu restaurare testată; revizuirea furnizorilor; răspuns la incidente cu ceasul de 72 de ore; practici de dezvoltare securizate; instruirea personalului și confidențialitate; export și ștergere de date în produs; un "kill-switch" pentru integrări.

5. Consultare

Avizul DPO este înregistrat (Art. 35(2)); punctele de vedere ale persoanelor sau ale reprezentanților acestora sunt solicitate acolo unde este cazul (Art. 35(9)), de exemplu, printr-un panou de utilizatori sau o asociație de pacienți.
Dacă rămâne un risc rezidual ridicat, consultați autoritatea de supraveghere înainte de prelucrare (Art. 36). Majoritatea aplicațiilor de sănătate bine controlate nu ajung în acest punct; platformele care prelucrează pentru multe clinici uneori ajung.

6. Aprobare și revizuire

Aprobare de către managementul controlorului; datată; versiune.
Revizuită atunci când scopurile, datele, tehnologia sau destinatarii se modifică, și cel puțin o dată la unu sau doi ani (Art. 35(11)).

Constatări tipice în EIPD-urile aplicațiilor de sănătate

Cele mai frecvente constatări în EIPD-urile aplicațiilor de sănătate includ SDK-uri de analiză și raportare a erorilor care primesc identificatori împreună cu contextul de sănătate, notificări push care dezvăluie afecțiuni pe ecranul de blocare, personal de suport cu acces neîngrădit la baza de date, backup-uri în afara UE, date păstrate după închiderea unui cont, ecrane de consimțământ care grupează scopuri și seturi de date „anonimizate” care identifică în continuare persoanele.

Fiecare dintre acestea are o soluție concretă, iar EIPD-ul este locul unde se angajează soluția.

Șablonul

Șablonul EIPD de pe această pagină este un document Markdown completabil pentru o aplicație de sănătate, structurat în șase secțiuni (descrierea prelucrării, necesitatea și proporționalitatea, riscuri pentru persoane, măsuri, consultare, aprobare și revizuire) cu un tabel de riscuri și un tabel de măsuri. Acesta respectă Articolul 35(7) din GDPR și criteriile CEPD și reprezintă o structură de pornire, nu un sfat juridic.

Descărcați șablonul EIPD. Acesta poate fi importat în orice instrument de documente; DPO-ul dumneavoastră îl va adapta.

În Anpheros

Anpheros menține o EIPD pentru Anpheros Daily și una pentru Anpheros Platform ca procesator, cu structura de mai sus, iar alegerile la care au condus sunt vizibile în produs: consimțământ per scop, acces limitat și jurnalizat, fără SDK-uri de publicitate, găzduire în UE, export și ștergere în aplicație. Vezi Transparența sănătății.

Această pagină explică reglementările pentru echipele de produs și inginerie. Nu este un sfat legal; textele legate sub Surse sunt autoritatea, iar ofițerul dvs. de protecție a datelor, organismul notificat sau consilierul decide pentru cazul dvs. Ultima revizuire: Octombrie 2026.

Pagini înrudite

Surse

Întrebări frecvente

Am nevoie de o EIPD pentru o aplicație mică, cu puțini utilizatori?

Dacă prelucrează date de sănătate, aproape întotdeauna da: datele sensibile plus persoanele vulnerabile îndeplinesc deja testul celor două criterii, iar mai multe liste naționale menționează explicit aplicațiile de sănătate. EIPD-ul unei aplicații mici este pur și simplu mai scurt.

Cine scrie EIPD-ul?

Controlorul este responsabil; în practică, proprietarul produsului și liderul de inginerie îl scriu cu avizul DPO, deoarece aceștia cunosc fluxurile de date. Externalizarea completă produce un document pe care nimeni nu îl poate menține actualizat.

Trebuie publicată EIPD-ul?

Nu. Este un document intern de responsabilitate prezentat autorității de supraveghere la cerere. Multe organizații publică un rezumat; EHDS și unele reglementări naționale impun transparență cu privire la anumite prelucrări.

Cum diferă o EIPD de o evaluare a riscurilor conform ISO 27001?

Evaluarea ISO analizează riscurile pentru organizație; EIPD analizează riscurile pentru persoanele ale căror date sunt prelucrate. Acestea împărtășesc controale și dovezi, iar un program bun de securitate alimentează secțiunea de măsuri a EIPD-ului.

Anpheros Platform

Încearcă gratuit în sandbox

Primul apel FHIR în 5 minute. Un API HL7 FHIR R4 cu consimțământul pacientului integrat: încearcă-l în sandbox, apoi conectează-ți propria aplicație sau sistemul clinicii.

Creează un sandbox gratuit Citește ghidurile pentru dezvoltatori →

Gratuit · 30 de pacienți sintetici · fără card

Acest ghid este informativ și nu înlocuiește consultul medical. Pentru decizii despre sănătatea ta, vorbește cu medicul tău. În caz de urgență, sună la numărul de urgență local (112 în Europa).

Scris de

Echipa Anpheros

Anpheros construiește un dosar medical pe care pacientul îl controlează și îl poate da oricărei clinici, pe o platformă HL7 FHIR R4, cu sediul în UE. Ghidurile te ajută să-ți înțelegi și să-ți organizezi sănătatea; nu înlocuiesc medicul.

Despre Anpheros →