Identificatie en authenticatie van de patiënt

Bij het uitwisselen van medische gegevens van patiënten geldt dat de identiteit van de patiënt die als natuurlijk persoon, verzorgd of behandeld wordt, of als auteur of betrokkene gegevens verwerkt, zeker gesteld dient te zijn. Ook dient het BSN van de patiënt geverifieerd te zijn, voordat het gebruikt wordt in de gegevensregistratie. Hiervoor biedt het CIBG een ondersteunende faciliteit: Sectorale Berichtenvoorziening in de Zorg (SBV-Z). Deze diensten zijn beschikbaar voor zorgverleners die zich kunnen authenticeren met een UZI-pas. De SBV-Z diensten ondersteunen bij het vaststellen van de identiteit en het koppelen van persoonsgegevens aan het juiste BSN.

Het vaststellen van de identiteit dient altijd plaats te vinden op basis van de WID (Wettelijk Identiteitsdocument)-controle: het controleren of de patiënt een WID bij zich heeft, dat hoort bij die persoon (bijvoorbeeld op basis van foto, geslacht, leeftijd) tijdens een face-to-face controle. Daarnaast dient de zorgverlener te verifiëren dat het een geldig WID is (echtheidskenmerken en/of check op geldigheid via register (niet verlopen/gestolen) zoals SBV-Z of de BRP. Indien een patiënt herkend wordt die al eerder langs is geweest waarbij er een WID-controle is gedaan spreekt men van vergewissen. Een derde mogelijkheid betreft het stellen van een aantal vragen die alleen die patiënt kan beantwoorden, bijvoorbeeld bij telefonische triage. Het gaat om voor- en achternaam, geboortedatum, postcode en huisnummer. Dit levert echter geen identificatie op en mag daarom alleen tijdelijk gebruikt worden waarbij in de communicatie het ontbreken van identificatie vermeld dient te worden (conform onder het onder de WABVPZ hangende 'Besluit gebruik burgerservicenummer in de zorg'. Artikel 29 gaat over verlenen van zorg per telefoon of elektronisch bericht. In ditzelfde artikel wordt geregeld dat gegevens over een pasgeborene mogen worden uitgewisseld o.b.v. het BSN van de moeder).

Na het vaststellen van de identiteit volgt de stap om het BSN van de patiënt te verifiëren, alvorens het gebruikt mag worden in de gegevensregistratie. Dat kan door het BSN te verkrijgen of valideren uit een daartoe aangewezen register (bv. SBV-Z of BRP) op basis van attributen zoals achternaam, woonplaats en adres. Als dat niet eenduidig is (bv bij tweelingen) dient het verkregen BSN vergeleken te worden met het BSN op het WID.

Voor ontvangers van gegevens geldt dat - tenzij anders aangegeven - ervan uitgegaan mag worden dat de zorgaanbieder die gegevens aanlevert een geverifieerd BSN meegeeft (het had anders immers vermeld moeten worden). Op basis daarvan kunnen aanvullende gegevens opgevraagd worden (als de patiënt met dat BSN daar de benodigde toestemming voor gegeven heeft waarmee de dossierhouder(s) de gegevens beschikbaar mag stellen). Het BSN (en de via dit BSN verkregen gegevens) mag pas in de eigen administratie worden overgenomen indien de zorgaanbieder de identiteit zelf heeft vastgesteld en het BSN overeenkomt. Een andere mogelijkheid is het BSN te verkrijgen uit een identificatie- of authenticatiemiddel voor het BSN-domein, zoals het overnemen/uitlezen van het rijbewijs of paspoort of DigiD login.

De betreffende functionaliteiten van SBV-Z die gebruikt kunnen worden zijn:

'Controle identiteitsdocument': de zorgaanbieder kan met deze functie opvragen of het getoonde identiteitsdocument in omloop mag zijn.
BSN opvragen: een zorgaanbieder kan op basis van een aantal persoonsgegevens het BSN van een persoon opvragen.
BSN verifiëren: een zorgaanbieder kan de vraag stellen of de persoonsgegevens en het BSN inderdaad bij elkaar horen.
Opvragen persoonsgegevens: een zorgaanbieder kan op basis van een BSN de bijbehorende persoonsgegevens opvragen. Deze dienst kan bijvoorbeeld gebruikt worden om in geval van twijfel bij een BSN- opvraging of verificatie een extra controle uit te voeren.
Initiële vulling: hiermee kunnen zorgaanbieders hun hele patiëntenadministratie voorzien van BSN's.

Identificatie en authenticatie van zorgaanbieders en zorgverleners

Bij het uitwisselen van medische gegevens dient de identiteit van de zorgaanbieder geverifieerd te zijn. Dat kan door het vaststellen van een onweerlegbare zorgaanbieder identiteit. Binnen AORTA is gekozen voor validatie tegen publiek UZI-server certificaat met daarin het URA uitgegeven door UZI-register.

Daarnaast dient de identiteit van de (verantwoordelijke) zorgverlener die gegevens verstuurt of opvraagt, geverifieerd te zijn. Binnen AORTA is gekozen voor realisatie van het vertrouwensniveau EIDAS hoog, waarbij een unieke identiteit wordt gebruikt die door anderen te verifiëren is op basis van het UZI nummer. Deze identiteit wordt geauthentiseerd door het gebruik van de private sleutel op een UZI-pas waarmee de verbinding wordt opgezet of de interactie wordt ondertekend.

Het gebruik van de UZI-pas kan beperkt worden door gebruik te maken van AORTA tokens. Met de AORTA tokens wordt het mogelijk om al bestaande functionaliteit (zoals gebruikt bij het postdateren), namelijk de ontkoppeling tussen het moment van ondertekenen en het uitvoeren van een transactie, breder in te zetten. Hiervoor is een nieuw begrip geïntroduceerd: "de conditionele query". Een conditionele query is een query die onder bepaalde condities door het XIS kan worden uitgevoerd onder verantwoordelijkheid van de zorgverlener.
Het verschil met de 'gewone' query is dat met behulp van de tokens:

de zorgverlenersopdracht voor de inzet van de conditionele query in de tijd gescheiden kan zijn van de daadwerkelijke uitvoer van de query door het systeem terwijl bij de 'gewone' query de opdracht en uitvoer altijd gelijk na elkaar plaatsvinden.
systemen onder strikte voorwaarden op basis van condities (triggers) medische gegevens (binnen de behandelovereenkomst) kunnen opvragen. Deze condities zullen op voorhand gedefinieerd moeten worden. Enkele voorbeelden van condities die kunnen leiden tot een query zijn: agenda afspraak, openen dossier, ontvangen van een medicatieafspraak, een ontvangen signaal n.a.v. een genomen abonnement etc.
federatieve authenticatie kan worden toegestaan indien aan bepaalde voorwaarden wordt voldaan, waardoor niet iedere medewerker meer een UZI-pas nodig heeft (door onder mandaat te weren, waarbij alleen mandaatverleners een UZI-pas nodig hebben).

Voor het kunnen inzetten van de conditionele query zijn een aantal vooraf gemaakte zekerheden nodig. Deze zijn verwerkt in:

Het mandaattoken
Het inschrijftoken
Het transactietoken

De volgende paragrafen beschrijven het vereenvoudigd gebruik UZI-pas (VGU) in detail.

Vereenvoudigd gebruik UZI-pas

Het proces met betrekking tot het gebruik van de UZI-pas is aangepast. Het is binnen AORTA mogelijk gemaakt voor XIS-leveranciers om functionaliteiten te bouwen, waardoor het werkproces van de zorgverlener met betrekking tot de UZI-pas sterk vereenvoudigd kan worden. Naast een sterke vereenvoudiging in het werkproces is het ook mogelijk dat er kostenbesparing kan plaatsvinden vanwege de mogelijkheid dat er minder UZI-passen nodig zijn.
De implementatie van het vereenvoudigd gebruik van de UZI-pas (VGU) binnen een organisatie kan sterk verschillen; implementatie is afhankelijk van de zorgtoepassing en het werkproces van de zorgverlener en/of organisatie. Het doel van dit document is om voor zorgaanbieders en koepelorganisaties inzichtelijk te maken hoe ze het meest kunnen profiteren van de oplossing voor het vereenvoudigde gebruik van de UZI-pas met de wettelijke normen in het achterhoofd. Daarnaast is het bedoeld als beschrijving voor XIS-leveranciers. Ze kunnen dit document gebruiken om de mogelijkheden met betrekking tot de oplossing beter in beeld te krijgen en om met een zorgorganisatie in gesprek te gaan om tot een goed geïmplementeerde oplossing te komen.
In dit document is een generieke beschrijving van de oplossing opgenomen. Eventuele voorbeelden dienen alleen als voorbeeld en zijn niet leidend voor de uiteindelijke implementatie. Per zorgtoepassing kan de oplossing op details verschillen. Deze details zullen in het ontwerp van de zorgtoepassing zijn opgenomen.

Probleem

Het gebruik van de UZI-pas leidt in sommige zorgprocessen tot vertragingen en vanuit informatiebeveiligingsoogpunt tot onveilige werksituaties als gevolg van onjuist gebruik. Uit verschillende reacties van leveranciers, zorgverleners en andere betrokkenen is dan ook de wens gekomen om de werkwijze met de UZI-pas te herzien. Met name binnen ziekenhuizen en zorgbehandelcentra is gebleken dat de werkwijze m.b.t. de UZI-pas niet aansluit bij de zorgprocessen; men wil patiëntinformatie reeds opgevraagd hebben voordat de patiënt langs komt voor behandeling (het zogenaamde 'prefetching').
Binnen AORTA is een oplossing geïntroduceerd waardoor het gebruik van de UZI-pas sterk vereenvoudigd kan worden. Het gaat hierbij om een generieke oplossing die het werkproces van een zorgaanbieder kan ondersteunen. Het werkproces kan binnen een zorgtoepassing en zelfs per instelling sterk verschillen. Het is dus aan een individuele instelling om te bepalen hoe men gebruik wil maken van de oplossing zoals binnen AORTA is opgenomen.

Generieke oplossing

Met de generieke oplossing is het mogelijk om vooraf een aantal waarborgen af te geven, waarmee een zorgverlener op het moment van het versturen van een bericht (bijvoorbeeld een bevraging van patiëntgegevens, het versturen van patiëntgegevens of het afsluiten van een abonnement) geen UZI-pas meer nodig heeft. Het wordt mogelijk om op basis van bepaalde triggers het systeem berichten te laten versturen.

Tokens

Voor interactie met het LSP zonder het gebruik van de UZI-pas op het moment van de interactie worden er drie verschillende waarborgen onderscheiden. Deze waarborgen komen in de vorm van zogenaamde tokens en moeten worden meegestuurd met een interactie Het selecteren en toevoegen van de tokens is niet een handeling dat een zorgverlener hoeft uit te voeren. Dit zal geautomatiseerd door de XIS-applicatie aan een uitgaande interactie worden toegevoegd. . Elk token staat voor een ander waarborg en kunnen op verschillende momenten in de tijd worden aangemaakt. De combinatie van waarborgen zorgen voor een vergelijkbaar beveiligingsniveau als een interactie verstuurt met een UZI-pas.
Met het inschrijftoken wordt gewaarborgd dat een patiënt is ingeschreven bij een organisatie. Van een ingeschreven patiënt dient een token te worden gegenereerd door middel van het gebruik van een UZI-pas. Een technische beschrijving van het inschrijftoken is opgenomen in de IH Inschrijftoken.
Een verantwoordelijke zorgverlener geeft in een mandaattoken aan welke zorgverleners of onder welke omstandigheden het systeem onder zijn verantwoordelijkheid een interactie mag versturen. Een technische beschrijving van het mandaattoken is opgenomen in de IH Mandaattoken.
Het transactietoken is een waarborg dat wordt aangemaakt door het systeem op het moment van uitsturen van een bericht. Het transactietoken waarborgt dat een interactie met betrekking tot een specifieke patiënt wordt verstuurd onder verantwoordelijkheid van een verantwoordelijke zorgverlener. Het transactietoken koppelt het inschrijftoken, het mandaattoken en het uit te sturen bericht aan elkaar. Een gebruiker van het systeem heeft geen weet van het transactietoken. Het genereren van het transactietoken wordt gedaan door het systeem met behulp van het UZI-servercertificaat. Een technische beschrijving van het transactietoken is opgenomen in de IH Transactietoken.

Triggers

Een XIS-applicatie kan Indien een zorgverlener via het mandaattoken toestemming heeft gegeven om het systeem onder zijn verantwoordelijkheid te laten opvragen. op basis van verschillende triggers een bericht uitsturen met betrekking tot een specifieke patiënt. Deze triggers zijn niet vast voor gedefinieerd, maar kunnen verschillen per zorgtoepassingen en/of per werkproces. Een aantal voorbeelden van triggers zijn:

Het beschikbaar komen van nieuwe informatie bij een zorgverlener; een zorgverlener heeft nieuwe informatie beschikbaar gesteld via het LSP en het LSP stuurt een signaal naar alle abonneehouders.
Een agenda-afspraak met een patiënt; een patiënt heeft die dag een afspraak en het systeem krijgt hiermee het verzoek om de patiëntgegevens van die patiënt op te vragen.
Een bepaalde tijdsperiode; elke eerste van de maand bevraagt het systeem bepaalde gegevens t.b.v. bijvoorbeeld een bewakings- of rapportageproces.
Het openen van een dossier; een geautoriseerde zorgverlener opent een dossier van een patiënt en het systeem zorgt ervoor dat de zorgverlener de meest actuele gegevens opgeleverd krijgt door alle nieuwe informatie op te vragen.
Een handeling door een daarvoor geautoriseerde gebruiker; een zorgverlener kan het systeem actief opdracht geven om een bevraging te doen m.b.t. een specifieke patiënt.

Het is mogelijk dat een XIS-applicatie meerdere triggers ondersteunt. Binnen een zorgtoepassing zal worden bepaald welke trigger van belang is en welke potentiële eisen er gelden m.b.t. deze trigger. Op verzoek van een XIS-leverancier kan in overleg met VZVZ worden nagedacht over mogelijke andere triggers. Deze zullen echter altijd in een zorgtoepassing opgenomen moeten worden en een XIS zal altijd moeten worden geaccepteerd voor deze nieuwe trigger. Het kan dus voor een zorgaanbieder interessant zijn om met zijn XIS-leverancier in gesprek te gaan over de implementatie van de conditionele query in de diverse werkprocessen.

Processen met betrekking tot UZI-middelen

Het vereenvoudigd gebruik met de UZI-pas sluit het gebruik van de UZI-pas niet helemaal uit. De UZI-pas blijft nodig binnen twee deelprocessen:

Bij de bevestiging van inschrijving van een patiënt;
Bij het afgeven van een mandaat door een verantwoordelijke zorgverlener.

Deze twee deelprocessen kunnen op afzonderlijke momenten in de tijd plaatsvinden. Het is aan een zorgaanbieder in overleg met zijn XIS-leverancier zaak om een goede invulling te vinden, die aansluit bij het werkproces zoals geïmplementeerd binnen de zorgaanbieder.
Naast de UZI-passen dient er gebruik te worden gemaakt van servercertificaten. Deze zijn nodig voor het proces om een specifieke zorgaanbieder te identificeren en te authenticeren Hieronder wordt gesproken over een UZI-servercertificaat. Het is mogelijk dat in sommige gevallen gebruik wordt gemaakt van een PKIo-servercertificaat.

UZI-middelen

Er zijn verschillende soorten UZI-middelen te onderscheiden. Het gaat hierbij om persoonlijke als organisatie UZI-middelen.

Zorgverlenerpas: Pas ten behoeve van zorgverlener waarvan het beroep valt onder artikel 3, 34 of 36a beroepen van de Wet BIG. De certificaten op de pas bevatten de unieke identificatie (UZI-nummer) en de functie (UZI-rolcode) van de betreffende zorgverlener.

Medewerkerpas: Pas voor medewerkers die geen beroep uitoefenen wat valt onder artikel 3, 34 of 36a van de Wet BIG. Met de certificaten op deze pas is het niet mogelijk om je te authenticeren voor toegang tot de AORTA infrastructuur. Een alternatief voor deze pas is het gebruik van ZORG-ID.
Medewerkerpas-op-naam: Pas voor medewerkers die geen beroep uitoefenen wat valt onder artikel 3, 34 of 36a van de Wet BIG. De certificaten die opgenomen zijn bevatten een unieke identificatie van de medewerker (UZI-nummer). Deze medewerker vervult niet een functie die valt onder artikel 3, 34 of 36a van de Wet BIG en krijgt hiermee geen unieke rolcode toegekend. Ook een UZI-medewerkerpas op naam kan toegang krijgen tot het LSP, maar alleen als deze is gemandateerd door een BIG- geregistreerde zorgverlener met een UZI- zorgverlenerpas. Een alternatief voor de medewerkerspas-op-naam is het gebruik van ZORG-ID.

Servercertificaat: zorgt voor identificatie en authenticatie van de zorgaanbiederapplicatie. Met een servercertificaat kunnen beveiligde verbindingen worden opgezet met het LSP. Binnen AORTA geldt dat er gebruik moet worden gemaakt van UZI-servercertificaten, tenzij het niet mogelijk is voor de betreffende zorgaanbieder om een UZI-servercertificaat aan te vragen. In dat geval zal gewerkt worden met een PKIo-servercertificaat.

Inschrijfproces

Zodra een patiënt is ingeschreven en er een WID- en een BSN-controle heeft plaatsgevonden bij het SBV-Z, dan is het mogelijk om een inschrijftoken te ondertekenen. Het ondertekenen kan op verschillende momenten in de tijd gebeuren:

Direct na de initiële inschrijving en de benodigde SBV-Z controles;
Op een later moment na de initiële inschrijving en de benodigde SBV-Z controles Het is hierbij van belang dat er extra waarborgen zijn dat een patiënt daadwerkelijk door een geautoriseerd persoon is ingeschreven inclusief alle benodigde controles. Een kwaadwillende mag niet in staat gesteld worden om inschrijftokens te laten genereren. ;
Op het moment van bevraging en er nog geen inschrijftoken beschikbaar is.

Het is aan een zorgaanbieder in overleg met zijn XIS-leverancier zaak om een goede invulling te vinden, die aansluit bij het werkproces zoals geïmplementeerd binnen de zorgaanbieder.
Het inschrijftoken moet worden ondertekend met het authenticatiecertificaat van minimaal Dit kan ook met een zorgverlenerpas gebeuren. een medewerkpas-op-naam pas. Deze pas dient geldig te zijn op het moment van ondertekenen van een inschrijftoken. Een inschrijftoken is 1.5 jaar geldig, ongeacht de geldigheidsduur van de UZI-pas. Na 1.5 jaar dient de inschrijving opnieuw bevestigd te worden door middel van ondertekening.
Als gevolg van deze ondertekening kan onweerlegbaar worden vastgesteld dat een geautoriseerde gebruiker binnen de organisatie heeft vastgesteld dat de inschrijving van de patiënt door deze persoon is gedaan of dat deze persoon heeft geconstateerd dat de inschrijving correct heeft plaatsgevonden.
Registratie en ondertekening van het inschrijftoken dient te gebeuren voordat het systeem gebruik kan maken van het vereenvoudigd gebruik van de UZI-pas.

Mandaatproces

Een zorgverlener kan door middel van een mandaat zijn autorisaties overdragen aan een andere zorgverlener. Op een soortgelijke wijze kan een zorgverlener het XIS delegeren om onder zijn verantwoordelijkheid een interactie te versturen met betrekking tot de patiënten waar de betreffende zorgverlener een behandelrelatie mee heeft.
Het mandaat dat een verantwoordelijke zorgverlener heeft geregistreerd, wordt vastgelegd in de vorm van een mandaattoken. Voor het vereenvoudigd gebruik van de UZI-pas dient de applicatieID van het systeem van waaruit een AORTA-interactie wordt verstuurd, opgenomen te zijn in het mandaat. Na het registreren van een mandaat, dient de verantwoordelijke zorgverlener het mandaat te ondertekenen met het handtekeningcertificaat van zijn UZI-pas. Dit dient de zorgverlener eenmalig te doen gedurende de geldigheidsduur van zijn UZI-pas.
Een mandaattoken dient ondertekend te worden met een zorgverlenerpas. Het mandaattoken is maximaal net zolang geldig als de geldigheidsduur van de zorgverlenerpas. Indien een zorgverlenerpas verlopen is, dan zal het mandaattoken niet meer gebruikt kunnen worden.
Registratie en ondertekening van het mandaattoken dient te gebeuren voordat het systeem gebruik kan maken van het vereenvoudigd gebruik van de UZI-pas.

Genereren transactietoken a.g.v. trigger

Om zeker te weten dat een bericht ook daadwerkelijk door een zorgaanbieder is opgesteld, dient er een transactietoken te worden ondertekend door het UZI-servercertificaat. Het transactietoken bevestigd dat een specifiek bericht is opgesteld onder verantwoordelijkheid van een specifieke zorgaanbieder die een behandelrelatie heeft met de patiënt op wie het bericht betrekking heeft.
Het aanmaken van een transactietoken wordt geïnitieerd door een trigger zoals omschreven in hoofdstuk 2.2.2.

Bericht versturen over AORTA

Voor het versturen van een bericht, dient het versturende XIS een verbinding op te zetten met het LSP. Een verbinding wordt opgezet op basis van het servercertificaat van de XIS. Het bericht dat verstuurd wordt, dient begeleidt te worden met:

het inschrijftoken van de patiënt die onderwerp is van het bericht;
het mandaattoken van de verantwoordelijke zorgverlener die een behandelrelatie heeft met deze patiënt;
het transactietoken die is aangemaakt als gevolg van een trigger.

Het XIS moet deze tokens koppelen aan een bericht.
Het is mogelijk dat er meerdere mandaattokens beschikbaar zijn, die gebruikt zouden kunnen worden. Afhankelijk van de trigger zou een gebruiker van het systeem het juiste mandaattoken kunnen kiezen of kan het systeem op basis van de context van het bericht zelf een mandaattoken kunnen kiezen. De wijze van implementeren kan afhankelijk zijn van het zorgproces waarin dit proces wordt toegepast. Het is dan ook aan de XIS-leverancier om hier goed mee om te gaan. VZVZ zal hier bij de implementatie in kunnen begeleiden.

Voor wie UZI-passen?

Om patiëntgegevens op te mogen vragen, dient de verantwoordelijke zorgverlener een behandelrelatie te hebben met de patiënt wiens gegevens worden opgevraagd. Het is aan de verantwoordelijke zorgverlener en/of de organisatie om de behandelrelatie te verantwoorden aan een patiënt of inspectiedienst.
De rol van de verantwoordelijke zorgverlener bepaalt welke inhoudelijke informatie er bij een opvraag wordt opgeleverd. Welke informatie wordt opgeleverd voor een bevraging door een specifieke rol heeft te maken met de autorisatierichtlijnen die worden opgesteld door de verschillende koepels; niet elke zorgverlener krijgt vanzelfsprekend dezelfde dataset opgeleverd.
Met name voor organisaties waar verschillende zorgverlenerrollen actief zijn, is het van belang om een goede afweging te maken over welke zorgverlener met welke zorgverlenerrol een UZI-pas moet bezitten. VZVZ kan de autorisatieconfiguratie Het gaat hierbij om de autorisatieconfiguratie zoals opgenomen in de Selectie en Determinatie Service (SDS). Meer informatie over de werking van deze service is opgenomen in de AORTA-publicatie (AORTA 8.3.0 - AORTA 8.3.0 - Afsprakenstelsels (vzvz.nl)). beschikbaar stellen om de keuze te vergemakkelijken.
Voor alle interactietypes (opvragen, versturen, infrastructurele berichten etc.) geldt dat het Medische Autorisatie Protocol (MAP) bepaalt of een bepaalde rolcode een bericht mag versturen. Ook hiervoor geldt dat VZVZ de MAP-configuratie beschikbaar kan stellen om een goede afweging te maken voor welke rollen er UZI-passen aangeschaft dienen te worden.

Aantal UZI-passen?

Het aantal benodigde UZI-passen is sterk afhankelijk van de organisatiestructuur en de werkprocessen binnen een organisatie. Er zijn wel een aantal zaken aan te geven, waar organisaties rekening mee kunnen houden bij het bepalen van het aantal benodigde UZI-passen:

Verschillende soorten zorgverlenerrollen binnen de organisatie (zie paragraaf 3.2); autorisaties worden binnen AORTA toegekend per zorgverlenerrol. Niet elke zorgverlener heeft dezelfde autorisaties. Er dient dus nagedacht te worden welke zorgverlenerrollen een UZI-pas dienen aan te vragen om de juiste patiëntgegevens te kunnen opvragen.
Onderkennen verantwoordelijke zorgverlener binnen zorgprocessen; een zorgverlener dient een behandelrelatie te hebben met een patiënt om diens gegevens op te vragen. Het is aan de zorgaanbieder om een behandelrelatie te verantwoorden aan een patiënt of inspectiedienst.
Doorstroom van personeel; een UZI-pas is gekoppeld aan een persoon. Indien deze persoon uit dienst gaat, mag de UZI-pas en de hiermee getekende tokens niet meer gebruikt worden.
Vervangen verlopen en/of ingetrokken UZI-pas; een UZI-pas die verlopen is, moet niet leiden tot een verstoord zorgproces. Het is dus aan te raden om altijd meerdere actieve UZI-passen in een instelling te gebruiken, zodat bij het verlopen of intrekken van een UZI-pas het zorgproces niet stil valt.

Rol VZVZ

VZVZ kan een XIS-leverancier en/of zorgaanbieder begeleiden met het implementeren en in gebruik nemen van het proces met betrekking tot het vereenvoudigd gebruik van de UZI-pas.
VZVZ kan advies geven over het aantal te gebruiken UZI-passen en aan wie die UZI-passen het best kunnen worden toegekend. Dit zal echter een niet bindend advies zijn. Het is aan de zorgaanbieder om hierin de juiste keuzes voor zijn organisatie te maken.
Indien een zorgaanbieder in overleg met zijn XIS-leverancier bepaalde tekortkomingen ziet met betrekking tot het vereenvoudigd gebruik van de UZI-pas, dan gaat VZVZ graag in gesprek om een oplossing te vinden voor deze tekortkomingen. Hierbij valt bijvoorbeeld te denken aan het ontbreken van een juiste trigger voor het initiëren van het versturen van een bericht. VZVZ zal hierbij altijd de geldende normen, regels en wetten in ogenschouw nemen.

ZORG-ID is compatibel met het vereenvoudigd gebruik van de UZI-pas. In combinatie met ZORG-ID wordt het aantal UZI-passen binnen een organisatie verder verminderd; er is geen medewerkerpas-op-naam nodig om het inschrijftoken te ondertekenen.
Dit hoofdstuk gaat niet in op de precieze werking van ZORG-ID, maar beschrijft alleen de impact op het proces m.b.t. het vereenvoudigd gebruik UZI-pas.

Inschrijftoken

Het inschrijftoken dat benodigd is voor het vereenvoudigd gebruik van de UZI-pas kan op twee manieren worden ondertekend:

Door het authenticatiecertificaat van minimaal een medewerkerpas-op-naam;
Door een identiteitscertificaat dat is uitgegeven door ZORG-ID.

Indien een inschrijftoken wordt ondertekend door middel van een identiteitscertificaat dat is uitgegeven door ZORG-ID, dan zal er in het inschrijftoken een WID- en Scan-token moeten zijn opgenomen. Voor de precieze beschrijving van deze laatste twee tokens wordt verwezen naar de ZORG-ID en de AORTA 8.3 documentatie (AORTA SAML tokens - AORTA 8.3.0 - Afsprakenstelsels (vzvz.nl)).
Op de wijze van ondertekening en de geneste WID- en Scan-token na zijn er geen verschillen tussen beide inschrijftokens. Een organisatie kan deze inschrijftokens dan ook door elkaar gebruiken indien gewenst.
Het inschrijftoken wordt aangemaakt op het moment van de daadwerkelijke WID-controle.

Hieronder staat uitgewerkt hoe het vereenvoudigd gebruik van de UZI-pas (VGU) toegepast kan worden. Het betreft een generieke uitwerking die toegepast kan worden op elke interactie die over de AORTA infrastructuur wordt verstuurd. Het gaat daarbij zowel om infrastructurele berichten gericht aan het LSP als om zorginhoudelijke berichten gericht aan een ontvangende XIS.

Legenda

Onderstaande legenda toont de symbolen zoals gebruikt in onderstaande diagram

Generiek proces

Het generieke proces dat gevolgd dient te worden om gebruik te maken van het vereenvoudigde gebruik van de UZI-pas staat hieronder uitgewerkt.

Samenvatting

Onderstaande tabel beschrijft de actoren, UZI-middelen en resultaat van de tokens in de tijd.

Tijdstip	Proces	Actoren	Token	Duur token	Middel
T-x (x>0) Het tijdstip ligt in ieder geval voor het moment dat een transactietoken aangemaakt wordt. Op welk moment het mandaattoken precies aangemaakt wordt, is afhankelijk van het zorgproces.	Mandaatproces	Verantwoordelijke zorgverlener XIS	Mandaattoken	Richtlijn 5 minuten, maximaal 90 minuten.	UZI-zorgverlenerpas, handtekeningcertificaat
T-y (y>0) Het tijdstip ligt in ieder geval voor het moment dat een transactietoken aangemaakt wordt. Op welk moment het mandaattoken precies aangemaakt wordt, is afhankelijk van het zorgproces. Hierbij geldt dat er geen verband is tussen x en y.	Inschrijfproces	Medewerker Patiënt XIS	Inschrijftoken	Maximaal de geldigheidsduur van het handtekeningcertificaat waarmee is ondertekend .	UZI-medewerkerpas-op-naam, authenticatiecertificaat, of ZORG-ID
T	Genereren transactietoken a.g.v. trigger	XIS	Transactietoken	Maximaal 1,5 jaar	UZI-servercertificaat
T+1	Bericht versturen over AORTA	XIS LSP	Mandaattoken Transactietoken Inschrijftoken		UZI-servercertificaat

Inzage logging

Patiënten hebben de mogelijkheid om via Volgjezorg Het goed beheerde patiëntenportaal onder verantwoordelijkheid van VZVZ, volgjezorg.nl in te zien welke zorgaanbieder welke gegevens heeft opgevraagd bij welke zorgaanbieder en/of naar welk zorgaanbieder gegevens zijn verstuurd. Hierbij worden geen individuele zorgverleners getoond. Echter, de patiënt heeft wel het recht om bij de zorgaanbieder op te vragen welke zorgverleners er bij de bevraging betrokken zijn geweest. Hierbij dient dan in ieder geval de verantwoordelijke zorgverlener aan de patiënt kenbaar te worden gemaakt. Het is dus van belang dat een zorgaanbieder te allen tijde kan uitleggen, waarom er een bericht is verstuurd onder het mandaat van een bepaalde zorgverlener.

Verlopen UZI-passen

Een verlopen UZI-pas kan leiden tot een verstoord zorgproces. De UZI-pas en het mandaattoken getekend met de bewuste UZI-pas kunnen respectievelijk mogen dan niet meer gebruikt worden. Het is aan de zorgaanbieder om een goed proces in te richten om genoeg UZI-passen beschikbaar te hebben binnen de organisatie en om deze UZI-passen (in overleg met de verantwoordelijke zorgverleners) tijdig te verlengen.

Verlopen UZI-servercertificaten

Afhankelijk van de grootte van de organisatie is het mogelijk dat er twee servercertificaten worden vereist. Met deze twee servercertificaten kan er onderscheid worden gemaakt tussen het opzetten van een beveiligde verbinding en het daadwerkelijk dataverkeer (d.m.v. ondertekening van het transactietoken). Het is van belang dat beide UZI-servercertificaten tijdig worden vervangen. Met een verlopen of ingetrokken servercertificaat is het niet mogelijk om patiëntgegevens op te vragen of te versturen via AORTA.

Voor implementatie van het vereenvoudigd gebruik UZI-pas bij een zorgaanbieder moet de leverancier zijn XIS laten accepteren door het VZVZ-acceptatieteam. Daarnaast dient de zorgaanbieder die de functionaliteit in productie gaat nemen een self assesment in te vullen.

Self assesment vereenvoudigd gebruik UZI-pas

Met betrekking tot het vereenvoudigd gebruik van de UZI-pas heeft VZVZ geen beveiligingsconcessies willen doen t.o.v. het gebruik van de UZI-pas. Om te kunnen blijven voldoen aan de NEN 7510 en de NEN 7512, wordt een deel van de beveiligingsverantwoordelijkheid overgedragen aan een zorgaanbieder. Indien een zorgaanbieder er voor kiest om gebruik te maken van het vereenvoudigd gebruik van de UZI-pas, dan dient de zorgaanbieder expliciet aan te geven dat hij voldoet aan de maatregelen behorend bij die beveiligingsverantwoordelijkheid. Deze maatregelen zijn opgenomen in de PvE (Programma van Eisen) van een zorgtoepassing en benoemd in een self assesment in de vorm van een aantal vragen. De zorgaanbieder dient deze vragen te beantwoorden en te ondertekenen, voordat er gebruik mag worden gemaakt van het proces met betrekking tot het vereenvoudigd gebruik van de UZI-pas.
Het self assesment staat gepubliceerd op de VZVZ-website: selfassesment_zorgaanbieders_vereenvoudigd_gebruik_uzi_pas (formdesk.com) .

PvE Zorgtoepassing

In een PvE van de zorgtoepassing zijn alle eisen opgenomen die van toepassing zijn voor die zorgtoepassing. Het betreft hier zorgaanbiederorganisatie-, XIS-applicatie- en XIS-leverancierseisen. Hierin zijn ook alle eisen opgenomen die geïmplementeerd dienen te worden om gebruik te kunnen maken van het proces met betrekking tot het vereenvoudigd gebruik van de UZI-pas.
Een zorgaanbieder dient te voldoen aan de zorgaanbiedereisen zoals opgenomen in het PvE van de zorgtoepassing.
Een XIS-leverancier dient het reguliere acceptatietraject te doorlopen om zijn applicatie geaccepteerd te krijgen.

Browser not supported