Cum Sunt Protejate Datele Pacienților
Imaginea completă: cine este responsabil pentru datele pacienților, cum își dau pacienții consimțământul, cum funcționează notele de informare privind confidențialitatea și ce pot și ce nu pot vedea angajații platformei.
Acesta este documentul de citit primul, dacă doriți să înțelegeți modul în care RestartiX gestionează datele pacienților — la un nivel care nu necesită cunoștințe juridice sau tehnice. Acoperă cea mai consecventă decizie de proiectare din platformă (cine este operator pentru datele pacienților) și o urmărește până la consecințele practice asupra înregistrării, programărilor, opțiunilor de marketing, drepturilor GDPR și asupra cazurilor rare în care angajații platformei au nevoie să consulte datele unei clinici.
Dacă sunteți autoritate de reglementare, investitor, administrator de clinică ce evaluează platforma sau membru al echipei de management ce se pregătește pentru o discuție de due-diligence — aceasta este pagina potrivită.
Pentru raționamentul arhitectural formal, consultați De ce clinica este operator, iar platforma este persoană împuternicită.
Decizia Centrală: Cine Este Responsabil pentru Datele Pacienților
Conform legii europene de protecție a datelor, fiecare parte care gestionează date cu caracter personal este fie operator (decide de ce și cum sunt utilizate datele), fie persoană împuternicită de operator (acționează conform instrucțiunilor operatorului). Greșirea acestei distincții este una dintre cele mai costisitoare erori pe care le poate face o platformă healthtech — atât pentru platformă, cât și pentru clinicile pe care le deservește.
RestartiX adoptă aceeași poziție pe care Stripe o are față de comercianți:
- Fiecare clinică este operator pentru datele pacienților săi — clinica deține relația cu pacientul, decide ce servicii oferă, ce formulare colectează și cum sunt utilizate datele pacienților.
- RestartiX este persoană împuternicită de operator — furnizează platforma în baza unui Acord de Prelucrare a Datelor (APD) și prelucrează datele pacienților numai conform instrucțiunilor clinicii.
- Fără operatori asociați pentru datele pacienților. Funcționalitățile inter-clinici care altfel ar crea o relație de operatori asociați funcționează exclusiv pe date anonimizate.
Există o singură excepție îngustă: RestartiX este operator pentru felia subțire de date la nivel de cont necesare pentru ca platforma să funcționeze — credențialele de autentificare, telemetria de securitate asupra contului în sine, prevenirea fraudelor. (Stripe face aceeași distincție în politica sa de confidențialitate: comercianții sunt operatori pentru datele tranzacțiilor; Stripe este operator numai pentru contul propriu al comerciantului.)
Aceasta nu este o alegere de prezentare. Este impusă prin modul în care este construită platforma — fiecare funcționalitate, fiecare pagină din Console, fiecare capabilitate inter-clinici respectă această graniță. Datele pacienților nu circulă între clinici. Angajații platformei nu pot naviga implicit prin datele identificabile ale pacienților din mai multe clinici. Notele de informare privind confidențialitatea aparțin clinicilor. Solicitările privind drepturile persoanelor vizate (DSAR) se direcționează către clinică.
Restul acestei pagini este consecința practică a acelei singure decizii.
Ce Vede Pacientul: O Suprafață a Consimțământului pe Două Niveluri
Pacienții întâlnesc consimțământul în două locuri distincte, iar cele două sunt deliberat separate. Aceasta este suprafața pe care o experimentează pacientul; sub capotă, fiecare acordare sau retragere este înregistrată într-un registru unic, doar de adăugare, astfel încât istoricul complet să fie disponibil ulterior.
Nivelul A — Consimțăminte de tip SaaS (preferințe și confirmări comutabile)
Acestea sunt consimțămintele pe care pacientul le întâlnește în momentul în care se înregistrează, plus preferințele de tip marketing pe care le poate comuta din setările contului. Se comportă ca niște consimțăminte dintr-un produs SaaS obișnuit.
| Consimțământ | Ce este | Retractabil? | Unde apare |
|---|---|---|---|
| Termenii și condițiile platformei | Contractul cu RestartiX pentru utilizarea portalului pacientului | Nu (revocarea = ștergerea contului) | Înregistrare |
| Nota de informare privind confidențialitatea platformei | Confirmarea prelucrării datelor la nivel de cont de către platformă | Nu (acceptare informativă) | Înregistrare |
| Termenii și condițiile clinicii (dacă clinica publică așa ceva) | Contractul dintre pacient și clinică | Nu (revocarea = părăsirea clinicii) | La înregistrarea în clinică, prin portal |
| Nota de informare privind confidențialitatea clinicii | Informarea proprie a clinicii privind protecția datelor (nota GDPR principală a pacientului) | Nu (informativă, dar prelucrarea subiacentă are propriul temei juridic) | La înregistrarea în clinică, prin portal |
| Email / SMS de marketing | Permite acceptarea sau refuzul comunicărilor de marketing ale clinicii | Da — comutator în setările pacientului | Bifări la înregistrare sau în setări |
| Analiză | Permite acceptarea sau refuzul analizei de utilizare pseudonimizate | Da — comutator în setările pacientului | Bifări la înregistrare sau în setări |
| Prelucrare AI | Permite acceptarea sau refuzul prelucrării asistate de AI a datelor clinice ale pacientului | Da — comutator în setările pacientului | Bifări la înregistrare sau în setări |
Atunci când un pacient dezactivează un comutator de marketing, modificarea intră în vigoare imediat — nu mai pleacă niciun email de marketing, comutatorul este înregistrat ca retras în registru, iar jurnalul de audit arată cine a efectuat acțiunea (în mod normal, pacientul însuși).
Atunci când un pacient dorește să revoce termenii platformei — singura cale este ștergerea contului. Portalul afirmă explicit acest lucru: „pentru a revoca aceste prevederi, ștergeți contul" cu un buton care declanșează fluxul de ștergere conform GDPR.
Nivelul B — Consimțăminte medicale bazate pe formulare
Acestea sunt consimțămintele asociate formularelor semnate ale clinicii — acceptarea telemedicinei, consimțământul pentru înregistrarea video, consimțământul pentru captura biometrică, consimțăminte specifice tratamentului, consimțământul pentru partajarea profilului. Sunt semnate la momentul programării sau înainte de o activitate specifică și sunt semnate în raport cu nota de informare privind confidențialitatea a clinicii — niciodată în raport cu cea a platformei.
Fiecare consimțământ de Nivel B are trei moduri de semnare disponibile, în funcție de situație:
- Click în portal — pacientul semnează de pe telefonul sau laptopul propriu, oriunde are conexiune la internet. Folosit pentru consimțămintele de telemedicină, partajarea profilului și majoritatea pașilor de consimțământ premergători programării.
- Desenat pe tabletă în clinică — pacientul este la recepție, recepționerul îi înmânează o tabletă, pacientul își desenează semnătura cu degetul sau cu stylus-ul, iar formularul semnat este salvat imediat. Fără hârtie, fără scanare, fără aplicație separată.
- Trimis pe telefon prin link — pentru consimțăminte ce trebuie semnate rapid în timpul unei programări telefonice (de exemplu, pacienții vârstnici care sună). Agentul generează un link unic, îl trimite pe telefonul pacientului, iar pacientul finalizează consimțământul pe propriul dispozitiv.
În oricare dintre moduri, platforma înregistrează aceeași dovadă: cine a semnat, când, de la ce adresă IP, pe ce dispozitiv și în raport cu ce versiune exactă a textului formularului. Odată semnat, formularul este imutabil din punct de vedere juridic — sistemul respinge orice tentativă de modificare.
Retragerea consimțămintelor de Nivel B se face per scop. Retragerea consimțământului pentru înregistrare video oprește înregistrările ulterioare fără a afecta planul de tratament subiacent sau alte consimțăminte.
Note de Informare privind Confidențialitatea: Deținute de Clinică, cu Schelăria Furnizată de Platformă
Fiecare clinică publică propria notă de informare privind confidențialitatea. Platforma nu prezintă pacienților o notă generică „RestartiX" în numele clinicilor — acest lucru ar atribui greșit calitatea de operator.
În schimb, platforma furnizează șabloane versionate pe care clinica le completează:
- Platforma livrează un șablon de bază (în română și engleză) redactat conform ghidurilor ANSPDCP, care acoperă prelucrarea evidențelor medicale conform art. 9 alin. (2) lit. (h) din GDPR, retenția conform Legii nr. 95/2006, drepturile pacientului și lista sub-procesatorilor.
- Șablonul are locuri marcate pe care clinica le completează: denumirea clinicii, sediul social, emailul responsabilului cu protecția datelor, sumarul temeiului juridic și altele.
- Șablonul are secțiuni comutabile pentru activități de prelucrare pe care nu orice clinică le desfășoară — înregistrare video, captură biometrică, transfer transfrontalier pentru a doua opinie. Administratorul clinicii revizuiește fiecare secțiune și o include numai dacă se aplică efectiv clinicii sale.
- Administratorul clinicii previzualizează nota de informare asamblată așa cum va apărea pacienților, apoi o publică.
- Nota publicată devine versiunea pe care pacienții clinicii o văd și o acceptă în timpul înregistrării.
Atunci când platforma își actualizează șablonul (o modificare reglementară, o schimbare la nivelul sub-procesatorilor), fiecare clinică primește o solicitare de „revizuire a actualizării șablonului" — dar nota existentă a clinicii continuă să fie servită până când clinica republică. Nu există niciun moment în care actul juridic să fie în schimbare fără ca clinica să îl aprobe explicit.
O clinică ce nu și-a finalizat și publicat nota de informare privind confidențialitatea nu poate înregistra pacienți. Sarcina „finalizați nota dumneavoastră de informare privind confidențialitatea" face parte din procesul de admitere a clinicii tocmai din acest motiv.
Ce Pot și Ce Nu Pot Vedea Angajații Platformei: Accesul Break-Glass
Angajații platformei (suport, securitate, inginerie din partea RestartiX) nu pot naviga implicit prin datele identificabile ale pacienților din mai multe clinici. Console — aplicația de superadmin a platformei — este construită în jurul acestei constrângeri. Implicit, fiecare suprafață Console este la nivel agregat / domeniu de persoană împuternicită: lista organizațiilor, profilul și facturarea organizației, contoare de pacienți, metadate de audit (timestamp-uri, acțiuni, coduri de status), starea de sănătate a sistemului.
Datele identificabile inter-clinici ale pacienților — listele de pacienți pe clinică, detaliile pacienților, conținutul jurnalului de audit cu diferențe — necesită elevare break-glass.
Cum funcționează break-glass
Atunci când un angajat al platformei are nevoie să acceseze date identificabile ale pacienților dintr-o anumită clinică — pentru a investiga un tichet de suport, a răspunde la un incident de securitate, a redirecționa un DSAR ajuns în locul greșit sau a urmări o investigație de fraudă — trebuie să:
- Deschidă o sesiune de elevare delimitată la o singură clinică și la un singur tip de acces (de exemplu, „detaliu pacient la Clinica X").
- Furnizeze o justificare — o categorie (
tichet_suport,incident_securitate,redirecționare_dsar,investigație_fraudă,inginerie_platformă) și o descriere liberă, plus referința tichetului sau a incidentului, dacă există. - Stabilească un timp de expirare — sesiunile au implicit 1 oră, plafonate la 4 ore. Nu există un mod de tipul „lasă-l deschis toată ziua".
- Aibă permisiunea corespunzătoare — domeniile break-glass sunt permisionate individual, nu generic. Un inginer de suport poate avea
break_glass.detaliu_pacientpentru o clinică, dar nu șibreak_glass.căutare_inter_organizații.
Odată sesiunea deschisă, fiecare citire efectuată de angajat în interiorul ei este înregistrată în jurnalul de audit — nu doar mutațiile. Sesiunea se închide automat la expirare sau manual de către angajat ori de către un coleg cu permisiune de gestiune break-glass.
De ce primesc clinicile notificări de fiecare dată
Compromisul care face break-glass apărabil — în fața clinicilor, a pacienților, a autorităților de reglementare — este transparența. În momentul în care o sesiune break-glass se deschide față de o clinică, administratorul clinicii primește:
- Un email, care indică numele angajatului RestartiX care a deschis sesiunea, momentul, domeniul către care s-a făcut elevarea și motivul declarat.
- Un banner în interfața admin a clinicii, care arată sesiunile break-glass active și recente față de clinică, cu aceleași metadate.
Clinica știe întotdeauna când angajații platformei s-au uitat la datele sale. Nu există nicio cale de acces silențioasă. Dacă o clinică observă o sesiune ce nu corespunde unui tichet de suport sau unui incident pe care îl așteptau, are un jurnal de audit pe baza căruia poate solicita explicații, iar contractul platformei o obligă să răspundă.
Ce nu este niciodată break-glass
- Navigarea prin toți pacienții din toate clinicile — nu există nicio pagină Console care să facă asta.
- Citirea fișelor clinice ale pacienților pentru a evalua planurile de tratament — aceasta este sarcina clinicii, nu a platformei. Angajații RestartiX nu sunt clinicieni.
- Marketingul sau analiza de produs — acestea rulează exclusiv pe date anonimizate (vezi mai jos).
Ce Pot Vedea Angajații Clinicii: Sesiunea de Reprezentare a Pacientului
Un model separat, dar paralel, gestionează situațiile cotidiene în care angajații clinicii acționează în numele unui pacient — un pacient vârstnic care sună pentru ajutor la completarea unui formular, un pacient cu deficiențe de accesibilitate care are nevoie ca recepționera să îi programeze consultația, o barieră lingvistică în care un angajat bilingv traduce și acționează în sistem. Acest scenariu este o chestiune internă a clinicii (angajații clinicii acționează asupra propriilor pacienți) și, prin urmare, nu privește raportul operator/persoană împuternicită de operator, însă i se aplică aceeași poziție de transparență.
Atunci când angajații clinicii acționează în numele unui pacient:
- Deschid o sesiune de reprezentare a pacientului, cu un motiv declarat și o durată scurtă.
- Sesiunea este limitată în timp (implicit 1 oră, maximum 4); după expirare, nicio acțiune nu mai poate fi efectuată sub umbrela ei.
- Fiecare acțiune din sesiune este înregistrată în jurnalul de audit ca fiind efectuată de către angajat, pacientul fiind identificat prin înregistrarea sesiunii. Formularele sau programările create în timpul sesiunii sunt atribuite pacientului la nivelul datelor; rândul de audit este sursa de adevăr criminalistică pentru „acest angajat a făcut acest lucru în numele pacientului."
- Pacientul vede fiecare sesiune în propriul istoric de acces din portal — cine, când, motivul, durata și ce entități au fost atinse.
Postura de încredere de aici este similară cu cea de la break-glass — limitată în timp, justificată prin motiv, auditată integral, transparentă pentru partea afectată. Diferențele sunt deliberate: partea afectată este pacientul (nu administratorul clinicii), iar accesul rămâne în limitele calității de operator a clinicii. Clinica are deja încredere în angajat prin rolul de bază pe care i l-a acordat; reprezentarea pacientului adaugă deasupra stratul de audit și transparență, nu permisiuni mai fine.
Regula Anonimizării Inter-Clinici
Orice funcționalitate care trebuie să calculeze pe datele pacienților din mai multe clinici — analiza la nivel de platformă, indicatori de referință, corpus de antrenament AI, căutare inter-clinici — funcționează exclusiv pe date anonimizate. Odată ce datele sunt despuiate ireversibil de identificatori, ele încetează să fie date cu caracter personal, iar întrebarea privind calitatea de operator se dizolvă.
Exemplu concret: atunci când RestartiX construiește un dashboard de referință care arată „aderența medie la planul de tratament în toate clinicile de pe platformă", acel dashboard este construit din date în care fiecare identificator de pacient a fost înlocuit cu un hash unidirecțional. Dashboard-ul este util administratorilor de clinică — pot vedea cum se compară clinica lor — dar nu poate fi inversat pentru a identifica vreun pacient individual la vreo clinică.
Nu identificăm niciodată pacienții dumneavoastră în mai multe clinici. Dacă o funcționalitate chiar nu poate funcționa fără date identificabile inter-clinici, aceasta este o decizie deliberată ce necesită o analiză arhitecturală separată și o justificare documentată — iar sistemul de clasificare a datelor o impune la nivelul ieșirii.
Cum Sunt Gestionate Drepturile Pacientului (DSAR-uri GDPR)
Pacienții își exercită drepturile GDPR — acces, rectificare, ștergere, portabilitate, restricționarea prelucrării — în raport cu operatorul. Operatorul pentru datele pacienților este clinica. Rolul platformei este să ajute pacientul și clinica să finalizeze solicitarea, nu să acționeze ca destinatar principal.
Ce vede pacientul
În portalul pacientului, o pagină „Clinicile dumneavoastră" listează fiecare clinică la care pacientul este înregistrat, cu informațiile de contact ale operatorului fiecărei clinici: emailul responsabilului cu protecția datelor, sediul social și un buton „Trimiteți o solicitare ca persoană vizată" care precompletează datele de contact corecte și identitatea pacientului.
Pentru solicitările de rutină pe care pacientul le poate gestiona singur:
- Acces — pacientul își exportă datele direct din portal. Exportul conține tot ce deține platforma despre el: profil, programări, formulare, consimțăminte, planuri de tratament. În format structurat, citibil de mașini.
- Rectificare — pacientul își actualizează propriul profil. Pentru corecturile clinice, solicită corectura prin personalul clinicii.
- Restricționarea prelucrării — pacientul comută direct consimțămintele retractabile (marketing, SMS, analiză, prelucrare AI). Efectul este imediat.
Pentru solicitările care nu sunt de rutină:
- Ștergere — pacientul transmite solicitarea către clinică. Platforma sprijină fluxul de ștergere (anonimizare, nu eliminare propriu-zisă, deoarece retenția evidențelor medicale este o obligație legală conform Legii nr. 95/2006 — art. 17 alin. (3) lit. (c) din GDPR permite explicit acest lucru).
- Portabilitate dincolo de exportul standard — pacientul transmite solicitarea către clinică.
- Solicitări inter-clinici („ștergeți-mă de peste tot") — fiecare clinică gestionează solicitarea în mod independent. Platforma ajută pacientul să identifice fiecare clinică unde s-a înregistrat vreodată.
Atunci când o solicitare ajunge la platformă din greșeală
Dacă un pacient trimite un DSAR direct către RestartiX fără a indica o clinică, răspunsul platformei este să confirme primirea, să identifice clinica (sau clinicile) relevante și să direcționeze solicitarea către contactul de operator al clinicii. RestartiX nu acționează ca operator principal pentru datele pacienților, iar răspunsul precizează acest lucru.
Dacă pacientul chiar nu poate identifica la ce clinică s-a înregistrat — situația rară a fostului pacient orfan — break-glass este calea documentată: un angajat al platformei deschide o sesiune de tip redirecționare_dsar, identifică clinica și înaintează DSAR-ul. Clinica primește aceeași notificare break-glass ca pentru orice alt acces elevat.
Cum Se Retrage Consimțământul
Mecanica retragerii diferă în funcție de temeiul juridic în baza căruia a fost colectat consimțământul:
| Consimțământ | Cum se retrage | Efect |
|---|---|---|
| Email / SMS de marketing, analiză, prelucrare AI | Comutator în setările pacientului | Imediat. Înregistrat în registrul de consimțăminte și în jurnalul de audit. |
| Partajarea profilului cu o anumită clinică | Retragere din setări sau prin clinică | Clinica pierde imediat accesul la profilul portabil și vede numai numele pacientului. Înregistrările clinice deja create la clinică rămân (sunt înregistrările clinicii, nu datele portabile ale pacientului). |
| Consimțăminte medicale de Nivel B (telemedicină, înregistrare video, captură biometrică, specifice tratamentului) | Retragere prin clinică; unele pot fi retrase din portal | Imediat pentru consimțământul în sine. Efectul ulterior depinde de consimțământ — retragerea înregistrării video oprește noile înregistrări; retragerea capturii biometrice dezactivează instrumentele de măsurare bazate pe cameră. |
| Termenii și condițiile clinicii | Fluxul „părăsesc clinica" din portal | Relația pacientului cu acea clinică se încheie; înregistrările clinice de la clinică intră în fluxul de anonimizare conform politicii de retenție a clinicii. Celelalte clinici de pe platformă nu sunt afectate. |
| Termenii și condițiile platformei | Fluxul „șterg contul" din portal | Contul este închis și toate datele la nivel de platformă sunt anonimizate. Datele pacientului la fiecare clinică sunt gestionate prin procesul de ștergere al fiecărei clinici. |
Fiecare retragere reprezintă un rând în registrul de consimțăminte și un rând în jurnalul de audit. Reacordarea unui consimțământ retras anterior creează o intrare nouă — vechea retragere este păstrată, iar istoricul complet poate fi interogat ulterior.
De Ce Am Ales Această Abordare
Costul de pre-producție al implementării corecte este delimitat și cunoscut: un tabel consents, o mașinărie de șabloane pentru note de informare, un tabel break_glass_sessions, un modal de elevare în Console, o pagină „clinicile dumneavoastră" în portal. Câteva săptămâni de muncă la fundație.
Costul post-producție al implementării greșite este nelimitat. Eliminarea unei suprafețe de tip „navighează prin toți pacienții" din Console, după lansare, este un coșmar de revizuire a achizițiilor pe parcursul mai multor trimestre. Repararea unei calități de operatori asociați apărută din greșeală este un eveniment de nivelul unei sancțiuni de la autoritatea de reglementare. Autoritatea română (ANSPDCP) a aplicat amenzi publice pentru exact acest tipar la alte platforme healthtech din UE.
Construim fundația în mod corect deoarece alternativa este să plătim costul fundației cumulativ, de fiecare dată când o nouă funcționalitate este construită peste o formă greșită.
Unde Puteți Citi Mai Multe
- Conformitate GDPR — încadrarea reglementară și documentele necesare
- Drepturile Pacientului — cum arată în practică fiecare drept GDPR
- Jurnal de Audit — ce este înregistrat, inclusiv sesiunile break-glass
- Izolarea Datelor — cum sunt impuse granițele clinicii la nivelul bazei de date
- Listă de Conformitate — lista completă pentru lansare, pe părți și etape
- Decizia arhitecturală (analiză detaliată) — raționamentul formal, alternativele luate în considerare și compromisurile acceptate
Pentru dezvoltatori
Schema, politicile RLS și middleware-ul care impun toate cele de mai sus sunt documentate în planul de implementare a fundației (secțiunile 1B.9 — Registrul de consimțăminte, 1B.10 — Șabloane pentru note de informare, 1B.11 — Acces break-glass al platformei).