Evaluare a Impactului asupra Protecției Datelor (DPIA)

Cerută conform Art. 35 GDPR atunci când prelucrarea este susceptibilă să genereze un risc ridicat pentru drepturile și libertățile persoanelor fizice. Motive de declanșare obligatorii în cazul nostru: (a) prelucrare la scară largă a datelor sensibile privind starea de sănătate, (b) monitorizare sistematică a comportamentului pacienților (telemetria de aderență), (c) prelucrarea CNP-urilor (când este cazul). O DPIA la nivelul întregii platforme, cu anexe țintite pentru funcționalitățile cu cel mai mare risc (telereabilitarea F9, telemetria F10, consultațiile video F5.5). v1 redactată la 15.05.2026. Revizuită la 06.09.2026 în raport cu lansarea din septembrie 2026, la care populația de aproximativ 20.000 de pacienți din sistemul preexistent migrează pe această platformă. Fiecare afirmație a fost verificată în raport cu codul sursă, nu în raport cu revizia anterioară; paisprezece nu au trecut această verificare.

Stadiul revizuirii juridice

Ciornă v1 redactată de dezvoltator. Consilierul revizuiește evaluarea necesității și proporționalității, validează scorarea riscurilor în raport cu ghidurile ANSPDCP și semnează concluzia privind riscul rezidual. RPD contrasemnează conform memorandumul de desemnare RPD §„Atribuțiile RPD". Atunci când riscul rezidual rămâne „ridicat", se aplică consultarea prealabilă conform Art. 36 către ANSPDCP.

De citit înaintea registrului de riscuri

Două lucruri pe care un evaluator trebuie să le știe de la început.

Prelucrarea evaluată aici este lansarea din septembrie 2026, la care populația preexistentă de aproximativ 20.000 de pacienți — peste 11.000 de planuri de tratament și peste 5.000 de abonamente — migrează pe această platformă. Migrarea constituie ea însăși o operațiune de prelucrare și este evaluată la R14. Criteriul „scară largă” de la Art. 35 alin. (3) lit. (b) este îndeplinit din prima zi, nu atins ulterior.

Fiecare măsură invocată aici descrie sistemul așa cum funcționează, nu așa cum se intenționează să funcționeze. Acolo unde o măsură de siguranță nu există, documentul o consemnează ca atare și marchează intrarea cu ⚠️, în loc să descrie proiectarea planificată.

§1 Descrierea prelucrării

1.1 Platforma în sferă

Platforma RestartiX livrează servicii de telereabilitare și de operare a clinicii, pacienților, în numele clinicilor. {{LEGAL_ENTITY}} cumulează două roluri:

• Infrastructura platformei (rol de Persoană Împuternicită pentru clinicile terțe; operator de platformă)
• Clinica RestartiX (rol de Operator pentru pacienții proprii)

Clinicile terțe ulterioare aderă ca Operatori suplimentari; rolul platformei rămâne cel de Persoană Împuternicită pentru aceștia. Nicio clinică terță nu este încă înrolată, prin urmare fiecare activitate descrisă aici se desfășoară în prezent într-un singur tenant — motiv pentru care punctele deschise din §3 pot fi remediate înainte de a afecta pe altcineva decât pe noi.

Platforma este un dispozitiv medical înregistrat. RestartiX MedCare v1.0 poartă marcaj CE, clasa I conform MDR (UE) 2017/745, regula 13, producător RESTARTIX CENTER S.R.L., SRN RO-MF-000055558, Basic UDI-DI 5943172000RESTARTIXRY. Această calificare nu modifică analiza din perspectiva GDPR — cele două regimuri sunt paralele — însă este un element de context pe care o autoritate de supraveghere se așteaptă să îl regăsească aici și care limitează ceea ce prelucrarea poate pretinde că face: destinația medicală declarată prevede că dispozitivul nu are funcție de măsurare și nu interpretează date fiziologice. A se vedea dispozitivul medical.

1.2 Natura prelucrării

• Înregistrare și identitate pacient — auto-înscriere prin Portal, autentificare OAuth sau parolă prin Clerk, profilul pacientului (nume, e-mail, telefon, data nașterii).

• Capturarea consimțământului — consimțământ pe scop, înregistrat într-un registru consents versionat, dovedit prin momentul acordării, principalul care l-a acordat și adresa IP de origine (granted_via_ip). Retragerea este singura actualizare permisă; ștergerea nu există. Nu se înregistrează user-agent.

• Livrarea programului ghidat de exerciții — pacientul primește un program prescris de clinician, a cărui durată o stabilește clinicianul; urmează exerciții ghidate video; auto-raportează durerea (VAS) și efortul (RPE) pe sesiune; înregistrează finalizarea.

• Telemetrie de aderență — procentul de vizionare video, timestamp-urile de finalizare a sesiunilor, abandonul la exerciții sunt capturate continuu pe parcursul sesiunilor.

• Corespondență clinică — ajustări ale programului, note ale specialistului, prescripții pregătite și predate pacientului.

• Consultații video în timp real (F5.5) — audio și video între pacient și clinician, retransmise de Daily, Co.. Fără înregistrare. Este singura prelucrare prin care date din categoria Art. 9 ajung necriptate la un subîmputernicit — evaluată la R11 și în §6.

• Programări, formulare și documente — programări și calendare, formulare și consimțăminte completate de pacient, documente clinice generate (F3–F6).

• Codul numeric personal (CNP) — colectat exclusiv de la pacient, stocat criptat AES-256-GCM, cu un blind index (national_id_hmac) care permite căutarea fără decriptare și citit în baza unei permisiuni dedicate care generează o înregistrare de audit. A se vedea §2.2.

• Jurnal de audit — fiecare operațiune care modifică starea, cu adăugare exclusivă, consemnând actorul, acțiunea, entitatea, IP-ul, user-agentul, codul de stare și modificările la nivel de câmp, valorile sensibile fiind mascate de lista centralizată de redactare.

  Citirile nu se jurnalizează. Constanta audit.ActionRead există, însă are exact un punct de apel — dezvăluirea CNP-ului — sub o regulă de admitere explicită („ar întreba o autoritate de supraveghere cine a accesat această valoare anume?”). Consecința pe care un evaluator trebuie să o rețină: o sesiune break-glass exclusiv de citire nu produce nicio înregistrare de audit, cu excepția cazului în care a atins un CNP. Deschiderea și închiderea sesiunii break-glass se consemnează; ce anume a fost consultat în cursul ei, nu. Un jurnal general de acces este proiectat, dar neimplementat.

• Notificări — e-mail tranzacțional și operațional prin AWS SES, plus notificări în aplicație. Mesajele operaționale respectă o opțiune de dezabonare per destinatar. Nu se trimite marketing — nicio categorie de marketing nu este înregistrată, iar dispecerul refuză din principiu această clasificare (a se vedea §2.3).

1.3 Sfera și contextul

• Volum: aproximativ 20.000 de pacienți, peste 11.000 de planuri de tratament și peste 5.000 de abonamente active la lansarea din septembrie 2026, migrate din sistemul preexistent pe care această platformă îl înlocuiește. Nu este o proiecție de creștere, ci o populație cunoscută, cu evidențe deja constituite, care sosește simultan. Criteriul „scară largă” de la Art. 35 alin. (3) lit. (b) este îndeplinit din prima zi, nu atins ulterior — de aici și existența prezentei evaluări, precum și riscul distinct de la R14.
• Geografie: România la lansare. La nivel arhitectural pentru toată UE; piețele din afara UE nu sunt în sferă.
• Demografie: pacienți de reabilitare din populația adultă, precum și minori. Minorii nu sunt blocați, iar la înregistrare nu există niciun flux de consimțământ parental. Ceea ce există este o verificare a majoratului (18 ani), care stabilește dacă un aparținător poate accepta termenii clinicii în numele altei persoane. Pragul de 16 ani prevăzut de Art. 8 GDPR, aplicabil prelucrărilor întemeiate pe consimțământ, nu este implementat. A se vedea R5 și §3.2 din nota către consilier.
• Sensibilitatea datelor: datele privind starea de sănătate, din categoria specială prevăzută la Art. 9, constituie tipul central de date, iar de la F5.5 acestea includ și stream-ul consultației în timp real. CNP-ul se prelucrează în temeiul art. 4 din Legea nr. 190/2018 — a se vedea §2.2, unde mențiunea anterioară „se decide după consilier” este soluționată pe latura implementării și rămâne deschisă pe latura juridică.
• Asimetrie de putere: pacienții sunt persoanele vizate; clinica (operatorul) stabilește scopurile; platforma prelucrează conform instrucțiunilor. Pacienții sunt într-o poziție de dependență față de clinică pentru îngrijire; acest aspect influențează analiza de proporționalitate și forța consimțământului.
• Tehnologie: SaaS standard — Next.js, Go, PostgreSQL cu RLS, Redis, găzduit pe AWS în eu-central-1 (o singură regiune; nu există replicare în altă parte). Nicio componentă de inteligență artificială nu intervine în deciziile clinice; nu există profilare automată cu efecte juridice asupra persoanelor vizate, prin urmare Art. 22 nu se aplică.

1.4 Scop

• Furnizarea telereabilitării ghidate ca serviciu clinic, în concordanță cu modelul clinică-ca-operator.
• Capturarea datelor de aderență pentru ca clinica să poată identifica abandonurile, să intervină și să îmbunătățească rezultatele.
• Menținerea pistei de audit cerute de responsabilitatea Art. 5 alin. (2) GDPR și de suprapunerea cu evidența medicală a Legii nr. 95/2006.

1.5 Categorii de date — a se vedea EAP

Partea A (RestartiX-ca-operator) și Partea B (RestartiX-ca-persoană-împuternicită) din EAP acoperă categoriile de date în detaliu operațional. Această DPIA le tratează ca fiind incluse prin referință.

§2 Necesitate și proporționalitate

2.1 Temei juridic (Art. 6 + Art. 9)

Prelucrare	Temei Art. 6	Temei Art. 9
Înregistrare + cont	(b) Executarea unui contract	n/a (fără date sensibile în acest pas)
Capturarea consimțământului	(c) Obligație legală (proba Art. 7)	n/a
Livrarea planului de tratament	(b) Executarea unui contract	(h) Prestarea de asistență medicală și socială + (a) consimțământul explicit la înregistrare
Telemetria de aderență	(b) Executarea unui contract + (f) interes legitim (îmbunătățire operațională)	(h) + (a) consimțământ explicit
Comunicări (tranzacționale)	(b)	n/a
Jurnalizare audit	(c) Obligație legală + (f) interes legitim	n/a
Asistență clienți	(f) Interes legitim (când este solicitat)	(a) Consimțământ explicit pentru orice subiect de date privind starea de sănătate apărut în asistență
Prelucrarea CNP	(c) Obligație legală	n/a (CNP nu este dată din categoria Art. 9 — este număr național de identificare, conform art. 4 din Legea nr. 190/2018)
Consultație video în timp real	(b) Executarea unui contract	(h) Prestarea de asistență medicală, cu consimțământ explicit prin instrumentul telemedicine, care trebuie adoptat înainte de începerea consultației

Fiecare temei Art. 9 alin. (2) este documentat per scop de consimțământ în catalogul scopurilor de consimțământ (1B.9).

2.2 Evaluarea necesității

Testul de minimizare a datelor din Art. 5 alin. (1) lit. c) aplicat fiecărei categorii:

Categorie	Necesară?	De ce
E-mail	Da	Canalul de comunicare al contului; fără alternativă realistă
Nume	Da	Personalizare; norma profesională a clinicianului
Telefon	Condiționat	Necesar doar dacă SMS devine canal de avarie; în prezent opțional, iar niciun furnizor de SMS nu este contractat
Data nașterii	Da	Stabilește dacă un aparținător poate consimți în numele persoanei (sub 18 ani); metadată de relevanță clinică. Nu alimentează nicio verificare a pragului de 16 ani, care nu este implementat
Locale	Da	Limba UI; limba de comunicare
VAS / RPE / aderență	Da	Produsul clinic; programul de reabilitare este lipsit de sens fără acestea
CNP	Da, cu restricții	Necesar pentru evidența clinică și pentru documentele care trebuie să îl conțină potrivit reglementărilor din România. Măsurile de minimizare sunt structurale, nu procedurale: se scrie exclusiv printr-un traseu cu audiență de pacient — pagina de profil a pacientului sau un răspuns national_id în cadrul unei sesiuni de formular — și se stochează criptat AES-256-GCM cu un blind index national_id_hmac, pentru ca o clinică să poată căuta fără decriptare, este mascat implicit în fișa pacientului, se dezvăluie doar printr-o permisiune dedicată patients.view_national_id, pe un endpoint separat care generează o înregistrare de audit la fiecare citire — singura citire auditată din platformă — și este refuzat prin declanșator la nivel de bază de date în cele două spații de stocare cu formă liberă (custom_field_values.value și forms.values), astfel încât nu poate ajunge lateral într-un răspuns de formular. Răspunsul obligatoriu al consilierului privind solicitarea CNP-ului la înregistrare rămâne restant (§3.1); implementarea îl tratează ca opțional și controlat de pacient, ceea ce reprezintă interpretarea prudentă
Stream-ul audio-video al consultației	Da	Consultația este stream-ul; nu există o formă mai restrânsă a ei. Minimizată prin lipsa înregistrării — a se vedea R11
Comentarii text liber ale pacientului	Da	Context clinic furnizat voluntar de pacient
IP / user-agent (înregistrare, audit)	Da	Securitate și responsabilitate; minimizate în jurnale (fără IP în analiza de business)
Metadate vizionare video	Da	Proxy pentru aderență; susține intervenția la abandon

⚠️ „Introdus de pacient” este o proprietate a traseului tehnic, nu o garanție privind persoana care a tastat. O scriere cu audiență de personal este refuzată din start (national_id_patient_only), iar personalul care impersonează un pacient nu poate scrie deloc — prin urmare, nicio rută autentificată ca personal nu poate seta un CNP. Însă o sesiune de formular este publică și autorizată printr-un token, nu poartă niciun principal și este tratată prin construcție ca având audiență de pacient. Acesta este fluxul cu tableta din clinică: personalul emite tokenul și înmânează dispozitivul. Platforma nu poate, așadar, să distingă între un pacient care își tastează propriul CNP și un recepționer care îl tastează în locul său, iar prezentul document nu trebuie să pretindă că poate. Ceea ce este garantat este mai restrâns și rămâne valoros: niciun membru al personalului nu poate seta un CNP fiind autentificat ca personal sau impersonând pacientul.

2.3 Evaluarea proporționalității

Fiecare categorie colectată se află într-o relație unu-la-unu cu un scop. Nu există colectare în masă, nu există profilare pentru scopuri nedezvăluite, nu există analiză între tenanți pe date identificabile. Constrângerea între tenanți este aplicată arhitectural (RLS) și operațional (break-glass).

⚠️ Un consimțământ este colectat fără a putea fi valorificat. marketing_email și marketing_sms sunt înregistrate ca scopuri întemeiate pe consimțământ, iar formularul de înscriere afișează fiecare astfel de scop ca opțiune facultativă — prin urmare pacientul este întrebat dacă acceptă comunicări de marketing din partea clinicii și poate răspunde afirmativ. Niciun mesaj de marketing nu poate fi însă trimis: nicio categorie nu este înregistrată ca marketing, iar dispecerul refuză din principiu această clasificare. Permisiunea rămâne, așadar, fără efect.

Situația nu este nelegală — nicio prelucrare nu are loc în temeiul ei — însă ridică o problemă de echitate și transparență în sensul art. 5 alin. (1) lit. (a): solicitarea unei permisiuni care nu este niciodată exercitată lasă pacientul cu o imagine falsă asupra a ceea ce a acceptat și lasă în registru un consimțământ acordat căruia nu îi corespunde nicio prelucrare. Remedierea constă fie în trimiterea comunicărilor pe care consimțământul le descrie, fie în retragerea opțiunii din formular până când acest lucru devine adevărat.

Migrarea nu lărgește această sferă. Aducerea celor 20.000 de pacienți existenți reprezintă o schimbare de custodie, nu de scop: operatorul care primește datele este același, relația terapeutică este aceeași, iar categoriile sunt cele deja enumerate. Ceea ce migrarea nu trebuie să facă este să importe mai mult decât are schema nouă un scop declarat să prelucreze — un câmp preexistent care nu are corespondent aici se elimină la graniță, în loc să fie parcat într-o coloană „pentru orice eventualitate”. Aceasta este o constrângere de proiectare asupra instrumentelor de migrare, evaluată la R14.

2.4 Drepturile persoanei vizate

Drept	Mecanism	Stadiu
Informare (Art. 13–14)	Nota de informare privind confidențialitatea — publicată de clinică, șablonată de platformă (1B.10)	Livrat (mecanismul de șabloane); conținutul așteaptă revizuirea consilierului
Acces (Art. 15)	GET /v1/me/export — o arhivă JSON cu evidențele persoanei vizate	Livrat. Subiectul se rezolvă din contul apelant, nu se preia din cerere — a se vedea R13
Rectificare (Art. 16)	Editor de profil al pacientului în Portal; editare de personal în Aplicația Clinică	Livrat
Ștergere (Art. 17)	Anonimizare cu respectarea Art. 17 alin. (3) lit. (c) + Legea nr. 95/2006; ștergere logică peste tot, niciodată o ștergere fizică a fișei pacientului	Livrat pentru sistemele active. Nu poate atinge arhiva de backup — a se vedea R12
Restricționare (Art. 18)	Retragerea consimțământului pe scop, cu efect imediat; retragerea închide orice sesiune pe care scopul o condiționa	Livrat
Portabilitate (Art. 20)	Aceeași arhivă JSON ca la Art. 15	Livrat
Opoziție (Art. 21)	Retragerea consimțământului pentru scopurile întemeiate pe consimțământ; pentru telemetria întemeiată pe interes legitim, o rutare operațională prin operator	Parțial livrat — calea de retragere este implementată, procedura de rutare a opoziției este documentată, dar nu are titular cât timp postul de RPD este vacant
Decizii automate (Art. 22)	Nu se aplică — nicio decizie automată nu produce efecte juridice sau similar semnificative	N/A

§3 Evaluarea riscurilor

Cum se citește prezentul registru

Acestea sunt riscuri, nu incidente. Fiecare intrare denumește ceva ce ar putea funcționa greșit în cadrul acestei prelucrări, arată cât de grav ar fi dacă s-ar întâmpla, enumeră măsurile care fac evenimentul improbabil și evaluează ce rămâne după acestea. Exact acest lucru îl cere art. 35 alin. (7) lit. (c) de la o evaluare de impact: analizarea anticipată a modurilor de eșec și expunerea raționamentului.

Prin urmare, o intrare precum R1 Scurgere de date între tenanți nu semnalează că o clinică poate vedea pacienții alteia. Ea consemnează că scurgerea între tenanți este eșecul cu cele mai grave consecințe pentru o platformă medicală multi-tenant și expune ce anume îi stă în cale: RLS la nivelul bazei de date, verificarea de corespondență între URL și domeniul de acces pe fiecare rută per organizație, etichete de cache delimitate la vizibilitatea datelor. Evaluarea reziduală este ceea ce rămâne după aplicarea acestora: niciodată zero, pentru că nicio măsură nu este perfectă, iar un registru care ar pretinde contrariul nu ar fi credibil.

Două intrări sunt de altă natură și o spun în propriul text. R13 este un defect identificat efectiv în sistemul aflat în funcțiune și este marcat ca închis, împreună cu ceea ce lasă în urmă. Intrările marcate cu ⚠️ denumesc o măsură care lipsește, nu una doar imperfectă. În rest, fiecare măsură descrisă aici a fost verificată și este în funcțiune.

Un rezidual „Mediu” nu este un semnal de alarmă. Este starea normală a unei amenințări serioase împotriva căreia există măsuri care funcționează. Ar fi îngrijorător un rezidual „Ridicat” sau un risc inerent fără nicio măsură enumerată — niciunul dintre acestea nu se regăsește în prezent în registru.

Pentru fiecare risc identificat: probabilitate × severitate = risc inerent, apoi risc rezidual după controale.

Scală: Scăzut / Mediu / Ridicat / Critic.

R1 — Scurgere de date între tenanți

Aspect	Detaliu
Amenințare	Un bug sau o acțiune a operatorului expune datele pacienților unei clinici către o altă clinică
Drepturi afectate	Confidențialitate, Art. 5 alin. (1) lit. f) integritate și confidențialitate
Persoane vizate afectate	Pacienți ai clinicii din care s-a făcut scurgerea
Probabilitate / severitate inerentă	Mediu / Ridicat → Ridicat
Controale	Row-Level Security la nivelul BD (RLS delimitat la app.current_org_id); P47 URL-≡-scope guard pe fiecare rută per organizație; P42 scope-ul tag-urilor de cache trebuie să se potrivească cu vizibilitatea datelor; teste de integrare acoperă RLS; nicio cale de interogare între tenanți în cod
Probabilitate / severitate reziduală	Scăzut / Ridicat → Mediu

R2 — Acces al personalului platformei care depășește granița de persoană împuternicită

Aspect	Detaliu
Amenințare	Personalul platformei navighează în datele identificabile ale pacienților fără autorizare corespunzătoare
Drepturi afectate	Confidențialitate, angajamentul de persoană împuternicită din Art. 28
Persoane vizate afectate	Oricare
Probabilitate / severitate inerentă	Mediu / Ridicat → Ridicat
Controale	Primitiva break-glass — delimitată ca scop, ≤ 4 ore, justificată, jurnal de audit, notificată în timp real către clinica afectată. Niciun rol RBAC static nu acordă citire pe datele pacienților între tenanți. Arhitectura Consolei interzice citiri „de fundal" (a se vedea decisions.md → break-glass). ⚠️ Revizuirea trimestrială a jurnalului break-glass nu se desfășoară încă — este o atribuție a RPD, iar niciun RPD nu este desemnat
Probabilitate / severitate reziduală	Scăzut / Mediu → Scăzut

R3 — Compromiterea cheilor de criptare

Aspect	Detaliu
Amenințare	Materialul cheii KMS compromis, expunând CNP și credențialele criptate la nivel de coloană
Drepturi afectate	Confidențialitate
Persoane vizate afectate	Orice pacient cu CNP stocat (sub rezerva răspunsului consilierului §3.1)
Probabilitate / severitate inerentă	Scăzut / Ridicat → Mediu
Controale	AWS KMS cu politici de cheie care restricționează accesul administrativ; rotație anuală a cheilor; migrarea planificată la CMK gestionat de client ca Faza 2; criptare envelope (datele de coloană criptate cu cheia de date criptată cu cheia master KMS); cheie KMS separată per mediu
Probabilitate / severitate reziduală	Scăzut / Ridicat → Mediu (compromiterea cheii rămâne catastrofală, dar probabilitatea este redusă substanțial)

R4 — Compulsare de acces guvernamental al unui subîmputernicit (proces juridic SUA)

Aspect	Detaliu
Amenințare	Procesul juridic american obligă Clerk, Cloudflare sau AWS să dezvăluie date autorităților
Drepturi afectate	Confidențialitate, setul de garanții Schrems II
Persoane vizate afectate	Oricare
Probabilitate / severitate inerentă	Scăzut / Ridicat → Mediu
Controale	A se vedea TIA pentru fiecare transfer. Clerk: sferă limitată de date (fără date Art. 9); CCS + EO 14086 + DPF (când este aplicabil). Cloudflare: niciun corp autentificat în cache; CCS. AWS: rulare exclusiv UE; CCS pentru suprafața de acces a societății-mamă; criptare la nivel de coloană pentru coloanele cele mai sensibile. Contingențele de încetare a colaborării cu subîmputerniciții sunt documentate
Probabilitate / severitate reziduală	Scăzut / Mediu → Scăzut

R5 — Consimțământ nevalabil (sub 16 ani, retras sau capturat incorect)

Aspect	Detaliu
Amenințare	Platforma continuă să prelucreze datele pacientului în temeiul unui consimțământ nevalabil (auto-înscriere sub 16 ani, retras dar neonorat, capturat sub coerciție sau în termeni neclari)
Drepturi afectate	Legalitatea prelucrării (Art. 6/9)
Persoane vizate afectate	Pacienții afectați
Probabilitate / severitate inerentă	Mediu / Ridicat → Ridicat
Controale	Registru de consimțământ pe scop, cu retragere cu efect imediat; limbaj explicit în catalogul scopurilor; re-consimțământul este impus la fiecare schimbare de versiune printr-o poartă care returnează 412 până la acceptarea versiunii curente. Tratamentul vârstei, formulat precis, întrucât sunt în joc două praguri: o verificare a majoratului (18 ani, capacitatea de a contracta în dreptul român) stabilește dacă un aparținător poate accepta termenii clinicii în numele altei persoane, și este implementată și aplicată — o dată de naștere necunoscută este tratată ca aparținând unui adult, astfel încât un câmp necompletat nu poate genera autoritate asupra acestuia. ⚠️ Pragul de 16 ani prevăzut la Art. 8 GDPR este un prag diferit, pentru un temei juridic diferit — prelucrările întemeiate pe consimțământ, precum marketingul și analiza — și nu există nicio blocare a minorilor sub 16 ani și niciun flux de consimțământ parental la înregistrare. §3.2 din nota către consilier rămâne deschis
Probabilitate / severitate reziduală	Scăzut / Mediu → Scăzut (sub rezerva concluziei consilierului privind sub 16 ani)

R6 — Colectare excesivă / derivă de profilare a telemetriei de aderență

Aspect	Detaliu
Amenințare	Platforma începe să folosească datele de aderență pentru scopuri dincolo de urmărirea clinică dezvăluită (de exemplu, discriminare prin preț, eligibilitate pentru programe viitoare)
Drepturi afectate	Limitarea scopului (Art. 5 alin. (1) lit. b)), autonomia pacientului
Persoane vizate afectate	Orice pacient care generează date de aderență
Probabilitate / severitate inerentă	Scăzut / Mediu → Mediu
Controale	Scopurile telemetriei enumerate în catalogul scopurilor de consimțământ; registrul de clasificare a datelor restricționează ieșirea la țintele dezvăluite, cu verificare automată în CI. ⚠️ Neimplementat: nu există o coloană de versiune a algoritmului pe rândurile de metrică, prin urmare o modificare a modului în care se derivă o metrică nu poate fi reconstituită din date. Revizuirea bianuală a RPD asupra utilizării telemetriei depinde de desemnarea RPD
Probabilitate / severitate reziduală	Scăzut / Scăzut → Scăzut

R7 — Activarea amânată a urmăririi poziției corporale fără consimțământ reînnoit

Aspect	Detaliu
Amenințare	Pipeline-urile de urmărire a poziției corporale există în schemă (tabele goale, schele); activarea fără consimțământ biometric reînnoit explicit și DPIA actualizată ar constitui prelucrare Art. 9 fără temei
Drepturi afectate	Legalitate (Art. 9), limitarea scopului
Persoane vizate afectate	Pacienții din orice program activat pentru urmărirea poziției corporale
Probabilitate / severitate inerentă	Mediu / Ridicat → Ridicat dacă este activat fără controale
Controale	Activarea urmăririi poziției corporale este blocată în spatele: (a) consimțământ explicit reînnoit conform scopului de consimțământ amânat biometric_capture; (b) anexă DPIA actualizată specifică pentru urmărirea poziției corporale; (c) aviz RPD; (d) versiune actualizată a notei de informare privind confidențialitatea. Politica de inginerie: scriitorii tabelelor de poziție corporală nu pot fi activați doar prin configurație — calea de cod este feature-flagged în spatele mecanismului de blocare de consimțământ
Probabilitate / severitate reziduală	Scăzut / Ridicat → Mediu (mecanismul de blocare previne activarea accidentală, dar severitatea ridicată rămâne ca limita superioară)

R8 — Pierderea disponibilității (indisponibilitate RDS, backup nerecuperabil)

Aspect	Detaliu
Amenințare	Un incident regional sau o corupție de date distruge evidențele pacienților mai rapid decât procesul de recuperare le poate restaura
Drepturi afectate	Disponibilitate (Art. 32 alin. (1) lit. b))
Persoane vizate afectate	Toți
Probabilitate / severitate inerentă	Scăzut / Ridicat → Mediu
Controale	Bază de date Multi-AZ cu failover automat; fereastră PITR de 35 de zile; pg_dump logic zilnic al bazelor principale și de telemetrie, într-un depozit sub Object Lock, unde artefactul este re-calculat ca sumă de control după încărcare și doar o potrivire octet cu octet publică backupul. Există o testare de restaurare în cloud, care s-a dovedit utilă de la prima rulare: a demonstrat că producția nu se putea restaura din propriul dump, iar defectul a fost remediat. ⚠️ Neimplementate: replicarea către o a doua regiune UE (neconfigurată în niciun mediu) și o cadență a testării legată de fiecare lansare. RTO 4h / RPO 1h sunt ținte, nu valori măsurate
Probabilitate / severitate reziduală	Scăzut / Mediu → Scăzut

R9 — Scurgere de date cu caracter personal în jurnale (Sentry, CloudWatch, jurnalele aplicației)

Aspect	Detaliu
Amenințare	O excepție sau o linie de jurnal scurge date identificabile ale pacientului către telemetria operațională consumată de un subîmputernicit (Sentry) sau de personalul platformei în afara elevării
Drepturi afectate	Confidențialitate, limitarea scopului
Persoane vizate afectate	Persoana ale cărei date apar în linia de jurnal
Probabilitate / severitate inerentă	Mediu / Mediu → Mediu
Controale	O listă centralizată de redactare maschează valorile cheilor sensibile — password, secret, token, apikey, authorization, cookie, session, nationalid, cnp — denumirile fiind normalizate, astfel încât api_key, api-key și X-API-KEY se potrivesc toate. Lista este instalată pe handlerul de jurnalizare structurată al API-ului și pe scriitorul JSONB al jurnalului de audit, ceea ce contează pentru că audit_log este stocat în clar, cu adăugare exclusivă și retenție de ani. De reținut că redactarea se face după numele cheii, nu după valoare: email, phone și name sunt deliberat absente din listă, prin urmare o valoare cu caracter personal jurnalizată sub o cheie neutră nu este interceptată. Urmărirea erorilor rulează cu sendDefaultPii: false, plus o curățare a URL-urilor și a firimiturilor de navigare. ⚠️ Sferă: lista este instalată doar în API, nu și în serviciile de telemetrie și media; urmărirea erorilor este implementată doar în Portal
Probabilitate / severitate reziduală	Scăzut / Scăzut → Scăzut

R10 — Ștergere insuficientă la cererea pacientului

Aspect	Detaliu
Amenințare	Pacientul solicită ștergerea; platforma șterge contul, dar date identificabile reziduale persistă în jurnalul de audit, backup-uri sau în stocările subîmputerniciților
Drepturi afectate	Ștergere (Art. 17)
Persoane vizate afectate	Pacientul care a solicitat ștergerea
Probabilitate / severitate inerentă	Mediu / Mediu → Mediu
Controale	Fluxul de ștergere F11.1 anonimizează câmpurile identificabile, păstrând auditul și evidențele clinice reținute conform Legii nr. 95/2006 (Art. 17 alin. (3) lit. c)); ștergere în cascadă în Clerk prin API-ul de gestionare; gestionarea ștergerii la subîmputerniciți documentată în subîmputerniciți; backup-urile sunt suprascrise prin lifecycle, nu șterse selectiv — pacientul este informat despre acest aspect în nota de informare privind confidențialitatea
Probabilitate / severitate reziduală	Scăzut / Scăzut → Scăzut

R11 — Expunerea stream-ului de consultație la subîmputernicit

Aspect	Detaliu
Amenințare	Stream-ul audio și video al unei consultații de reabilitare — date privind sănătatea, din categoria Art. 9, în clar — este retransmis de un subîmputernicit din Statele Unite. Expunerea ar putea proveni dintr-o divulgare impusă legal, din compromiterea furnizorului, din activarea înregistrării sau din retransmiterea fluxului în afara UE
Drepturi afectate	Confidențialitate (Art. 32), legalitatea transferului (Art. 44–46), limitarea scopului
Persoane vizate afectate	Fiecare pacient și clinician care participă la o consultație video
Probabilitate / gravitate inerentă	Medie / Ridicată → Ridicat
Măsuri	Nu se înregistrează nimic — camerele se creează fără înregistrare, niciun traseu de cod nu o activează și, în consecință, nu există stream stocat care să poată fi solicitat, compromis sau distribuit greșit; serverele de media sunt fixate în UE (geo = eu-central-1) de un adaptor care refuză să creeze o cameră atunci când regiunea nu este configurată, în loc să aplice o valoare implicită; participanții sunt identificați către furnizor printr-o referință opacă, niciodată printr-un identificator de pacient, astfel încât furnizorul nu poate asocia un participant unei persoane; niciun context clinic nu circulă în numele camerei, în token sau în webhook; camerele sunt private, fiecare intrare necesită un token per participant emis de noi, cu expirare obligatorie, iar eject_at_room_exp face ca expirarea să încheie o consultație în desfășurare; DTLS-SRTP criptează fiecare segment de media în tranzit
Probabilitate / gravitate reziduală	Scăzută / Ridicată → Mediu
⚠️ Rămâne deschis	Contractul prevăzut la Art. 28 și instrumentul de transfer prevăzut la Art. 46 sunt în vigoare — termenii furnizorului încorporează prin referință acordul de prelucrare și consideră clauzele contractuale standard semnate la încheierea contractului, modulul 3 fiind selectat de poziția noastră de persoană împuternicită. Nu este închis faptul că contul la furnizor este partajat cu sistemul preexistent restartix-leo, ale cărui webhookuri sunt la nivel de cont: endpointul nostru primește notificări pentru consultațiile în desfășurare ale acelui sistem, purtând nume reale de pacienți. Nu se stochează nimic — handlerul respinge orice cameră pe care platforma nu a derivat-o, înainte de a construi evenimentul — însă primirea este prelucrare, iar un filtru scris pentru o ipoteză este singurul element care separă cele două sisteme. A se vedea TIA T4

R12 — Ștergerea nu poate atinge arhiva de backup

Aspect	Detaliu
Amenințare	Arhiva pg_dump se află sub Object Lock în modul COMPLIANCE, pe 7 ani, fără regulă de expirare. Nici administratorul, nici furnizorul de cloud nu pot șterge un obiect în interiorul acestei ferestre, prin urmare o ștergere solicitată în temeiul Art. 17 nu poate fi executată acolo. O notă de informare sau un acord care promite ștergerea în 90 de zile este, aparent, contrazis
Drepturi afectate	Ștergere (Art. 17), limitarea stocării (Art. 5 alin. (1) lit. (e))
Persoane vizate afectate	Orice pacient care solicită ștergerea
Probabilitate / gravitate inerentă	Ridicată (este certă, nu probabilă) / Scăzută → Mediu
Măsuri	Poziția CEPD privind backupurile este adoptată explicit, nu subînțeleasă: ștergerea se aplică sistemelor active și fiecărui subîmputernicit, arhiva este utilizată exclusiv pentru recuperare în caz de dezastru, fără niciun traseu de citire analitic, operațional sau de asistență, iar o restaurare este un eveniment de răspuns la incident după care fiecare ștergere consemnată de la momentul backupului se reaplică înainte ca sistemul restaurat să deservească trafic
Probabilitate / gravitate reziduală	Ridicată / Scăzută → Scăzut, cu condiția ca reaplicarea să fie o procedură reală, nu o intenție
⚠️ Rămâne deschis	Procedura de reaplicare a ștergerilor după restaurare nu există încă

R13 — Subiectul exportului preluat dintr-un antet neautorizat (închis)

Aspect	Detaliu
Amenințare	GET /v1/me/export prelua subiectul din antetul X-Patient-Profile-ID. Middleware-ul verifică acel antet doar ca formă și, în mod deliberat, nu îl autorizează, lăsând această sarcină interogării — iar depozitul acestui endpoint citește din pool-ul de administrare, unde nu există nicio interogare căreia să i-o lase: RLS nu se aplică, iar fiecare instrucțiune din arhivă era WHERE patient_profile_id = $1, fără niciun predicat privind apelantul sau organizația. Prin urmare, orice pacient autentificat putea obține arhiva completă a oricărui alt pacient modificând un singur antet
Efect în caz de exploatare	Profilul, programările, formularele, consimțămintele și evidențele clinice ale persoanei numite, din toate clinicile pe care le frecventează, într-un singur fișier JSON. Interogarea selectează identificatorul național criptat, iar serviciul îl decriptează — corect pentru o persoană vizată reală, însă pe acest traseu o divulgare a CNP-ului care ocolea deopotrivă permisiunea patients.view_national_id și singura înregistrare de audit de citire din platformă
Drepturi afectate	Confidențialitate (Art. 32) și integritatea însăși a dreptului de acces prevăzut la Art. 15
Persoane vizate afectate	Potențial, fiecare pacient de pe platformă
Probabilitate / gravitate inerentă	Exploatarea nu necesita niciun privilegiu peste un cont de pacient valid, însă necesita cunoașterea unui identificator de profil — un UUID aleatoriu, care nu poate fi nici ghicit, nici enumerat. Gravitate: ridicată → Ridicat
Soluționare	Închis. Subiectul se rezolvă acum prin patientscope.ResolveSubject, care răspunde exclusiv cu profiluri la care ajunge contul apelant — propriul profil și cele pentru care deține o legătură de aparținător. O cerere care numește un profil inaccesibil este refuzată, în loc să primească în tăcere arhiva proprie a apelantului, astfel încât nimeni să nu primească un fișier etichetat cu numele altei persoane. Un test de integrare verifică toate cele trei proprietăți: profilul unui străin este refuzat, exportul propriu funcționează în continuare, iar un aparținător își poate exporta în continuare persoana aflată în întreținere
Probabilitate / gravitate reziduală	Scăzută / Ridicată → Scăzut
⚠️ De consemnat	Endpointul nu scrie nicio înregistrare de audit, prin proiectare: cel care accesează este în mod normal persoana vizată, iar jurnalizarea faptului că cineva își citește propria evidență constituie supravegherea exercitării unui drept, nu un control asupra lui. Raționamentul este corect și se sprijinea pe ipoteza pe care acest defect a infirmat-o — prin urmare, nu există nicio evidență a faptului că defectul a fost sau nu exploatat înainte de a fi închis. Orice evaluare privind producerea unei încălcări a securității datelor trebuie să pornească de la această absență, nu de la jurnale

R14 — Migrarea propriu-zisă a datelor preexistente

Aspect	Detaliu
Amenințare	Mutarea a aproximativ 20.000 de pacienți, a peste 11.000 de planuri de tratament și a peste 5.000 de abonamente din sistemul preexistent în această platformă este, în sine, o operațiune de prelucrare la scară largă. Modurile de eșec diferă de cele ale funcționării curente: evidențe atribuite pacientului greșit; starea consimțământului pierdută sau inventată în traducere; câmpuri preexistente importate fără un scop declarat; o rulare încheiată parțial, care lasă două sisteme convinse deopotrivă că dețin evidența de referință
Drepturi afectate	Exactitate (Art. 5 alin. (1) lit. (d)), legalitate (Art. 6), minimizare (Art. 5 alin. (1) lit. (c)), integritate (Art. 32)
Persoane vizate afectate	Întreaga populație migrată — cel mai numeros grup vizat de prezentul document
Probabilitate / gravitate inerentă	Medie / Ridicată → Ridicat
Măsuri	Constrângerile de proiectare deja incidente: schema preexistentă nu se preia, prin urmare fiecare câmp ajunge printr-o corespondență explicită, nu printr-o copiere de tabele — un câmp fără corespondent nu are unde să ajungă, ceea ce impune minimizarea chiar la graniță. Consimțământul nu se deduce: un scop fără dovadă în sistemul preexistent sosește neacordat, nu presupus, iar poarta de re-consimțământ îl solicită apoi pacientului. Ștergerea logică generalizată face ca o evidență atribuită greșit să fie recuperabilă, nu distrusă. Migrarea rulează pe o schemă-țintă completă printr-o secvențiere deliberată — este programată ultima tocmai pentru a nu migra într-o țintă în mișcare
Probabilitate / gravitate reziduală	Medie / Ridicată → Mediu, și numai sub ipoteza de mai jos
⚠️ Ipoteză	Instrumentele de migrare nu există încă, prin urmare aceste măsuri descriu o intenție de proiectare, nu o implementare verificată. Riscul trebuie reevaluat în raport cu instrumentele reale înainte de rulare, iar această reevaluare este o condiție prealabilă a lansării din septembrie, nu o acțiune ulterioară. Fidelitatea evidențelor de consimțământ preexistente decide, în particular, dacă pacienții migrați sosesc cu un temei juridic consemnat sau trebuie reîntrebați

Sumarul riscului rezidual

Se citește coloana din dreapta. Cea din stânga arată riscul dacă platforma nu ar avea nicio măsură de protecție — este „Ridicat” pentru majoritatea intrărilor pentru că este vorba despre date privind sănătatea, iar un registru în care nu ar fi așa ar însemna că amenințările au fost subevaluate. Coloana din dreapta este evaluarea care descrie platforma așa cum funcționează efectiv, cu măsurile din intrările de mai sus aplicate.

Risc	Dacă nu s-ar face nimic	Cu măsurile aplicate
R1 scurgere între tenanți	Ridicat	Mediu
R2 acces al personalului	Ridicat	Scăzut
R3 compromiterea cheilor	Mediu	Mediu
R4 acces guvernamental	Mediu	Scăzut
R5 consimțământ nevalabil	Ridicat	Scăzut (sub rezerva consilierului)
R6 deriva telemetriei	Mediu	Scăzut
R7 activarea urmăririi poziției corp.	Ridicat	Mediu
R8 disponibilitate	Mediu	Scăzut
R9 scurgere în jurnale	Mediu	Scăzut
R10 ștergere insuficientă	Mediu	Scăzut
R11 stream-ul consultației video	Ridicat	Mediu
R12 arhiva imuabilă vs. ștergere	Mediu	Scăzut
R13 autorizarea subiectului exportului	Ridicat	Scăzut (închis)
R14 migrarea datelor preexistente	Ridicat	Mediu (sub o ipoteză neverificată)

Cu măsurile aplicate, nicio intrare din prezentul registru nu se situează la „Ridicat”. Cinci din cele paisprezece intrări rămân la „Mediu” — R1, R3, R7, R11 și R14 — iar celelalte nouă la „Scăzut”. Potrivit practicii CEPD și ANSPDCP, acesta este profilul unei prelucrări care poate continua fără consultarea prealabilă prevăzută la art. 36 — sub rezerva avizelor de mai jos, care nu au fost obținute.

R13 a constituit excepția până de curând: evaluat ca ridicat și neatenuat, închis între timp la sursă. Este păstrat în registru, nu eliminat: o autoritate de supraveghere are dreptul să vadă că defectul a existat și ce s-a făcut în privința lui, iar nota sa privind auditul rămâne o limitare permanentă, nu una soluționată.

Avizul consilierului și contrasemnarea RPD rămân neobținute, independent de acest aspect.

Celelalte zone de atenție:

• R11 consultațiile video — cel mai sensibil, iar măsura care face cea mai mare parte a muncii este o alegere de inginerie, nu una contractuală: nu se înregistrează nimic. Dacă înregistrarea se activează vreodată, R11 se reevaluează de la zero, nu se modifică.
• R3 compromiterea cheilor de criptare — redus suplimentar prin migrarea la KMS gestionat de client, Faza 2, documentată în aws-infrastructure.md.
• R7 ingestia datelor de poziție corporală — blocat de două ori: consimțământ reînnoit, anexă DPIA, aviz RPD și versiune nouă a notei de informare, pe latura GDPR; actualizarea destinației medicale declarate către clasa IIa, pe latura MDR. Jumătatea de ingestie nu este scrisă, ceea ce constituie o măsură mai puternică decât un comutator de funcționalitate.
• R12 ștergerea față de arhiva de backup — poziția este apărabilă și acum consemnată; procedura de reaplicare după restaurare este restantă.

§4 Anexă — Programul de telereabilitare F9

Anexă DPIA țintită pentru jumătatea de pacient F9 livrată la lansare. Acoperă programul ghidat asincron de exerciții — fără consultații în direct la lansare.

F9.1 Descriere

Fiecare pacient primește un program a cărui durată o stabilește clinicianul. Per sesiune:

• Pacientul lansează sesiunea în Portal
• Redă clipul video pentru fiecare exercițiu prescris. Redarea se face printr-un element <video> nativ, cu stream HLS de la CDN-ul video, nu printr-un player terț încorporat în iframe. Distincția contează pentru prezenta evaluare: niciun cadru terț nu se execută în sesiunea pacientului, astfel încât CDN-ul vede o cerere de fișier media, nu contextul paginii din jurul ei
• Auto-raportează VAS (durere) și RPE (efort) la finalul sesiunii
• Înregistrează finalizarea sesiunii
• Adaugă opțional comentarii text liber

Pacientul poate face pauză și relua; sesiunile nu sunt blocate temporal.

F9.2 Riscuri specifice

• R-F9-1: Calitatea datelor auto-raportate. Risc: pacienții înțeleg greșit scala VAS sau RPE → semnal clinic de calitate scăzută → posibile decizii clinice ulterioare luate pe baza unor date defectuoase Control: explicație în aplicație a scalelor, multilingvă; revizuirea periodică a distribuției scalelor pentru distorsiuni sistematice; revizuirea de către clinician a scorurilor individuale în context.
• R-F9-2: Abandon fără intervenție. Risc: pacientul abandonează, clinica nu observă, starea clinică a pacientului se agravează. Control: aderența și abandonul sunt afișate personalului clinicii în suprafețele de analiză din Aplicația Clinică — perspectiva clinicii asupra propriilor pacienți; un tablou de bord la nivel de platformă ar constitui o citire între tenanți. Escaladarea este un proces clinic aflat în sarcina operatorului; platforma pune la dispoziție semnalul.
• R-F9-3: Deriva conținutului sub un pacient aflat în program. Risc: clinicianul modifică un conținut partajat, iar modificarea ajunge la un pacient aflat deja la jumătatea programului, alterându-i prescripția fără o decizie clinică. Control: conținutul este copiat la derivare, nu referențiat — rândul pe care îl redă pacientul îi aparține, prin urmare modificarea unui șablon din bibliotecă nu îl poate atinge. Modificarea unei prescripții active impune mai întâi retragerea publicării, ceea ce deschide o pauză consemnată, iar republicarea este un act explicit.

F9.3 Necesitate / proporționalitate

Catalogul video, evidența de aderență pe sesiune, instrumentul clinic pe sesiune — fiecare este necesar pentru produsul clinic. Mai puține date ar însemna un program clinic mai puțin util.

§5 Anexă — Telemetria de aderență F10 (jumătatea media)

Anexă DPIA țintită pentru serviciul de telemetrie care ingerează datele de vizionare și de finalizare. Ingestia datelor de poziție corporală nu se află în sferă și nu este implementată — a se vedea R7.

F10.1 Descriere

Un serviciu Go dedicat (services/telemetry/) ingerează:

• evenimente de redare: buffering, actualizări ale procentului de vizionare, erori
• o metrică agregată pe sesiune: procent total de vizionare, finalizare, durată
• evenimente de eroare video

Rândurile sunt indexate după patient_id, în cadrul unui organization_id — un identificator opac, niciodată un nume, o adresă de e-mail sau un CNP; reidentificarea necesită accesul la baza de date principală, controlată separat.

Ingestia este condiționată de audiența și semnătura tokenului de sesiune, nu de un indicator de consimțământ. Telemetria de angajament și de calitate a redării se prelucrează în temeiul interesului legitim, art. 6 alin. (1) lit. (f). Dreptul de opoziție prevăzut la Art. 21 este respectat, cu consecința că pacientul nu mai poate rula sesiuni, întrucât datele de calitate a redării sunt necesare pentru funcționarea redării — acesta este rezultatul testului de echilibru.

F10.2 Riscuri specifice

• R-F10-1: Dreptul de opoziție prevăzut la Art. 21 nu este respectat. Risc: un pacient se opune prelucrării întemeiate pe interes legitim a telemetriei de redare, iar platforma continuă ingestia. Control: clinica prezintă nota de informare, ca operator, și transmite opoziția către platformă; răspunsul platformei este suspendarea ingestiei pentru acel pacient, cu consecința că nu mai pot avea loc sesiuni până la soluționare. Proces urmărit de RPD; prin proiectare nu există un comutator per sesiune în interfață, întrucât Art. 7 alin. (4) l-ar invalida ca fiind consimțământ constrâns.
• R-F10-2: Colectare excesivă de telemetrie. Risc: evenimentele se acumulează peste ceea ce necesită scopul dezvăluit (de exemplu, interacțiuni detaliate din interfață, dincolo de procentul de vizionare). Control: suprafața de ingestie acceptă un set fix de forme de evenimente și respinge orice altceva, prin urmare lărgirea colectării necesită o modificare de schemă și de cod, nu una de configurare. ⚠️ Limita este însăși schema de ingestie — nicio verificare automată din CI nu o afirmă independent, deci nimic nu oprește compilarea dacă setul acceptat se lărgește.
• R-F10-3: Retenția bloburilor de telemetrie. ⚠️ Neactiv, păstrat deliberat în registru. Telemetria se agregă în propria bază de date PostgreSQL; niciun bucket S3 pentru telemetrie nu este definit în infrastructură, prin urmare nu există bloburi de reținut și nicio politică de ciclu de viață care să le guverneze. Riscul devine real în momentul introducerii stocării de bloburi — cel mai probabil prin pipeline-ul amânat de urmărire a poziției corporale — moment în care o măsură veritabilă de retenție trebuie construită și consemnată aici, nu presupusă.
• R-F10-4: Bypass autentificare între servicii. Risc: un verificator de token de sesiune semnat configurat greșit permite ingestia dintr-o sursă din afara platformei. Control: token-uri semnate HS256 emise de API la începutul sesiunii cu TTL scurt; verificatorul este livrat în services/telemetry/; testele acoperă validarea tokenului.

F10.3 Necesitate / proporționalitate

Aderența este principalul indicator de rezultat pe care clinica îl folosește pentru a evalua eficacitatea programului și pentru a identifica abandonurile. Fără aceasta, clinica nu poate interveni. O telemetrie mai puțin granulară (de exemplu, doar „sesiune finalizată da/nu", fără procent de vizionare) ar slăbi substanțial detectarea abandonurilor. Granularitatea procentului de vizionare este proporțională.

§6 Anexă — Consultațiile video F5.5

Anexă țintită pentru consultațiile video în timp real. Există pentru că aceasta este singura prelucrare prin care platforma predă date din categoria Art. 9 în clar unui terț.

F5.5.1 Descriere

Un clinician și un pacient se alătură unei camere private pentru o consultație programată. Platforma creează camera, emite câte un token de scurtă durată pentru fiecare participant și primește notificări privind ciclul de viață al camerei. Stream-ul media este retransmis de Daily, Co. printr-un server de media fixat în eu-central-1. Nu se înregistrează nimic, nici de către noi, nici de către furnizor.

Integrarea cu furnizorul este deliberat îngustă: tot comportamentul specific furnizorului este izolat într-un singur fișier adaptor, iar schema subiacentă este agnostică față de furnizor, astfel încât subîmputernicitul poate fi înlocuit fără o modificare a modelului de date.

F5.5.2 Ce află și ce nu află furnizorul

Furnizorul primește	Furnizorul nu primește
Stream-ul consultației propriu-zis (audio și video)	Niciun identificator de pacient, adresă de e-mail, dată de naștere sau CNP
Un nume afișat în cadrul consultației	Evidența clinică, conținutul programării, răspunsurile la formulare sau datele de aderență
O referință opacă de participant, derivată de platformă	Orice mijloc de a asocia acea referință unei persoane
Referința camerei, numărul maxim de participanți, expirarea tokenului	Afecțiunea, serviciul sau specialitatea clinicianului — nimic din numele camerei, din token sau din webhook nu transmite context clinic
Metadate de conexiune WebRTC (IP, dispozitiv, calitatea rețelei)	Nimic în repaus: nu există o înregistrare care să fie stocată

Referința opacă este elementul de proiectare care merită enunțat explicit. Ea revine la fiecare notificare, deci atribuirea funcționează de partea noastră, fără ca furnizorul să afle vreodată cine este participantul.

F5.5.3 Riscuri specifice

Evaluate la R11. Pe scurt: postura tehnică este cea mai solidă dintre toate transferurile din evaluarea transferurilor, pentru că absența înregistrării elimină depozitul de care depind deopotrivă constrângerea legală, compromiterea și distribuirea greșită. Postura contractuală este de asemenea solidă: termenii furnizorului încorporează acordul de prelucrare și consideră clauzele contractuale standard semnate, cu modulul 3 — persoană împuternicită către subîmputernicit — selectat de rolul nostru real. Singurul punct deschis este că contul la furnizor este partajat cu sistemul preexistent, ceea ce constituie o problemă de segregare în sensul Art. 32 și lasă neconfirmată entitatea juridică parte la contract.

F5.5.4 Necesitate / proporționalitate

O consultație la distanță este chiar serviciul pe care pacientul l-a solicitat; nu există o modalitate mai puțin intruzivă de a o desfășura. Proporționalitatea se sprijină pe trei alegeri, fiecare renunțând la date pe care platforma le-ar fi putut colecta:

• Absența înregistrării. O înregistrare ar fi utilă clinic și este chiar scopul pentru care a fost redactat instrumentul de consimțământ video_recording. Nu este activată, instrumentul nu este publicat, iar niciun traseu de cod nu o pornește. Activarea înregistrării înseamnă o nouă DPIA, un instrument publicat și un nou consimțământ — nu o schimbare de configurare.
• Fixarea în UE care eșuează în siguranță. Adaptorul returnează eroare atunci când regiunea nu este configurată, în loc să aplice o valoare implicită, astfel încât o configurare greșită nu poate retransmite discret date de sănătate din UE printr-un server din Statele Unite.
• Pseudonimitate prin construcție. Furnizorul primește strictul necesar funcționării.

F5.5.5 Consimțământ

Instrumentul telemedicine trebuie adoptat înainte de începerea unei consultații; poarta se armează la adoptare, iar retragerea închide sesiunea în curs. video_recording este un instrument separat, nepublicat, care condiționează o funcționalitate ce nu operează.

§7 Sumarul măsurilor de atenuare

Platforma operează cu:

Atenuare	Unde
Izolare multi-tenant bazată pe RLS	Nivel BD
Break-glass pentru accesul platformei între tenanți	Middleware + UI
Consimțământ pe scop cu retragere cu efect imediat	Serviciul de consimțământ (1B.9)
Jurnal de audit al fiecărei modificări de stare (citirile nu se jurnalizează)	Jurnal de audit (P41)
Criptat la repaus + în tranzit	KMS, TLS verify-full
Rezidență de date UE	eu-central-1
CCS + TIA pentru subîmputerniciții din afara UE	Lista subîmputerniciților + TIA
Backup + DR, cu restaurare testată chiar din arhivă	Multi-AZ + PITR + arhivă pg_dump sub Object Lock
⚠️ RPD nedesemnat — mai multe măsuri din prezenta evaluare sunt atribuții ale RPD	Memorandumul de desemnare RPD
Procedura de notificare a incidentelor + 48h notificare operator	Procedura de notificare a incidentelor
Absența înregistrării consultațiilor + fixarea media în UE care eșuează în siguranță	Adaptorul furnizorului video (F5.5)
CNP criptat, scris doar pe un traseu cu audiență de pacient, mascat, auditat la citire, refuzat prin declanșator în spațiile cu formă liberă	internal/core/crypto + declanșatoare BD
Controale specifice F9 / F10 / F5.5	Anexele prezentei evaluări

§8 Concluzie (sub rezerva consilierului + RPD)

Poziția onestă, înaintea unei lansări care mai mult decât cvadruplează populația vizată:

Construcția prelucrării rezistă. Modelul de izolare, registrul de consimțăminte, postura de criptare pentru identificatorii care o justifică, decizia de a nu înregistra consultațiile, refuzul de a deduce consimțământul pentru marketing — toate au fost verificate în raport cu codul în prezenta revizie și sunt reale.

Ceea ce nu rezistă este presupunerea că tot ce afirma acest document era implementat. Trei măsuri denumite explicit s-au dovedit inexistente, iar un endpoint s-a dovedit defect în mod semnificativ. Este un eșec de disciplină documentară în aceeași măsură în care este unul de inginerie: o DPIA ale cărei măsuri sunt aspiraționale este mai rea decât inutilă pentru o autoritate de supraveghere, întrucât este chiar artefactul pe care aceasta s-ar sprijini pentru a conchide că riscul a fost analizat.

Condiție	Stadiu
Avizul consilierului prin F11.0.5 D7	⛔ Neobținut. Angajamentul descris nu a fost inițiat
Contrasemnarea RPD — memorandumul de desemnare	⛔ Neobținută; postul este vacant
§3.1 din nota către consilier (CNP)	⚠️ Implementat prudent (doar trasee cu audiență de pacient, criptat, mascat, auditat) înaintea răspunsului juridic. Răspunsul rămâne restant
§3.2 (sub 16 ani), §3.4 (tabel de retenție), §3.5 (sfera semnăturii biometrice)	⛔ Deschise
Contractul Art. 28 + instrumentul de transfer Art. 46 pentru subîmputernicitul video	✅ În vigoare prin încorporare în termenii furnizorului. ⚠️ Contul este partajat cu sistemul preexistent, deci entitatea contractantă rămâne neconfirmată
R14 — reevaluarea instrumentelor de migrare	⛔ Instrumentele nu există încă; măsurile din prezenta evaluare sunt intenție de proiectare și trebuie reverificate în raport cu implementarea reală
Mediul de producție aprovizionat cu MTO-urile documentate	✅ În funcțiune din 05.06.2026

Două lucruri trebuie să fie adevărate înaintea lansării din septembrie, niciunul nefiind blocat de altceva decât de decizia de a le face:

1. R14 este reevaluat în raport cu instrumentele reale. În prezent, măsurile sale sunt intenții.
2. Angajamentul consilierului și desemnarea RPD au loc. Fiecare document din acest director este redactat de dezvoltator și nerevizuit, iar mai multe măsuri invocate aici sunt atribuții ale unui RPD care nu există.

R13 era al treilea și este închis.

Celelalte elemente procedurale — separarea contului la furnizor, mecanismul de arhivare a jurnalului de audit — sunt reale, însă nu condiționează lansarea în felul în care o fac cele trei de mai sus.

§9 Aprobări

Rol	Nume	Semnătura	Data
Redactat de (Platformă)	{{SIGNATORY}}	__	__
Aviz consilier	{{COUNSEL_FIRM}}	__	__
Contrasemnare RPD	{{DPO_NAME}}	__	__
Recunoaștere management de top	{{TOP_MANAGEMENT}}	__	__

Jurnal de modificări

Data	Modificare
06.09.2026	R13 închis la sursă — exportul își rezolvă acum subiectul din contul apelant, în locul antetului cererii, cu un test de integrare care acoperă refuzul, exportul propriu și cazul aparținătorului.
06.09.2026	Reverificată afirmație cu afirmație în raport cu codul sursă și reîncadrată de la lansarea abandonată din iunie 2026 (aproximativ 5.000 de pacienți) la lansarea din septembrie 2026, la care migrează aproximativ 20.000 de pacienți preexistenți. Paisprezece enunțuri au fost corectate. Noi: R11 (stream-ul consultației video), R12 (arhiva imuabilă față de ștergere), R13 (endpointul de export nu autorizează persoana vizată — activ, RIDICAT, neatenuat) și R14 (migrarea ca operațiune de prelucrare distinctă), plus §6. Trei măsuri denumite explicit s-au dovedit inexistente: cmd/check-telemetry-bounds, treatment_plans_versions.sessions_snapshot și depozitul S3 de telemetrie cu politica sa de ciclu de viață. Corectate: citirile nu se jurnalizează (un singur punct de apel ActionRead; o sesiune break-glass exclusiv de citire nu consemnează nimic); registrul de consimțăminte reține IP-ul, dar nu user-agentul; marketingul este refuzat din principiu, nu condiționat de consimțământ; nu există blocare sub 16 ani și niciun flux de consimțământ parental; telemetria se indexează după patient_id, nu principal_id; patient_exercise_logs nu există; redarea se face printr-un <video> nativ, nu printr-un iframe Bunny; aderența se afișează în Aplicația Clinică, nu într-un tablou de bord al Consolei; telemetria se prelucrează în temeiul interesului legitim, nu al consimțământului; drepturile de la Art. 15/17/20 sunt livrate, nu în curs. Consemnate și înregistrarea ca dispozitiv medical clasa I, precum și postura implementată a CNP-ului.
15.05.2026	DPIA inițială v1 — platformă + anexe F9 + F10 (jumătatea media). Anexa pentru urmărirea poziției corporale amânată până la momentul activării