# Sicurezza, privacy e residenza dei dati

> Come vengono protetti i dati dei pazienti: residenza dei dati nell'UE, isolamento dei progetti, ID pairwise, credenziali, consenso, provenienza, un audit visibile al paziente e i limiti della beta privata.

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

I dati medici sono i dati più sensibili che un'applicazione possa detenere. Questa pagina elenca come Anpheros Platform li protegge oggi — solo ciò che è implementato — e cosa è ancora limitato durante la beta privata.

## Residenza dei dati

- Tutti i dati della piattaforma sono archiviati ed elaborati nell'Unione Europea: il servizio e i suoi database in Google Cloud `europe-west4` (Paesi Bassi), la coda di consegna dei webhook in `europe-west3` (Francoforte) e l'esportazione append-only del log di accesso nella località EU di BigQuery.
- **Regione dati USA:** disponibile su richiesta per i clienti di produzione nell'ambito di un accordo di business associate HIPAA (vedi sotto); i dati dei pazienti USA non lasciano quindi mai la regione USA.
- I documenti sono archiviati in un bucket di storage EU crittografato con una chiave di crittografia gestita dal cliente (CMEK). Gli originali sono immutabili dopo la finalizzazione; il loro checksum SHA-256 e la loro dimensione vengono registrati.

## Isolamento tra applicazioni

- Ogni API key appartiene a un **progetto**. Un progetto vede solo i pazienti che ha creato, inclusa la propria copia di pazienti sintetici nella sandbox, che nessun altro progetto può vedere.
- **Identificatori pairwise:** ogni progetto riceve il proprio ID per la stessa persona; gli ID interni non lasciano mai la piattaforma, quindi gli ID non possono essere correlati tra applicazioni.
- Un record a cui non è possibile accedere risponde `404`, mai `403`, quindi l'esistenza di un paziente non può essere sondata.
- **Sandbox e produzione sono database separati.** Una chiave sandbox (`sk_test_`) fisicamente non può accedere a pazienti reali.
- Con il consenso del paziente, un'organizzazione legge l'intero record, inclusi i dati scritti da altre organizzazioni, ma può modificare o eliminare solo ciò che ha scritto autonomamente.

## Credenziali

- Le chiavi API vengono mostrate una sola volta e memorizzate solo come hash SHA-256. Le chiavi hanno `read` / `write` scope e non attraversano mai il loro ambiente.
- OAuth 2.1 con PKCE obbligatorio (S256); il `redirect_uri` deve essere registrato esattamente. I token di accesso durano 30 minuti, i token di aggiornamento 30 giorni e ruotano ad ogni utilizzo.
- **Rilevamento riutilizzo refresh token:** la presentazione di un refresh token già utilizzato revoca l'intera catena di token.
- Le risposte dei token trasportano `Cache-Control: no-store`. Gli `id_token` di OpenID Connect sono firmati con RS256; le chiavi pubbliche sono pubblicate su `/oauth/jwks`.

## Consenso, provenienza e audit

- Un paziente concede a un'applicazione l'accesso su una pagina di consenso ospitata, scegliendo il record e la durata (30, 90, 180 o 365 giorni). Gli scope sono per tipo di risorsa e azione, opzionalmente filtrati per categoria. Ogni concessione viene rispecchiata come una risorsa FHIR `Consent`.
- La revoca ha effetto alla richiesta successiva; l'applicazione non può più essere aggiornata.
- **Ogni scrittura** produce una risorsa `Provenance`: chi l'ha scritta (paziente, professionista sanitario, dispositivo, importazione o IA), per quale organizzazione, da quale sistema sorgente.
- **Ogni lettura viene registrata e visibile al paziente**, incluse le letture effettuate con la chiave API di un progetto, e incluso il contesto costruito per i modelli di IA.

## Sicurezza dei trasporti e web

- Solo HTTPS, con HTTP Strict Transport Security. Le risposte dell'API includono una Content-Security-Policy restrittiva, `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY` e una referrer policy rigorosa.
- Le consegne dei webhook sono firmate con HMAC-SHA256 sul timestamp e sul corpo; i ricevitori devono rifiutare firme più vecchie di 5 minuti. Gli eventi includono ID e versioni, mai contenuti clinici.
- Limiti di frequenza: 600 richieste al minuto per credenziale e per IP; corpi JSON fino a 2 MiB; documenti fino a 25 MiB.

## Motori di ricerca e crawler AI

Le pagine pubbliche (anpheros.com, la presentazione della piattaforma e questa documentazione) sono aperte ai motori di ricerca e ai crawler AI. L'API, la dashboard, le pagine OAuth e di consenso e l'app paziente (`app.anpheros.com`) sono escluse con le regole `noindex` e `robots.txt`; nessuna di esse restituisce dati del paziente senza autenticazione.

## HIPAA (Cliniche USA)

Per una clinica negli Stati Uniti, Anpheros è un **Business Associate**. Quanto è in atto, mappato alla HIPAA Security Rule:

| Safeguard | Come lo fa Anpheros |
|---|---|
| Responsabilità assegnata, analisi dei rischi, politiche scritte (§164.308) | Un Security Officer nominato; un'analisi dei rischi annuale; dieci politiche scritte (accesso, crittografia, logging, risposta agli incidenti, notifica delle violazioni, conservazione e backup, formazione, dispositivi, accesso di emergenza, fornitori), conservate per sei anni |
| Identificazione univoca dell'utente, controllo degli accessi (§164.312(a)) | Ogni chiave, token e persona ha la propria identità; i progetti vedono solo i propri pazienti; gli ambiti di consenso applicati su ogni lettura; MFA o SSO richiesti per le organizzazioni con un progetto di produzione; disconnessione automatica sulla dashboard |
| Controlli di audit (§164.312(b)) | Ogni lettura e scrittura registrata, concatenata tramite hash, esportata in modo append-only; visibile al paziente |
| Integrità (§164.312(c)) | Risorse versionate, provenienza su ogni scrittura, documenti immutabili con SHA-256 |
| Sicurezza della trasmissione (§164.312(e)) | TLS 1.2+, HSTS, webhook firmati, consegne solo HTTPS |
| Crittografia a riposo | Database e backup crittografati; documenti sotto una chiave gestita dal cliente |
| Piano di emergenza (§164.308(a)(7)) | Backup giornalieri, ripristino point-in-time, esercitazione di ripristino ogni 90 giorni con tempi registrati |
| Notifica delle violazioni (§164.410) | La Covered Entity viene notificata entro 5 giorni lavorativi dal nostro BAA (60 giorni per legge) |
| Catena di business associate (§164.308(b)) | Google Cloud sotto il suo BAA; l'elenco dei sub-processori è nell'allegato del BAA |

Un **Business Associate Agreement** e una **regione dati USA** sono disponibili su richiesta per i clienti di produzione (scrivere a platform@anpheros.com); la produzione per i dati dei pazienti USA apre dopo la firma del BAA. La sandbox contiene solo pazienti sintetici, quindi gli sviluppatori negli Stati Uniti possono iniziare a lavorare oggi senza un BAA. Anpheros non è certificato SOC 2 o HITRUST; un audit SOC 2 Type II è previsto quando un cliente ospedaliero lo richiederà.

## Limiti attuali (beta privata)

- Hosting a singola zona senza failover automatico; nessun SLA contrattuale ancora disponibile.
- Le chiavi di produzione vengono rilasciate a organizzazioni verificate con un accordo di elaborazione dati firmato; i partner beta iniziano con dati sintetici.
- Il lancio SMART EHR e il parametro OpenID `nonce` non sono ancora supportati.

## Correlati

- [GDPR e dati sanitari per sviluppatori](https://developers.anpheros.com/it/guides/gdpr-health-data-developers)
- [Provenienza dei dati medici spiegata](https://developers.anpheros.com/it/guides/medical-data-provenance): chi ha scritto cosa e come registrarlo
- [Modello di consenso e accesso](https://developers.anpheros.com/it/guides/consent)
- [Autenticazione e OAuth](https://developers.anpheros.com/it/guides/authentication)
- [Limiti e rate limits](https://developers.anpheros.com/it/guides/limits)
- [Affidabilità, stato e incidenti](https://developers.anpheros.com/it/guides/reliability): monitoraggio, backup, comunicazione incidenti
- [Architettura](https://developers.anpheros.com/it/guides/architecture)
- [Lo Spazio Europeo dei Dati Sanitari (EHDS) per sviluppatori](https://developers.anpheros.com/it/guides/ehds-for-developers)