Lista Subîmputerniciților

Artefact public de transparență (Art. 28 alin. (2) + Art. 30 GDPR) și Anexa A la fiecare APD pe care platforma îl semnează. Menținut în repository pentru ca modificările să treacă printr-o revizuire de tip PR; publicat ca pagină web pe restartix.pro. Ultima revizuire: 06.09.2026.

Stadiul revizuirii juridice

Aceasta este o ciornă v1 redactată de dezvoltator. Consilierul revizuiește formularea și confirmă mecanismele de transfer în cadrul angajamentului F11.0.5. Nu se publică extern până la primirea scrisorii de închidere D7.

Ce este acest document

Un subîmputernicit este orice terț care prelucrează date cu caracter personal în numele platformei pentru susținerea serviciului. Art. 28 alin. (2) GDPR impune ca operatorul (clinica) să autorizeze subîmputerniciții, iar persoana împuternicită de operator (platforma) să publice lista. Adăugarea, eliminarea sau înlocuirea unui subîmputernicit declanșează o notificare către fiecare operator de pe platformă.

Trei termeni se păstrează distincți (a se vedea glosarul):

• Subîmputernicit — terțul care prelucrează date cu caracter personal conform instrucțiunilor platformei (această pagină).
• Furnizor selectat / Cat A — API terț apelat de platformă cu credențialele platformei (se suprapune cu subîmputernicitul atunci când apelul implică date cu caracter personal; a se vedea furnizorii externi).
• Cont conectat / Cat B — terțul pe care îl conectează clinica cu propriile credențiale (nu este subîmputernicit al platformei; clinica rămâne în propria sa relație operator-persoană împuternicită de operator cu acel terț).

Această listă acoperă exclusiv subîmputerniciții. Serviciile Cat B (de exemplu, Google Calendar al clinicii, furnizorul propriu de SMS al clinicii) apar în comunicarea proprie a clinicii privind subîmputerniciții, nu în a noastră.

Mecanism de notificare

Modificările substanțiale ale acestei liste (adăugarea unui subîmputernicit, înlocuirea, modificarea categoriei de date partajate, modificarea mecanismului de transfer) declanșează:

1. Notificare cu 30 de zile înainte către fiecare operator, prin sistemul de notificări în aplicație + e-mail către contactul administrativ înregistrat.
2. Dreptul operatorului de a obiecta. Operatorul care obiectează asupra unui nou subîmputernicit poate înceta APD-ul relevant în conformitate cu termenii săi de încetare (de regulă 30 de zile de la obiecție).
3. O intrare în jurnalul de modificări de mai jos, cu data efectivă.

Modificările fără notificare prealabilă sunt rezervate răspunsului la incidente de securitate (de exemplu, schimbarea de urgență a CDN-ului) și sunt notificate ulterior, în termen de 7 zile.

Subîmputerniciții la lansare

#	Furnizor	Rol	Locație găzduire / date	Mecanism de transfer	APD
1	Clerk	Furnizor de identitate (înregistrare, autentificare, sesiune)	Statele Unite	CCS (Modulul 2) + TIA — a se vedea TIA	clerk.com/legal/dpa
2	Bunny.net	CDN video, stocare video (clipuri de exerciții ale planurilor de tratament), streaming HLS, API Stream	UE (Slovenia + edge-uri UE)	Exclusiv UE; fără transfer conform Art. 44	bunny.net/dpa
3	Amazon Web Services (AWS)	Găzduire (RDS Aurora, ECS Fargate, S3, ALB), livrare e-mail (SES)	UE (eu-central-1 / Frankfurt) primar; replicare între regiuni către o a doua regiune UE pentru DR	Exclusiv UE la rulare; CCS + TIA pentru suprafața de acces a societății-mamă — a se vedea TIA	aws.amazon.com/service-terms + BAA AWS prin Artifact
4	Cloudflare	CDN, WAF, protecție DDoS, rutare cu nume de host personalizate (Cloudflare for SaaS)	Edge global (PoP-uri în UE + la nivel mondial) — terminare TLS, cache pentru active publice, proxying pe căile de cerere	CCS (Modulul 2) + TIA — a se vedea TIA	cloudflare.com/cloudflare-customer-dpa
5	Sentry	Urmărirea erorilor aplicației	Regiunea UE (Frankfurt)	Exclusiv UE; fără transfer conform Art. 44	sentry.io/legal/dpa
6	Daily, Co.	Consultații video în timp real (stream WebRTC, gestionarea camerelor și a tokenurilor)	Servere de media fixate în UE (geo = eu-central-1); planul de control și operațiunile societății în Statele Unite	CCS (modulul 3), încorporate prin referință — a se vedea TIA T4	daily.co/legal/data-processing-addendum — în vigoare prin Termenii și Condițiile furnizorului

Notele pentru fiecare intrare se găsesc în §„Detaliu per furnizor".

Subîmputerniciți care NU sunt în sfera lansării

Aceștia sunt menționați în alte locuri din documentația platformei, însă sunt în afara sferei lansării de la 10.06.2026:

• Anthropic / OpenAI — Capabilitățile AI sunt schițate în fundație (1C.8), dar nicio funcționalitate AI nu este livrată la lansare. Vor fi adăugați când o funcționalitate AI este activată.
• Stripe / Netopia / Euplatesc / Twilio — furnizori de plăți și SMS, condiționați de funcționalități amânate (motorul de facturare F12; SMS neimplementat).
• FGO — facturare electronică românească (TVA + e-Factura prin ANAF). Nu este angajat: capacitatea de facturare este doar o interfață, implementarea ei se livrează odată cu motorul de facturare F12, aflat în afara sferei, iar astăzi nicio dată nu ajunge la FGO. Revine în tabelul de mai sus în același PR care livrează implementarea.
• Serviciu antispam / raportare DMARC — În afara sferei lansării; gestionarea respingerilor / reclamațiilor prin SES este înlocuitorul pentru lansare.

Detaliu per furnizor

1. Clerk

• Utilizare: înregistrare, autentificare (parolă + OAuth), gestionarea sesiunii, emitere JWT. Operează și webhook-ul de intrare (Cat D) care oglindește evenimentele Clerk de utilizator în tabelele noastre humans și patients.
• Categoriile de date transferate: e-mail, nume, telefon (E.164), data nașterii (când este colectată la înregistrare), metadate de autentificare (ultima autentificare, IP, user-agent, expirarea sesiunii), token-uri ale furnizorilor OAuth (când pacientul se autentifică cu Google/Apple).
• Date care NU sunt transferate: date privind starea de sănătate a pacientului (VAS, RPE, aderență), CNP, evidențe clinice, jurnalele de exerciții. Clerk nu primește niciodată date din categoria specială Art. 9.
• Locație de găzduire: Statele Unite. Clerk este o companie din SUA fără o instanță UE la momentul redactării.
• Mecanism de transfer: Clauzele contractuale standard 2021 ale Comisiei Europene, Modulul 2 (operator-către-persoană împuternicită de operator). TIA conform metodologiei EDPB în șase pași în TIA.
• Retenție: Clerk reține evidența autentificării cât timp contul este activ + 30 de zile după ștergerea contului (conform termenilor lor). Ștergerea contului în sistemul nostru declanșează ștergerea în cascadă în Clerk prin API-ul de gestionare.
• Sub-sub-împuterniciți: AWS (regiuni SUA), Google Cloud (regiuni SUA), Twilio (SMS OTP dacă este activat — nu este activat la lansare). Sunt comunicați de Clerk.
• De ce acest furnizor: suprafață de identitate consolidată în trei aplicații + complexitate OAuth + gestionare de sesiune la nivel de producție. Alternative evaluate (Auth0, Supabase Auth, soluție in-house) — a se vedea decisions.md. Poziția pe care consilierul român o poate confirma este că, costul în materie de rezidență a datelor UE generat de consolidarea identității într-un singur furnizor american este compensat de costul de securitate al fragmentării autentificării în trei aplicații.

2. Bunny.net

• Utilizare: Bunny Stream pentru livrarea HLS a clipurilor de exerciții și a conținutului video din planul de tratament; Bunny Storage pentru object store-ul video subiacent; Bunny CDN pentru edge-ul de livrare.
• Categoriile de date transferate: obiecte video (în fișierele video propriu-zise nu există conținut cu date cu caracter personal — sunt clipuri de demonstrație a exercițiilor produse în prealabil, nu conținut înregistrat de pacient); jurnalele cererilor de redare (URL, timestamp, IP, user-agent), limitate la ceea ce reține Bunny în mod implicit.
• Date care NU sunt transferate: profilul pacientului, datele clinice, CNP, datele de autentificare. Player-ul video din Portal este un iframe care încarcă un token de redare semnat; identitatea pacientului nu este transmisă către Bunny în URL.
• Locație de găzduire: UE (Bunny are sediul în Slovenia; regiunea de stocare pe care o folosim este UE; edge-urile sunt globale).
• Mecanism de transfer: UE–UE; regulile de transfer din Art. 44 GDPR nu se aplică pentru regiunea de stocare. Nodurile edge din afara SEE pot servi active publice în cache, însă nicio dată cu caracter personal nu este indexată pe aceste noduri.
• Retenție: controlată de noi; setăm lifecycle-ul pe Storage. Jurnalele de redare Stream sunt reținute de Bunny conform termenilor lor (~30 zile pentru jurnalele brute).
• De ce acest furnizor: evaluat în raport cu Cloudflare Stream, Mux, Vimeo. Bunny a oferit cel mai bun preț în EUR pentru bandă per GB la scara estimată (5.000 pacienți × ~10 sesiuni × ~5 minute × 1080p). decisions.md consemnează alegerea.

3. AWS

• Utilizare:
  • RDS Aurora PostgreSQL (Multi-AZ în producție) — baza de date principală a platformei.
  • ECS Fargate — rulare pentru toate cele 6 servicii (API + 3 aplicații Next.js + telemetrie + composer).
  • S3 — bloburi de sesiune de telemetrie (F10), backup-uri pg_dump, arhive de jurnale de audit în nivel warm.
  • ALB + ACM — ingres public + terminare TLS.
  • SES — livrare e-mail tranzacțional (canalul de e-mail de ieșire al platformei; a se vedea capabilitatea email.Channel din 1A).
  • KMS — cheie de criptare la nivel de coloană pentru clasele auth_secret și pii_regulated.
  • CloudWatch — metrici, jurnale, alarme.
• Categoriile de date transferate: orice categorie de date pe care platforma o prelucrează — acesta este hostul. Identificatori ai pacienților, date privind starea de sănătate, CNP (criptat la nivel de coloană pentru clasa pii_regulated), jurnalul de audit, telemetria, conținutul de e-mail.
• Locație de găzduire: eu-central-1 (Frankfurt), o singură regiune. ⚠️ Replicarea backup-urilor într-o a doua regiune UE a fost discutată ca îmbunătățire pentru recuperarea în caz de dezastru, dar nu este configurată — nu există replicare în niciun mediu.
• Mecanism de transfer: datele la rulare rămân în UE. AWS, ca societate-mamă din SUA, are un acces teoretic prin procedură legală conform CLOUD Act; CCS (Modulul 2) + măsurile suplimentare descrise în TIA (criptare la nivel de coloană cu chei KMS controlate de platformă pentru coloanele cele mai sensibile, IAM strict, CloudTrail la nivel de organizație, BAA AWS) formează stiva de garanții. A se vedea TIA.
• Retenție: controlată de noi pentru baza de date activă (backup-uri automate 35 de zile; fereastră PITR 35 de zile; jurnal de audit 6+ ani). Arhiva pg_dump de nivel 2 NU poate fi ștearsă de noi. Ajunge într-un bucket S3 aflat sub Object Lock în modul COMPLIANCE, cu retenție de 7 ani și fără regulă de expirare — nici administratorul, nici furnizorul de cloud nu pot șterge un obiect în interiorul acelei ferestre. Este o măsură deliberată împotriva ransomware-ului și a ștergerii din interior și este motivul pentru care poziția privind ștergerea, de mai jos, este cea care este.
• Sub-sub-împuterniciți: niciunul în afara AWS pentru serviciile pe care le folosim; AWS contractează direct pentru întreaga stivă.
• BAA AWS acceptat: de confirmat în AWS Artifact pre-lansare. BAA este de inspirație HIPAA (cadru american), însă este cel mai apropiat echivalent pentru „AWS ca persoană împuternicită desemnată pentru date sensibile privind starea de sănătate" — îl acceptăm ca parte a check-list-ului de pregătire pentru lansare.

4. Cloudflare

• Utilizare:
  • DNS pentru restartix.pro și rutarea numelor de host personalizate de tenant prin Cloudflare for SaaS.
  • WAF + DDoS pe calea de ingres înainte de ALB.
  • CDN pentru active statice publice (site-ul de marketing, iconițe publice, previzualizări publice ale clipurilor de demonstrare a exercițiilor).
  • Cache — exclusiv active cache-abile public. Căile de cerere autentificate sunt trecute prin proxy cu Cache-Control: private.
• Categoriile de date transferate: metadate ale cererilor (IP, user-agent, URL, header-e, metadate TLS) trec prin Cloudflare pentru fiecare cerere. Cloudflare termină TLS și restabilește TLS către origine; aceasta este o proprietate structurală a utilizării unui CDN la edge.
• Date care NU sunt transferate pentru cache: corpul cererilor, corpul răspunsurilor și header-ele cererilor autentificate nu sunt salvate în cache; trec prin proxy. Cookie-urile marcate Secure; HttpOnly (inclusiv cookie-ul de sesiune Clerk) nu sunt reținute de Cloudflare după servirea cererii.
• Locație de găzduire: Cloudflare operează o rețea edge globală. Cererile din România se termină de regulă la PoP-uri UE (București, Sofia, Frankfurt, Viena). Deciziile de rutare sunt operaționale, nu contractuale.
• Mecanism de transfer: CCS (Modulul 2) pentru societatea-mamă din SUA a Cloudflare + TIA care abordează rutarea la edge și scenariile de procedură legală americană. A se vedea TIA. Cloudflare Data Localization Suite (rutare exclusiv UE) este luată în considerare — prețul și aplicabilitatea sunt în evaluare; dacă va fi adoptată, secțiunea din TIA se actualizează.
• Retenție: TTL-urile cache la edge sunt guvernate de header-ele Cache-Control pe care le setăm. Jurnalele de acces ale Cloudflare sunt reținute conform termenilor lor (de regulă ≤ 30 zile la nivelul nostru de plan).
• Postura WAF: întrebarea deschisă „Cloudflare WAF-for-SaaS add-on vs. AWS WAF pe ALB" se află în planul de lansare iunie, decizii deschise. Oricare ar fi alegerea, Cloudflare rămâne în sfera de utilizare ca DNS + CDN; alegerea WAF afectează doar punctul de inspecție WAF.

5. Sentry

• Utilizare: urmărirea erorilor aplicației. ⚠️ Implementată exclusiv în Portalul pacientului. API-ul, aplicațiile Clinică și Consolă, serviciile de telemetrie și media nu sunt conectate la ea.
• Categoriile de date transferate: stack trace-uri, mesaje de eroare, URL-uri ale cererilor și firimituri de navigare (curățate — a se vedea mai jos), SHA-ul versiunii, mediul. Nu se transmite niciun identificator de utilizator, nici măcar pseudonim.
• Redactarea datelor cu caracter personal: SDK-ul rulează cu sendDefaultPii: false, ceea ce îl împiedică din start să atașeze adrese IP, cookie-uri, header-e, corpuri de cerere și identificatori de utilizator. Un hook beforeSend închide apoi scurgerea reziduală pe care acea setare nu o acoperă — secrete purtate în URL-uri (tichete de autentificare, tokenul de preluare din sistemul preexistent, parametri de handshake), care altfel ar apărea în URL-ul cererii și în firimiturile de navigare și de fetch.
• Locație de găzduire: Regiunea UE a Sentry (Frankfurt). Selectată la crearea organizației și imutabilă.
• Mecanism de transfer: rezidență exclusiv UE. Societatea-mamă din SUA a Sentry are izolare documentată între regiuni; ne bazăm pe acea clauză contractuală.
• Retenție: retenția evenimentelor conform nivelului nostru de plan (de regulă 90 de zile pentru detaliile evenimentelor, mai mult pentru agregările pe issue-uri). Configurabilă până la 30 de zile pentru sensibilitate mai ridicată, dacă consilierul recomandă acest lucru.

6. Daily, Co.

• Utilizare: consultații video în timp real între un pacient și un clinician (F5.5). Platforma creează o cameră privată per consultație, emite câte un token de scurtă durată pentru fiecare participant și primește notificări privind ciclul de viață al camerei. Suprafața specifică furnizorului este izolată într-un singur adaptor, iar schema este agnostică față de furnizor, deci subîmputernicitul poate fi înlocuit fără o modificare a modelului de date.
• Categoriile de date transferate: stream-ul audio și video al unei consultații de reabilitare — date din categoria specială prevăzută la Art. 9. Numele afișat în cadrul consultației; o referință opacă de participant, derivată de platformă, care revine la fiecare notificare și face posibilă atribuirea fără a spune furnizorului cine este participantul; referința camerei, numărul maxim de participanți, expirarea tokenului; metadate de conexiune WebRTC (IP, dispozitiv, calitatea rețelei).
• Categoriile de date care NU se transferă: identificatorul pacientului, adresa de e-mail, telefonul, data nașterii, CNP-ul, evidența clinică, conținutul programării, răspunsurile la formulare, datele de aderență.
• Locul de găzduire: serverele de media sunt fixate în UE. Proprietatea geo a camerei se stabilește din configurația platformei (eu-central-1, Frankfurt), iar adaptorul refuză să creeze o cameră atunci când geo nu este configurat, în loc să aplice o valoare implicită — o cameră creată fără regiune este o cameră al cărei flux media poate ajunge oriunde. Planul de control (api.daily.co) și contul se află în Statele Unite.
• Mecanismul de transfer: clauzele contractuale standard 2021, modulul 3 (persoană împuternicită către subîmputernicit) — modulul care corespunde exact poziției noastre. Acordul de prelucrare nu necesită o semnătură separată. Termenii și Condițiile furnizorului îl încorporează prin referință, iar acordul prevede că, prin încheierea contractului, exportatorul de date este considerat a fi semnat clauzele contractuale standard încorporate. Acceptarea Termenilor la crearea contului a adus, prin urmare, în vigoare deopotrivă contractul prevăzut la Art. 28 și instrumentul de transfer prevăzut la Art. 46.
• Înregistrare: camerele se creează fără înregistrare activată, iar platforma nu apelează nicio funcție de înregistrare, deci niciun flux de consultație nu este stocat la furnizor. Instrumentul de consimțământ video_recording există, dar nu este publicat, și nicio cale de cod nu activează înregistrarea.
• Retenție: nu se stochează niciun flux de consultație, nici de noi, nici de furnizor. Camerele și tokenurile expiră (eject_at_room_exp este activ, deci expirarea încheie o consultație în desfășurare, nu doar refuză intrări noi). Jurnalele de conexiune ale furnizorului se păstrează conform termenilor săi.
• Sub-subîmputerniciți: furnizorul își publică propria listă la daily.co/legal/sub-processors — AWS și Oracle pentru găzduire, Cloudflare și Twilio pentru traversarea rețelei, plus Sentry, BigQuery, Stripe și WorkOS. Două intrări de acolo trebuie citite cu atenție: Deepgram (transcriere) și OpenAI (completări de tip chat) figurează sub produsul WebRTC. Ele aparțin funcționalităților de inteligență artificială ale furnizorului, pe care nu le activăm și care nu se pot declanșa pe o cameră care nu este niciodată înregistrată și nu este niciodată direcționată către o linie de transcriere — însă un operator care parcurge acea pagină le va vedea și va întreba. Răspunsul este că integrarea noastră apelează crearea camerei, emiterea tokenului și recepția webhookurilor, și nimic altceva.
• De ce acest furnizor: evaluat față de Whereby și o instalare LiveKit găzduită de noi; schema acceptă atât daily, cât și whereby, deci alegerea este reversibilă. Fixarea geo în UE și modelul de token per participant au fost factorii decisivi.

Puncte deschise înainte de înrolarea unei clinici terțe

Contractul este în vigoare, prin urmare punctele de mai jos sunt mai restrânse decât păreau inițial — dar sunt reale:

1. Contul este partajat cu sistemul preexistent, iar acest lucru nu este abstract. Consultațiile se desfășoară prin același cont Daily ca restartix-leo. La ultima inspecție (09.08.2026), acel cont conținea 13.228 de întâlniri, aproape toate ale sistemului preexistent, cu nume reale de pacienți vizibile ca nume afișate în consultație.

   Consecința relevantă aici este că webhookurile furnizorului sunt la nivel de cont: endpointul nostru primește notificări pentru consultațiile în desfășurare ale sistemului preexistent, purtând acele nume. 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 filtrul care face această treabă a fost scris pentru a ignora „camere pe care același cont le-ar putea găzdui”, o ipoteză la momentul redactării. Este acum singurul element dintre datele pacienților altui sistem și coloana noastră payload, iar acest rol i-a revenit accidental.

   Este o problemă de segregare în sensul Art. 32 și lasă acordul de prelucrare în vigoare atașat entității juridice care a acceptat Termenii pe acel cont — de confirmat, nu de presupus, chiar dacă aceeași societate se află în spatele ambelor sisteme. Mutarea pe un cont propriu al platformei rezolvă totul, nu necesită nicio modificare de cod și nu ar trebui să aștepte prima clinică.

2. Notificarea privind subîmputerniciții este datorată fiecărui operator înainte de înrolarea unei clinici terțe cu consultații video. Astăzi, pe platformă se află doar clinica RestartiX, deci nu există nicio notificare restantă către un terț.

3. Dezactivarea înregistrării este moștenită, nu afirmată. Adaptorul declară o proprietate enable_recording, dar nu o setează niciodată, deci „dezactivat” provine din valoarea implicită a furnizorului, nu din cererea noastră. Ar trebui transmisă explicit, pentru ca măsura să ne aparțină și să fie vizibilă în cererea pe care o facem.

Neangajat încă — FGO

Neangajat. Păstrat aici ca formă a intrării, pentru a fi mutată în tabelul de mai sus atunci când motorul de facturare F12 livrează implementarea. Astăzi nu se transferă nimic.

• Utilizare: e-factură românească — calculul TVA-ului RO, transmiterea e-Factura către ANAF. Implicit pentru clinicile de pe platformă care emit facturi în jurisdicția română. (La lansare — clinica RestartiX nu facturează pacienții, deoarece programul de lansare este gratuit; FGO rămâne însă în sferă, deoarece platforma RestartiX poate emite facturi către sine sau către clinici terțe timpurii pe un nivel plătit.)
• Categoriile de date transferate: date de facturare pentru entitatea juridică — denumirea clinicii, CNP/CIF, adresa, linii de factură, totaluri, taxe. Nicio dată privind starea de sănătate a pacientului nu ajunge la FGO; liniile de factură fac referire la produsele de abonament la nivel de platformă, nu la evenimente clinice la nivel de pacient.
• Locație de găzduire: România.
• Mecanism de transfer: UE–UE; fără probleme de transfer conform Art. 44.
• Retenție: guvernată de regulile române de păstrare a evidenței fiscale (10 ani conform Codului Fiscal, Art. 78). FGO păstrează evidența cel puțin pentru această perioadă.
• Statut special: transmiterea FGO către ANAF este obligatorie prin lege, nu opțională. Temeiul juridic pentru transferul către FGO + ANAF este Art. 6 alin. (1) lit. c) GDPR (obligație legală), nu consimțământul.

Ștergerea și nivelul de backup

O listă a subîmputerniciților care promite ștergerea trebuie să spună ce înseamnă „șters” în raport cu un nivel de backup care nu poate fi modificat.

Atunci când un pacient își exercită dreptul prevăzut la Art. 17, platforma anonimizează evidența activă (Art. 17 alin. (3) lit. (c) se aplică evidențelor medicale), iar modificarea se propagă către fiecare sistem în funcțiune și către fiecare subîmputernicit de mai sus, în termenul de notificare. Ea nu ajunge însă înapoi în arhiva pg_dump de nivel 2, aflată sub Object Lock în modul COMPLIANCE timp de 7 ani și imuabilă din punct de vedere tehnic pentru acea perioadă.

Aceasta este poziția standard a CEPD privind backupurile — restaurarea unui backup este ea însăși o prelucrare, iar ștergerea se reaplică la restaurare, nu se execută în interiorul arhivei. Angajamentele care decurg de aici:

• Backupurile nu se folosesc în niciun alt scop decât recuperarea în caz de dezastru. Nu există niciun traseu de citire analitic, operațional sau de asistență către ele.
• O restaurare este un eveniment de răspuns la incident, jurnalizat, urmat de reaplicarea fiecărei ștergeri și anonimizări consemnate de la momentul realizării backupului, înainte ca sistemul restaurat să deservească trafic.
• Arhiva expiră după propriul calendar; nimic nu îl prelungește.

Confirmarea ștergerii pe care o transmitem unui operator acoperă, prin urmare, sistemele active și subîmputerniciții și enunță explicit poziția privind backupurile, în loc să sugereze că datele au dispărut de pretutindeni.

Jurnal de modificări

Data	Modificare	Notificare transmisă
06.09.2026	Daily, Co. adăugat ca subîmputernicit #6 (consultații video în timp real, F5.5), cu TIA T4 corespunzător. FGO scos din tabelul activ: capacitatea de facturare este doar o interfață, implementarea se livrează odată cu F12, aflat în afara sferei. Intrarea Sentry corectată: implementată doar în Portal, fără niciun identificator de utilizator. Retenția AWS corectată: arhiva pg_dump se află sub Object Lock (COMPLIANCE, 7 ani), iar replicarea între regiuni nu este configurată. Secțiune nouă privind ștergerea și nivelul de backup.	⚠️ Datorată. Notificare cu 30 de zile înainte către fiecare operator. Astăzi, pe platformă se află doar clinica RestartiX, deci nu există notificare restantă către un terț — însă aceasta este intrarea care trebuie transmisă înainte de înrolarea unei clinici terțe
15.05.2026	Lista inițială v1 redactată	n/a (pre-lansare)

---

Anexă: legenda categoriilor de date

Categorie	Exemple
Identificatori de cont	e-mail, nume, telefon, data nașterii, locale
Metadate de autentificare	ultima autentificare, IP, user-agent, expirarea sesiunii, token-uri OAuth
Date privind starea de sănătate (Art. 9)	VAS pentru durere, RPE, aderență (finalizarea sesiunii, abandon la exerciții), comentarii text liber ale pacientului către specialiști
Cod numeric personal (România)	CNP — atunci când este colectat; criptat la nivel de coloană (pii_regulated)
Financiar / fiscal	linii de factură, TVA, CIF
Telemetrie operațională	jurnalele cererilor, stack trace-urile erorilor, metricile aplicației
Active video	clipuri de demonstrare a exercițiilor (fără conținut înregistrat de pacient la lansare)