Toestemming in een spoedsituatie: hoe toegang tot patiëntgegevens werkt.

Waarom dit belangrijk is.

In moderne, pull-gebaseerde infrastructuren voor zorginformatie-uitwisseling is het vaak vereist dat een patiënt expliciete toestemming heeft gegeven voordat zijn of haar gegevens door andere zorgprofessionals mogen worden geraadpleegd of gedeeld. De basis hiervoor zijn opt-in toestemmingsregels en governance die worden afgedwongen door lokale regelgeving en/of nationale wetgeving.

In echte spoedsituaties, waarin patiëntgegevens van andere zorgaanbieders geraadpleegd moeten worden, kan dit een uitdaging vormen. Wanneer die andere zorgaanbieders geen toestemming van de patiënt hebben om informatie vrij te geven, is er tijdens de spoedsituatie geen informatie beschikbaar voor artsen. Dit kan de behandeling vertragen of risico’s introduceren die de patiënt kunnen schaden.

Twee benaderingen worden vaak overwogen om dit op te lossen. Beide zijn erop gericht een balans te vinden tussen het beschermen van de privacy van een patiënt en de noodzaak om essentiële informatie — zoals bloedgroep of allergieën — te kunnen raadplegen in situaties waarin tijd een cruciale factor is.

Spoedprotocol.

Een protocol dat het mogelijk maakt om normale toegangscontroles te omzeilen, definieert doorgaans de voorwaarden of beperkingen waaraan voldaan moet worden voordat het geactiveerd kan worden. Die voorwaarden bepalen wie toegang mag krijgen, om welke reden (waarom) en tot welke gegevens. Een SEH-arts (wie) mag bijvoorbeeld de medische samenvatting van een patiënt (welke gegevens) raadplegen wanneer de patiënt op de spoedeisende hulp wordt binnengebracht (waarom).

(Tijdelijke) spoedtoestemming.

Een spoedtoestemming houdt doorgaans in dat een patiënt wordt gevraagd toestemming te geven voor het raadplegen en/of delen van zijn of haar gegevens gedurende een beperkte periode. Een dergelijke toestemming kan vooraf worden geregistreerd bij de zorgaanbieder die de informatie beheert. De toestemming kan ook worden geregistreerd bij de raadplegende zorgaanbieder die de spoedzorg verleent en vervolgens worden gebruikt als (a) bewijs dat aan andere zorgaanbieders kan worden getoond zodat zij de gevraagde informatie mogen vrijgeven, of (b) bewijs dat de raadplegende zorgaanbieder volgens het lokale spoedprotocol een noodprocedure mocht activeren.

Spoedtoestemmingen zijn vaak tijdelijk van aard en verlopen na een vooraf bepaalde periode. Daarom wordt spoedtoestemming ook wel tijdelijke toestemming genoemd.

Beide oplossingen hebben hun eigen voor- en nadelen wanneer ze worden toegepast op infrastructuren voor op bevraging gebaseerde zorginformatie-uitwisseling. Ze sluiten elkaar bovendien niet uit. Een spoedprotocol kan bijvoorbeeld vereisen dat eerst spoedtoestemming wordt verkregen voordat het protocol geactiveerd mag worden.

De afbeeldingen hieronder tonen de verschillende manieren waarop toestemming gebruikt kan worden. Links staat een situatie waarin een patiënt de dossierhouder vooraf toestemming heeft gegeven om zijn of haar informatie vrij te geven in een spoedsituatie. Rechts staat een situatie waarin tijdelijke toestemming wordt gegeven aan de zorgaanbieder die de spoedzorg verleent om gegevens bij de dossierhouder op te vragen.

Hoe werkt dit in de praktijk binnen een zorginformatie-uitwisseling.

Ongeacht welke aanpak wordt gekozen, moeten de wie, de waarom en de wat gedeeld worden tussen een raadpleger en een dossierhouder. In de praktijk kennen de raadpleger — een gebruiker of een systeem dat namens een gebruiker handelt — en de dossierhouder — een zorgorganisatie en het systeem waarin de gegevens worden beheerd — elkaar mogelijk niet vooraf.

Simpel gezegd: het EPD-systeem van Ziekenhuis A weet niet wie de arts van Ziekenhuis B is die patiëntinformatie opvraagt, laat staan dat het weet dat dit verzoek in de context van een spoedsituatie wordt gedaan. Technisch betekent dit dat het EPD identificerende en contextuele informatie moet kunnen meesturen met het verzoek naar een systeem in een ander ziekenhuis.

Break the glass.

Een break-the-glass-functie, die door sommige klinische applicaties wordt aangeboden, kan de contextuele uitdaging oplossen. De naam verwijst naar het brandalarm achter breekbaar glas. Het lost de waarom-vraag op: als iemand ‘het glas breekt’, is de aanname dat er sprake is van een situatie die het activeren van een noodprocedure rechtvaardigt.

Maar break the glass lost het andere deel van het probleem niet op. Hoe weet Ziekenhuis A dat iemand bij Ziekenhuis B ‘het glas heeft gebroken’? Met andere woorden: hoe weet Ziekenhuis A dat er bij Ziekenhuis B sprake is van een spoedsituatie?

Hier komt Purpose of Use in beeld: een korte, een gestandaardiseerde code die met het verzoek wordt meegestuurd en het ontvangende systeem vertelt waarom toegang wordt gevraagd, bijvoorbeeld ‘spoedeisende zorgverlening’. Verschillende standaarden definiëren hiervoor codes, waaronder ISO 14265 en de HL7 ActReason Codeset. Welke standaard een zorginformatienetwerk kiest, is uiteindelijk minder belangrijk dan ervoor zorgen dat iedereen binnen het netwerk de code op dezelfde manier interpreteert.

De raadpleger identificeren.

De break-the-glass-functionaliteit lost ook niet het probleem op om te bepalen wie de gebruiker — of het systeem — is die toegang tot patiëntinformatie vraagt. Wanneer iedereen hetzelfde systeem gebruikt, bijvoorbeeld één PACS of één EPD, is het vastleggen van gebruikerscontext relatief eenvoudig: iedere mogelijke gebruiker is immers al bekend via zijn of haar account.

Binnen een zorginformatie-uitwisseling is dat meestal niet het geval. Het oplossen van de wie-vraag komt daarom neer op twee zaken: systemen moeten identiteitsinformatie aan een verzoek kunnen toevoegen en er moet voldoende vertrouwen bestaan tussen de raadplegende organisatie en de dossierhouder, zodat de dossierhouder erop kan vertrouwen dat de meegestuurde informatie klopt.

Het toevoegen van identiteitsinformatie werkt ongeveer zoals inloggen bij een applicatie met je Google- of Microsoft-account in plaats van overal opnieuw een wachtwoord in te voeren: het verzoek bevat een beveiligd en geverifieerd token dat aangeeft wie het verzoek doet. Binnen de zorg definieert IHE hiervoor twee standaarden — XUA en IUA — waarmee identiteitsinformatie wordt opgenomen in een token dat met het verzoek wordt meegestuurd.

Vertrouwen creëren tussen organisaties die elkaar niet al kennen, is het complexere vraagstuk. Dit wordt doorgaans op één van twee manieren opgelost: organisaties sluiten rechtstreeks een overeenkomst met elkaar, of alle organisaties spreken af om gebruik te maken van een gezamenlijke, vertrouwde derde partij die namens het netwerk identiteiten bevestigt. Voorbeelden hiervan zijn het Nederlandse UZI-systeem voor zorgverleners, de toekomstige EU Digital Identity Wallet of andere sterke oplossingen voor identiteitsverificatie.

Alles bij elkaar komt het oplossen van de wie, waarom en wat neer op drie bouwstenen, die elk ondersteund worden door bestaande standaarden. Onderstaande tabel biedt een kort overzicht; de labels in de eerste kolom zijn daarbij het belangrijkst.

De laatste stap.

Zelfs wanneer de uitdagingen rond gebruiker, context en gegevens zijn opgelost, blijft er nog één belangrijk onderdeel over: bewijs.

Dat betekent dat er een audit trail moet worden gecreëerd waarmee (1) kan worden vastgelegd dat toegang tot patiëntgegevens plaatsvond als gevolg van het activeren van een spoedprotocol, en (2) bewijs van de gegeven spoed- of tijdelijke toestemming kan worden bewaard.

IHE heeft voor beide profielen. ATNA en BALP leggen als onderdeel van een auditeerbare gebeurtenis vast wie toegang had tot welke gegevens, wanneer en waarom. BPPC bewaart de toestemming van een patiënt die tijdens een spoedsituatie is gegeven of gebruikt.

Dat laatste leidt soms tot de vraag wie verantwoordelijk is voor het bewaren van de spoedtoestemming. Het lijkt logisch dat deze wordt opgeslagen door de zorgaanbieder die de patiënt voor spoedbehandeling heeft opgenomen. Maar het is net zo logisch om de toestemming te bewaren bij de zorgaanbieder van wie de gegevens zijn geraadpleegd. 

De IHE XUA- en IUA-profielen bieden hiervoor een voorziening. Beide bieden de mogelijkheid om — naast de PoU — een verwijzing naar een BPPC-document (toestemmingsdocument) op te nemen in het token dat wordt gedeeld. Een zorgaanbieder van wie gegevens worden opgevraagd, kan deze verwijzing gebruiken om het toestemmingsdocument op te halen en lokaal te bewaren als bewijs dat het opvragen van de patiëntinformatie gerechtvaardigd was.

Wat betekent dit voor een HIE-netwerk?

Het belangrijkste aspect van spoedtoegang tot patiëntgegevens is het creëren van vertrouwen tussen de deelnemers aan een HIE dat iedereen dezelfde toestemmingsregels — oftewel governance — volgt.

Wanneer raadplegers tijdelijke toestemming van een patiënt opvragen en gebruiken, moeten dossierhouders erop kunnen vertrouwen dat de juiste noodprocedures zijn gevolgd. Een HIE-governance kan bijvoorbeeld een toestemming van 48 uur definiëren en bepalen dat deze toestemming op verzoek van een dossierhouder beschikbaar moet zijn in het geval van een privacyaudit.

De governance kan ook de voorwaarden vastleggen waaraan voldaan moet worden voordat een toestemming van 48 uur gebruikt mag worden om toegangsregels voor niet-spoedeisende behandelingen te omzeilen. Daarnaast moet de governance bepalen welke PoU-codes als onderdeel van een verzoek om toegang tot gegevens worden meegestuurd en hoe gebruikers binnen het HIE-netwerk worden geïdentificeerd.

Hoe pakken we dit aan bij Founda?

Het Founda-platform ondersteunt de hierboven beschreven standaarden voor identiteit en toestemming volledig. Met dezelfde XUA- en IUA-standaarden wordt identiteitsinformatie van een gebruiker of systeem opgenomen in een beveiligd token en toegevoegd aan ieder verzoek van een raadpleger aan een dossierhouder.

Zie het als een raadpleger die een kopie van zijn paspoort of identiteitskaart bij het verzoek voegt, zodat de ontvanger kan controleren wie het verzoek doet.

Patiënttoestemming — permanent of tijdelijk, en ongeacht of deze door een raadpleger of dossierhouder wordt vastgelegd — wordt opgeslagen als een IHE Basic Patient Privacy Consent-document. Deze documenten leggen het antwoord van een patiënt op een toestemmingsvraag vast door te verwijzen naar de toestemmingsregels waarmee de patiënt heeft ingestemd.

Toestemmingsdocumenten kunnen net als ieder ander document worden gedeeld. De ontvanger van een verzoek om toegang tot gegevens kan het toestemmingsdocument daarom opvragen en beoordelen voordat toegang tot de beheerde gegevens wordt verleend — of geweigerd.

Tot slot is in het Founda Portal een break-the-glass-functionaliteit beschikbaar waarmee gebruikers kunnen aangeven dat onmiddellijke toegang noodzakelijk is. Bij het gebruik hiervan moet een gecodeerde purpose-of-use-reden worden ingevoerd.

Naast de reguliere auditing bevatten auditberichten die tijdens spoedtoegang worden gegenereerd ook deze door de gebruiker ingevoerde purpose-of-use-code. Hierdoor zijn dergelijke gebeurtenissen eenvoudig terug te vinden bij het analyseren van audit trails.

De afbeelding hieronder toont een voorbeeld van de break-the-glass-functie in het Founda Health Portal.

Toestemming die automatisch verloopt.

Het is ook mogelijk om de mogelijkheid voor een gebruiker om de purpose of use te wijzigen te koppelen aan een expliciete spoedtoestemming van de patiënt.

Dit is bijvoorbeeld relevant wanneer een patiënt bij opname in een ziekenhuis of op de spoedeisende hulp mondeling toestemming geeft. Een arts of verpleegkundige registreert deze toestemming, waarna automatisch een vervaldatum wordt toegevoegd — in Nederland wordt dit soms de 72-uurs-toestemming genoemd.

De break-the-glass-functie is vervolgens alleen beschikbaar zolang deze toestemming geldig is.

Hoe ziet dit er in de praktijk uit?.

Eerder dit jaar deed zich in Kreis Paderborn, Duitsland, een situatie voor waarbij een persoon met een verminderd bewustzijn, zonder familieleden of andere aanwezigen die informatie konden geven, zelf de hulpdiensten inschakelde. Toen de ambulance arriveerde, kon de patiënt belangrijke vragen over medicatie, allergieën of bestaande aandoeningen niet beantwoorden.

Omdat de patiënt zich eerder had aangemeld voor het regionale digitale gezondheidsplatform en toestemming had gegeven, kon het ambulanceteam relevante gezondheidsinformatie rechtstreeks vanuit de ambulance raadplegen, nog voordat de patiënt het ziekenhuis had bereikt.

Met die informatie kon het team de behandeling aanpassen en een beter onderbouwde keuze maken over welk ziekenhuis het meest geschikt was voor de zorg die de patiënt nodig had, in plaats van simpelweg naar het dichtstbijzijnde ziekenhuis te rijden.

Dat is het resultaat waar dit artikel naartoe werkt. Het oplossen van de wie, waarom en wat is geen oefening in toegangscontrole omwille van toegangscontrole. In dit geval betekende het dat een ambulanceteam op het juiste moment toegang had tot relevante informatie, zelfs toen de patiënt die informatie zelf niet kon geven.

De standaarden achter die uitwisseling — XUA en IUA voor identiteit, Purpose of Use voor context en ATNA, BALP en BPPC voor auditing en toestemming — zijn op zichzelf niet het doel. Hun waarde zit in het mogelijk maken van dit soort use cases binnen een consistent governancekader: vaststellen wie informatie opvraagt, waarom die informatie nodig is, waartoe iemand toegang mag krijgen en hoe die toegang wordt vastgelegd.

Voor iedere HIE die een model voor spoedtoegang ontwikkelt of opnieuw beoordeelt, zijn de use case en de bijbehorende governance-eisen daarom het uitgangspunt, niet de technologie. Bepaal wat er moet gebeuren wanneer een patiënt zelf geen informatie kan geven, wie toegang moet kunnen krijgen, onder welke omstandigheden dat mag en hoe die toegang moet worden beheerd en geaudit.

Van daaruit kunnen bestaande standaarden de technische basis bieden, zonder dat ieder netwerk zijn eigen aanpak vanaf nul hoeft te ontwerpen.

Het platform van Founda is gebouwd rondom deze standaarden en de praktijkgerichte use cases die ze moeten ondersteunen. Als je onderzoekt hoe toestemming en toegang binnen je eigen netwerk ingericht moeten worden, gaan we daar graag over in gesprek.