Zabezpečení a identita v aplikacích pro zdraví: mapa

Krátká odpověď: zabezpečení v aplikaci pro zdraví odpovídá na čtyři otázky, v tomto pořadí. Kdo to je? Identita: ověřený uživatel (pacient, lékař, systém) prostřednictvím OpenID Connect a pro lékaře národní profesní identita; úroveň ověření je důležitější než síla hesla. Co smí dělat? Autorizace: OAuth 2.0 (přechod na 2.1) tokeny s rozsahy (scopes) v syntaxi SMART on FHIR, odvozené ze souhlasu pacienta pro daný účel a dobu trvání, vynucované na vrstvě dat. Co udělali? Odpovědnost: log přístupů, který si pacient může přečíst, a AuditEvent ve formátu FHIR pro organizaci. Jsou data v bezpečí při uložení, přenosu a v zálohách? Ochrana: šifrování, správa klíčů, segregace, testované obnovy. Kolem nich: základ tvoří ISO 27001 a 27799, NIS2 a bezpečnostní pravidlo HIPAA, a specifická rizika zdravotnických dat (prohlížení dat interními pracovníky, nesprávné zařazení, ransomware).

Mapa

Zabezpečení a identita v aplikaci pro zdraví mají sedm vrstev: identita prostřednictvím OpenID Connect a národních či profesních průkazů, autorizace prostřednictvím OAuth 2.0 a rozsahů SMART on FHIR, souhlas jako zdroj každého udělení, odpovědnost prostřednictvím přístupových protokolů a FHIR AuditEvent, ochrana prostřednictvím šifrování a záloh, základna ISO 27001, ISO 27799, NIS2 a HIPAA a sdílení iniciované pacientem.

Vrstva	Standard nebo praxe	Co vám to dává	Stránka
Identita	OpenID Connect; národní ID (eIDAS, NHS login, GesundheitsID); profesní identity (eHBA, CPS, UZI)	Ověřený subjekt s úrovní záruky	Vysvětlení SMART App Launch
Autorizace	OAuth 2.0 a 2.1 (PKCE povinné, žádné implicitní nebo heslové udělování); rozsahy SMART on FHIR (patient/Observation.rs); backendové služby s asymetrickou autentizací klienta	Tokeny vázané na uživatele, kontext pacienta a rozsah	Vysvětlení SMART App Launch, SMART on FHIR backend
Souhlas	FHIR Consent; udělení na základě účelu a času; odvolání; "break-the-glass" s odůvodněním a upozorněním	Pacient jako zdroj každé autorizace	Platforma pro souhlas pacienta, Žádosti o přístup z kliniky
Odpovědnost	Logy přístupů na záznam viditelné pro pacienta; FHIR AuditEvent; úložiště odolné proti neoprávněné manipulaci; uchovávání	Kdo co viděl, kdy, proč	Kdo si prohlížel můj zdravotní záznam?
Ochrana	TLS 1.2+, šifrování při uložení se spravovanými klíči, šifrování na úrovni polí pro identifikátory, oddělená prostředí, zálohy s testovanou obnovou	Důvěrnost a dostupnost	ISO 27001 vs ISO 27799
Základ	ISMS ISO 27001, zdravotnické kontroly ISO 27799, opatření NIS2, bezpečnostní pravidlo HIPAA, národní schémata (HDS, DSPT, C5)	Co očekávají nemocnice, auditoři a regulátoři	NIS2 pro nemocnice a dodavatele, HIPAA vs GDPR
Sdílení	SMART Health Links a Cards; ověřitelné pověření	Sdílení iniciované pacientem pomocí odkazu nebo QR kódu, odvolatelné	Vysvětlení SMART Health Links

Identita: záruka nad hesly

Identita v aplikaci pro zdraví závisí na ověření spolehlivosti, nikoli na síle hesla: úrovně ověření identity, jako jsou NIST IAL, eIDAS substantial a high, nebo NHS login P9, popisují, jak silně byla osoba ověřena při registraci, zatímco vícefaktorové ověřování a passkeys popisují každé přihlášení. Zdravotníci jsou identifikováni prostřednictvím profesních identit, které jsou zrušeny, když odejdou.

Aplikace pro pacienta, která zobrazuje úplný záznam, musí vědět, že komunikuje s tímto pacientem. Úrovně záruky identity (IAL podle NIST, podstatná a vysoká podle eIDAS, NHS login P9) popisují, jak silně byla identita ověřena při registraci; síla autentizace (vícefaktorová, passkeys) popisuje každé přihlášení. Nemocnice a národní systémy stále častěji vyžadují ověřené identity z uznávaných schémat namísto samo-deklarovaných registrací a peněženka EU Digital Identity Wallet se stane přijímaným prostředkem. Pro lékaře je profesní identita (a její zrušení při odchodu) systémem záznamu o tom, kdo vůbec může působit jako lékař.

Autorizace: souhlas se stává rozsahy

Autorizace v záznamu ovládaném pacientem převádí souhlas pacienta, například umožnění klinice číst laboratorní výsledky a diagnózy po dobu 90 dnů, do rozsahů OAuth a kontextu pacienta v tokenu, v syntaxi SMART on FHIR, jako je patient/Observation.rs, vynucované na vrstvě dat při každém požadavku a zrušené, když pacient odvolá souhlas. Break-the-glass je samostatná, auditovaná cesta.

V záznamu ovládaném pacientem je souhlas pacienta politikou: tato klinika smí číst mé laboratorní výsledky a diagnózy po dobu 90 dnů. Systém jej přeloží do rozsahů OAuth a kontextu (který pacient, které zdroje, které operace) na tokenu, který obdrží systém kliniky, vynucuje je při každém požadavku na vrstvě dat a zruší je, když pacient odvolá. Syntax rozsahů SMART on FHIR (patient/Observation.rs, patient/Condition.rs) je pro to lingua franca; granulární rozsahy (podle kategorie nebo kódu) existují v SMART v2 pro jemnější kontrolu. "Break-the-glass" (nouzový přístup bez souhlasu) je samostatná, auditovaná cesta s povinným odůvodněním a upozorněním pacienta, nikdy není výchozí. Viz Platforma pro souhlas pacienta.

Odpovědnost: log, který si pacient čte

Odpovědnost v aplikaci pro zdraví znamená, že každý přístup k záznamu, kým, kdy, co a na základě jakého souhlasu, je zapsán do protokolu pouze pro přidávání, který si pacient může přečíst ve své aplikaci, a do organizační auditní stopy ve formátu FHIR AuditEvent. Norma ISO 27799 považuje toto za povinné a viditelný protokol je nejsilnější odstrašující prostředek proti prohlížení dat interními pracovníky.

Každý přístup k záznamu, kým, kdy, co, pod jakým souhlasem, zapsaný do logu pouze pro přidávání, který si pacient může přečíst ve své aplikaci, a do organizačního auditního záznamu (FHIR AuditEvent) pro bezpečnostní týmy. ISO 27799 považuje toto za povinné pro zdravotnické informace; princip transparentnosti GDPR a práva pacienta podle EHDS ukazují stejným směrem; největší odstrašující prostředek proti prohlížení dat interními pracovníky je viditelný log. Viz Kdo si prohlížel můj zdravotní záznam?.

Ochrana: inženýrský základ

Technickým základem pro ochranu zdravotních dat je všudypřítomné TLS, šifrování dat v klidu s řízenými, rotovanými klíči, oddělené šifrování nebo tokenizace pro přímé identifikátory, segregovaná prostředí se syntetickými daty mimo produkci, přístup s nejnižšími oprávněními s vícefaktorovým ověřováním pro administrátory, správa tajemství a zranitelností, šifrované zálohy testované obnovením proti ransomwaru a reakce na incidenty v rámci časových limitů GDPR a NIS2.

TLS všude, s moderními šiframi a připínáním certifikátů v aplikacích, kde je to vhodné; šifrování při uložení s klíči ve spravované službě klíčů a jejich rotací; oddělené šifrování nebo tokenizace pro přímé identifikátory; oddělení produkčního prostředí od vývojového, se syntetickými daty mimo produkci; přístup s minimálními oprávněními pro personál, žádné sdílené účty, vícefaktorová autentizace pro veškerý administrativní přístup; správa tajemství; správa závislostí a zranitelností s oznámením; zálohy šifrované, testované obnovou a chráněné proti ransomwaru, který opakovaně zasáhl nemocnice a laboratoře (WannaCry v roce 2017, nemocnice v Düsseldorfu v roce 2020, Change Healthcare a Synnovis v roce 2024). Reakce na incidenty se 72hodinovými hodinami GDPR a 24hodinovými hodinami NIS2 v jednom runbooku.

Hrozby specifické pro zdravotnická data

Hrozby specifické pro zdravotní data zahrnují prohlížení záznamů známých osob interními pracovníky, nesprávné zařazení mezi pacienty, příliš široké sdílení udělené na příliš dlouhou dobu, reklamní SDK uvnitř aplikací, které zpracovávají zdravotní data, injektáž dokumentů do funkcí AI a dlouhodobé uchovávání po desetiletí, během kterých klíče, formáty a pravidla přístupu musí přežít zaměstnance a dodavatele.

Prohlížení dat interními pracovníky záznamů známých nebo veřejných osob: přístup založený na vztazích a viditelné logy.
Nesprávné zařazení mezi pacienty: shoda identit a původ, nejen řízení přístupu.
Příliš široké sdílení: klinika, které bylo uděleno "vše" na rok; rozsahy a doby trvání s rozumnými výchozími hodnotami.
Aplikace s reklamními SDK: žádné sledovací prvky třetích stran v čemkoli, co zpracovává zdravotnická data.
Vkládání do dokumentů do funkcí AI: obsah je data, nikdy instrukce (RAG na zdravotnických záznamech).
Dlouhé uchovávání: záznamy žijí desítky let; klíče, formáty a pravidla přístupu musí přežít personál a dodavatele.

V Anpheros

Anpheros aplikuje bezpečnostní mapu na sebe s OAuth 2.0 s PKCE pro aplikace a asymetrickou autentizací klienta pro backendy, souhlasem na účel a dobu trvání jako zdrojem přístupu každé kliniky, protokolem přístupu k jednotlivým záznamům v aplikaci osoby, šifrováním dat v klidu i při přenosu, hostováním v EU, žádnými reklamními SDK a ISMS v souladu s ISO 27001 a 27799.

Anpheros aplikuje tuto mapu na sebe: OAuth 2.0 s PKCE pro aplikace a asymetrickou autentizací klienta pro backendy; souhlas na účel a dobu trvání jako zdroj přístupu každé kliniky, s odvoláním a bez tichého "break-the-glass"; log přístupů na záznam v aplikaci dané osoby; šifrování při uložení a přenosu, hosting v EU, žádné reklamní SDK; ISMS podle ISO 27001 se zdravotnickými kontrolami 27799. Stránka pro vývojáře dokumentuje autentizaci, souhlas a zabezpečení.

Související stránky

Zdroje

Časté otázky

Je OAuth 2.1 jiný než 2.0?

OAuth 2.1 konsoliduje 2.0 s osvědčenými bezpečnostními postupy: PKCE je povinné pro všechny klienty, implicitní a heslové udělování jsou odstraněny, přesměrovací URI se musí přesně shodovat a obnovovací tokeny pro veřejné klienty musí být vázané nebo rotované. SMART on FHIR v2 již většinu z toho vyžaduje.

Co je "break-the-glass"?

Nouzový přístup k záznamu bez předchozího souhlasu pacienta, prováděný lékařem, který uvede odůvodnění. Musí být vzácný, zaznamenaný, zkontrolovaný a nahlášený pacientovi; nikdy to není výchozí cesta přístupu.

Proč by pacienti měli vidět log přístupů?

Protože je to nejsilnější odstrašující prostředek proti nevhodnému přístupu a nejjasnější vyjádření kontroly: osoba vidí, která klinika si co a kdy přečetla, a může to odvolat. ISO 27799 a EHDS ukazují stejným směrem.

Potřebuji samostatný auditní systém?

Potřebujete auditní záznam pouze pro přidávání (FHIR AuditEvent nebo ekvivalent), který aplikace nemůže změnit, uchovávaný podle zásad, a pohled pro pacienta odvozený z něj. Zda se jedná o samostatný systém, nebo chráněné úložiště uvnitř platformy, je volba implementace.

Anpheros Platform

Vyzkoušejte zdarma v sandboxu

První volání FHIR za 5 minut. API standardu HL7 FHIR R4 s integrovaným souhlasem pacienta: vyzkoušejte si ho v sandboxu a poté propojte svou vlastní aplikaci nebo klinický systém.

Vytvořit sandbox zdarma Přečíst návody pro vývojáře →

Zdarma · 30 syntetických pacientů · bez karty

Tento návod slouží pouze pro informační účely a nenahrazuje lékařskou radu. Ohledně rozhodnutí o svém zdraví se poraďte se svým lékařem. V naléhavém případě volejte místní tísňové číslo (v Evropě 112).

Napsal

Tým Anpheros

Anpheros vytváří zdravotní záznamy, které pacient ovládá a může sdílet s jakoukoli klinikou, na platformě HL7 FHIR R4 se sídlem v EU. Tyto průvodce vám pomohou porozumět vašemu zdraví a uspořádat si ho; nenahrazují vašeho lékaře.

O Anpheros →