Krátka odpoveď: bezpečnosť v zdravotníckej aplikácii odpovedá na štyri otázky, v tomto poradí. Kto je to? Identita: overený používateľ (pacient, lekár, systém) prostredníctvom OpenID Connect a pre lekárov národná profesijná identita; úroveň overenia je dôležitejšia ako sila hesla. Čo smie robiť? Autorizácia: OAuth 2.0 (prechádza na 2.1) tokeny s rozsahmi (scopes) v syntaxi SMART on FHIR, odvodené z súhlasu pacienta na daný účel a časové obdobie, vynucované na úrovni dát. Čo urobil? Zodpovednosť: log prístupov, ktorý si pacient môže prečítať, a FHIR AuditEvent stopa pre organizáciu. Je dátový obsah v bezpečí pri uložení, pri prenose a v zálohách? Ochrana: šifrovanie, správa kľúčov, segregácia, testované obnovy. Okolo nich: základná úroveň ISO 27001 a 27799, NIS2 a Bezpečnostné pravidlo HIPAA, a špecifické hrozby zdravotných dát (prezeranie internými zamestnancami, nesprávne zaradenie, ransomware).
Mapa
Bezpečnosť a identita v zdravotníckej aplikácii tvoria sedem vrstiev: identita cez OpenID Connect a národné alebo profesijné ID, autorizácia cez OAuth 2.0 a rozsahy SMART on FHIR, súhlas ako zdroj každého povolenia, zodpovednosť cez prístupové logy a FHIR AuditEvent, ochrana cez šifrovanie a zálohy, základná úroveň ISO 27001, ISO 27799, NIS2 a HIPAA, a zdieľanie iniciované pacientom.
| Vrstva | Štandard alebo prax | Čo vám to poskytuje | Strana |
|---|---|---|---|
| Identita | OpenID Connect; národné ID (eIDAS, NHS login, GesundheitsID); profesijné identity (eHBA, CPS, UZI) | Overený subjekt s úrovňou záruky | Vysvetlenie SMART App Launch |
| Autorizácia | OAuth 2.0 a 2.1 (PKCE je povinné, žiadne implicitné alebo heslové granty); rozsahy SMART on FHIR (patient/Observation.rs); backendové služby s asymetrickou autentizáciou klienta | Tokeny viazané na používateľa, kontext pacienta a rozsah | Vysvetlenie SMART App Launch, SMART on FHIR backend |
| Súhlas | FHIR Consent; granty viazané na účel a čas; odvolanie; "break-the-glass" s odôvodnením a upozornením | Pacient ako zdroj každej autorizácie | Platforma súhlasu pacienta, Požiadavky na prístup kliniky |
| Zodpovednosť | Logy prístupov ku každému záznamu viditeľné pre pacienta; FHIR AuditEvent; úložisko odolné voči neoprávneným zásahom; uchovávanie | Kto, čo, kedy videl | Kto si prezeral môj zdravotný záznam? |
| Ochrana | TLS 1.2+, šifrovanie pri uložení so spravovanými kľúčmi, šifrovanie na úrovni poľa pre identifikátory, segregované prostredia, zálohy s testovanou obnovou | Dôvernosť a dostupnosť | ISO 27001 vs ISO 27799 |
| Základná úroveň | ISO 27001 ISMS, 27799 zdravotnícke kontroly, opatrenia NIS2, Bezpečnostné pravidlo HIPAA, národné schémy (HDS, DSPT, C5) | Čo očakávajú nemocnice, audítori a regulačné orgány | NIS2 pre nemocnice a dodávateľov, HIPAA vs GDPR |
| Zdieľanie | SMART Health Links a Cards; overiteľné poverenia | Zdieľanie iniciované pacientom pomocou odkazu alebo QR kódu, odvolateľné | Vysvetlenie SMART Health Links |
Identita: záruka nad heslami
Identita v zdravotníckej aplikácii závisí od overenia, nie od sily hesla: úrovne overenia identity ako NIST IAL, eIDAS substantial a high, alebo NHS login P9 popisujú, ako silno bola osoba overená pri registrácii, zatiaľ čo viacfaktorová autentizácia a passkeys popisujú každé prihlásenie. Klinickí lekári sú identifikovaní prostredníctvom profesijných identít, ktoré sú zrušené, keď odídu.
Aplikácia pre pacienta, ktorá zobrazuje kompletný záznam, musí vedieť, že komunikuje práve s týmto pacientom. Úrovne záruky identity (IAL podľa NIST, eIDAS podstatná a vysoká, NHS login P9) popisujú, ako silno bola identita overená pri registrácii; sila autentizácie (viacfaktorová, passkeys) popisuje každé prihlásenie. Nemocnice a národné systémy čoraz častejšie vyžadujú overené identity z uznávaných schém namiesto samo-deklarovaných registrácií a Európska digitálna peňaženka sa stane akceptovaným prostriedkom. Pre lekárov je profesijná identita (a jej odvolanie, keď niekto odíde) systémom záznamu o tom, kto vôbec môže konať ako lekár.
Autorizácia: súhlas sa mení na rozsahy
Autorizácia v zázname ovládanom pacientom prevádza súhlas pacienta, napríklad povolenie klinike čítať výsledky laboratórnych testov a diagnózy na 90 dní, do OAuth rozsahov a kontextu pacienta v tokene, v syntaxe SMART on FHIR ako patient/Observation.rs, vynucované na úrovni dát pri každej požiadavke a zrušené, keď pacient odvolá súhlas. Break-the-glass je samostatná, auditovaná cesta.
V zázname kontrolovanom pacientom je súhlas pacienta politikou: táto klinika môže čítať moje laboratórne výsledky a diagnózy po dobu 90 dní. Systém to prekladá do rozsahov OAuth a kontextu (ktorý pacient, ktoré zdroje, ktoré operácie) na tokene, ktorý dostane systém kliniky, vynucuje ich pri každej požiadavke na úrovni dát a odvoláva ich, keď ich pacient zruší. Syntax rozsahu SMART on FHIR (patient/Observation.rs, patient/Condition.rs) je pre toto lingua franca; granulárne rozsahy (podľa kategórie alebo kódu) existujú v SMART v2 pre jemnejšie ovládanie. Break-the-glass (núdzový prístup bez súhlasu) je samostatná, auditovaná cesta s povinným odôvodnením a upozornením pacienta, nikdy nie je predvolená. Pozri Platforma súhlasu pacienta.
Zodpovednosť: log, ktorý si pacient číta
Zodpovednosť v zdravotníckej aplikácii znamená, že každý prístup k záznamu, kým, kedy, čo a na základe akého súhlasu, je zaznamenaný do nemenného logu, ktorý si pacient môže prečítať vo svojej aplikácii, a do organizačnej auditnej stopy vo FHIR AuditEvent. Norma ISO 27799 považuje toto za povinné a viditeľný log je najsilnejšou prevenciou proti neoprávnenému prehliadaniu záznamov zo strany zamestnancov.
Každý prístup k záznamu, kým, kedy, čo, pod akým súhlasom, zapísaný do logu, do ktorého sa dá len pridávať, ktorý si pacient môže prečítať vo svojej aplikácii, a do organizačnej auditnej stopy (FHIR AuditEvent) pre bezpečnostné tímy. ISO 27799 to považuje za povinné pre zdravotné informácie; princíp transparentnosti GDPR a práva pacienta v EHDS smerujú rovnakým smerom; najväčšou reálnou odstrašujúcou silou proti prezeraniu internými zamestnancami je viditeľný log. Pozri Kto si prezeral môj zdravotný záznam?.
Ochrana: základná technická úroveň
Technickým základom na ochranu zdravotných údajov je TLS všade, šifrovanie v pokoji s riadenými, rotovanými kľúčmi, samostatné šifrovanie alebo tokenizácia priamych identifikátorov, segregované prostredia so syntetickými údajmi mimo produkcie, prístup s najmenšími oprávneniami s viacfaktorovou autentizáciou pre administrátorov, správa tajných kódov a zraniteľností, šifrované zálohy testované obnovením proti ransomvéru a reakcia na incidenty v rámci časových rámcov GDPR a NIS2.
TLS všade, s modernými šiframi a pripínaním certifikátov v aplikáciách, kde je to vhodné; šifrovanie pri uložení s kľúčmi v spravovanej kľúčovej službe a rotáciou; samostatné šifrovanie alebo tokenizácia pre priame identifikátory; segregácia produkcie od vývoja, so syntetickými dátami mimo produkcie; prístup s najmenšími oprávneniami pre zamestnancov, žiadne zdieľané účty, viacfaktorová autentizácia pre všetok administratívny prístup; správa tajných kódov; správa závislostí a zraniteľností s zverejňovaním; zálohy šifrované, testované obnovou a chránené proti ransomwaru, ktorý opakovane zasiahol nemocnice a laboratóriá (WannaCry v roku 2017, nemocnica v Düsseldorfe v roku 2020, Change Healthcare a Synnovis v roku 2024). Reakcia na incidenty so 72-hodinovými hodinami GDPR a 24-hodinovými hodinami NIS2 v jednom runbooku.
Hrozby špecifické pre zdravotné dáta
Hrozby špecifické pre zdravotné údaje zahŕňajú neoprávnené prehliadanie záznamov známych osôb zo strany zamestnancov, nesprávne zaradenie medzi pacientov, príliš široké zdieľanie povolené na príliš dlhú dobu, reklamné SDK v aplikáciách, ktoré spracúvajú zdravotné údaje, injektovanie dokumentov do funkcií AI a dlhodobé uchovávanie po desaťročia, počas ktorých kľúče, formáty a pravidlá prístupu musia prežiť zamestnancov a dodávateľov.
- Prezeranie záznamov známymi alebo verejne známymi osobami internými zamestnancami: prístup založený na vzťahoch a viditeľné logy.
- Nesprávne zaradenie medzi pacientov: zosúladenie identity a pôvodu, nielen kontrola prístupu.
- Príliš široké zdieľanie: klinika, ktorej bolo udelené "všetko" na rok; rozsahy a trvania s rozumnými predvolenými hodnotami.
- Aplikácie s reklamnými SDK: žiadne sledovacie nástroje tretích strán v čomkoľvek, čo spracúva zdravotné dáta.
- Vloženie do dokumentov do funkcií AI: obsah je dáta, nikdy inštrukcie (RAG na zdravotných záznamoch).
- Dlhé uchovávanie: záznamy žijú desaťročia; kľúče, formáty a pravidlá prístupu musia prežiť zamestnancov a dodávateľov.
V Anpheros
Anpheros aplikuje bezpečnostnú mapu na seba pomocou OAuth 2.0 s PKCE pre aplikácie a asymetrickej autentizácie klienta pre backendy, súhlasu na účel a trvanie ako zdroja prístupu každej kliniky, logu prístupu na záznam v aplikácii danej osoby, šifrovania v pokoji a pri prenose, hostingu v EÚ, žiadnych reklamných SDK a ISMS v súlade s ISO 27001 a 27799.
Anpheros aplikuje túto mapu na seba: OAuth 2.0 s PKCE pre aplikácie a asymetrickú autentizáciu klienta pre backendy; súhlas na účel a trvanie ako zdroj prístupu každej kliniky, s odvolaním a bez tichého "break-the-glass"; log prístupov ku každému záznamu v aplikácii osoby; šifrovanie pri uložení a pri prenose, európske hostingové služby, žiadne reklamné SDK; ISMS podľa ISO 27001 s kontrolami 27799 pre zdravotníctvo. Stránka pre vývojárov dokumentuje autentizáciu, súhlas a bezpečnosť.
Súvisiace stránky
- Vysvetlenie SMART App Launch
- Platforma súhlasu pacienta
- Kto si prezeral môj zdravotný záznam?
- Vysvetlenie SMART Health Links
- ISO 27001 vs ISO 27799
- NIS2 pre nemocnice a dodávateľov zdravotníckych technológií
- Bezpečnosť platformy (stránka pre vývojárov)
- Autentizácia (stránka pre vývojárov)
Zdroje
- HL7 SMART App Launch
- IETF: OAuth 2.1 (návrh)
- 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: Procurement guidelines for cybersecurity in hospitals
Časté otázky
Je OAuth 2.1 odlišný od 2.0?
OAuth 2.1 konsoliduje 2.0 s jeho bezpečnostnými osvedčenými postupmi: PKCE je povinné pre všetkých klientov, implicitné a heslové granty sú odstránené, presmerovacie URI sa musia presne zhodovať a obnovovacie tokeny pre verejné klientov musia byť viazané alebo rotované. SMART on FHIR v2 už vyžaduje väčšinu z toho.
Čo je "break-the-glass"?
Núdzový prístup k záznamu bez predchádzajúceho súhlasu pacienta, vykonaný lekárom, ktorý uvedie odôvodnenie. Musí byť zriedkavý, zaznamenaný, preskúmaný a nahlásený pacientovi; nikdy nie je predvolenou cestou prístupu.
Prečo by mali pacienti vidieť log prístupov?
Pretože je to najsilnejšia odstrašujúca sila proti neoprávnenému prístupu a najjasnejší prejav kontroly: osoba vidí, ktorá klinika si čo a kedy prečítala, a môže to odvolať. ISO 27799 a EHDS smerujú rovnakým smerom.
Potrebujem samostatný auditný systém?
Potrebujete auditnú stopu, do ktorej sa dá len pridávať (FHIR AuditEvent alebo ekvivalent), ktorú aplikácia nemôže zmeniť, uchovávanú podľa politiky, a pohľad pre pacienta odvodený z nej. Či je to samostatný systém alebo chránené úložisko v rámci platformy, je implementačná voľba.
Vyskúšajte zadarmo v sandboxe
Prvé volanie FHIR za 5 minút. API podľa štandardu HL7 FHIR R4 s integrovaným súhlasom pacienta: vyskúšajte si ho v sandboxe a potom pripojte svoju vlastnú aplikáciu alebo klinický systém.
Zadarmo · 30 syntetických pacientov · bez karty
Anpheros vyvíja zdravotný záznam, ktorý pacient ovláda a môže zdieľať s akoukoľvek klinikou, na platforme HL7 FHIR R4, so sídlom v EÚ. Tieto návody vám pomôžu pochopiť a usporiadať si svoje zdravie; nenahrádzajú vášho lekára.
O Anpherose →