Push autorisatie (PA) is een zeer privacy-vriendelijke methode om patiëntgegevens uit te wisselen.

Om toegang te krijgen tot medische informatie zijn een aantal generieke functies nodig:

• autorisatie: wie mag en kan toegang krijgen tot welke gegevens?
• addressering: hoe kun je gegevens naar een persoon of organisatie(onderdeel) toesturen?
• lokalisatie: waar zijn gegevens op te halen?
• identificatie/authenticatie: wie probeert toegang te krijgen?

Vaak worden voor deze functies ‘voorzieningen’ gebouwd — centrale diensten die genoemde functies implementeren. Vaak wordt hierbij de zeggenschap (controle) over wie toegang krijgt tot welke gegevens verschoven naar de voorziening. Dit is onnodig en onwenselijk, vooral vanuit de vertrouwelijkheid van de arts-patiëntrelatie geredeneerd. Immers, vanuit de behandelrelatie en het beroepsgeheim gezien moeten de behandelend arts en de patiënt het laatste woord hebben over de ontsluiting van hun gegevens.

Via push autorisatie worden gegevens gericht beschikbaar gesteld binnen het zorgproces. Bij push autorisatie blijft de controle decentraal, bij de bron. Lokalisatie informatie wordt met een autorisatie meegestuurd, als deel van een push autorisatie URL (PA-URL) die naar een specifieke ontvanger wordt opgestuurd. De URL is uniek per autorisatie en kan slechts door één persoon (of organisatieEen dossier en dus een PA-URL mag alleen bevraagd worden door een persoon, onder meer door wettelijke eisen die voortkomen vanuit de EIDAS-2 wetgeving (zie Ontw. NEN 7519, 7520). Een autorisatie kan echter in een aantal situaties gekoppeld worden aan een identity management systeem van een geautoriseerde organisatie. Hierdoor kunnen na autorisatie van een organisatie verscchillende personen uit deze organisatie gegevens opvragen (mits voldoende aan voorwaarden zoals lidmaatschap van het behandelteam van de patiënt). Details zijn buiten scope voor deze PoC en inleiding. ) gebruikt worden om beschikbaar gestelde gegevens op te halen en in te zien.

Via deze methode worden gegevens gericht beschikbaar gesteld aan specifiek personen of organisaties die bij de behandleing betrokken zijn, in tegenstelling tot hoe beschikbaarheid van gegevens in veel uitwisselingssystemen in de zorg wordt georganiseerd (‘pull’ systemen, ongericht).

Naast het versturen van een PA-URL kan ook om een 6 of 7-cijferige autorisatiecode worden opgestuurd of met de patiënt worden meegegeven, die door een zorgverlener die deze code heeft ontvangen gebruikt kan worden om de een PA-URL op te halen en te bindenMerk op dat de beveiliging van push autorisatie URLs niet alléén op het beveiligd transport van PA-URLs rust. Binding informatie, policies en andere parameters worden ingeregeld aan de bron, op het moment van het aanmaken van een PA-URL. Aan de bron kunnen voor autorisatie relevante zaken worden ingeregeld, zoals bijvoorbeeld of een PIN moet worden opgegeven voordat gegevens kunnen worden opgehaald, een eigenschap die wordt toegepast bij het gebruik van autorisatiecodes. . Deze PA-URL kan vervolgens geopend worden om de gegevens van de patiënt op te halen. Niemand anders dan de ontvanger kan de PA-URL bevragen en de gegevens inzien. Voor meer informatie over binding en autorisatiecodes, zie verderop in dit artikel.

Uitgebreide beschrijvingen van de mogelijkheden die push autorisatie biedt zijn beschreven in een tweetal patenten. Deze patenten zijn overgedragen en onder beheer van Stichting Decozo gebracht met als doel het push autorisatie communicatiemodel als open standaard (onder FRAND termen) beschikbaar te stellen voor gebruikers. De governance afspraken met Decozo garanderen dat de privacy-beschermende eigenschappen op lange termijn gegarandeerd blijven. Voor meer informatie zie “Ontwikkeling van de standaard en rol Stichting Decozo” onderaan dit artikel.

1. Keep it simple stupid: eenvoud en consistentie

Het push autorisatie model is bewust eenvoudig, en gebaseerd op bestaande web technologie (HTTP, zie kader hierboven). De rationale achter het ontwerp is dat een URL of een code van 6 of 7 cijfers gemakkelijk in vrijwel elk zorgproces kan worden overgedragen, op elke mogelijke manier.

Een URL of een code is digitaal, schriftelijk en ook mondeling, telefonisch of op papier door te geven aan een andere zorgverlener. Dit maakt dat gericht beschikbaar stellen van gegevens vrijwel altijd en overal praktisch realiseerbaar is — zónder dat hiervoor een grootschalig uitwisselingssysteemHet is zeker denkbaar om met de push autorisatie standaard een centrale lokalisatie voorziening (index) te ontwikkelen, om te voorzien in situaties waar een systeem dat werkt als een EUS onontkoombaar is, zoals bijvoorbeeld bij een zogeheten “spoed-EUS”. Het voordeel van het gebruiken van PA-URLs in deze situatie is dat de ontvangende partij dan bij zowel gerichte als ongerichte beschikbaarheid van gegevens met hetzelfde (end-to-end beveiligde) URL gebaseerde mechanisme werkt om gegevens op te vragen. Dit bevordert schaalbaarheid. De ontwikkeling van een pull systeem met een variant van PA-URLs systemen is echter buiten scope van dit PoC/pilot project. met bijbehorende toestemmingsinfrastructuur hoeft te worden ingericht. Een patiënt kan ook zelf een (spoed)code meenemen, bijvoorbeeld via een App, via een kaartje in zijn portemonnee, of via een SOS-amulet.

Naast de toepassing voor gerichte gegevensuitwisseling is de onderliggende technologie ook breder toepasbaar. Zo kan een elektronisch uitwisselingssysteem worden ontworpen voor ongerichte toegang tot gegevens, dor middel van het uitgeven van URLs — uiteraard alleen met toestemming vooraf. Dit kan relevant zijn voor een landelijk systeem voor spoedsituaties. Een andere optie is dat een patiënt via een PGO (een persoonlijke gezondheids omgeving) of MGO, in een portaal of via een App zelf autorisaties kan aanmaken en codes kan geven aan zorgverleners of mantelzorgers die bij de zorg betrokken zijn.

Het voordeel van het gebruiken van PA-URLs in al deze situaties is dat de ontvangende partij altijd met dezelfde (end-to-end beveiligde) URL-gebaseerde technologie kan werken om gegevens op te vragen. Dit bevordert interoperabiliteit.

Zowel vanuit het zorgproces gezien als vanuit technisch perspectief gaat het adagium ‘keep it simple, stupid (KISS)’ dus op.

2. Positionering van push autorisatie in gegevensuitwisseling in de zorg

Push autorisatie positioneert zich nadrukkelijk als een alternatief voor (grootschalige) elektronische uitwisselingssystemen. Patiënten moeten hun eigen (private) afweging ten aanzien van risico’s voor de gezondheid jegens privacyrisico’s kunnen maken, en zelf kunnen beslissen of zij gegevens ongericht beschikbaar willen laten stellen voor zorgverleners of niet. Als patiënten beslissen dat zij dit niet willen, moet er een alternatief beschikbaar zijn.

Push autorisatie is een privacy-by-design methode waarin gegevens alleen gericht beschikbaar worden gesteld aan binnen het zorgproces bekende zorgverleners. Dit model bedient patiënten die niet wil dat hun gegevens breed beschikbaar worden gemaakt. En het bedient situaties/workflows waarin het niet nodig is om gegevens breed te delen, zoals bij verwijzing of het versturen van een recept.

Push autorisatie is uniek omdat het in staat is om óók in complexe, lange ketens van behandelend zorgaanbieders/zorgverleners gegevens beschikbaar te maken, ook wanneer dit niet aan de voorkant volledig voorspelbaar is wie deze zorgverleners zullen zijn. In dynamische ketens dus. Daarmee neemt push autorisatie een unieke positie in tussen enerzijds de grote, ingewikkelde, en in potentieel onveilige pull systemen, en de veel in de zorg toegepaste technieken om berichten op te sturen, push communicatie.

Om te zien hoe push autorisatie een rol kan spelen in de zorg, is het van belang om een aantal ‘prototypische’ zorgprocessen te beschouwen.

Onderstaande figuur illustreert de werking van push autorisatie voor een aantal zorgprocessen.

In figuur 1 zijn verschillende soorten zorgprocessen te zien.

• Boven de gestreepte lijn worden ‘reguliere’ zorgprocessen getoond – dit zijn processen die planbaar zijn en waarbij patiëntgegevens van zorgpartij naar zorgpartij worden overgedragen, bijvoorbeeld bij een verwijzing of het versturen van een recept.
• Onder de gestreepte lijn zijn spoedprocessen beschreven. Belangrijk is de huisartsenpost, die de ANW (avond, nacht en weeken) diensten overneemt van de huisarts. Als vervanger van de huisarts in de avonden en weekenden kan de huisartsenpost permanent geautoriseerd zijn voor de meeste patiënten (geen toestemming vereist onder de Wgbo), stap 4 . Vanuit deze rol kan de huisartsenpost diverse stappen in de spoedketen organiseren, zoals overdracht naar de spoedeisende hulp (SEH) of het uitsturen van een ambulance (stap 6). (Bij spoed is ongericht beschikbaar stellen van gegevens vaak niet nodig. Een aantal spoedprocessen zijn voor push autorisatie uitgewerkt in het programma Met Spoed Beschikbaar).
• Ten slotte kan ook de patiënt zelf een autorisatie uitgeven. Dit kan rechtstreeks via een PGO (stap 5), die via het MedMIJIdealiter kunnen in het MedMij stelsel vanuit een PGO niet alleen gegevens bij een bron opgehaald worden, maar ook push autorisatie URLs. Dit is heden nog niet het geval. De beschreven opties beschrijven wat de PA standaard mogelijk maakt. Dt is niet allemaal al gerealiseerd. stelsel gegevens kan opvragen bij een bron. Of via een autorisatiecode die de patiënt van de huisarts kan krijgen of via een patiëntenportaal of een PGO kan aanmaken.

3. Binding

Een kern-eigenschap van push autorisatie is dat elke PA-URL uniek is — elke PA-URL bevat een uniek nummer — en dat deze specifiek aan één zorgverlener of zorgaanbieder gebonden moet zijn.

Binding is een proces waarmee een PA-URL gekoppeld wordt aan de identiteit van een gebruiker (persoon of organisatie), die deze PA-URL voor een voor deze binding te bepalen set acties mag gebruiken. Binding kan plaatsvinden bij het aanmaken van de PA-URL (pre-binding) of on first use (late binding). Als een PA-URL eenmaal gebonden is, kan deze niet ook of alsnog aan een andere entiteit gekoppeld worden.

4. Doorautoriseren

Een voor toepassing in de zorg cruciale eigenschap van push autorisatie is dat een gebonden partij met een PA-URL een nieuwe autorisatie-URL kan ophalen bij de bron.

Zo kan een gebonden Binding zorgt ervoor dat externe partijen (zorgaanbieders/zorgverleners) die niet bij de behandeling van een patiënt betrokken zijn, “zichzelf” niet kunnen autoriseren, ook niet als zij via een inbraak een PA-URL bemachtigen. gebruiker een doorautorisatie-URL aanvragen en deze uitgeven aan een andere partij die deze gegevens nodig heeft. Zo kan bij een spoedverwijzing een autorisatie die verwijst naar het huisartsendossier worden doorgezet vanuit de huisartsenpost naar de SEH.

Een aangevraagde URL is een gewone PA-URL. Deze kan pre-bound zijn als de ontvanger ten tijde van het aanvragen bekend is, of late-bound als de ontvanger niet precies bekend is. Binding kan in dat geval plaatsvinden door iemand die een autorisatiecode via de telefoon heeft ontvangen. De bron ziet zowel de autorisatiestap (en wie dat doet) als degene die gebonden wordt.

Flexibiliteit binnen het zorgproces is een van de ontwerpcriteria voor push autorisatie. De mogelijkheid tot doorautoriseren zorgt ervoor dat de toegang het zorgproces als het ware kan volgen.

Dit wordt in figuur 2 uitgebeeld:

De grijze lijnen tussen de blokjes (van bronhouder naar partij 1, naar partij 2 etc.) laten de “logische” doorautorisatie-stappen zien. Onder de blokjes wordt de uitgifte van de individuele ‘sleuteltjes’ (PA-URLs) per partij getoond die per stap worden uitgegeven en waarmee de bron kan worden bevraagd (blauwe lijnen.

Bij iedere stap in het zorgproces wordt door de zorgverlener die wil gaan doorautoriseren aangegeven dat informatie wordt ‘doorgezet’ naar de volgende partij in de keten. Daarbij kan de patiënt bezwaar maken tegen de overdracht van de gegevens / autorisatie. De patiënt en de bronhouder kunnen achteraf altijd achterhalen wie een doorautorisatie heeft aangemaakt of gebruikt. Deze kunnen ook ingetrokken worden.

5. Voorbeelden

Voorbeeld: doorzetten van medicatie in de zorgketen

1. Bij een verwijzing stuurt een huisarts een verwijsbrief op naar een specialist. De huisarts schrijft in de verwijsbrief gegevens die relevant zijn voor de specialist, en voegt daaraan een PA-URL toe. Deze wijst bijvoorbeeld naar het medicatie-overzicht die de huisarts in zijn dossier heeft. De specialist ontvangt de verwijsbrief en maakt een afspraak met patiënt. Als de patiënt langskomt (dit kan enkele weken later zijn), kan de specialist via de PA-URL het actuele medicatieoverzicht ophalen bij de huisarts.
2. De specialist komt tot de ontdekking dat de patiënt iets heeft dat een andere specialist beter kan behandelen. De specialist maakt een nieuwe verwijzing naar een andere specialist in een andere zorginstelling. De verwijsbrief bevat een samenvatting van de oorspronkelijke klachten, de nieuwe bevindingen, en de reden voor verwijzen. Met patiënt wordt besproken dat de medicatiegegevens van de huisarts beschikbaar worden gemaakt voor de specialist waarnaar verwezen wordt (veronderstelde toestemming).
3. Bij (impliciet) akkoord van de patiënt vraagt de specialist via de PA-URL van de huisarts een nieuwe PA-URL of een autorisatiecodeDe autorisatiecode wordt aangevraagd door de specialist, en vervolgens aangemaakt door het huisartssysteem die de code gebruikt om via een cryptografische procedure een eenmalige, unieke pseudoniem aan te maken die wordt gebruikt om de late-bound, gepseudonimiseerde URL vindbaar te maken. Het pseudoniem kan alleen gereprocudeerd worden door degene die zowel het BSN van de patiënt als de autorisatiecode kent (de ontvanger van de autorisatiecode dus). De autorisatiecode wordt na het ophalen van de URL door de ontvanger als een one-time password / PIN meegegeven met het verzoek om gegevens dat via de nieuwe URL wordt gedaan; pas als de autorisatiecode klopt zal het bronsysteem de PA-URL binden aan de geauthenticeerde gebruiker. In de documentatie van de standaard zal deze procedure nader worden geprecisieerd. aan bij de bron, en plaatst deze in de verwijsbrief die opgestuurd wordt naar de volgende specialist. Met de direct of indirect (via een code) doorgestuurde doorautorisatie-URL kan de tweede specialist actuele medicatiegegevens ophalen, end-to-end beveiligd, rechtstreeks bij de huisarts.
4. De specialist schrijft op een later moment medicatie voor voor de patiënt, en stuurt een recept op naar de apotheek. Hiermee kan de apotheek de medicatielijst bij de huisarts ophalen en controleren als onderdeel van de medicatieverstrekking. Merk op dat de opgevraagde informatie altijd actueel is, omdat het brondossier direct bevraagd wordt op het moment dat de informatie nodig is.

Aanvullend op bovenstaande kan ook een doorautorisatie voor het medicatie-overzicht van een apotheek worden meegestuurd in de verwijsketen. Dit kan als de apotheek met de huisarts is verbonden door de huisarts een (doorautoriseerbare) PA-URL te sturen.

Voor de eenvoud van expositie is dit hierboven niet besproken, maar deze extra bron kan in figuur 1 links van ‘bron’ getekend worden. Precies dit proces zal gedemonstreerd worden als PoC, om de bruikbaar van push autorisatie voor het medicatieproces aan te tonen.

Een andere mogelijke demonstrator voor het doorsturen van een autorisatie die ook past bij het medicatieproces is het in een recept opnemen van een autorisatiecode, receptcode genoemd. Bij gebruikk van een papieren recept kan een browser gebruikt worden en om de PA-URL met de autorisatiecode te openen, direct in een browser met een UZI pas.

Voorbeeld 2: doorsturen van beelden

Een eenvoudiger voorbeeld voor het gebruik van push autorisatie is het doorsturen van een beeld (of een set beelden met een verslag) vanuit ziekenhuis A naar ziekenhuis B. Hiermee kan gedemonstreerd worden dat beelden volledig decentraal kunnen worden doorgezet tussen ziekenhuizen, met behulp van een autorisatiecode. We kunnen dit zien als als alternatief voor het Twiin portaal. Deze usecase is onderzocht als onderdeel van het Twiin onderzoek naar push autorisatie.

Bij beeldbeschikbaarheid is het interessant om een index met beelden bij te houden bij de huisarts, zodat de toegang tot relevante historische beelden en verslagen georganiseerd kan worden door de huisarts bij het maken van een verwijzing. Zie voor het idee hierachter de paragraaf ‘huisarts als indexbewaker’ (UC2).

Dit voorbeeld is besproken als onderdeel van de PoCs; het implementeren van een beeld-index bij de huisarts is voorlopig geparkeerd om praktische redenen (beschikbaarheid partner leveranciers).

6. Te toetsen onderdelen

De basisconcepten voor de flows hierboven zijn voor een deel geïmplementeerd. Zo bestaat er reeds een koppeling tussen huisarts en huisartsenpost in het Whitebox systeem, wat vanuit een eerdere beproeving heden in productie draait in Amsterdam en Maastricht (zie https://whiteboxsystems.nl/pilot-resultaten).

Er is ook al een doorautorisatiemechanisme geïmplementeerd in het HAP systeem van Topicus. Hiermee kan vanuit het scherm dat inzage geeft in het huisartsendossier, een huisarts op de HAP een autorisatiecode aanmaken die kan worden doorgezet naar de SEH of naar een ambulance. Dit is nog niet in de praktijk getest; de bedoeling is dit in de context van PoC 5 of in een vervolg-pilot te doen.

Wat nog niet bestaat, is een mechanisme voor het versturen van sets van referenties (PA-URLs), die verwijzen naar meerdere bronnen. Dit kan werken via een zogeheten Lokalisatie structuur in lijn met de NEN norm lokalisatie, NEN7519. Een minimal viable PoC van een lokalisatiestructuur zal in de PoC medicatieoverdracht (UC1) worden geïmplementeerd.

Wat ook nog niet bestaat, is een implementatie van een decentrale index van PA-URLs naar verschillende bronnen, die door een huisarts als onderdeel van het huisarts informatie systeem (HIS) kan worden bijgehouden. De reden heirvan wordt in de volgende paragraaf besproken.

7. De huisarts als indexbewaker

In het push autorisatie raamwerk is een belangrijke rol voor de huisarts weggelegd. De huisarts kan hierbij de rol krijgen van ‘indexbewaker’. In onze visie wordt de huisarts bijna automatisch de houder van een decentrale index die wordt bijgehouden als onderdeel van het huisartssysteem. Deze index staat los van een eventuele centrale index die voor landelijke uitwisseling wordt gebruikt – hij is nadrukkelijk bedoeld voor gebruik door de huisarts, als onderdeel van diens bestaande takenpakket.

Deze rol klinkt mogelijk zwaarder en verantwoordelijker dan hij is.

De huisarts krijgt nu al veel informatie van andere zorgverleners, zoals ontslagbrieven van specialisten of retourberichten van de huisartsenpost of afschriften van verstrekkingen van medicatie door een apotheek. Deze legt de huisarts vast in diens informatiesysteem, meestal gegroepeerd onder Episodes, hoofdstukaanduidingen die de huisarts aan bepaalde medische gebeurtenissen in het leven van een patiënt toekent.

De huisarts heeft hierdoor – als poortwachter en als enige arts met een permanente behandelrelatie met de patiënt – een uniek overzicht over de medische historie van diens patiënten.

Bij elke episodes kunnen referenties naar bronnen (PA-URLs) worden vastgelegd. Dit kan veelal geautomatiseerd gebeuren omdat de PA-URLs meegestuurd waren met bijvoorbeeld een ontslagbrief. Een PA-URL kan daardoor meestal onder dezelfde episode alsde ontslagbrief worden gecategoriseerd.

De huisarts is vervolgens ‘indexbewaker’ zoals deze nu ook ‘dossierbewaker’ is. Bij het maken van een verwijsbrief maakt de huisarts een selectie van informatie (episodes) die relevant kunnen zijn voor de ontvanger. Door de koppeling met de episodes kunnen PA-URLs geautomatiseerd ook als (door)autorisaties in de verwijsbrief opgenomen worden.

In eerste instantie zullen we het concept van een decentrale index bij de huisarts alleen beproeven met autorisaties tot medicatie-informatie van de eigen apotheek. Deze informatie kan in feite altijd mee bij een verwijzing zonder dat hiervoor een categoriseringop basis van Episodes nodig is. Vervolgens onderzoeken we of we een uitbreiding van de PoC kunnen realiseren die (geautomatiseerde) registratie, categorisering en inclusie van PA-URLs op basis van Episodes toetst.

Dit kan bijvoorbeeld in een vervolg-PoC worden beproefd voor PA-URLs die naar beelden van ziekenhuizen of van verloskundigen (echo’s) wijzen, bijvoorbeeld.

De combinatie van inclusie van medicatieinformatie en beelden is een relevant voorbeeld van het gebruik van een lokalisatie structuur conform het informatiemodel van de NEN7519, als ‘drager’ voor het opsturen van sets van PA-URLs met verschillende documenttypen (LDS-typen: medicatie, beelden).

8. Uitwerking use cases voor de PoCs

De volgende twee usecases beschrijven deze voorbeelden (usecases).

UC1: Huisarts als indexbewaker: usecase “medicatie-index”

In voorbeeld 1 hierboven wordt het medicatiedossier van de huisarts ontsloten – de medicatie-voorschrijfhistorie. In de dagelijkse zorgpraktijk is het echter van belang om niet alleen het medicatiedossier van de huisarts, maar tenminste óók het medicatiedossier van de eigen apotheek beschikbaar te hebben. Dit omdat deze de verstrekkingshistorie (voorzover bekend bij die apotheker) bevat, wat van belang is voor de medicatiecontroleTen behoeve van medicatiecontrole kan op basis van de combinatie van voorschrijfhistorie van de eigen huisarts en verstrekkingsinformatie van de apotheek een vergelijking gemaakt worden tussen de informatie in het huisarts en het apotheeksysteem. Op basis basis hiervan kunnen deze twee bronnen desgewnst ook ‘gelijk getrokken’ kunnen worden. bij het voorschrijven van medicatie.

In fase 1 van het project willen we de keten daarom doortrekken, en zorgen dat de huisarts – via een ‘postbusAlternatief kan de huisarts zelf eerst een PA-URL naar de apotheker sturen om deze te autoriseren voor toegang tot diens voorschrijfhistorie (met behulp van een autorisatiecode via de patiënt en/of via een recept). Hierna kan de apotheek vervolgens een autorisatie naar de huisarts ’terugsturen’ via de PA-URL die de huisarts uitstuurde (dit wordt pushback genoemd). ‘ – een autorisatie van de apotheker krijgt waarmee de huisarts toegang krijgt tot de verstrekkingsinformatie van de (eigen) apotheek.

De huisarts kan met behulp van de PA-URL van de apotheek een doorautorisatie-URL maken en deze, samen met een PA-URL die naar het eigen medicatieoverzicht wijst, in een eenvoudige versie van een lokalisatie structuur plaatsen en de autorisatie naar deze structuur doorsturen naar een specialist. Zo kan de ontvanger van de verwijsbrief naast het medicatieoverzicht van de huisarts ook bij het medicatieoverzicht van de apotheek.

UC2: Huisarts als indexbewaker: usecase “beeld-index”

Een huisarts kan meerdere soorten autorisaties bijhouden in diens index. Via de PA-URLs kunnen de bronnen die in deze index geregistreerd staan ook voor de huisarts zelf inzichtelijk gemaakt worden.

De ‘huisarts-index’ is een intern en/of extern adresseerbaar write-only register. Partijen zoals ziekenhuizen gebruiken nu al adressering om ontslagbrieven naartoe te sturen. Een huisarts kan een endpoint aanbieden waar PA-URLs kunnen worden ingeschoten onder een identifier die geautomatiseerd koppelbaar is aan bijvoorbeeld een ontslagbrief (vanwege eerdergenoemde episodekoppeling). Van belang is dat een adresserings- en authenticatiefunctie wordt gebruikt waarmee de verzender van een PA-URL zeker weet dat de juiste huisarts de autorisatie krijgt.

Alternatief kan het huisartssysteem de autorisatiecode uit een verwijsbrief halen en deze, na invoeren in het systeem, in het register plaatsen. Dit kan bijvoorbeeld gaan om PA-URLs die verwijzen naar een radiologisch beeld, een radiologisch verslag, of een (concept) ontslagbrief. Vergelijkbaar kunnen autorisaties naar medicatiegevens uit recepten worden gehaald en in de index geplaatst worden.

Via een user interfaceVia de user interface kan een huisarts kan binnengekomen PA-URLs (bronnen) categoriseren op episode, en bij het doorautoriseren zoeken op bepaalde documenttypen (zoals “beeld”), of een episodenaam of ICPC code, en vervolgens een lokalisatiestructuur vullen met kopieën van PA-URLs die naar deze bronnen verwijzen. Een PA-URL die verwijst naar deze lokalisatiestructuur kan worden opgestuurd naar een andere zorgverlener. die Whitebox biedt kan de huisarts ook direct op de index zoeken. Zo kan de huisarts een tijdlijn doorzoeken om specifieke relevante beelden (URLs die wijzen naar radiologisch verslagen en image studies) of medicatieoverzichten in te zien. Deze kunnen ook geïncludeerd worden in een lokalisatiestructuur die kan wordem meegestuurd met een verwijsbrief. Deze UI kan helpen bij het beproeven en illustreren van het concept in de PoC fase.

9. Techniek: de werking van “indexloze” gegevensuitwisseling

Een belangrijke eigenschap van push autorisatie is dat lokalisatie informatie én autorisatie gekoppeld zijn inéén PA-URL, die direct via de keten direct naar de betrokken zorgverlener wordt gestuurd. Zo kan lokalisatie uitgewisseld worden van bron naar ontvanger/opvrager, zónder dat hier een centrale (gemeenschappelijke) index voor nodig is.

Alleen de verzender en de ontvanger van een push autorisatie URL (PA-URL) weten zo dat er gegevens beschikbaar zijn gesteld en waar die zich bevinden. Er zit géén index voor lokalisatie of ‘broker’ tussen.

Gegevens kunnen alleen worden opgehaald via een PA-URL met een identificatiemiddel op EIDAS niveau hoog (bijvoorbeeld, een UZI pas) en een geschikte rolcode, die overeenkomt met een beveiligings-policy aan de bron gedefinieerd wordt. In deze (decentrale) policy wordt gedefinieerd welk type ontvanger (welke rol) welke gegevens kan inzien. Zo kan de verzender (de bronhouder) precies controleren wie welke gegevens mag ophalen via een PA-URL.

Het ophalen van gegevens is end-to-end beveiligd, en aan de bron wordt gelogd wie welke gegevens op welk moment heeft opgehaald, en wie welke doorautorisatie heeft aangevraagd. Dat maakt de techniek zeer veilig en controleerbaar voor bronhouder en patiënt.

URL schema

De push autorisatie specificatieDe specificatie zal binnenkort beschikbaar komen en nader uitgewerkt worden gedurende de PoC/pilots.Het kan zijn dat blijkt dat voor de pilot aanvullende eigenschappen nodig zullen zijn (bijv. een deferred-copyable property) beschrijft in detail wat de velden zijn om te beschrijven hoe lang een autorisatielink (PA-URL) geldig is, wat voor soort gegevens via de link opvraagbaar of verstuurbaar zijn, wat de beveiligingseigenschappen van de URL zijn en en welke acties er naast inzage nog meer mogelijk zijn.

Concreet bevat een PA-URL een aantal velden in een voorgedefiniëerd format, zoals:

• welke soort (type) documenten via deze URL kan worden opgehaald
• wat voor type document(en) er kan worden opgestuurd naar de bron
• of een PIN-code nodig is om een document te openen/binden
• hoelang het brondossier en de URL beschikbaar en geldig is.
• De naam van de policy die bepaalt welke personen in het zorgproces een URL kunnen aanvragen en doorzetten (doorautoriseren).

Een PA-URL is self-describing. De codering van al deze gegevens in één URL (schema) maakt de URL self-contained, wat de verwerking van de PA-URLs vereenvoudigd.

De PA-URL interface (HTTP methods)

Omdat push autorisatie werkt met URLs voor lokalisatie en autorisatie, bestaan de basis-operaties op push autorirsatie uit HTTP calls. De basis-operaties op een PA-URL zijn deze:

GET	Haal document op (voorbehouden binding en juiste authenticatie middel/identiteit)
POST	Maak een kopie-URL of een autorisatiecode aan, of stuur een bericht naar de bron (pushback)

In de praktijk worden deze calls zelden direct aangeroepen door een applicatie; meestal worden deze calls aangeroepen via een library of middleware component die een abstractielaag biedt bovenop deze calls. Dit is ook het geval bij de Whitebox implementatie van het push autorisatie model. Er zijn echter situaties waarin het direct aanroepen van de PA-URLs zinvol is, zoals wanneer een web (HTML) rendering van een document nodig is.

GET doet wat het suggereert: het maakt het mogelijk om een dossier op te halen. Als GET wordt aangeroepen vanuit een web browser wordt een HTML renderingAls een document in HTML gerenderd wordt, kan deze voorzien worden van invulvelden voor terugkoppeling (pushback) van informatie en voor het aanmaken van een autorisatiecode via POST methods. Dit kan ook relevant zijn wanneer een document gerenderd wordt in een iframe in een webgebaseerde applicatie. van het dossier gepresenteerd; in andere gevallen kan het dossier in een specifiek formaat worden opgeleverd (bijv. MEDEUR of HL7v3).

Authenticatie vindt plaats door middel van sessie-authenticatie (mutual TLS), maar het is ook mogelijk om een token mee te geven met de web call – bijvoorbeeld een JSON (web)token dat is ondertekend met een UZI pas (dmv SafeSign of ZorgID).

De push autorisatie middleware De Whitebox is een voorbeeld van push autorisatie middleware. In het project zullen stappen gezet worden om een (open source) Whitebox te realiseren, die geïntegreerd kan worden in uiteenlopende XIS systemen. kan gezien worden als een specifiek soort autorisatie server met een aantal functies waarmee in zorg-workflows autorisatie georkestreerd kan worden, waarmee één of meer partijen een PA-URL ontvangen en daarmee geautoriseerd zijn. Het resultaat van het gebruik van een PA-URL kan zijn dat informatie als HTML of in een gestructureerd formaat – bijv. in HL7 – door de PA-URL wordt teruggegeven; alternatief kan de push autorisatie component als een soort OAuth server functioneren waarbij een bevraagde PA-URL een endpoint en een access token teruggeeft waarmee een client applicatie een brondossier kan bevragen; dit is bijvoorbeeld zinvol als de bron een FHIR server is die gequeried moet worden vanuit een specifieke client applicatie.

POST wordt gebruikt voor meerdere functies. POST krijgt een json struct mee die beschrijft welke actie uitgevoerd moet worden: het maken van een kopie-URL het opsturen van gegevens (pushback), of het aanmaken en teruggeven van een autorisatiecode. Deze functies worden voor het project gespecificeerd.

Als een reguliere applicatie (back-end of front-end) gebruik wil maken van PA-URLs kan dat via bovengenoemde URLs, waarbij normaal gesproken gebruik gemaakt zal worden van token authenticatie. Veelal echter zal een applicatie gebruik maken van een middleware systeem met een API die het gebruik van URLs grotendeels wegabstraheert. Whitebox Systems stelt hiervoor een applicatie beschikbaar de Dienstverlener Push Autorsatie / Recipient oftewel DVPA-r.Heden is deze component geïntegreerd in een software product van Whitebox Systems, de Hapbox. Tijdens deze pilot zal Whitebox samen met stichting Decozo werken aan een open source DVPA-r component die getest/getoetst kan worden in de PoC. De DVPA-r API is beschreven op https://docs.mcsr.nl/dvpa-r/docs .

10. Systeem componenten

Voor integratie en gebruik van PA-URLs in systemen van zorgverleners, zijn een aantal koppelvlakken (API’s) gedefinieerd.

In Figuur 3 worden een aantal koppelvlakken / interfaces benoemd die in de PoCs nodig zijn. Niet al deze interfaces bestaan al. Een globale beschrijving van de functie van de interfaces staat onder de figuur.

Voor een beschrijving van de koppelvlakken zie https://docs.google.com/ … (vraag toegang via link).

11. Aanvullende informatie

De rol van de burger

Push autorisaties (PA-URLs) kunnen niet alleen met een zorgpartij worden uitgewisseld, maar ook met de patiënt.

In Nederland bestaat sinds 2018 het MedMij initiatief, waarin zogeheten Persoonlijke Gezondheids Omgevingen (PGO’s) zijn ontwikkeld waarin patiënten medische gegevens kunnen ophalen bij verschillende bronnen, en deze gegevens kunnen opslaan en beheren. Ook kunnen zij zelf gegevens (zoals zelfmetingen) opslaan in hun PGO.

Behalve de medische gegevens zelf, kunnen PGO’s ook in theorie PA-URLs ophalen bij verschillende bronnen, die kunnen worden opgeslagen in het PGO. Zie stap 5 in figuur 1.

Het autoriseren van een PGO via een PA-URL in plaats van het ophalen en opslaan van gegevens in een PGO heeft als voordeel dat het PGO geen medische gegevens hoeft op te slaan, maar belangrijker: een patiënt kan zo via een PGO een nieuwe PA-URL of een autorisatiecode aanvragen bij de bron en deze doorzetten (doorsturen) naar een zorgaanbieder. Deze zorgaanbieder kan zo, met deze PA-URL, de brongegevens rechtstreeks ophalen bij de oorspronkelijke bron, in plaats dat de zorgaanbieder gegevens krijgt of ophaalt bij of via het PGO, dat diverse nadelen heeft.

Een voordeel van deze aanpak is dat zorgaanbieders geen apart technisch protocol hoeven te implementeren voor het bevragen van een PGO. Een autorisatie die via een PGO is ontvangen wijst naar dezelfde bron en kent hetzelfde formaat en dezelfde technsiche specificatie als een PA-URL die rechtstreeks van een andere zorgverlener is ontvangen.

NB: soortgelijke functionaliteit kan ook via gezondheids-Apps, een MGO en via patiëntenportalen van artsen/XISsen geboden worden.

Ontwikkeling van de standaard en de rol van Stichting Decozo

De push autorisatie is een dynamische, decentraal beheerde communicatiestandaard. Deze is gebaseerd op wijd verbreide en algemeen toegepaste web (w3c) standaarden, en daarom snel en eenvoudig toepasbaar – zelfs in een gewone browser en óók in het buitenland, mits er een afdoende sterke identificatie middel beschikbaar is. Bijvoorbeeld de UZI pas of een ander modern identificatiemiddel voor zorgverleners.

De standaard is oorspronkelijk ontwikkeld door Whitebox Systems (een spin-out van de Universteit van Amsterdam) en getest in pilots en verschillende proof-of-concept beproevingen. Het systeem wordt in productie gebruikt in Amsterdam en Maastricht. Zie voor meer informatie https://whiteboxsystems.nl/pilot-resultaten.

Alle eigendomsrechten van de standaard zijn in 2024 overgedragen naar Stichting Decozo, met als nadrukkelijk doel om deze door Decozo als open, privacybeschermende standaard te laten beheren zodat de hele zorg hier beter van wordt – en natuurlijk, zodat de privacy van burgers in de zorg optimaal beschermd wordt.

De eigendomsrechten en de rol van Decozo hangen samen met de volgende aspecten:

• Push autorisatie is vormgegeven via een URL schema. De basis elementen van dit schema – en daarmee de capabilities van het model worden via Decozo gestandaardiseerd.
• Het autorisatiecode systeem (ook wel spoedcode of verwijscode genoemd) vereist een centrale server die alleen anonieme (gepseudonimiseerde) gegevens verwerkt, waarvan het adres kenbaar is. Stichting Decozo zal deze servers hosten.
• Decozo zal een rol spelen in het organiseren van bijeenkomsten en communities rond het standaardiseren van policies op basis van modellering van (specifieke) relevante zorgprocessen samen met stakeholders en met inbreng van burgerrechtenorganisaties.

De organisatie en de effectiviteit van het governance model van Decozo zullen de komende periode beproefd worden. Decozo zal de PoCs/pilots in dit project ondersteunen door middel van standaardisatie activiteiten, en door de in deze pilot ontwikkelde protocollen en processen te evalueren en te testen.

De specificaties voor het push autorisatie mechanisme (PA-URL schema’s, opties en werking) en voor spoedcodes/autorisatiecodes zullen via de site van Decozo beschikbaar worden gesteld.

Lost & foundAutorisaties kunnen, als PA-URLs of autorisatiecodes, in vrijwel alle bestaande workflows (bijv. voor verwijzing of receptenverkeer) worden meegenomen. Er zijn veel situaties in de zorg waarin flexibiliteit (bijv. van keuze van zorgverlener) wenselijk is, of zelfs een formele vereiste – denk bijvoorbeeld aan keuzevrijheid mbt verstrekkingen van medicatie (vrijheid van apotheekkeuze). Daarvoor biedt push autorisatie met gebruik van late binding een oplossing. Tegelijkertijd kan het model ook prima functioneren in situaties waar statische autorisaties nodig zijn en de ontvanger op voorhand bekend is, zoals bij het (permanent) autoriseren van de huisartsenpost door de huisarts. In zo’n geval kan een pre-bound URL worden ‘ingeschoten’ bij een zorgaanbieder. Nota bene: het push autorisatie model kent vele parameters die heel precies kunnen worden ingeregeld om risico’s die samenhangen met het gebruik van late-bound URLs zo goed mogelijk te mitigeren, los van beveiliging van het ’transport’ van de PA-URLs en de basis-beveiliging van het gebruik van UZI middelen zoals UZI passen en mTLS. Denk aan het gebruik van PIN-codes (autorisatiecodes) die de patiënt meedraagt, of een beperkte maximale geldigheidsduur waarbinnen een ongebonden URL gebonden moet worden, anders verloopt deze. Ook kan worden ingeperkt wie (met welke rol) mag doorautoriseren, en welk type zorgverlener (rolcode) een specifieke PA-URL mag binden/gebruiken. De trade-offs die gelden bij het inregelen van de parameters zijn afhankelijk van de context van gebruik; het vaststellen van bruikbare en passende policies – afhankelijk van de usecase – is onderdeel van de PoC….URLs kunnen zelfs geopend worden in een browser, er vanuit gaande dat de een identificatie/authenticatiemiddel op niveau Hoog gebruikt wordt, zoals een UZI pas of een wallet in lijn met EIDAS-2. Dit maakt integratie in zeer uiteenlopende systemen mogelijk.