# Securitate, confidențialitate și rezidența datelor

> Cum sunt protejate datele pacienților: rezidența datelor în UE, izolarea proiectelor, ID-uri pairwise, credențiale, consimțământ, proveniență, un audit vizibil pentru pacient și limitele beta-ului privat.

Source: https://developers.anpheros.com/ro/guides/security

Datele medicale sunt cele mai sensibile date pe care le poate deține o aplicație. Această pagină enumeră modul în care Anpheros Platform le protejează astăzi — doar ceea ce este implementat — și ce este încă limitat în timpul beta-ului privat.

## Rezidența datelor

- Toate datele platformei sunt stocate și procesate în Uniunea Europeană: serviciul și bazele sale de date în Google Cloud `europe-west4` (Olanda), coada de livrare a webhook-urilor în `europe-west3` (Frankfurt) și exportul imuabil al jurnalului de acces în locația UE BigQuery.
- **Regiune de date din SUA:** disponibilă la cerere pentru clienții de producție sub un acord de asociat de afaceri HIPAA (vezi mai jos); datele pacienților din SUA nu părăsesc atunci regiunea SUA.
- Documentele sunt stocate într-un bucket de stocare din UE criptat cu o cheie de criptare gestionată de client (CMEK). Originalele sunt imuabile după finalizare; suma de control SHA-256 și dimensiunea lor sunt înregistrate.

## Izolarea între aplicații

- Fiecare cheie API aparține unui **proiect**. Un proiect vede doar pacienții pe care i-a creat — în sandbox, inclusiv propria copie de pacienți sintetici, pe care niciun alt proiect nu o poate vedea.
- **Identificatori pereche:** fiecare proiect primește propriul ID pentru aceeași persoană; ID-urile interne nu părăsesc niciodată platforma, deci ID-urile nu pot fi corelate între aplicații.
- Un înregistrare la care nu puteți ajunge răspunde `404`, niciodată `403`, deci existența unui pacient nu poate fi investigată.
- **Sandbox și producție sunt baze de date separate.** O cheie de sandbox (`sk_test_`) fizic nu poate accesa pacienți reali.
- Cu consimțământul pacientului, o organizație citește întregul dosar, inclusiv ceea ce au scris alte organizații, dar poate modifica sau șterge doar ceea ce a scris ea însăși.

## Credențiale

- Cheile API sunt afișate o singură dată și stocate doar ca hash SHA-256. Cheile au `read` / `write` scope-uri și nu părăsesc niciodată mediul lor.
- OAuth 2.1 cu PKCE obligatoriu (S256); `redirect_uri` trebuie înregistrat exact. Token-urile de acces durează 30 de minute, token-urile de reîmprospătare 30 de zile și se rotesc la fiecare utilizare.
- **Detectarea reutilizării token-ului de reîmprospătare:** prezentarea unui token de reîmprospătare care a fost deja utilizat revocă întregul lanț de token-uri.
- Răspunsurile token-urilor transportă `Cache-Control: no-store`. Token-urile OpenID Connect `id_token` sunt semnate cu RS256; cheile publice sunt publicate la `/oauth/jwks`.

## Consimțământ, proveniență și audit

- Un pacient acordă unei aplicații acces pe o pagină de consimțământ găzduită, alegând înregistrarea și durata (30, 90, 180 sau 365 de zile). Scopurile sunt pe tip de resursă și acțiune, opțional filtrate după categorie. Fiecare acord este reflectat ca o resursă FHIR `Consent`.
- Revocarea intră în vigoare la următoarea cerere; aplicația nu se mai poate reînnoi.
- **Fiecare scriere** produce o resursă `Provenance`: cine a scris-o (pacient, practician, dispozitiv, import sau AI), pentru ce organizație, din ce sistem sursă.
- **Fiecare citire este înregistrată și vizibilă pentru pacient**, inclusiv citirile efectuate cu cheia API proprie a unui proiect și inclusiv contextul construit pentru modele AI.

## Securitate de transport și web

- Doar HTTPS, cu HTTP Strict Transport Security. Răspunsurile API includ o politică restrictivă Content-Security-Policy, `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY` și o politică strictă de referent.
- Livrările Webhook sunt semnate cu HMAC-SHA256 peste timestamp și corp; receptorii ar trebui să respingă semnăturile mai vechi de 5 minute. Evenimentele includ ID-uri și versiuni, niciodată conținut clinic.
- Limite de rată: 600 de cereri pe minut per acreditare și per IP; corpuri JSON de până la 2 MiB; documente de până la 25 MiB.

## Motoare de căutare și roboți AI

Paginile publice (anpheros.com, prezentarea platformei și această documentație) sunt deschise motoarelor de căutare și roboților AI. API-ul, dashboard-ul, paginile OAuth și de consimțământ și aplicația pentru pacienți (`app.anpheros.com`) sunt excluse cu regulile `noindex` și `robots.txt`; niciuna dintre acestea nu returnează date ale pacienților fără autentificare.

## HIPAA (clinici din SUA)

Pentru o clinică din Statele Unite, Anpheros este un **Asociat de Afaceri** (Business Associate). Ce este implementat, corespunzător Regulii de Securitate HIPAA:

| Măsură de protecție | Cum gestionează Anpheros |
|---|---|
| Responsabilitate alocată, analiză de risc, politici scrise (§164.308) | Un Ofițer de Securitate numit; o analiză anuală de risc; zece politici scrise (acces, criptare, înregistrare, răspuns la incidente, notificare breșe, retenție și backup, instruire, dispozitive, acces de urgență, furnizori), păstrate timp de șase ani |
| Identificare unică a utilizatorului, control acces (§164.312(a)) | Fiecare cheie, token și persoană are propria identitate; proiectele văd doar proprii pacienți; scopuri de consimțământ aplicate la fiecare citire; MFA sau SSO necesar pentru organizațiile cu un proiect de producție; deconectare automată pe dashboard |
| Controale de audit (§164.312(b)) | Fiecare citire și scriere înregistrată, hash-chain, exportată append-only; vizibilă pentru pacient |
| Integritate (§164.312(c)) | Resurse versionate, proveniență la fiecare scriere, documente imuabile cu SHA-256 |
| Securitatea transmiterii (§164.312(e)) | TLS 1.2+, HSTS, webhooks semnate, livrări exclusiv HTTPS |
| Criptare la repaus | Baza de date și backup-urile criptate; documente sub o cheie gestionată de client |
| Plan de contingență (§164.308(a)(7)) | Backup-uri zilnice, recuperare point-in-time, exercițiu de restaurare la fiecare 90 de zile cu timpi înregistrați |
| Notificare breșă (§164.410) | Entitatea Acoperită (Covered Entity) este notificată în termen de 5 zile lucrătoare de către BAA-ul nostru (60 de zile conform legii) |
| Lanț de asociați de afaceri (§164.308(b)) | Google Cloud sub BAA-ul său; lista sub-procesatorilor se află în anexa BAA |

Un **Acord de Asociat de Afaceri** (Business Associate Agreement) și o **regiune de date din SUA** sunt disponibile la cerere pentru clienții de producție (scrieți la platform@anpheros.com); producția pentru datele pacienților din SUA se deschide după semnarea BAA. Sandbox-ul conține doar pacienți sintetici, astfel încât dezvoltatorii din SUA pot construi astăzi fără un BAA. Anpheros nu este certificat SOC 2 sau HITRUST; un audit SOC 2 Tip II este planificat atunci când un client spitalicesc îl va solicita.

## Limite curente (beta privat)

- Găzduire într-o singură zonă, fără failover automat; nu există încă un SLA contractual.
- Cheile de producție sunt emise organizațiilor verificate cu un acord de procesare a datelor semnat; partenerii beta încep cu date sintetice.
- Lansarea SMART EHR și parametrul OpenID `nonce` nu sunt încă suportate.

## Conexe

- [GDPR și datele medicale pentru dezvoltatori](https://developers.anpheros.com/ro/guides/gdpr-health-data-developers)
- [Proveniența datelor medicale explicată](https://developers.anpheros.com/ro/guides/medical-data-provenance): cine a scris ce și cum să o înregistrați
- [Modelul de consimțământ și acces](https://developers.anpheros.com/ro/guides/consent)
- [Autentificare și OAuth](https://developers.anpheros.com/ro/guides/authentication)
- [Limite și limite de rată](https://developers.anpheros.com/ro/guides/limits)
- [Fiabilitate, stare și incidente](https://developers.anpheros.com/ro/guides/reliability): monitorizare, backup-uri, comunicare despre incidente
- [Arhitectură](https://developers.anpheros.com/ro/guides/architecture)
- [Spațiul European pentru Datele din Sănătate (EHDS) pentru dezvoltatori](https://developers.anpheros.com/ro/guides/ehds-for-developers)