Biztonság és azonosítás egészségügyi alkalmazásokban: a térkép

Rövid válasz: egy egészségügyi alkalmazásban a biztonság négy kérdésre válaszol, sorrendben. Ki ez? Identitás: egy hitelesített felhasználó (beteg, orvos, rendszer) az OpenID Connecten keresztül, az orvosok számára pedig a nemzeti szakmai identitás; a hitelesítés szintje fontosabb, mint a jelszó erőssége. Mit tehet? Engedélyezés: OAuth 2.0 (2.1-re váltó) tokenek hatókörökkel a SMART on FHIR szintaxisában, a beteg hozzájárulásából származó célra és időtartamra, az adatrétegen érvényesítve. Mit tett? Elszámoltathatóság: egy hozzáférési napló, amelyet a beteg elolvashat, és egy FHIR AuditEvent nyomvonal a szervezet számára. Biztonságban van az adat tárolás, átvitel és biztonsági mentések során? Védelem: titkosítás, kulcskezelés, szegregáció, tesztelt visszaállítások. Körülöttük: az ISO 27001 és 27799, a NIS2 és a HIPAA biztonsági szabályzata, valamint az egészségügyi adatok specifikus fenyegetései (belső böngészés, téves archiválás, ransomware).

A térkép

Az egészségügyi alkalmazások biztonsága és identitása hét rétegből áll: identitás az OpenID Connect és nemzeti vagy szakmai azonosítók révén, engedélyezés az OAuth 2.0 és a SMART on FHIR hatókörökön keresztül, hozzájárulás mint minden engedély forrása, elszámoltathatóság hozzáférési naplókon és FHIR AuditEvent-en keresztül, védelem titkosítással és biztonsági mentésekkel, alapvető szabványokként az ISO 27001, ISO 27799, NIS2 és HIPAA, valamint a beteg által kezdeményezett megosztás.

Réteg	Szabvány vagy gyakorlat	Mit ad neked	Oldal
Identitás	OpenID Connect; nemzeti azonosítók (eIDAS, NHS login, GesundheitsID); szakmai identitások (eHBA, CPS, UZI)	Egy hitelesített alany, biztosítási szinttel	SMART App Launch magyarázata
Engedélyezés	OAuth 2.0 és 2.1 (PKCE kötelező, nincs implicit vagy jelszavas hozzáférés); SMART on FHIR hatókörök (patient/Observation.rs); aszimmetrikus kliens hitelesítésű backend szolgáltatások	Tokenek, amelyek egy felhasználóhoz, egy betegkontextushoz és egy hatókörhöz kötöttek	SMART App Launch magyarázata, SMART on FHIR backend
Hozzájárulás	FHIR Consent; cél- és időhöz kötött engedélyek; visszavonás; "break-the-glass" indoklással és riasztással	A beteg minden engedélyezés forrása	Beteg hozzájárulási platform, Klinikai hozzáférési kérelmek
Elszámoltathatóság	Rekordonkénti hozzáférési naplók, amelyek a beteg számára láthatók; FHIR AuditEvent; manipulációbiztos tárolás; megőrzés	Ki mit, mikor, miért látott	Ki nézte meg az orvosi dokumentumomat?
Védelem	TLS 1.2+, titkosítás tárolás közben, felügyelt kulcsokkal, mezőszintű titkosítás azonosítókhoz, szegregált környezetek, biztonsági mentések tesztelt visszaállítással	Titkosság és elérhetőség	ISO 27001 vs ISO 27799
Alap	ISO 27001 ISMS, 27799 egészségügyi kontrollok, NIS2 intézkedések, HIPAA Security Rule, nemzeti rendszerek (HDS, DSPT, C5)	Amit a kórházak, auditálók és szabályozók elvárnak	NIS2 kórházaknak és gyártóknak, HIPAA vs GDPR
Megosztás	SMART Health Links és Cards; igazolható hitelesítő adatok	Beteg által kezdeményezett megosztás linkkel vagy QR-kóddal, visszavonható	SMART Health Links magyarázata

Identitás: biztosítás jelszavak helyett

Az egészségügyi alkalmazásokban az identitás a jelszóerősség helyett az ellenőrzés megbízhatóságán alapul: az identitás-ellenőrzési szintek, mint például a NIST IAL, az eIDAS szubstanciális és magas szintű, vagy a NHS login P9 írják le, hogy egy személyt milyen erősen ellenőriztek a regisztráció során, míg a többtényezős hitelesítés és a jelszavak (passkeys) minden bejelentkezést írnak le. A klinikusokat szakmai identitások azonosítják, amelyeket távozásukkor visszavonnak.

Egy betegalkalmazásnak, amely teljes dokumentumot jelenít meg, tudnia kell, hogy azzal a beteggel beszél. Az identitásbiztosítási szintek (NIST IAL, eIDAS szubstanciális és magas, NHS login P9) leírják, milyen erősen lett igazolva az identitás a regisztrációkor; az autentikációs erősség (többfaktoros, jelszókulcsok) minden bejelentkezést ír le. A kórházak és a nemzeti rendszerek egyre inkább elismert rendszerekből származó hitelesített identitásokat követelnek meg az önállóan megadott regisztrációk helyett, és az EU Digitális Identitás Tárca elfogadott eszközzé válik. Az orvosok számára a szakmai identitás (és annak visszavonása, amikor valaki távozik) a rendszer alapja arról, hogy ki jogosult orvosként eljárni.

Engedélyezés: a hozzájárulásból hatókörök lesznek

A beteg által vezérelt rekordban az engedélyezés a beteg hozzájárulását fordítja le, például lehetővé téve egy klinika számára, hogy 90 napig olvassa a laboreredményeket és a diagnózisokat, OAuth hatókörökké és betegkontextussá a tokenen, SMART on FHIR szintaxisban, mint például a patient/Observation.rs, az adatrétegen érvényesítve minden kérésnél, és visszavonva, amikor a beteg ezt kéri. A „break-the-glass” egy külön, auditált útvonal.

Egy beteg által vezérelt dokumentumban a beteg hozzájárulása a szabályzat: ez a klinika 90 napig olvashatja a laboreredményeimet és állapotaimat. A rendszer ezt OAuth hatókörökre és kontextusra (melyik beteg, mely erőforrások, mely műveletek) fordítja a tokenen, amelyet a klinika rendszere kap, minden kérésre érvényesíti az adatrétegen, és visszavonja, amikor a beteg visszavonja. A SMART on FHIR hatókör szintaxisa (patient/Observation.rs, patient/Condition.rs) a lingua franca ehhez; a SMART v2-ben léteznek részletes hatókörök (kategória vagy kód szerint) a finomabb vezérlés érdekében. A "break-the-glass" (vészhelyzeti hozzáférés hozzájárulás nélkül) egy külön, auditált út, kötelező indoklással és riasztással a beteg felé, soha nem alapértelmezett. Lásd: Beteg hozzájárulási platform.

Elszámoltathatóság: a napló, amit a beteg olvas

Az egészségügyi alkalmazásokban az elszámoltathatóság azt jelenti, hogy minden rekordhoz való hozzáférés – ki, mikor, mit és milyen hozzájárulás alapján – egy csak hozzáadható naplóba kerül, amelyet a beteg a saját alkalmazásában olvashat, valamint egy szervezeti audit nyomvonalra FHIR AuditEvent formájában. Az ISO 27799 ezt kötelezőnek tekinti, és egy látható napló a legerősebb visszatartó erő a belső visszaélésekkel szemben.

Minden dokumentumhoz való hozzáférés, ki által, mikor, mit, milyen hozzájárulás alapján, egy csak hozzáadható naplóba írva, amelyet a beteg elolvashat az alkalmazásában, és egy szervezeti audit nyomvonalra (FHIR AuditEvent) a biztonsági csapatok számára. Az ISO 27799 ezt kötelezőnek tekinti az egészségügyi információkra; a GDPR átláthatósági elve és az EHDS betegjogai ugyanarra mutatnak; a belső böngészés elleni legnagyobb valós visszatartó erő egy látható napló. Lásd: Ki nézte meg az orvosi dokumentumomat?.

Védelem: a mérnöki alap

Az egészségügyi adatok védelmének mérnöki alapja mindenhol a TLS, az adatok tárolás közbeni titkosítása felügyelt, forgatott kulcsokkal, a közvetlen azonosítók külön titkosítása vagy tokenizálása, elkülönített környezetek szintetikus adatokkal a gyártáson kívül, a legkisebb jogosultság elve a rendszergazdák többtényezős hitelesítésével, titkok és sebezhetőségek kezelése, titkosított biztonsági mentések, amelyeket visszaállítási tesztekkel ellenőriznek ransomware ellen, és incidenskezelés a GDPR és NIS2 határidőin belül.

TLS mindenhol, modern titkosítókkal és tanúsítvány rögzítéssel az alkalmazásokban, ahol releváns; titkosítás tárolás közben felügyelt kulcsszolgáltatásban lévő kulcsokkal és forgatással; külön titkosítás vagy tokenizálás a közvetlen azonosítókhoz; a termelés és a fejlesztés szegregációja, szintetikus adatokkal a termelésen kívül; minimális jogosultságú hozzáférés a személyzet számára, nincsenek megosztott fiókok, többfaktoros hitelesítés minden adminisztratív hozzáféréshez; titkos kulcsok kezelése; függőség- és sérülékenységkezelés közzététellel; titkosított biztonsági mentések, visszaállítással tesztelve, és védve a ransomware ellen, amely ismételten sújtotta a kórházakat és laboratóriumokat (WannaCry 2017-ben, a düsseldorfi kórház 2020-ban, a Change Healthcare és a Synnovis 2024-ben). Incidensre reagálás a GDPR 72 órás és a NIS2 24 órás határidejével egyetlen futtatási tervben.

Az egészségügyi adatokra jellemző fenyegetések

Az egészségügyi adatokra jellemző fenyegetések a következők: ismerősök rekordjainak belső böngészése, betegek közötti téves archiválás, túl hosszú ideig adott túl széles körű megosztás, egészségügyi adatokat kezelő alkalmazásokon belüli reklám SDK-k, dokumentumokon keresztüli injekció az AI funkciókba, valamint a több évtizedes hosszú megőrzési időszak, amely alatt a kulcsoknak, formátumoknak és hozzáférési szabályoknak túl kell élniük a személyzetet és a beszállítókat.

Belső böngészés ismerősök vagy közszereplők dokumentumaiban: kapcsolat alapú hozzáférés és látható naplók.
Téves archiválás betegek között: identitás-egyeztetés és eredet, nem csak hozzáférés-vezérlés.
Túl széles körű megosztás: egy klinika, amelynek egy évre "mindent" megadtak; hatókörök és időtartamok ésszerű alapértelmezésekkel.
Hirdetési SDK-kkal rendelkező alkalmazások: nincsenek harmadik féltől származó követők semmiben, ami egészségügyi adatokat kezel.
Dokumentum alapú injekció AI funkciókba: a tartalom adat, soha nem utasítás (RAG orvosi dokumentumokon).
Hosszú megőrzés: a dokumentumok évtizedekig élnek; a kulcsoknak, formátumoknak és hozzáférési szabályoknak túl kell élniük a személyzetet és a beszállítókat.

Az Anpherosnál

Az Anpheros saját magára alkalmazza a biztonsági térképet: OAuth 2.0 PKCE-vel az alkalmazásokhoz és aszimmetrikus kliens-hitelesítéssel a backendekhez, célonkénti és időtartamra szóló hozzájárulás minden klinika hozzáférésének forrásaként, rekordonkénti hozzáférési napló a személy alkalmazásában, titkosítás tárolás és átvitel közben, EU-s tárhely, nincsenek reklám SDK-k, valamint egy ISMS az ISO 27001 és 27799 szabványok szerint.

Az Anpheros ezt a térképet alkalmazza önmagára: OAuth 2.0 PKCE-vel az alkalmazásokhoz és aszimmetrikus kliens hitelesítéssel a backendekhez; hozzájárulás célonként és időtartamonként minden klinika hozzáférésének forrásaként, visszavonással és nincsenek néma "break-the-glass" funkciók; egy per-rekord hozzáférési napló a személy applikációjában; titkosítás tárolás és átvitel közben, EU-s tárhely, nincsenek hirdetési SDK-k; egy ISMS az ISO 27001 szerint, a 27799 egészségügyi kontrollokkal. A fejlesztői weboldal dokumentálja a hitelesítést, a hozzájárulást és a biztonságot.

Kapcsolódó oldalak

Források

Gyakori kérdések

Az OAuth 2.1 különbözik a 2.0-tól?

Az OAuth 2.1 összefoglalja a 2.0-t annak biztonsági legjobb gyakorlataival: a PKCE kötelező minden kliens számára, az implicit és jelszavas hozzáférések eltávolításra kerültek, a visszahívási URI-knak pontosan meg kell egyezniük, és a nyilvános kliensek frissítési tokenjeit kötni vagy forgatni kell. A SMART on FHIR v2 már sok ilyen követelményt támaszt.

Mi az a "break-the-glass"?

Vészhelyzeti hozzáférés egy dokumentumhoz a beteg előzetes hozzájárulása nélkül, egy orvos által, aki indoklást állít. Ritkának, naplózottnak, felülvizsgáltnak és a betegnek jelentettnek kell lennie; soha nem az alapértelmezett hozzáférési út.

Miért láthatják a betegek a hozzáférési naplót?

Mert ez a legerősebb visszatartó erő a nem megfelelő hozzáféréssel szemben, és a kontroll legvilágosabb kifejezése: a személy látja, melyik klinika mit és mikor olvasott, és visszavonhatja. Az ISO 27799 és az EHDS is erre mutat.

Szükségem van külön audit rendszerre?

Szüksége van egy csak hozzáadható audit nyomvonalra (FHIR AuditEvent vagy megfelelő), amelyet az alkalmazás nem tud módosítani, chính sách szerint megőrizve, és egy ebből származó, beteg-orientált nézetre. Az, hogy ez egy külön rendszer vagy egy védett tároló a platformon belül, implementációs választás.

Anpheros Platform

Próbálja ki ingyen a sandboxban

Az első FHIR-hívás 5 perc alatt. Egy HL7 FHIR R4 API, amely tartalmazza a beteg beleegyezését: próbáld ki a sandboxban, majd csatlakoztasd saját alkalmazásodat vagy klinikai rendszeredet.

Ingyenes sandbox létrehozása Olvasd el a fejlesztői útmutatókat →

Ingyenes · 30 szintetikus beteg · kártya nélkül

Ez az útmutató tájékoztató jellegű, és nem helyettesíti az orvosi tanácsot. Az egészségeddel kapcsolatos döntésekhez beszélj az orvosoddal. Vészhelyzetben hívja a helyi segélyhívó számot (Európában 112).

Szerző:

Az Anpheros csapata

Az Anpheros egy olyan egészségügyi nyilvántartást épít, amelyet a beteg irányít, és megoszthat bármelyik klinikával, egy EU-ban működő HL7 FHIR R4 platformon. Ezek az útmutatók segítenek megérteni és rendszerezni az egészségügyi adataidat; nem helyettesítik az orvosodat.

Tudj meg többet az Anpherosról →