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

Securitate, confidențialitate și rezidența datelor

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

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:

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 [email protected]); 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
• Proveniența datelor medicale explicată: cine a scris ce și cum să o înregistrați
• Modelul de consimțământ și acces
• Autentificare și OAuth
• Limite și limite de rată
• Fiabilitate, stare și incidente: monitorizare, backup-uri, comunicare despre incidente
• Arhitectură
• Spațiul European pentru Datele din Sănătate (EHDS) pentru dezvoltatori

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