Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Sicurezza, privacy e residenza dei dati

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

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:

Un Business Associate Agreement e una regione dati USA sono disponibili su richiesta per i clienti di produzione (scrivere a [email protected]); 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
• Provenienza dei dati medici spiegata: chi ha scritto cosa e come registrarlo
• Modello di consenso e accesso
• Autenticazione e OAuth
• Limiti e rate limits
• Affidabilità, stato e incidenti: monitoraggio, backup, comunicazione incidenti
• Architettura
• Lo Spazio Europeo dei Dati Sanitari (EHDS) per sviluppatori

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card