Pe scurt: securitatea într-o aplicație de sănătate răspunde la patru întrebări, în ordine. Cine este acesta? Identitate: un utilizator verificat (pacient, clinician, sistem) prin OpenID Connect și, pentru clinicieni, identitatea profesională națională; nivelul de verificare contează mai mult decât tăria parolei. Ce au voie să facă? Autorizare: tokenuri OAuth 2.0 (în curs de migrare la 2.1) cu scopuri în sintaxa SMART on FHIR, derivate din consimțământul pacientului pentru un scop și o durată, impuse la nivelul datelor. Ce au făcut? Responsabilitate: un jurnal de acces pe care pacientul îl poate citi și o pistă de înregistrare FHIR AuditEvent pentru organizație. Sunt datele în siguranță în repaus, în tranzit și în backup-uri? Protecție: criptare, gestionarea cheilor, segregare, restaurări testate. În jurul lor: linia de bază a ISO 27001 și 27799, NIS2 și Regula de Securitate HIPAA, precum și amenințările specifice datelor de sănătate (navigare internă, înregistrare greșită, ransomware).
Harta
Securitatea și identitatea într-o aplicație de sănătate au șapte niveluri: identitate prin OpenID Connect și ID-uri naționale sau profesionale, autorizare prin OAuth 2.0 și scopuri SMART on FHIR, consimțământ ca sursă pentru fiecare permisiune, responsabilitate prin jurnale de acces și FHIR AuditEvent, protecție prin criptare și backup-uri, o bază de securitate conform ISO 27001, ISO 27799, NIS2 și HIPAA, și partajare inițiată de pacient.
| Strat | Standard sau practică | Ce îți oferă | Pagină |
|---|---|---|---|
| Identitate | OpenID Connect; ID-uri naționale (eIDAS, NHS login, GesundheitsID); identități profesionale (eHBA, CPS, UZI) | Un subiect verificat cu un nivel de asigurare | SMART App Launch explicat |
| Autorizare | OAuth 2.0 și 2.1 (PKCE obligatoriu, fără granturi implicite sau de parolă); scopuri SMART on FHIR (patient/Observation.rs); servicii backend cu autentificare asimetrică a clientului | Tokenuri legate de un utilizator, un context de pacient și un scop | SMART App Launch explicat, SMART on FHIR backend |
| Consimțământ | FHIR Consent; granturi legate de scop și timp; revocare; break-the-glass cu justificare și alertă | Pacientul ca sursă a fiecărei autorizări | Platformă de consimțământ a pacientului, Solicitări de acces clinic |
| Responsabilitate | Jurnale de acces per înregistrare vizibile pacientului; FHIR AuditEvent; stocare sigură împotriva modificărilor; retenție | Cine a văzut ce, când, de ce | Cine mi-a vizualizat dosarul medical? |
| Protecție | TLS 1.2+, criptare în repaus cu chei gestionate, criptare la nivel de câmp pentru identificatori, medii segregate, backup-uri cu restaurare testată | Confidențialitate și disponibilitate | ISO 27001 vs ISO 27799 |
| Linie de bază | ISMS ISO 27001, controale de sănătate ISO 27799, măsuri NIS2, Regula de Securitate HIPAA, scheme naționale (HDS, DSPT, C5) | Ce așteaptă spitalele, auditorii și autoritățile de reglementare | NIS2 pentru spitale și furnizori, HIPAA vs GDPR |
| Partajare | SMART Health Links și Cards; credențiale verificabile | Partajare inițiată de pacient cu un link sau QR, revocabilă | SMART Health Links explicat |
Identitate: asigurare peste parole
Identitatea într-o aplicație de sănătate depinde de gradul de asigurare, mai degrabă decât de tăria parolei: nivelurile de asigurare a identității, cum ar fi NIST IAL, eIDAS substanțial și înalt, sau NHS login P9, descriu cât de puternic a fost verificată o persoană la înregistrare, în timp ce autentificarea multi-factor și passkeys descriu fiecare autentificare. Clinicienii sunt identificați prin identități profesionale care sunt revocate atunci când pleacă.
O aplicație pentru pacienți care afișează un dosar complet trebuie să știe că vorbește cu acel pacient. Nivelurile de asigurare a identității (IAL NIST, substanțial și înalt eIDAS, NHS login P9) descriu cât de puternic a fost verificată identitatea la înrolare; tăria autentificării (multi-factor, passkeys) descrie fiecare conectare. Spitalele și sistemele naționale necesită din ce în ce mai mult identități verificate din scheme recunoscute, mai degrabă decât înregistrări auto-declarate, iar Portofelul de Identitate Digitală al UE va deveni un mijloc acceptat. Pentru clinicieni, identitatea profesională (și revocarea acesteia atunci când cineva pleacă) este sistemul de înregistrare pentru cine poate acționa ca clinician.
Autorizare: consimțământul devine scopuri
Autorizarea într-un dosar controlat de pacient traduce consimțământul pacientului, cum ar fi permiterea unei clinici să citească rezultatele de laborator și condițiile timp de 90 de zile, în scopuri OAuth și contextul pacientului pe token, în sintaxă SMART on FHIR precum patient/Observation.rs, aplicat la nivelul datelor la fiecare solicitare și revocat atunci când pacientul își retrage consimțământul. Break-the-glass este o cale separată, auditată.
Într-un dosar controlat de pacient, consimțământul pacientului este politica: această clinică poate citi rezultatele mele de laborator și condițiile mele timp de 90 de zile. Sistemul îl traduce în scopuri OAuth și context (ce pacient, ce resurse, ce operațiuni) pe tokenul pe care îl primește sistemul clinicii, le impune la fiecare cerere la nivelul datelor și le revocă atunci când pacientul își retrage consimțământul. Sintaxa scopurilor SMART on FHIR (patient/Observation.rs, patient/Condition.rs) este limba francă pentru aceasta; scopuri granulare (după categorie sau cod) există în SMART v2 pentru un control mai fin. Break-the-glass (acces de urgență fără consimțământ) este o cale separată, auditată, cu justificare obligatorie și o alertă către pacient, niciodată un implicit. Vezi Platformă de consimțământ a pacientului.
Responsabilitate: jurnalul pe care îl citește pacientul
Responsabilitatea într-o aplicație de sănătate înseamnă că fiecare acces la un dosar, de către cine, când, ce și sub ce consimțământ, este înregistrat într-un jurnal imuabil pe care pacientul îl poate citi în aplicația sa și într-o pistă de audit organizațională în FHIR AuditEvent. ISO 27799 tratează acest lucru ca fiind obligatoriu, iar un jurnal vizibil este cel mai puternic factor de descurajare împotriva accesării neautorizate din interior.
Fiecare acces la un dosar, de către cine, când, ce, sub ce consimțământ, este scris într-un jurnal de tip append-only pe care pacientul îl poate citi în aplicația sa, și într-o pistă de audit organizațională (FHIR AuditEvent) pentru echipele de securitate. ISO 27799 tratează acest lucru ca fiind obligatoriu pentru informațiile de sănătate; principiul transparenței GDPR și drepturile pacienților din EHDS indică aceeași direcție; cel mai mare factor de descurajare în lumea reală pentru navigarea internă este un jurnal vizibil. Vezi Cine mi-a vizualizat dosarul medical?.
Protecție: linia de bază inginerească
Baza inginerească pentru protejarea datelor de sănătate este TLS peste tot, criptare la repaus cu chei gestionate și rotite, criptare sau tokenizare separată pentru identificatori direcți, medii segregate cu date sintetice în afara producției, acces cu privilegii minime cu autentificare multi-factor pentru administratori, gestionarea secretelor și vulnerabilităților, backup-uri criptate testate prin restaurare împotriva ransomware-ului și răspuns la incidente în termenele GDPR și NIS2.
TLS peste tot, cu cifruri moderne și fixarea certificatelor în aplicații acolo unde este cazul; criptare în repaus cu chei într-un serviciu de gestionare a cheilor și rotație; criptare sau tokenizare separată pentru identificatori direcți; segregarea producției de dezvoltare, cu date sintetice în afara producției; acces cu privilegii minime pentru personal, fără conturi partajate, multi-factor pentru tot accesul administrativ; gestionarea secretelor; gestionarea dependențelor și vulnerabilităților cu divulgare; backup-uri criptate, testate prin restaurare și protejate împotriva ransomware-ului care a lovit spitalele și laboratoarele în mod repetat (WannaCry în 2017, spitalul din Düsseldorf în 2020, Change Healthcare și Synnovis în 2024). Răspuns la incidente cu ceasurile de 72 de ore GDPR și 24 de ore NIS2 într-un singur plan de acțiune.
Amenințări specifice datelor de sănătate
Amenințările specifice datelor de sănătate includ accesarea neautorizată a dosarelor cunoscuților, greșeli de clasificare între pacienți, partajări prea largi acordate pentru prea mult timp, SDK-uri de publicitate în aplicațiile care gestionează date de sănătate, injecții de documente în funcționalități AI și păstrarea pe termen lung de zeci de ani, perioadă în care cheile, formatele și regulile de acces trebuie să supraviețuiască personalului și furnizorilor.
- Navigare internă a dosarelor cunoștințelor sau a persoanelor publice: acces bazat pe relații și jurnale vizibile.
- Înregistrare greșită între pacienți: reconcilierea identității și proveniența, nu doar controlul accesului.
- Partajare prea largă: o clinică căreia i s-a acordat "totul" timp de un an; scopuri și durate cu valori implicite rezonabile.
- Aplicații cu SDK-uri de publicitate: fără trackere terțe în orice care gestionează date de sănătate.
- Injectare prin documente în funcționalități AI: conținutul este date, niciodată instrucțiuni (RAG pe dosare medicale).
- Retenție lungă: dosarele trăiesc decenii; cheile, formatele și regulile de acces trebuie să supraviețuiască personalului și furnizorilor.
În Anpheros
Anpheros aplică harta de securitate pentru sine cu OAuth 2.0 cu PKCE pentru aplicații și autentificare asimetrică a clientului pentru backend-uri, consimțământ per scop și durată ca sursă pentru accesul fiecărei clinici, un jurnal de acces per dosar în aplicația persoanei, criptare la repaus și în tranzit, găzduire în UE, fără SDK-uri de publicitate și un ISMS conform ISO 27001 și 27799.
Anpheros aplică această hartă pentru sine: OAuth 2.0 cu PKCE pentru aplicații și autentificare asimetrică a clienților pentru backend-uri; consimțământ per scop și durată ca sursă a accesului fiecărei clinici, cu revocare și fără break-the-glass silențios; un jurnal de acces per înregistrare în aplicația persoanei; criptare în repaus și în tranzit, găzduire în UE, fără SDK-uri de publicitate; un ISMS conform ISO 27001 cu controalele de sănătate ISO 27799. Site-ul pentru dezvoltatori documentează autentificarea, consimțământul și securitatea.
Pagini conexe
- SMART App Launch explicat
- Platformă de consimțământ a pacientului
- Cine mi-a vizualizat dosarul medical?
- SMART Health Links explicat
- ISO 27001 vs ISO 27799
- NIS2 pentru spitale și furnizori de tehnologie medicală
- Securitatea platformei (site pentru dezvoltatori)
- Autentificare (site pentru dezvoltatori)
Surse
- HL7 SMART App Launch
- IETF: OAuth 2.1 (draft)
- OpenID Connect Core 1.0
- HL7 FHIR R4: AuditEvent
- HL7 FHIR R4: Consent
- NIST SP 800-63-4: Digital Identity Guidelines
- ISO 27799:2016
- ENISA: Ghiduri de achiziții pentru securitatea cibernetică în spitale
Întrebări frecvente
Este OAuth 2.1 diferit de 2.0?
OAuth 2.1 consolidează 2.0 cu cele mai bune practici de securitate ale sale: PKCE este obligatoriu pentru toți clienții, granturile implicite și de parolă sunt eliminate, URI-urile de redirecționare trebuie să se potrivească exact, iar tokenurile de reîmprospătare pentru clienții publici trebuie să fie legate sau rotite. SMART on FHIR v2 necesită deja majoritatea acestora.
Ce este break-the-glass?
Acces de urgență la un dosar fără consimțământul prealabil al pacientului, de către un clinician care declară o justificare. Acesta trebuie să fie rar, înregistrat, revizuit și raportat pacientului; nu este niciodată calea implicită de acces.
De ce ar trebui pacienții să vadă jurnalul de acces?
Deoarece este cel mai puternic factor de descurajare a accesului necorespunzător și cea mai clară expresie a controlului: persoana vede ce clinică a citit și când, și poate revoca. ISO 27799 și EHDS indică aceeași direcție.
Am nevoie de un sistem de audit separat?
Aveți nevoie de o pistă de audit de tip append-only (FHIR AuditEvent sau echivalent) pe care aplicația nu o poate modifica, păstrată conform politicii, și o vizualizare orientată către pacient derivată din aceasta. Indiferent dacă este un sistem separat sau un depozit protejat în cadrul platformei, este o alegere de implementare.
Încearcă gratuit în sandbox
Primul apel FHIR în 5 minute. Un API HL7 FHIR R4 cu consimțământul pacientului integrat: încearcă-l în sandbox, apoi conectează-ți propria aplicație sau sistemul clinicii.
Gratuit · 30 de pacienți sintetici · fără card
Anpheros construiește un dosar medical pe care pacientul îl controlează și îl poate da oricărei clinici, pe o platformă HL7 FHIR R4, cu sediul în UE. Ghidurile te ajută să-ți înțelegi și să-ți organizezi sănătatea; nu înlocuiesc medicul.
Despre Anpheros →