PvE Basisgegevenset Zorg MSZ - Ontvangend systeem

Datum:

13-1-2025

Status:

Definitief

Versie:

2.2.0

Eigenaar:

VZVZ

Revisie:

1

Datum

Status

Versie

Omschrijving

3-6-2023

Definitief

1.0.0

Definitieve versie van PvE BGZ Ontvangend Systeem na review VZVZ PDM en VZVZ Acceptatieteam.

3-9-2024

Definitief

2.0.0

PvE aangepast in overleg met NTV en project.

3-10-2024

Definitief

2.1.0

PvE aangepast in overleg met NTV en project.

13-1-2025

Definitief

2.2.0

Hoofdstuk 3 toegevoegd t.b.v. TWIIN deelnemers.

Details

Eis:

Mandaattokens dienen in een beveiligde container te worden opgeslagen. Een gebruiker krijgt door middel van een beveiligde verbinding alleen gebruik over die mandaattokens waarvoor het is geautoriseerd.

Toelichting bij eis:

Er moet voorkomen worden dat mandaattokens onderschept, gelezen en vervolgens misbruikt worden. Door middel van implementatie van een beveiligde container krijgen medewerkers alleen gebruik over die mandaattokens waarvoor ze zijn geautoriseerd.

De beveiligde container moet het onmogelijk maken om een mandaattoken te stelen.

Details

Eis:

Indien de geldigheid van een token is verlopen, dan dient deze automatisch te worden verwijderd.

Daarnaast moet het voor een gebruiker, die ingelogd is met tweefactorauthenticatie, mogelijk zijn om een token uit het systeem te verwijderen.

Toelichting:

Het verwijderen (en daarmee afwezig zijn) van een token leidt ertoe dat er geen automatische opvraag meer verstuurd mag worden t.b.v. het opvragen van patiëntgegevens van de in het token opgenomen patiënt-id. Dit kan gevolgen hebben voor het werkproces van de gebruiker van het systeem. Het is dan ook aan te raden om de gebruiker(s) van het systeem (tijdig) op de hoogte te stellen van het verwijderen van een token. Hoe hier invulling aan te geven is aan de systeembouwer.

Het gaat hierbij bijvoorbeeld om inschrijf- en consenttokens.

Details

Eis:

Om misbruik van tokens door een kwaadwillende te bemoeilijken, moeten de tokens in een beveiligde omgeving worden opgeslagen. Toegang tot de tokens moet alleen mogelijk zijn voor geautoriseerde gebruikers.

Toelichting:

Er worden geen specifieke eisen gesteld aan de rollen die geautoriseerd zijn en aan de wijze van opslag van de tokens. Dit is afhankelijk van de lokale systeemimplementatie. De systeembouwer is verantwoordelijk voor een goede invulling van deze eis.

Het gaat hierbij alleen om die tokens, die meerdere malen gebruikt kunnen worden, zoals inschrijf- en consenttokens.

Details

Eis:

Tokens mogen alleen verstuurd worden over beveiligde verbindingen.

Toelichting:

Om te voorkomen dat tokens worden afgevangen en misbruikt door een kwaadwillende moeten tokens verstuurd worden over beveiligde verbindingen. Afhankelijk van de opslag- of creatielocatie van de tokens, kan dit impliceren dat een GBX ook intern gebruik dient te maken van beveiligde verbindingen.

Details

Eis:

Het systeem moet fictieve gegevens opvallend onderscheidend presenteren aan gebruikers.

Toelichting bij eis:

Deze eis dient om onjuist gebruik van fictieve gegevens te voorkomen.

Het is aan de XIS-leverancier om eventueel in afstemming met zijn klant te komen tot een goede weergave van fictieve gegevens. VZVZ zal beoordelen of dit inderdaad ook voldoende is voor acceptatie.

Details

Eis:

Het moet mogelijk zijn om een bevraging op een later tijdstip te initiëren, dan het moment van binnenkomst van het consenttoken.

Toelichting bij eis:

Het consenttoken wordt gebruikt om een bevraging te kunnen doen bij een bronsysteem naar aanleiding van bijvoorbeeld een verwijzing. Het moet mogelijk zijn om de bevraging op een later tijdstip te initiëren, dan het moment van binnenkomst van het token. Het is bijvoorbeeld mogelijk dat er door een foutmelding een bevraging op het moment van ontvangst niet meteen mogelijk is.

Details

Eis:

Het systeem moet een gebruiker van het systeem attenderen op een binnengekomen verwijzing en de status van deze verwijzing tonen aan de gebruiker. Indien niet de volledige informatieset is opgevraagd, dan moet dit aan de gebruiker inzichtelijk worden gemaakt.

Bij de status van de afhandeling van de verwijzing dient ook de tijd (tot minimaal op de minuut) van binnenkomst van de verwijzing en het tijdstip van de eventuele afhandeling van die verwijzing getoond te worden.

Toelichting bij eis:

Er moet voorkomen worden, dat een verwijzing onafgehandeld blijft. Als gevolg van een verwijzing dient er een BGZ en (mogelijk) aanvullende documenten opgevraagd worden. De volledige informatieset die bevraagd dient te worden, wordt bepaald door de in de verwijzing opgenomen resources.

Het bevragen van de informatieset en de mogelijk aanvullende documenten bestaat uit het bevragen van de losse FHIR-resources door een XIS.

Details

Eis:

Het systeem dient de FHIR-resources te kunnen ontvangen zoals zijn opgenomen in de betreffende zorgtoepassing.

Toelichting bij eis:

In de zorgtoepassing is beschreven welke FHIR-resources een systeem moet kunnen ontvangen.

Details

Eis:

Het systeem dient de use cases te ondersteunen zoals beschreven in: https://aorta-on-fhir.scrollhelp.site/aorta-on-fhir-specificaties-versie-07x/latest/uc-resource-server-0-7-x .

Toelichting bij eis:

De use cases beschrijven o.a. de volgende zaken:

• Activeren TKID (indirect beschreven in toelichting);

• Opleveren AORTA CapabilityStatement;

• Verwerken AORTA FHIR-interacties;

• Opvragen Stelsteltoken (indirect beschreven in toelichting);

• Opvragen JWKS (indirect beschreven in toelichting);

• Verkrijgen AS Metadata.

Een technische invulling van deze use cases wordt beschreven in de onderliggende pagina's van het hoofdstuk Interface: https://aorta-on-fhir.scrollhelp.site/aorta-on-fhir-specificaties-versie-07x/latest/interfaces-0-7-x

Details

Eis:

In het geval een conditioneel bericht wordt beantwoord met een foutmelding, dan heeft het systeem ten hoogste drie pogingen om het conditionele bericht nogmaals te versturen.

Na drie pogingen mag het systeem het bericht niet nogmaals uitsturen en dient de GBZ-beheerder actie te ondernemen zoals is beschreven in de AORTA DAP.

Toelichting bij eis:

Er moet voorkomen worden dat de infrastructuur overbelast wordt door een conditioneel bericht. In het geval er een foutmelding optreedt, moet het niet mogelijk zijn dat het conditionele bericht onbeperkt vaak wordt uitgestuurd totdat er een antwoord (geen foutmelding) terugkomt. De GBZ-beheerder wordt geacht om te onderzoeken wat de foutmelding is en hoe die volgens de AORTA DAP behandeld dient te worden.

Details

Eis:

Berichten zonder een bijgaand transactietoken, bedoeld om via de AORTA-infrastructuur te versturen, mogen binnen de interne GBZ-infrastructuur alleen verstuurd worden over beveiligde verbindingen.

Toelichting:

Om te voorkomen dat niet getekende berichten worden afgevangen en misbruikt door een kwaadwillende, moeten deze berichten verstuurd worden over beveiligde verbindingen. Hiermee kan gegarandeerd worden dat berichten tijdens de verzending niet worden aangepast.

Details

Eis:

Bij het opvragen van inhoudelijke patiëntgegevens verschaft het systeem de gebruiker slechts toegang indien de patiënt is ingeschreven en

1. korter dan één jaar geleden een behandelrelatie is vastgelegd volgens Bijhouden behandelrelatie of

2. een behandelrelatie blijkt uit de werkcontext of

3. de zorgverlener alsnog een behandelrelatie vastlegt volgens Bijhouden behandelrelatie.

Details

Eis:

Wanneer patiëntgegevens, die conform Opvragen van patiëntgegevens (GBX.OPV.e4010.1) zijn ontvangen, ongewijzigd in de eigen patiëntadministratie worden opgenomen dan moet worden vastgelegd dat het een kopie betreft. Hierbij moet de originele OID bij de gegevens opgeslagen worden.

Toelichting bij eis:

Gewoonlijk zullen patiëntgegevens die via het LSP worden opgevraagd niet in de eigen patiëntadministratie worden opgenomen. Het kan echter gewenst zijn om ontvangen patiëntgegevens als onderbouwing bij besluitvorming te bewaren.

In het verlengde hiervan kan de zorgverlener eigen aantekeningen toevoegen, of de ontvangen gegevens wijzigen. Gewijzigd overgenomen gegevens worden beschouwd als eigen dossiergegevens.

Om redundantie van informatie te voorkomen mogen als kopie aangemerkte patiëntgegevens niet bij de verwijsindex worden aangemeld en niet worden opgeleverd bij het verwerken van een opvraagverzoek.

Wanneer een gebruiker als kopie aangemerkte, lokale gegevens raadpleegt, is het raadzaam om aan te geven dat het een kopie betreft en dat de gegevens mogelijk zijn verouderd.

Details

Eis:

Voor het gebruik van conditionele berichten moet er een transactietoken worden toegevoegd dat ondertekend is door het servercertificaat van het systeem waar vandaan het bericht verstuurd wordt. Het applicatie-id van het betreffende systeem dient voor te komen in de autorisatieregel die is opgenomen in het mandaattoken.

Toelichting bij eis:

Om een conditioneel bericht te kunnen versturen door een systeem, moet een zorgverlener het applicatie-id(’s) van een systeem kenmerken als systeem dat voor hem/haar een bericht mag versturen. Dit wordt vastgelegd in het mandaattoken. Om te kunnen garanderen dat een bericht door het betreffende systeem wordt verstuurd, is het nodig dat het systeem een transactietoken ondertekent en toevoegt bij het bericht.

Details

Eis:

Een bericht verstuurt door het systeem onder verantwoordelijkheid van een zorgverlener moet een getekend mandaattoken van de verantwoordelijke zorgverlener bevatten. Het mandaattoken moet een autorisatieregel bevatten (zie eis GBX.AUT.e4513) met minimaal de volgende invulling:

• Applicatie-id(’s) van het systeem.

Toelichting bij eis:

Een zorgverlener moet kunnen aangeven dat een systeem voor hem/haar automatisch een opvraag kan doen op basis van een specifieke trigger (zie GBX.OPV.e4040). Dit legt een zorgverlener vast in een mandaattoken. Het is mogelijk om hetzelfde mandaattoken te gebruiken om andere zorgverleners te mandateren.

Details

Eis:

De trigger die een conditioneel bericht initieert dient gelogd te worden. Hierbij dient de trigger gelinkt te kunnen worden aan een uitgaand conditioneel bericht. Indien het conditionele bericht geïnitieerd wordt door een systeemgebruiker, dan dient in ieder geval ook de gebruiker-id (UZI-nummer of andere gebruiker-id) gelogd te worden.

Toelichting bij eis:

In een audit of op verzoek van VZVZ moet duidelijk gemaakt kunnen worden wie of wat een conditioneel bericht getriggerd heeft. Hiervoor is het van belang dat de trigger gelogd wordt en gekoppeld kan worden aan een uitgaand conditioneel bericht.

In het geval een systeemgebruiker het conditionele bericht triggert, dan dient de identificatie van de gebruiker ook gelogd te worden. Dit kan bijvoorbeeld een UZI-nummer zijn, maar mag ook een andere identifier zijn die getraceerd kan worden naar een uniek persoon.

Details

Eis:

Het moet aan de gebruiker van het systeem inzichtelijk worden gemaakt wat het resultaat was van een conditioneel bericht.

Toelichting:

Met het in deze eis genoemde conditionele bericht wordt bedoeld: een bericht die ten behoeve van een gebruiker door het systeem is verstuurd.

Met het in deze eis genoemde resultaat wordt bedoeld of er een conditioneel bericht is verstuurd en of deze succesvol is beantwoord.

De definitie van gebruiker is afhankelijk van de trigger die gebruikt wordt om het conditionele bericht te initiëren. Indien het openen van een dossier als trigger geldt, dan zal degene die het dossier opent op de hoogte gesteld moeten worden van het resultaat. Bij een automatische opvraag als gevolg van een binnenkomend abonnementsignaal, zal de verantwoordelijke zorgverlener (zoals opgenomen in het mandaattoken) op de hoogte gesteld moeten worden.

Het conditionele bericht creëert bij de gebruiker bepaalde verwachtingen. Indien het systeem niet kan voldoen aan die verwachtingen, dan dient dat inzichtelijk te worden gemaakt aan de gebruiker. De gebruikte triggers voor het conditionele bericht bepalen de wijze hoe de gebruiker in te lichten.

Het is aan de systeembouwer om deze eis op een juiste manier te implementeren.

Details

Eis:

Het consenttoken mag alleen verstuurd worden i.c.m. een opvraag indien het token op het moment van versturen nog geldig is.

Het consenttoken geldt als een vervanging voor het inschrijftoken bij een conditioneel bericht.

Toelichting bij eis:

Om onnodige fouten in de keten te voorkomen, is het van belang dat er alleen geldige tokens worden gebruikt. Het XIS dient hierop te controleren alvorens het token te gebruiken.

Details

Eis:

Het systeem dient de FHIR-resources t.b.v. BGZ op te vragen en het antwoord te kunnen verwerken zoals is opgenomen in de betreffende zorgtoepassing.

Toelichting bij eis:

Een verwijzing naar de FHIR-resources zijn opgenomen in de publicatiepagina van de 'BGZ-zorgtoepassing'.

Details

Eis:

Een systeemgebruiker moet de mogelijkheid hebben om een ontvangen taak als gevolg van een verwijzing inclusief BGZ te beëindigen. Als gevolg dient het consenttoken door het systeem verwijderd te worden.

Toelichting bij eis:

Om het zorgproces niet in gevaar te brengen, dient een systeemgebruiker zelf aan te geven dat een taak is afgehandeld. Het systeem kan dus zelf niet een taak beëindigen en vervolgacties laten initiëren zoals het verwijderen van een consenttoken (GBX.FUN.e4020).

Details

Eis:

Het systeem moet een consenttoken verwijderen als:

• de geldigheid van het consenttoken is verlopen;

• een systeemgebruiker het verwijderen van het consenttoken heeft geïnitieerd.

Toelichting bij eis:

Een gebruiker kan direct of indirect als gevolg van een gebruikersactie een consenttoken laten verwijderen. Indien een gebruiker bijvoorbeeld heeft aangegeven dat een verwijzingsproces is afgehandeld, dan kan een bijbehorend consenttoken door het systeem verwijderd worden.

Door het verwijderen van niet geldige tokens wordt voorkomen dat tokens hergebruikt worden en hiermee fouten in de keten veroorzaken. Daarnaast willen we eventuele beveiligingsissues en privcayissues voorkomen. Patiëntdata (dus ook tokens) dienen verwijderd te worden, indien deze niet meer gebruikt gaan worden en geen auditfunctionaliteit hebben.

Details

Eis:

Het systeem dient de use cases te ondersteunen zoals beschreven in: https://aorta-on-fhir.scrollhelp.site/aorta-on-fhir-specificaties-versie-07x/latest/uc-resource-client-0-7-x .

Toelichting bij eis:

De use cases beschrijven o.a. de volgende zaken:

• Activeren TKID;

• Verkrijgen adresseergegevens (indirect beschreven in toelichting);

• Verkrijgen AORTA Access Token (indirect beschreven in toelichting);

• Initieren notified-pull;

• Initieren AORTA FHIR-interacties.

Een technische invulling van deze use cases wordt beschreven in de onderliggende pagina's van het hoofdstuk Interface: https://aorta-on-fhir.scrollhelp.site/aorta-on-fhir-specificaties-versie-07x/latest/interfaces-0-7-x

Details

Eis:

Een mandaterende en de in de autorisatieregel opgenomen gemandateerde zorgverlener(s) moeten via een melding op de hoogte worden gebracht als respectievelijk zijn gegeven mandaat of zijn verkregen mandaat binnen een tijdsbestek van 1 maand komt te verlopen.

Toelichting bij eis:

Er moet voorkomen worden dat door een verlopen mandaat het zorgproces in gedrang komt.

Het kan voor komen dat een mandaterende niet in hetzelfde systeem werkt als een gemandateerde. Het is daarom van belang dat een gemandateerde ook op de hoogte wordt gesteld indien het mandaattoken bijna verlopen is.

Details

Eis:

Verlopen mandaattokens moeten in de volgende gevallen uit het systeem worden verwijderd:

• De einddatum van het mandaattoken is verstreken;

• De mandaterende zorgverlener is niet meer werkzaam bij de zorgaanbieder;

• De mandaterende zorgverlener is niet meer werkzaam bij de zorgaanbieder in de rol zoals opgenomen is in het mandaattoken.

Toelichting bij eis:

Er moet voorkomen worden dat verlopen mandaattokens in het systeem achterblijven en mogelijk onterecht gebruikt worden.

Indien een certificaat op de CRL is geplaatst, dan zal het mandaattoken vervangen moeten worden door een mandaattoken dat getekend is met een geldig certificaat. Afhankelijk van de reden waarom een certificaat op de CRL is geplaatst zal het mandaattoken meteen moeten worden verwijderd:

In het geval de registratie is ingetrokken van een zorgverlener, dan zal deze ook niet meer werkzaam mogen zijn bij de zorgaanbieder onder de betreffende rol en zal het mandaattoken dus volgens de eis verwijderd moeten worden.

Als een zorgverlener zijn pas is kwijtgeraakt, dan zal niet direct het mandaattoken ingetrokken hoeven te worden. Het is mogelijk om het mandaattoken te laten bestaan, totdat de zorgverlener een nieuwe pas heeft ontvangen.

Details

Eis:

Met betrekking tot het mandaattoken dienen vier zaken gelogd te worden:

• Mandaattoken; bij het aanmaken van een mandaattoken dienen de gegevens gelogd te worden zoals opgenomen in GBX.AUT.e4511.

• Mandaattoken; bij het verwijderen van een mandaattoken dient de einddatum en de unieke identifier van het mandaattoken gelogd te worden.

• Autorisatieregel; bij het aanmaken van een autorisatieregel dienen de gegevens gelogd te worden zoals opgenomen in GBX.AUT.e4514.

• Groepen; bij elke wijziging aan een groep, dienen de gegevens gelogd te worden zoals opgenomen in GBX.AUT.e4515. In het geval een autorisatieregel geen gebruik maakt van groepen, dan hoeft deze uiteraard ook niet gelogd te worden.

In opdracht van VZVZ, van een toezichthouder of van een andere geautoriseerde belanghebbende moeten bovenstaande loggevens te allen tijde inzichtelijk gemaakt kunnen worden.

Toelichting bij eis:

Ten behoeve van een audit trail moet precies kunnen worden nagegaan of een mandaattoken terecht gebruikt is.

Het is mogelijk om de te loggen gegevens, zoals zijn benoemd in de eis, in één gecombineerde log op te nemen. Hierbij moet dan wel na elke aanpassing van een van de drie genoemde zaken opnieuw gelogd worden.

Details

Eis:

Het moet mogelijk zijn om een overzicht te genereren van de inhoud van een mandaat op een gegeven moment in de tijd. Hierbij moet in één overzicht inzichtelijk kunnen worden gemaakt welke zorgverleners er geautoriseerd waren om een specifiek mandaattoken te gebruiken.

Toelichting bij eis:

In opdracht van VZVZ, van een toezichthouder of van een andere geautoriseerde belanghebbende moet te allen tijde inzichtelijk gemaakt kunnen worden of een bepaalde zorgverlener gerechtigd was om gebruik te maken van een bepaald mandaattoken.

Details

Eis:

In een autorisatieregel kunnen één of meerdere groepen van gemandateerden worden opgenomen.

Een groep bestaat in ieder geval uit de volgende elementen:

• Unieke identifier; dit kan een nummer of een groepsnaam zijn.

• Lijst met gemandateerden; een lijst kan bestaan uit bijvoorbeeld UZI-nummer(s) of rollen/functies.

Alleen na inloggen met tweefactorauthenticatie is het mogelijk om de lijst met gemandateerden dynamisch uit te breiden. De identifier hoeft niet aangepast te worden bij uitbreiding van de lijst met gemandateerden.

Toelichting bij eis:

Door het gebruik van groepen in een autorisatieregel is het mogelijk om dynamisch rolcodes of UZI-nummers toe te voegen aan de lijst met gemandateerden.

Mocht er gebruik worden gemaakt van een andere waarde dan UZI-nummer of rolcode, dan dient vanuit de logging te worden aangetoond welke UZI-nummer of rolcode er aan de waarde gekoppeld is.

Details

Eis:

Een mandaat kan alleen afgegeven worden op basis van een autorisatieregel. Een autorisatieregel bepaalt of een bepaalde zorgverlener gebruik mag maken van een specifiek mandaat.

De precieze invulling van een autorisatieregel is niet gespecificeerd. Dit is ter invulling van de zorginstelling. Een autorisatieregel moet in ieder geval wel de volgende attributen bevatten:

• Lijst met werkcontext(en); De werkcontext(en) bepaalt de context(en) waarbinnen een mandaat geldig is. Dit kan bijvoorbeeld gekoppeld zijn aan een afdeling of een werkproces.

• Lijst met gemandateerden; Dit kunnen UZI-nummer(s), lokale zorgverleneridentificaties of (lokaal gedefinieerde) rollen zijn. Er kan ook een groep(en) (GBX.AUT.e4514) worden opgenomen waar rolcodes of UZI-nummers aan gekoppeld zijn. Door het gebruik van groep(en) is het mogelijk om dynamisch rolcodes of UZI-nummers toe te voegen aan de lijst van gemandateerden.

• Uniek identificatiekenmerk; Een autorisatieregel moet uniek gekenmerkt worden. Een uniek gekenmerkte autorisatieregel behorende bij een afgegeven mandaat mag niet veranderlijk zijn.

Toelichting bij eis:

Lokaal moet duidelijk en uniek geregistreerd zijn hoe er invulling is gegeven aan een autorisatieregel. Op verzoek (van bijvoorbeeld een toezichthouder) moet kunnen worden aangetoond dat een gemandateerde ten tijde van het versturen van een bericht onder mandaat, inderdaad gerechtigd was om gebruik te maken van het mandaattoken (GBX.AUT.e4517).

Om een flexibel mandaat in te richten is het aan te raden om gebruik te maken van dynamische groepen in de autorisatieregel. Een groep wordt aangeduid door middel van een groepsnaam. De UZI-nummers die direct of indirect (door middel van de rolcode) gekoppeld worden aan een groepsnaam moeten op een veilige manier worden beheerd (eis GBX.AUT.e4514).

Indien een lokale gebruikersidentificatie wordt gebruikt, dan kan het LSP alleen bevraagd worden via de conditionele query. Dit zal dan in een zorgtoepassing specifiek worden vereist.

Een autorisatieregel mag niet aangepast worden. De attributen die zijn opgenomen in verwijzingen (zoals bijvoorbeeld bij de onder punt 2 genoemde groepen) mogen wel worden aangepast.

Autorisatieregels en de invulling met betrekking tot de werkcontext en de lijst met gemandateerden dienen in een beveiligde container te worden opgeslagen.

Autorisatieregels mogen alleen door een geautoriseerde medewerker worden ingezien.

De lijst met gemandateerden mag alleen door een geautoriseerde medewerker worden aangepast.

Details

Eis:

Een zorgverlener moet, wanneer hij lokaal is ingelogd op vertrouwensniveau midden, mandaten kunnen vastleggen, inzien en intrekken.

Gebruikers mogen uitsluitend mandaten vastleggen waarvoor zij mandaterende zijn.

Voor een mandaat worden tenminste de volgende gegevens vastgelegd:

• de ingangsdatum van het mandaat;

• de einddatum van het mandaat;

• het UZI-nummer van de mandaterende zorgverlener;

• de rolcode van de mandaterende zorgverlener;

• het abonneenummer (URA) van de zorgaanbieder waarbinnen het mandaat geldig moet zijn;

• een verwijzing naar een autorisatieregel (zie eis GBX.AUT.e4513) op basis waarvan een mandaat verkregen kan worden;

• een unieke identifier.

Met betrekking tot deze eis worden de volgende subeisen gedefinieerd:

• Het wijzigen van een mandaat is niet toegestaan. Het systeem dient in dat geval een nieuw mandaat aan te maken. Hierbij dient dus een nieuwe unieke identifier te worden opgenomen.

• De einddatum van het mandaat mag door een mandaatverlener leeg gelaten worden. In dat geval moet het systeem de vervaldatum van het handtekeningcertificaat opnemen als einddatum.

• De mandaatverlener mag geen einddatum invullen die na de geldigheidstermijn van zijn handtekeningcertificaat ligt. Het systeem dient dan een duidelijk foutmelding te genereren voor de gebruiker.

• De ingangsdatum van het mandaat mag in de toekomst liggen.

• Er kan alleen een mandaat worden afgesloten voor de eigen organisatie.

• Er dient een verwijzing naar een autorisatieregel te zijn opgenomen. Dit kan bijvoorbeeld door middel van een URI, die verwijst naar de daadwerkelijke inhoud van een autorisatieregel.

• Een autorisatieregel is niet uniek gekoppeld aan een mandaat. Het is dus mogelijk om naar dezelfde autorisatieregel te verwijzen in meerdere mandaten.

Toelichting bij eis:

-

Details

Eis:

Het systeem moet aan Opzoeken en tonen patiënteninformatie, Voorlopig koppelen van patiëntgegevens aan een BSN, Controleren geldigheid van een WID, en Bijhouden behandelrelatie voldoen of (bij implementatie in een GBZ) een koppeling kunnen leggen met een derde systeem dat aan die eisen voldoet.

Een systeem dat gebruik maakt van een extern patiëntadministrerend systeem is verplicht om te controleren of een BSN daadwerkelijk aan alle AORTA eisen voldoet m.b.t. het BSN.

Toelichting bij eis:

Ieder GBZ moet over een patiëntadministratie beschikken, maar een XIS hoeft die niet per se in te bouwen. Het staat een GBZ vrij een eigen patiëntadministrerend systeem te kiezen dat voldoet aan de genoemde eisen. De systeemrol van Patiëntadministrerend systeem is daarmee niet verplicht voor XIS-typekwalificatie, maar een GBZ moet wel aantoonbaar over een dergelijk systeem beschikken en dit met het gebruikte XIS hebben gekoppeld om zodoende te kunnen garanderen dat er in de XIS-instantie met geverifieerde BSN's gewerkt wordt. Die gerefereerde eisen hoeven dan niet voor de XIS-typekwalificatie te worden ingebouwd.

Hoe de controle wordt gedaan op de geldigheid van een BSN is aan de XIS-applicatie. Het is denkbaar dat de XIS-applicatie het patiëntadministrerende systeem actief benadert, maar het is ook mogelijk dat de XIS-applicatie de status van een BSN toegezonden krijgt. Er mogen in géén geval BSN's in een bericht worden opgenomen die niet voldoen aan de AORTA eisen.

Details

Eis:

Het systeem moet een gebruiker de mogelijkheid bieden een patiënt op te zoeken in de lokale patiëntadministratie van de zorgaanbieder, door het invoeren van identificerende gegevens, waarna wordt getoond:

• of de patiënt/cliënt is gevonden, en zo ja

• of het BSN wel/niet is opgevraagd of geverifieerd bij de SBV-Z

• de datum en tijd van het opnemen van de BSN in de patiëntadministratie

• de manier van vaststellen van de identiteit:

  • Controle van echtheid en geldigheidsdatum van WID en de gelijkenis van de in de WID genoemde identificerende gegevens

  • Vergewissen:

    •  indien beschikbaar het UZI-nummer of anders een unieke identificatie van de gebruiker en het UZI-nummer van mandaterende zorgverlener indien van toepassing

    •  in geval van WID-controle: aard en nummer van het WID.

Toelichting bij eis:

Deze eis voorkomt dat de SBV-Z telkens opnieuw wordt geraadpleegd.

Details

Eis:

Het systeem moet een gebruiker de volgende mogelijkheden bieden in de lokale patiëntadministratie voor een patiënt/cliënt.

De status van de behandelrelatie inzien, waarbij wordt getoond:

• of een behandelrelatie bestaat, en zo ja met welke zorgverleners (in ieder geval o.b.v. UZI) een behandelrelatie bestaat;

• ten behoeve van welke zorgaanbieder (in ieder geval o.b.v. URA) de behandelrelatie wordt onderhouden.

Een nieuwe behandelrelatie beginnen, waarbij wordt vastgelegd:

• begindatum;

• UZI-nummer van de zorgverlener;

• de URA van de zorgaanbieder ten behoeve van wie de behandelrelatie onderhouden wordt.

Een bestaande behandelrelatie beëindigen, waarbij wordt vastgelegd:

• einddatum;

• UZI-nummer van de zorgverlener.

Toelichting bij eis:

De zorgverlener onderhoudt de behandelrelatie hetzij ten behoeve van de zorgaanbieder waarvoor hij werkzaam is, hetzij als zorgaanbieder indien het een zelfstandig werkende beroepsbeoefenaar betreft.

Een zorgverlener die de patiënt/cliënt niet ziet, bijvoorbeeld in een laboratorium, legt een behandelrelatie vast in de zin van een verklaring dat hij werkt in opdracht van een andere zorgverlener die een behandelrelatie met de patiënt/cliënt heeft.

Details

Eis:

Het systeem moet voor een geselecteerde patiënt/cliënt de gebruiker de mogelijkheid bieden:

• het 'in omloop mogen zijn' van het WID te controleren door raadplegen van de SBV-Z op basis van aard en nummer van het WID;

• in de lokale patiëntenindex vast te leggen dat hij 'het in omloop mogen zijn' van het WID heeft gecontroleerd, onder vermelding van:

             - resultaat van de controle;

             - datum en tijd;

             - indien beschikbaar het UZI-nummer of anders een unieke identificatie van de gebruiker;

             - aard en nummer van het WID.

• de onder 2. vastgelegde informatie op elk gewenst moment te raadplegen.

Toelichting bij eis:

Dit is belangrijk voor een zorgverlener/medewerker die in geval van twijfel over de echtheid of geldigheid van een WID wil nagaan of deze in omloop mag zijn. Hiertoe biedt de SBV-Z een dienst om te kunnen controleren of een bepaald WID in omloop is.

Details

Eis:

Het systeem moet voor een geselecteerde patiënt/cliënt de gebruiker:

• de mogelijkheid bieden gewaarschuwd te worden indien nog niet is vastgesteld dat het BSN hoort bij de patiënt/cliënt;

• de mogelijkheid bieden in de lokale patiëntenindex vast te leggen dat hij heeft vastgesteld dat het betreffende BSN hoort bij de patiënt/cliënt, onder vermelding van:

  • de manier van vaststellen:

    • i. Controle van echtheid en geldigheidsdatum van WID en de gelijkenis van de in de WID genoemde identificerende gegevens,

    • ii. Vergewissen,

  • Datum en tijd van vaststellen,

  • indien beschikbaar het UZI-nummer of anders een unieke identificatie van de gebruiker, en het UZI-nummer van mandaterende zorgverlener indien van toepassing.

  • zorgaanbieder-id van de gebruiker (URA of een door VZVZ uitgegeven organisatieID);

  • in geval van WID-controle: aard en nummer van het WID.

Daarmee is het BSN definitief gekoppeld.

Toelichting bij eis:

Dit is belangrijk voor een zorgaanbieder die (geautomatiseerd) wil vaststellen of is voldaan aan de eventuele wettelijke verplichting om de identiteit vast te stellen aan de hand van een WID.

Merk op dat de toelichting op Wet gebruik burgerservicenummer in de zorg artikel 26 een grote verantwoordelijkheid legt bij de zorgaanbieder voor de afweging wel/niet WID controleren. Daarom is geautomatiseerde ondersteuning belangrijk.

Manier van vaststellen:

• Vaststellen identiteit; Bij inschrijving van een patiënt waar nog geen behandelrelatie mee is, is het verplicht de identiteit van de patiënt vast te stellen aan de hand van een Wettelijk Identificatie Document (WID): een paspoort, Nederlands rijbewijs, Nederlandse ID-kaart of Nederlands vreemdelingendocument.

• WID-controle; Indien er wordt getwijfeld over de geldigheid van een identiteitsdocument, kan bij de Sectorale Berichten Voorziening in de Zorg (SBV-Z) een WID-controle worden uitgevoerd. Dit kan via een zorginformatiesysteem of via de website van SBV-Z.

• Opvragen/verifiëren BSN; Hierna moet het BSN geverifieerd worden en registreren worden dat deze verificatie heeft plaatsgevonden. Alle door VZVZ geaccepteerde zorginformatiesystemen ondersteunen deze mogelijkheid. Komt BSN van een patiënt via een andere zorgverlener? Dan hoeft het niet opnieuw geverifieerd te worden. Ook als het nummer direct uit de BRP komt , kunt BSN-verificatie achterwege worden gelaten.

Het systeem kan hierna overgaan tot het vrijgeven en aanmelden van de bij de patiënt/cliënt behorende gegevens.

Details

Eis:

Het systeem moet een gebruiker de mogelijkheid bieden het door een burgerregister geretourneerde BSN te koppelen aan de identificerende gegevens in de lokale patiëntenindex waarbij bij het overgenomen BSN automatisch wordt vastgelegd:

• de bron van het BSN;

• datum en tijd van koppelen;

• UZI-nummer of andere identificatie van de gebruiker.

Er is dan sprake van een voorlopige koppeling tussen BSN en patiëntgegevens.

Toelichting bij eis:

Dit is nodig opdat een zorgverlener/medewerker kan voldoen aan de wettelijke verplichting van de zorgaanbieder om het BSN op te nemen in zijn administratie, zie Wbsn-z artikel 8. Voor het landelijk uitwisselen van medische patiëntgegevens moet de SBV-Z of de GBA / BRP zijn geraadpleegd.

Details

Eis:

Een geboortedatum die teruggegeven wordt door de SBV-Z kan nullen bevatten (jjjjmm00, jjjj0000 of 00000000). Het XIS moet in staat zijn hiermee adequaat om te gaan zonder dat de applicatie vastloopt.

Deze eis leidt tot de volgende aanvullende eisen:

• Een XIS moet de mogelijkheid hebben om een BSN op te vragen of te verifiëren op basis van de Zoekpaden 1 en 2.

• Bij het overnemen van de gegevens uit de SBV-Z moet het voor de gebruiker mogelijk zijn om de geboortedatum aan te passen voor het opslaan, indien het systeem meldt dat de gegevens niet in de database kunnen worden opgeslagen.

• Bij het aanpassen van de geboortedatum in een databasegeaccepteerde datum moet er een indicatie komen dat de geboortedatum handmatig is aangepast. (bijvoorbeeld andere kleur of een indicatie erbij). Nog mooier is de opgeleverde datum opslaan in een (apart) tekstveld.

• De dienst ‘opvragen persoonsgegevens op basis van BSN’ moet kunnen worden uitgevoerd, ook als er al persoonsgegevens bekend zijn maar de verificatie mislukt is vanwege de geboortedatum. Hierbij kan er een dialoogvenster wordt getoond waarbij de gegevens van de SBV-Z worden vergeleken met die uit de database van de zorgverlener.

• Een aanpassing van de geboortedatum mag niet leiden tot ‘het niet geverifieerd zijn van het BSN’. Dit geldt echter alleen tijdens de dialoog van vergelijken. Indien de geboortedatum buiten de dialoog om aangepast wordt, moet dit wel leiden tot het vervallen van de verificatie.

Toelichting bij eis:

-

Details

Eis:

Grote storingen in een GBx mogen niet meer dan gemiddeld 2 keer per jaar voorkomen en dienen dan binnen 1 dag te zijn opgelost.

Toelichting bij eis:

De term 'grote storing' is niet SMART gedefinieerd. Het kan vele soorten storingen betreffen. Het doel van deze eis is om te voorkomen dat een GBx na een ernstige storing zeer lang onbeschikbaar blijft. Onbeschikbaarheid zou bijvoorbeeld kunnen komen omdat er geen onderhoudscontract is en daardoor de hulp slechts langzaam op gang komt.

Deze eis betekent voor de zorgaanbieder dat hij behalve professioneel beheer ook snel moet kunnen terugvallen op zijn XIS-leverancier, GZN en/of andere ICT-leveranciers. Zo moet bij ernstige storing, snel een leverancier beschikbaar zijn om het probleem te verhelpen. Wellicht kunnen zijn ICT-leveranciers hem een 24-uurs onderhoudscontract bieden. Indien de zorgaanbieder een ASP-leverancier heeft geselecteerd voor zijn XIS, zal hij dit wellicht geheel delegeren aan die ASP-leverancier.

Details

Eis:

Kleine storingen in een GBx mogen niet meer dan gemiddeld 1 keer per maand voorkomen en dienen dan binnen 10 werkdagen te zijn opgelost.

Toelichting bij eis:

De term 'kleine storing' is niet SMART gedefinieerd. Het kan vele soorten storingen betreffen. Het doel van deze eis is om te voorkomen dat een GBZ te vaak uitvalt en na een eenvoudig te verhelpen storing meteen langere tijd onbeschikbaar blijft.

Deze eis betekent voor de zorgaanbieder dat zijn ICT-voorzieningen professioneel moet (laten) beheren. Dit vergt periodieke controle met eventueel preventief onderhoud. Verder moet een onverhoopte storing meteen worden gesignaleerd, zodat een GBZ-beheerder snel beschikbaar kan zijn om het probleem te verhelpen. Wellicht kan zijn XIS-leverancier hem daarbij helpen. Indien de zorgaanbieder een ASP-leverancier heeft geselecteerd voor zijn XIS, zal hij dit wellicht geheel delegeren aan die ASP-leverancier. De afspraken en procedures zoals opgenomen in de AORTA DAP dienen hierbij gevolgd te worden.

Details

Eis:

Gepland onderhoud van een GBX-applicatie mag niet meer dan twaalf keer per jaar voorkomen en dient niet langer dan een uur te duren. Gepland onderhoud wordt bij voorkeur uitgevoerd binnen aangetoonde daluren.

De beheerders van de ZIM moeten twee weken van te voren worden ingelicht door de systeembeheerder.

Toelichting bij eis:

Deze eis is nodig om te voorkomen dat een GBx wegens onderhoud onnodig lang onbereikbaar is, ze betekent voor de organisatie dat onderhoud van de ICT-voorzieningen zoveel mogelijk wordt gepland en zodanig voorbereid dat het GBx slechts kort onbeschikbaar hoeft te zijn.

Implicaties:

Deze eis betekent voor de organisatie dat onderhoud van de ICT-voorzieningen zoveel mogelijk wordt gepland en zodanig voorbereid dat het GBX slechts kort onbeschikbaar hoeft te zijn.

Details

Eis:

Met uitzondering van gepland onderhoud dient een GBx-applicatie te allen tijde beschikbaar te zijn voor het afhandelen van berichten.

{GBZ} {GBP} De totale beschikbaarheid is minimaal 99,5%.

{GBK} De totale beschikbaarheid is minimaal 90,0%.

{GBO} De beschikbaarheid van het systeem is afhankelijk van procedurele afspraken tussen de uitwisselende partijen.

Toelichting bij eis:

Deze eis is nodig om te voorkomen dat een organisatie, die patiëntgegevens beschikbaar stelt of bereikbaar moet zijn om patiëntgegevens te ontvangen, de voor deze zaken benodigde systemen aan het eind van de werkdag uitschakelt. Deze eis betekent dat deze ICT-voorzieningen nagenoeg continu operationeel moeten zijn. De beschikbaarheid wordt als een voortschrijdend gemiddelde berekend. Omdat het GBK signaleringen kan ontvangen, is de eis verplicht voor GBK.

Implicaties:

Deze eis betekent dat deze ICT-voorzieningen nagenoeg continu operationeel moeten zijn. De beschikbaarheid wordt als een voortschrijdend gemiddelde berekend.

Details

Eis:

Data die persoonsgegevens bevatten dienen versleuteld en beveiligd te worden opgeslagen. Het gaat hierbij om alle opgeslagen data (bv. logging en backups).

Toelichting bij eis:

In principe moet alle data met persoonsgegevens worden geëncrypt. Dit betreft o.a. gegevens die worden opgeslagen ten behoeve van een autorisatiesessie. Mocht hiervan met het oog op systeemprestaties van afgeweken worden, dan dient dit overlegd te worden met VZVZ.

Details

Eis:

Een GBx dient een {GBx}UZI- of {GBK}{GBP}{GBO} PKIO-servercertificaat te hebben dat op naam staat van de opdrachtgever en is gecertificeerd door een Certificate Authority (CA) onder de root van de Staat der Nederlanden.

Toelichting bij eis:

Deze eis is nodig opdat de authenticiteit van het GBx en de exclusiviteit van getransporteerde gegevens door een Trusted Third Party (TTP) kan worden gewaarborgd.

Details

Eis:

Als een GBx voor een systeemrol is aangesloten op de ZIM, moet dat GBx patiëntgegevens in het kader van die systeemrol ook daadwerkelijk uitwisselen onder de regie van de ZIM.

Toelichting bij eis:

Alle aan AORTA deelnemende partijen zijn gebaat bij een zo volledig mogelijk beeld van relevante patiëntgegevens, daarom is het van belang dat aangesloten partijen hun gegevens ook daadwerkelijk beschikbaar maken via AORTA.

Details

Eis:

Voor een GBx moet zijn gedefinieerd:

• welke landelijke toepassingen en systeemrollen worden ondersteund en gebruikt;

• hoe de grenzen van het GBx lopen door de ICT-voorzieningen van de organisatie;

• hoe en wanneer patiëntgegevens die grenzen kunnen passeren;

• hoe wordt gewaarborgd dat patiëntgegevens in de dossiers en postbussen niet kunnen lekken naar onbetrouwbare bestemmingen;

• hoe wordt gewaarborgd dat patiëntgegevens uit onbetrouwbare bronnen niet kunnen terechtkomen in de dossiers en postbussen of de ZIM;

• hoe wordt gewaarborgd dat anderen dan bevoegde gebruikers geen fysieke toegang tot (delen van) het GBx kunnen krijgen.

Toelichting bij eis:

Deze eis is nodig om te voorkomen dat patiëntgegevens, bijvoorbeeld via een andere applicatie, door willekeurige medewerkers kunnen worden benaderd terwijl de organisatie zijn GBx heeft beveiligd met firewalls, authenticatie- en vertrouwensmiddelen.

Details

Eis:

Een GBx moet zodanig zijn ingericht dat:

1. passen met SHA-256-certificaten gelezen en gebruikt kunnen worden;

2. paslezers gekoppeld zijn aan werkplekken van gebruikers;

3. de PIN-code die ten behoeve van een authenticatiemiddel wordt ingetoetst op een werkplek, exclusief wordt aangeboden aan de gekoppelde paslezer,

4. {GBx} alle gegevens in berichten die ten behoeve van een gebruiker worden ontvangen exclusief aan die gebruiker worden gepresenteerd;

5. {GBK} alle gegevens in HL7-berichten die ten behoeve van een patiëntopdracht worden ontvangen exclusief gekoppeld worden aan de betreffende patiëntopdracht.

6. geborgd wordt dat:

• {GBx} het in het bericht vermelde UZI-nummer en de rolcode van de auteur overeenkomen met de UZI-pashouder die het bericht heeft geïnitieerd;

• {GBK} het in het bericht vermelde certificaatnummer en CA van de auteur overeenkomen met de PKIO-pashouder die het bericht heeft geïnitieerd;

• {GBx} de auteur inderdaad is gemandateerd door de in het bericht vermelde (eind)verantwoordelijke, of dezelfde persoon is;

• {GBx} de in het bericht vermelde URA van auteur, (eind)verantwoordelijke en zorginstelling aan elkaar gelijk zijn;

• {GBK} de in het bericht vermelde instellingsindicatie van de auteur het klantenloket is;

• {GBK} de instelling van de verantwoordelijke niet ingevuld is.

Details

Eis:

Een GBx dient voor gebruikersinteracties, na het commando van een gebruiker of een daaropvolgende ontvangst van een bericht van de ZIM, binnen 0,3 seconden het aangegeven resultaat te hebben bereikt.

Toelichting bij eis:

Deze eis is nodig om te voorkomen dat een zorgaanbieder bij zijn GZN of het LSP gaat klagen over te lange responstijden terwijl de oorzaak misschien ligt bij bijv. een eigen computer die in beslag wordt genomen door andere toepassingen of een lokaal netwerk met onvoldoende bandbreedte.

Deze eis betekent voor de zorgaanbieder dat hij zijn XIS-applicatie moet installeren op ICT-voorzieningen met voldoende prestaties. Zonodig moeten bijv. de computers worden ingeregeld op de behoefte van deze XIS-applicatie, bijv. als ze ook worden gebruikt voor andere toepassingen. Wellicht kan zijn XIS-leverancier helpen bij het selecteren en inregelen van ICT-voorzieningen. Indien de zorgaanbieder een ASP-leverancier heeft geselecteerd voor zijn XIS, kan hij dit voor de centrale ICT-voorzieningen wellicht overlaten aan die ASP-leverancier, maar moeten de lokale werkplekken niet vergeten worden.

Details

Eis:

Een GBx dient minimaal de hieronder genoemde snelheden te halen voor de hieronder genoemde interactiemechanismen.

Interactiemechanisme Minimale verwerkingssnelheid

Sturen van gegevens 100 kb/sec

Opvragen van gegevens 100 kb/sec

Een GBx dient een zodanige capaciteit te hebben voor het beantwoorden en ontvangen van berichten van de ZIM dat het kan voldoen aan de gestelde verwerkingssnelheden. Indien dat als gevolg van een onverwacht hoge piekbelasting tijdelijk niet mogelijk is, dan prevaleren de eisen inzake beschikbaarheid boven de eisen inzake verwerkingssnelheid.

Toelichting bij eis:

Deze eis is nodig opdat een XIS-applicatie tijdig berichten van de ZIM kan verwerken/beantwoorden ten behoeve van andere zorgaanbieders, ook als de belasting zodanig hoog is, dat de volgende berichten binnenkomen terwijl de vorige nog niet verwerkt/beantwoord zijn.

Deze eis betekent voor de organisatie dat de applicatie is geïnstalleerd op ICT-voorzieningen met voldoende capaciteit om een variabele belasting van berichten vanwege de ZIM te kunnen verwerken. Omdat de exacte belasting per GBx flink kan verschillen moet iedere organisatie zelf een inschatting maken van de benodigde capaciteit en ervoor zorgen dat het GBx die belasting aankan.

Details

Eis:

GBZ-beheerder moet er namens de eigenaar van het GBZ op toezien dat uitsluitend productiesystemen gekoppeld worden aan de productie-omgeving van het LSP. Overtredingen van deze eis zullen gemeld worden aan de eigenaar van het GBZ.

Toelichting bij eis:

Vanwege mogelijke beveiligingsrisico's en kwaliteitgaranties in de keten mogen er alleen GBZ-en met een geaccepteerde XIS-applicatie aansluiten op de productie-omgeving van het LSP .

Bij het niet naleven van bovenstaande eis behoudt VZVZ zich het recht voor op aanvullende sancties.

Details

Eis:

Een GBx dient NTP te gebruiken voor tijdsynchronisatie met de ZIM. De tijdklok van een GBx mag niet meer dan een halve seconde afwijken van de tijdklok van de ZIM.

Toelichting bij eis:

Deze eis is nodig om te voorkomen dat de tijdklok van het GBx gaat afwijken van de tijdklok van de ZIM. Voor eenzelfde interactie tussen een GBx en de ZIM moeten beide systemen immers dezelfde tijdstempels loggen. Dit is belangrijk wanneer de toezichthouder of patiënt een geval van vermeend onrechtmatige uitwisseling van patiëntgegevens wil onderzoeken en daartoe zowel de lokale toegangslog van het GBx als de centrale toegangslog van het LSP wil raadplegen.

Deze eis betekent voor de organisatie dat er binnen het GBx een NTP-client is geïnstalleerd en dat deze is afgestemd op de NTP-server van de ZIM. Ook is het mogelijk dat de GZN een gezamenlijke NTP-client beheert voor alle aangesloten zorgaanbieders en op een andere wijze klaarspeelt dat de tijdklok van hun GBx’en gelijk lopen met die van de ZIM.

Deze eis betekent voor de organisatie dat het GBx periodiek moet synchroniseren tegen een NTP-server om synchroon te blijven met de ZIM.

Details

Eis:

Een GBx moet bereikbaar zijn voor de ZIM:

• {GBx}{GBO} via het IP-adres dat is toegekend aan het GBx en dat is verkregen door DNS-vertaling van de hostnaam van dat GBx;

• {GBK} via het IP-adres dat door het LSP is toegekend aan het GBK en dat is verkregen door DNS-vertaling van de hostnaam van dat GBK;

• {GBP} via het IP-adres en de fully qualified domain name (FQDN) die door het LSP zijn toegekend aan het GBP en waarvoor het LSP de DNS-vertaling biedt.

De ZIM moet bereikbaar zijn vanuit een GBx via het IP-adres van de operationele ZIM, dat is verkregen door DNS-vertaling van de hostnaam van de ZIM.

Voor de DNS-vertaling geldt dat:

• de hostnaam een maximale time-to-live (TTL) heeft voor verversing van de cache;

• het IP-adres van de ZIM zich binnen een vooraf overeengekomen range bevindt die altijd gerouteerd moet worden naar de GZN;

• een systeem vanuit de applicatie alleen benaderd mag worden op de FQDN. Vertaling naar IP-adres wordt door de DNS uitgevoerd.

Een GBx mag de volgende IP-adressen niet intern gebruiken:

• het IP-adres dat door het LSP is uitgegeven voor het GBx als geheel,

• de IP-adressen die zijn gereserveerd voor de ZIM,

• de IP-adressen uit het landelijke IP-nummerplan van het LSP.

Toelichting bij eis:

Deze eis is nodig om ervoor te zorgen dat FQDN en IP-adressen op een juiste wijze worden ingesteld.

Deze eis is ook nodig voor het gebruik van een ZIM op twee operationele locaties en om IP-netwerkconflicten te voorkomen.

Deze eis betekent voor de organisatie dat die voor zijn GBx/GBO een FQDN moet krijgen van zijn GZN en deze laten registreren bij het LSP of bij SIDN. De GZN zal daaraan een IP-adres toekennen. De organisatie moet het toegekende IP-adres tenslotte (laten) configureren in zijn netwerkapparatuur binnen zijn GBx. Deze eis betekent dat een applicatie een ZIM expliciet op naam benadert en dat systemen geconfigureerd moeten worden voor het gebruik van DNS. Door middel van DNS-resolving kan voor het GBx transparant gebruik gemaakt worden van de operationele ZIM op locatie 1 of locatie 2.

Details

Eis:

Een GBx dient via een DCN van een gekwalificeerde GZN te communiceren met het LSP.

Toelichting bij eis:

Organisaties kunnen bij VZVZ verifiëren of een netwerkaanbieder over een GZN-kwalificatie beschikt.

Details

Eis:

Het systeem moet alle binnenkomende en uitgaande berichten loggen in de toegangslog. Hierbij dienen onderstaande gegevens gelogd te worden, indien aanwezig in het bericht:

de identiteit van de patiënt/cliënt/burger (BSN) waar het bericht betrekking op heeft;

de identiteit van de organisatie waar het bericht vandaan komt of naar toe wordt gestuurd;

de functie en identiteit van de zorgverlener, medewerker of patiënt zoals opgenomen in het verstuurde en/of ontvangen bericht. De functie is de AORTA-rolcode zoals opgenomen in het claim-element van het transactietoken.

de gebruikersinteractie-id. Dit is een combinatie van HTTP-operatie, de URL inclusief de ontvangen zoekparameters en de contentVersion uit de AORTA-Version header;

het tijdstip en tijdzone (ten opzichte van UTC) van het moment dat het bericht ontvangen/verstuurd is;

het bericht-id van het ontvangen/verstuurde bericht. Dit is het requestID in de HTTP header;

het initiële bericht-id van het ontvangen/verstuurde bericht. Dit is het initialRequestID in de HTTP header;

de aan het bericht gekoppelde gegevensdienst. Dit is de waarde zoals opgenomen in de scope van het transactietoken;

een indicatie van eventueel opgetreden foutsituaties met betrekking tot het ontvangen en verzenden van de berichten. Hierbij dient de HTTP-foutcode, alle informatie in de eventueel aanwezige OperationOutcome en de eventuele WWW-Authenticate HTTP response header gelogd te worden.

Toelichting bij eis:

Het doel van de logging is het inzichtelijk kunnen maken van de datastroom door de gehele keten. Het inzichtelijk maken van de loggegevens kan van belang zijn voor auditredenen of beheerwerkzaamheden zoals het oplossen van fouten in de keten.

Deze eis is conform de vereisten zoals beschreven in de NEN7513.

Voor de invulling van de velden zoals genoemd in de eis, gelden de standaardnotaties zoals opgenomen in de NEN713, tenzij anders is vermeld in de eis.

Details

Eis:

Er dient hardening op de diverse systeemlagen te worden toegepast. Het gaat hierbij om hardening op het niveau van operating system, middleware en database.

Alle systeemparameters dienen zodanig te zijn ingesteld dat met behoud van de gewenste functionaliteit een zo hoog mogelijk niveau van beveiliging bestaat.

Toelichting bij eis:

De intentie van deze eis is dat datgene wordt gedaan dat in de markt onder de gangbare maatregelen wordt gerekend op het gebied van hardening. Hierbij moet er uiteraard een afweging worden gemaakt tussen gebruiksvriendelijkheid en veiligheid.

Details

Eis:

Het GBx dient voor het landelijk uitwisselen van patiëntgegevens een TLS-sessie met de ZIM met de volgende kenmerken te accepteren:

• tweezijdige authenticatie met behulp van het UZI-servercertificaat van het GBZ en het servercertificaat van de ZIM,

• tijdelijke sleutels die elke 5 minuten ververst worden,

• gebruikmakend van Cipher Suites die door het NCSC minimaal worden gekenmerkt als goed en tevens worden ondersteund door de ZIM. Voor encryptie moet altijd de sterkste vorm als eerste worden geprobeerd,

• een maximale sessieduur van 8 uur,

• een maximale ongebruikte TLS-sessie van 15 minuten.

Toelichting bij eis:

Dit is nodig opdat de ZIM een voldoende hoog beveiligingsniveau kan afdwingen bij het opzetten van een TLS-sessie met een GBx.

Dit betekent voor de zorgaanbieder dat hij of zijn XIS-leverancier de bovenstaande parameters moet instellen in de TLS-library in de betrokken XIS-applicatie(s) en/of de eventuele communicatieserver.

Details

Eis:

Een GBZ dient voor transportbeveiliging een ander servercertificaat te gebruiken dan voor berichtauthenticatie. De verschillende certificaten horen daarbij in verschillende componenten ondergebracht te zijn in de architectuur van het XIS.

Toelichting bij eis:

Deze eis is conform NIST SP 800-57 norm; iedere XIS zou aparte sleutels moeten hanteren voor verschillende doeleinden.

Deze eis impliceert dat een XIS een ander certificaat moet gebruiken voor TLS dan voor het ondertekenen van transactietokens.

De applicaties van zorgaanbiedertype Ziekenhuis en Zelfstandig Behandelcentra (ZBC) dienen gebruik te maken van twee aparte servercertificaten zoals opgenomen in de eis. Alle overige zorgaanbiedertypes kunnen volstaan met applicaties waarbij gebruik wordt gemaakt van één servercertificaat. Indien door de zorgaanbieder zelf gewenst (bijvoorbeeld uit netwerk technische praktische overwegingen) dan zijn twee aparte servercertificaten uiteraard toegestaan.

Condities:

De verplichting voor het gebruik van een separaat certificaat is afhankelijk van de grootte van de zorgaanbiederorganisatie. Deze eis zal in overleg met VZVZ wel of niet toegepast dienen te worden.

Details

Eis:

Het GBx moet na het beschikbaar worden voor de ZIM:

verzoeken van de ZIM voor het opzetten van nieuwe TLS-sessies honoreren ten behoeve van berichtuitwisseling voor andere zorgaanbieders,

{GBx}{GBK}{GBO} voor gebruikers die landelijk patiëntgegevens willen uitwisselen, een of meer TLS-sessies met de ZIM (her)gebruiken voor berichtuitwisseling als gevolg van gebruikersfuncties.

Toelichting bij eis:

Deze eis is nodig opdat een GBx beveiligd kan communiceren met de ZIM volgens bewezen technologie op eigen initiatief en op initiatief van de ZIM.

Details

Eis:

Tokens moeten behandeld worden als medische gegevens (volgens de NEN7510).

Binnen de organisatie moet er een speciale rol toegewezen (en geautoriseerd) worden om toegang te krijgen tot de diverse opgeslagen tokens (inschrijf- en mandaattoken).

Toelichting bij eis:

Ten behoeve van beheermaatregelen moet het mogelijk zijn om toegang te krijgen tot de beveiligde container waar de tokens zijn opgeslagen. Toegang tot deze tokens moet ter voorkoming van misbruik van de tokens beperkt zijn tot daarvoor aangewezen rollen.

Details

Eis:

De GBx-beheerder moet de volgende configuratieparameters in het GBx kunnen instellen:

URI en hostnaam van de ZIM,

applicatie-id van de eigen applicatie,

applicatie-id van het productieschakelpunt waarop kan worden aangesloten.

Toelichting bij eis:

Dit is nodig opdat een GBx deze parameters kan gebruiken bij de HTTP-communicatie met en authenticatie van de ZIM.

De in het GBx ingestelde waarden komen overeen met de in het applicatieregister van de ZIM geregistreerde gegevens.

Details

Eis:

Binnen het GBx dient te worden bijgehouden welke UZI-passen worden toegelaten voor gebruik. Deze gebruikersregistratie is uitsluitend toegankelijk voor de rol van autorisatiebeheerder, na authenticatie op basis van een sterk authenticatiemiddel (tweefactorauthenticatie bijvoorbeeld via een UZI-pas).

Toelichting bij eis:

Dit is nodig om te voorkomen dat een willekeurig persoon de gebruikersregistratie kan aanpassen.

Dit betekent voor de zorgaanbieder dat hij invulling moet geven aan de rol van autorisatiebeheerder.

Details

Eis:

Het GBx dient voor het landelijk uitwisselen van patiëntgegevens een TLS-sessie met de ZIM met de volgende kenmerken op te zetten:

• tweezijdige authenticatie met behulp van het servercertificaat van de ZIM en het servercertificaat van het GBx;

• tijdelijke sleutels die elke 5 minuten ververst worden door middel van TLS Secure Renegotiation;

• gebruikmakend van Cipher Suites die door het NCSC minimaal worden gekenmerkt als goed;

• gebruikmakend van de sterkste cipher suite die gedeeld wordt met de ZIM;

• gebruikmakend van de hoogste toegestane TLS-versie die door beide partijen wordt ondersteund;

• een ongebruikte TLS-sessie van maximaal 15 minuten.

Toelichting bij eis:

Dit is nodig opdat een GBx een voldoende hoog beveiligingsniveau kan afdwingen bij het opzetten van een TLS-sessie met de ZIM.

Dit betekent voor de organisatie dat hij of zijn XIS-leverancier de bovenstaande parameters moet instellen in de TLS-library in de betrokken applicatie(s) en/of de eventuele communicatieserver. Het GBx is niet in staat te controleren of de ZIM daadwerkelijk het (server)certificaat van de GBx opvraagt, maar mag er impliciet van uitgaan dat dit gebeurt en dat de ZIM het certificaat ook controleert. Hiermee wordt tweezijdige authenticatie bewerkstelligd.

Details

Eis:

Het systeem moet een gebruikerssessie voor het landelijk uitwisselen van patiëntgegevens op vertrouwensniveau laag of midden afsluiten:

• op commando van de gebruiker (zoals een muisklik of toetsencombinatie);

• door uitnemen van het vertrouwensmiddel door de zorgverlener/medewerker;

• wanneer de applicatie gedurende maximaal 60 minuten niet is gebruikt. Deze tijd dient instelbaar te zijn in het systeem, maar mag niet de 60 minuten overschrijden;

• wanneer de sessie gedurende 1 uur open staat;

• IP-adres van gebruiker gedurende een sessie wijzigt.

Toelichting bij eis:

Dit is nodig opdat een gebruiker zelf zijn gebruikerssessie kan uitloggen met de zekerheid dat niemand anders zijn sessie kan voortzetten en vervolgens zijn bevoegdheden kan misbruiken. Daarnaast is deze eis nodig om te tegen te gaan dat een in onbruik geraakte sessie door een onbevoegde kan worden misbruikt.

Details

Eis:

Het GBx dient het starten van een gebruikerssessie op vertrouwensniveau midden te weigeren indien:

de geldigheidstermijn van het transactietoken is verlopen of nog niet is aangevangen;

het transactietoken niet correct is ondertekend;

het certificaat, waarmee het transactietoken is getekend, op een geldige lijst staat van ingetrokken certificaten (CRL) van het UZI-register;

het transactietoken is geweigerd door het LSP.

Toelichting bij eis:

Deze eis is conform de regels van PKI Overheid. Er moet voorkomen worden dat een GBZ toegang geeft als gevolg van een ongeldige UZI-pas.

Alleen een gebruiker die een UZI-pas heeft en de pincode weet en een geaccepteerde applicatie met een geldig UZI-servercertificaat, kan een geldig transactietoken genereren.

Details

Eis:

Het systeem moet een gebruiker de mogelijkheid bieden een gebruikerssessie op vertrouwensniveau midden te starten door:

{GBx}{GBK}het invoeren van zijn vertrouwensmiddel op de werkplek en het invoeren van de bijbehorende toegangscode;

{GBP} zich op niveau DigiD-midden te authentiseren.

{GBx} Een GBx dient hierbij een UZI-pas toe te laten indien:

de UZI-pas is geregistreerd in de gebruikerstabel (zie ook eis GBX.FBH.e4030);

de UZI-pas nog geldig is;

het passen betreft die zijn uitgegeven onder de op dat moment geldende certificaatboom of –bomen. (SHA-256).

Hierbij dient de applicatie te controleren of het certificaat op de pas niet op de CRL staat.

{GBK} Een GBK dient hierbij een PKIO-pas toe te laten indien de betreffende medewerker geautoriseerd is voor toegang tot de GBK-applicatie en te weigeren in de overige gevallen.

Toelichting bij eis:

Dit is nodig opdat gebruikers in staat worden gesteld tot het landelijk uitwisselen van gegevens op vertrouwensniveau midden.

VZVZ biedt gratis generieke tooling in de vorm van ZORG-ID om de implementatie van het authentiseren met de UZI-pas te ondersteunen.

Details

Eis:

Het GBx dient voor berichtuitwisseling met de ZIM de volgende protocolstack te gebruiken:

• HL7 FHIR

• JWT

• HTTP v1.1/HTTP v2.0

• TLS 1.3

• TCP

• IPv4

Toelichting bij eis:

Het is niet toegestaan om een lagere protocolversie te hanteren dan die in deze protocolstack vermeld is.

Details

Eis:

Het GBx dient alleen de keten van Certificate Authorities (CA's) van het GBX-certificaat kenbaar te maken aan de ZIM in het “certificate request” bericht van de TLS-handshake, waaronder ook het stamcertificaat (Root CA) van de keten.

Toelichting bij eis:

Dit is nodig opdat een GBx beperkt kenbaar maakt welke CA's het vertrouwt.

Dit betekent voor de zorgaanbieder dat hij of zijn XIS-leverancier selectief om moeten gaan met het aantal CA's waarmee de betrokken XIS-applicatie(s) en/of de eventuele communicatieserver worden opgezet.

Details

Eis:

Het GBx dient UZI/PKIo-servercertificaten van de (verschillende) generatie(s) te ondersteunen zoals beschikbaar wordt gesteld door het UZI-Register.

Er moet gebruik worden gemaakt van het SHA-256 ondertekeningsalgoritme.

Toelichting bij eis:

Het UZI-register geeft UZI-servercertificaten uit onder één of meerdere certificaatbomen. In het geval er onder diverse certificaatbomen UZI-servercertificaten wordt uitgegeven, is het zaak om alle servercertificaten uitgegeven onder de diverse certificaatbomen te kunnen ondersteunen. 

Een GBX-communicatieserver dient te zijn ingericht op het ondertekeningalgoritme SHA-256.

Details

Eis:

Een zorgaanbieder is verplicht om vóór in gebruik name van de conditionele query (CQ) functionaliteit een zelftoetsingvragenlijst (ook wel self assessment genoemd) m.b.t. de CQ ingevuld en ondertekend verzonden te hebben aan VZVZ. Deze zelftoetsingvragenlijst dient elke 3 jaar opnieuw ingevuld te worden.

Toelichting bij eis:

De Conditionele query wordt ook wel aangeduid als de oplossing voor vereenvoudigd gebruik UZI-pas. In lijn met de technische documentatie wordt in deze eis de term conditionele query gehanteerd.

VZVZ kan op basis van monitoring en/of steekproeven controleren of een zorgaanbieder met zijn XIS gebruik maakt van de CQ. VZVZ zal controleren of de bijbehorende zelftoetsingvragenlijst ingevuld en/of nog actueel is.

De zelftoetsingvragenlijst wordt door VZVZ ter beschikking gesteld aan een zorgaanbieder.

De GBZ-beheerder kan een zorgaanbieder begeleiden bij het invullen van de zelftoetsingvragenlijst.

Condities:

De zorgaanbieder wil gebruik maken van de CQ en er is nog geen zelftoetsingvragenlijst ingevuld of de zelftoetsingvragenlijst is meer dan 3 jaar geleden ingevuld.

Details

Eis:

Een XIS-applicatie moet vóór in gebruik name van de conditionele query (CQ) een penetratietest hebben uitgevoerd op die delen van de GBZ, waar de CQ betrekking op heeft.

Bevindingen met een medium of hoger risico dienen te zijn opgelost. Dit dient te gebeuren voordat de XIS-applicatie met de CQ-functionaliteit in productie mag.

Toelichting bij eis:

Een token dient als medische informatie te worden beschouwd. In ieder geval dient de beveiliging van de tokens in scope te zijn met als bijzondere aandachtspunten:

Authenticatie & autorisatie token gebruik en token opslag database(s)

HSM’s voor private key opslag van de UZI servercertificaten (volgens eis GBX.SBH.e4080)

HSM’s voor opslag symmetrische key t.b.v. versleuteling mandaat-/inschrijftokens (optioneel volgens eis GBX.SBH.e4080).

In het geval er sprake is van hosting van meerdere partijen in één (GBZ) oplossing: adequate scheiding van tokens & cryptografische sleutels.

In het geval er géén gebruik wordt gemaakt van een door GBZ-en gedeelde database, dan dient voor elke implementatie van een GBZ een penetratietest uitgevoerd te worden.

Condities:

De XIS-applicatie maakt het mogelijk om gebruik te maken van de CQ;

Er is meer dan 3 jaar geleden een penetratietest uitgevoerd;

Een onderdeel van de GBZ-implementatie die betrokken is bij de CQ is nog niet meegenomen in de scope van de penetratietest.

Details

Eis:

Een zorgaanbieder, die gebruik wil maken van de conditionele query, dient in de volgende gevallen een hardware security module (HSM) te implementeren:

Indien het totale aantal unieke BSN's dat via één uniek servercertificaat bevraagd kan worden > 100.000, dan dient een HSM ingezet te worden.

Indien er op één plaats meerdere unieke servercertificaten worden opgeslagen die tezamen >100000 unieke BSN's ontsluiten.

De servercertificaten voor het opzetten van een verbinding en het ondertekenen van een bericht, dienen hierin opgeslagen te worden.

Toelichting bij eis:

Het gebruik van een HSM is een risico beperkende maatregel. Er is door VZVZ een afweging gemaakt om het verplichte gebruik van een HSM af te laten hangen van de potentiële unieke BSN opvraag en/of opslag omvang. Het gebruik van een HSM in minder stringente omstandigheden is uiteraard toegestaan.

Aanvullend wordt geadviseerd, maar niet verplicht gesteld, om de mandaat- en inschrijftokens te versleutelen met een symmetrische key. Deze key wordt opgeslagen in de HSM, de tokens zelf in een beveiligde container/database. Op deze wijze zijn de tokens alleen bruikbaar indien de symmetrische sleutel beschikbaar is, impact van tokendiefstal uit de database wordt hier sterk mee verminderd. Het is evident dat goed sleutelbeheer hier ingeregeld moet zijn.

Condities:

De zorgaanbieder met een patiëntenpopulatie van meer dan 100.000 patiënten die gebruik wil maken van de CQ.

Details

Eis:

Gegevens in de log mogen niet wijzigbaar of verwijderbaar (alleen in het kader van eis AGE.LOG.e4050) zijn. Het niet kunnen wijzigen/verwijderen van loggegevens moet worden afgedwongen door technische maatregelen.

Toelichting bij eis:

Conform NEN 7513:2018 Paragraaf 6.4.3

Details

Eis:

Loggegevens moeten bij het verstrijken van <log_bewaartermijn> automatisch worden verwijderd uit de actieve log en uit het archief. De logregels moeten op een zodanige wijze vernietigd worden dat de data niet te reconstrueren is. Dit betekent ook dat eventueel reservekopieën verwijderd/vernietigd/volledig overschreven zijn.

Toelichting bij eis:

Conform NEN 7513:2018 paragraaf 8.5.

Elke afsprakenstelsel/architectuur dient expliciet invulling te geven aan de waarde voor <log_bewaartermijn>. Indien deze waarde ontbreekt dan geldt de standaard waarde van 5 jaar.

Details

Eis:

Het loggen van de berichtuitwisseling in de toegangslog en het loggen van acties op de toegangslog mogen niet uitgeschakeld kunnen worden.

Toelichting bij eis:

Conform NEN 7513:2018 Paragraaf 6.4.2

Details

Eis:

Directe toegang tot loggegevens en tot zoekvragen moet alleen mogelijk zijn op basis van tweefactorauthenticatie en expliciete autorisatie. Alleen de rol toegangslogbeheerder kan geautoriseerd worden voor toegang tot loggegevens waarin echte patiëntgegevens voorkomen of kunnen worden afgeleid.

Toelichting bij eis:

Conform NEN 7513:2018 Paragraaf 8.4

Details

Eis:

Elke wijziging in de toegangsregeling dient te worden gelogd. Hierbij moet onweerlegbaar kunnen worden vastgesteld welke persoon met welke rol welke specifieke aanpassing heeft doorgevoerd.

Toelichting bij eis:

Conform NEN 7513:2018 Paragraaf 6.3

Details

Eis:

Elke inzage van de toegangslog dient gelogd te worden. Hierbij moet onweerlegbaar kunnen worden vastgesteld welke persoon met welke rol inzage heeft gehad in welke specifieke gegevens.

Toelichting bij eis:

Deze eis is conform NEN 7513:2018.

Details

Eis:

De bewaartermijn van de toegangsloggegevens is <toegangslog_bewaartermijn>. Voor de overige logs (technische logs) geldt een bewaartermijn van <systeemlog_bewaartermijn>.

Toelichting bij eis:

Voor de toegangslog (log met betrekking tot patiëntgegevens) geldt (mogelijk) een andere bewaartermijn dan voor de systeemlog. Conform NEN 7513:2018 paragraaf 8.5 kan een patiënt binnen een bepaalde tijdsperiode nog aanspraak maken op inzage in de loggegevens. Deze tijdsperiode kan voor de technische log echter onnodig lang zijn en daarmee onnodig veel opslagcapaciteit verbruiken.

De waarden <toegangslog_bewaartermijn> en <systeemlog_bewaartermijn> kunnen per afsprakenstelsel/architectuur afgesproken worden. Indien deze waarden niet expliciet ingevuld worden door het afsprakenstelsel/architectuur, dan geldt voor beide de waarde 5 jaar.

Details

Eis:

Een GBx dient te voldoen aan de NEN 7510, NEN 7512 en NEN 7513 normen.

Toelichting bij eis:

In het ‘Besluit elektronische gegevensverwerking door zorgaanbieders’ worden de NEN 7510, NEN 7512 en NEN 7513 verplicht gesteld.

Details

Eis:

Om te voorkomen dat privacygevoelige of beveiliging gerelateerde gegevens achterblijven en in ongewenste handen vallen, dienen niet (meer) gebruikte websites, apps, informatie of code te worden vernietigd volgens de standaard NIST 800-88. Te vervangen fysieke opslagmedia dienen gecontroleerd vernietigd te worden volgens DIN 66399.

Toelichting bij eis:

Er is een proces nodig dat controleert of gegevens nog noodzakelijk zijn en te verwijderen gegevens voorgoed vernietigt.

Details

Eis:

De technische infrastructuur van het GBx dient zich in de Europese Unie te bevinden. De voertaal met de zorgaanbieder en de organisatie die het GBx beheert en exploiteert is Nederlands. Met betrekking tot de contracten tussen de zorgaanbieder en bovengenoemde moet de Nederlandse wet- en regelgeving van toepassing zijn.

De zorgaanbieder en de organisaties die het GBX beheert en exploiteert dient in Nederland gevestigd te zijn.

In de contracten tussen de zorgaanbieder en bovengenoemde moet de Nederlandse wet- en regelgeving van toepassing zijn.

Toelichting bij eis:

Dit is nodig zodat de infrastructuur en dienstverlening volledig onder Nederlandse wet- en regelgeving valt. De exploitant dient waarborgen actief te hebben die voorkomen dat gegevens oneigenlijk gebruikt kunnen worden en dient te voldoen aan de privacy wetgeving.

Details

Eis:

De GBx-organisatie dient voordat zij een beheerorganisatie van een op de productie-omgeving van AORTA draaiend systeem wordt, ervoor te zorgen dat de binnen de GBx-organisatie aangewezen persoon met als rol GBx-beheerder de GBx-workshop van VZVZ heeft gevolgd.

Toelichting bij eis:

Uit de praktijk blijkt dat partijen de workshop nodig hebben om zich een goed beeld te vormen van de samenwerking tussen de eigen beheerorganisatie en de andere GZN-, GBZ- en LSP-beheerorganisaties in de keten. Daarbij biedt VZVZ in de productiefase verschillende vormen van ondersteunende dienstverlening en een escalatiepad op ketenniveau. Deze ketensamenwerking vergroot de efficiency en effectiviteit van inzet van resources, en voorkomt dat verstoringen onnodig lang duren.

Details

Eis:

Beheerhandelingen moeten worden vastgelegd in een beheerlog. De organisatie dient de opdrachtgever en toezichthouder inzage te geven in deze beheerlog. In het beheerlog wordt bijgehouden wie de inhoud van welke berichten heeft ingezien.

Toelichting bij eis:

De beheerlog ondersteunt de controle op de juiste werking van systemen en de controle op het volgen van procedures.

Details

Eis:

De systeembeheerder mag de inhoud van berichten slechts inzien indien dit noodzakelijk is voor het oplossen van problemen, is ingelogd met een tweefactorauthenticatiemiddel en uitsluitend op verzoek van een:

{GBZ} zorgverlener/medewerker;

{GBP} patiënt/klant, een leidinggevende of de Toezichthouder.

Toelichting bij eis:

Vanuit zijn ondersteunende rol kan het voor een servicedeskmedewerker ({GBP}, servicemanager ({GBP}) of een beheerder nodig zijn de inhoud van berichten in te zien, bijvoorbeeld om een mogelijk verschil in twee berichten die dezelfde inhoud zouden moeten hebben te onderzoeken. Mede vanwege deze eis is het nodig dat de beheerder expliciet door de organisatieverantwoordelijke is aangewezen.

Details

Eis:

GBX-beheer moet de beheerde GBX-applicatie(s) bij LSP-beheer aanmelden zodat deze in het applicatieregister kan worden opgenomen en zodat GBX-beheer de status ervan actueel kan houden in Supportal.

Toelichting bij eis:

Deze eis is nodig om te kunnen participeren in berichtuitwisselingen via AORTA. Het actueel houden van het applicatieregister is belangrijk voor een correcte afhandeling van berichten.

Details

Eis:

De rol van systeembeheerder moet door de organisatie expliciet benoemd en belegd zijn.

De systeembeheerder en diens vervanger(s) dienen met actuele telefoonnummers bekend te zijn bij de LSP-beheerder en de centrale AORTA servicedesk. Tenminste één beheerder dient altijd bereikbaar te zijn en in staat om de nodige beheertaken uit te voeren.

De systeembeheerder dient verzoeken van de LSP-beheerder met betrekking tot het configureren van het GBx en het activeren/deactiveren van op het LSP aangesloten systeem in te willigen.

Toelichting bij eis:

Deze eis zorgt ervoor dat een systeembeheerder altijd kan worden gewaarschuwd als er problemen zijn met een GBx, die ingrijpen van de systeembeheerder vergen.

Details

Eis:

De organisatie moet een toegangslogbeheerder benoemen. De toegangslogbeheerder moet verzoeken van de toezichthouder om de lokale toegangslog te raadplegen inwilligen.

Toelichting bij eis:

Deze eis is nodig omdat de toezichthouder op AORTA voor het uitvoeren van haar bevoegdheden informatie nodig kan hebben over de gebeurtenissen waarbij het GBx met het LSP informatie heeft uitgewisseld.

{GBx} Deze toegangslogbeheerder kan door alle zorgverleners worden gemandateerd om de toegangslog te raadplegen, om zo te voorkomen dat hij voor een verzoek tot raadplegen van de lokale toegangslog inzake een bepaalde patiënt/cliënt steeds de behandelende zorgverleners moet inschakelen.

{GBK} Deze toegangslogbeheerder kan worden gemandateerd om de toegangslog te raadplegen door de GBK-verantwoordelijke.

{GBP} Deze toegangslogbeheerder dient vóór de aansluiting aan het LSP te worden doorgegeven aan VZVZ.

Details

Eis:

Het autorisatiebeleid binnen een organisatie moet rekening houden met het onderscheid tussen systeemgebruikers die gebruik mogen maken van LSP-functionaliteiten en systeemgebruikers die geen toegang tot deze functionaliteiten mogen hebben. De verantwoordelijke voor het toekennen van autorisaties binnen de organisatie dient in het systeem de juiste autorisaties toe te kennen aan de systeemgebruikers.

Toelichting:

GBZ-en zouden een additionele toegangscontrole moeten implementeren voor het initiëren van interacties met het LSP. Een medewerker met toegang tot het systeem van een GBZ zou niet automatisch ook toegang moeten hebben tot de functies om het LSP te bevragen.

Details

Eis:

Er mogen geen overmatige bevragingen van patiëntgegevens worden gedaan. In het geval van een bevraging door het systeem dient er een duidelijke trigger voor de bevraging te zijn. Indien een systeemgebruiker zelf een bevraging initieert, is het de verantwoordelijkheid van de systeemgebruiker om te bepalen of het gaat om een overmatige bevraging.

Toelichting bij eis:

Een overmatige bevraging van patiëntgegevens is een LSP-bevraging zonder een duidelijke noodzaak voor de betreffende patiënt. Het betreft hier bijvoorbeeld een bevraging zonder een duidelijke trigger, door een systeem, met als doel de lokale database aan te vullen met de meest recente patiëntinformatie (synchronisatie). Een duidelijke trigger kan bijvoorbeeld een afspraak zijn met de patiënt of een signaal als gevolg van een afgesloten abonnement.

Details

Eis:

Een organisatie moet zorgdragen dat er voldoende UZI-passen binnen een organisatie actief zijn. Het aantal benodigde UZI-passen is afhankelijk van de organisatiestructuur en de toepassing waarbinnen een UZI-pas wordt gebruikt.

Toelichting bij eis:

Zorgaanbieders waar veel zorgverleners werkzaam zijn mogen niet uit kostenoverwegingen besparen op UZI-passen en daarom bijvoorbeeld de mandatering in de gehele organisatie bij een of enkele specialisten leggen. Er dient goed afgewogen te worden wie verantwoordelijk is voor bepaalde interacties met het LSP. Verantwoordelijkheid wordt onder andere bepaald door de rol van de zorgverlener en het hebben van een (afgeleide) behandelrelatie met een patiënt.

Details

Eis:

Systeemgebruikers binnen een GBZ dienen op de hoogte te zijn van het beveiligingsbeleid en dienen het beveiligingsbeleid na te leven. In het beveiligingsbeleid dient in ieder geval aandacht te zijn voor:

Het gebruik van de systemen en de toegang daartoe;

Het gebruik van de UZI-pas (indien door het XIS gebruikt); Hierbij dient in ieder geval de verantwoordelijkheden met betrekking tot het bezit en het gebruik van de UZI-pas benoemd worden.

Het concept van mandatering (indien door het XIS gebruikt); Hierbij dient in ieder geval aandacht besteed te worden aan de juiste fijnmazigheid waarop gemandateerd mag worden. De verantwoordelijkheid die wordt weergegeven in een mandaattoken moet bij de reële organisatiestructuur en werkwijze horen.

Het concept van inschrijftoken (indien door het XIS gebruikt).

Toelichting bij eis:

Een GBZ moet concreet beleid maken om het bewustzijn van het beveiligingsbeleid onder de medewerkers en zorgverleners te bevorderen en iedereen te wijzen op zijn verantwoordelijkheden.

Beleid om bewustzijn onder personeel te bewerkstelligen horen al standaard onderdeel te zijn van beveiligingsmaatregelen binnen een GBZ. Dit is voorgeschreven in NEN 7510, 7.2.2.

Details

Eis:

De GBx-servicedesk dient gebruikers te ondersteunen bij GBx-, GZN- en LSP-gerelateerde problemen. De GBx-servicedesk dient:

Gebruikers een inschatting te geven van de verwachte oplostermijn;

Gebruikers regelmatig te informeren over de voortgang van de oplossing;

Tijdens kantooruren telefonisch bereikbaar te zijn voor gebruikers, GZN-leveranciers en het LSP-beheer;

Voor noodgevallen telefonisch bereikbaar te zijn voor gebruikers, de GZN en het LSP;

Incidenten en problemen te registreren en beheren;

een procedure geïmplementeerd te hebben voor het melden en afhandelen van incidenten en wijzigingsverzoeken conform het Dossier Afspraken en Procedures (AORTA DAP);

Nederlandstalig te zijn.

Toelichting bij eis:

Het doel van deze eis is om de landelijke elektronisch uitwisseling van gegevens door gebruikers te bevorderen, de diensten van AORTA te verbeteren en verstoringen te signaleren, voorkomen en verhelpen.

Details

Eis:

Een ingericht XIS-Servicedesk moet tijdens kantoortijden beschikbaar zijn voor vragen vanuit VZVZ, GBZ-beheerders van eigen klanten en XIS-servicedesks van andere XIS-leveranciers.

Toelichting bij eis:

Voor de oplostijden en de precieze beschikbaarheid van het XIS-servicedesk wordt verwezen naar de AORTA DAP.

Details

Eis:

De XIS-leverancier moet voor in gebruik name van een applicatie in productie, het XIS-aanspreekpunt en contactgegevens beschikbaar gesteld hebben via Supportal.

Toelichting bij eis:

Om een goed beheerproces te kunnen implementeren is het van belang dat de verantwoordelijke aanspreekpunten vindbaar en benaderbaar zijn. Het huidige ketenbeheerproces maakt voor communicatie binnen de keten gebruik van Supportal.

Het is van belang dat ook het XIS-aanspreekpunt vindbaar is in Supportal.

Details

Eis:

De XIS-leverancier moet een 'XIS-servicedesk' inrichten die als aanspreekpunt fungeert voor problemen m.b.t. het XIS, ketentestbevindingen en opvolging van werkplanafspraken. De XIS-servicedesk moet onderdeel uitmaken van het ketenbeheerproces.

Toelichting bij eis:

Via de GBZ-Servicedesks is niet altijd een goede voortgang te boeken met betrekking tot het oplossen van XIS gerelateerde problemen. Het ontbreken van voortgang wordt met name veroorzaakt doordat de GBZ-beheerder geen invloed heeft op de planning bij de leveranciers en doordat het precieze probleem en de ernst van het probleem niet altijd duidelijk doorkomen bij de XIS-leverancier.​ Daarnaast ontbreekt het de GBZ-beheerder in sommige gevallen aan de technische kennis, die nodig is om bepaalde problemen te detecteren en/of te benoemen.

De XIS-servicedesk moet de GBZ-beheerder ondersteunen bij het oplossen van eventuele technische bevindingen van het XIS. Daarnaast moet het XIS-servicedesk benaderbaar zijn voor VZVZ om bepaalde problemen en oplossingstijden te bespreken en de voortgang te bewaken. Het doel is om tot betere kwaliteit van de software te komen en om problemen in de keten effectiever op te lossen.

Naast bovenstaande wordt de XIS-servicedesk benaderd voor de opvolging van ketentestbevindingen en de opvolging van de werkplanafspraken.

Er dient in ieder geval een telefoonnummer en een emailadres bekend te zijn van de XIS-servicedesk.

Details

Eis:

Het systeem dient de volgende GBx-Systeemrolprofielen te implementeren:

ZA Opvragend Systeem (versie 1);

NP Ontvangend Systeem (versie 1).

Toelichting bij eis:

Een GBx-Systeemrolprofiel beschrijft de relevante functionaliteiten die door een XIS-applicatie ondersteund dienen te worden.

Een GBx-Systeemrolprofiel bevat alléén generieke infrastructurele functionaliteiten. De te ondersteunen zorgtoepassingssysteemrollen zijn beschreven in de IH van de zorgtoepassing.

De GBx-Systeemrollen en de toelichting op de GBx-systeemrolprofielen in het algemeen zijn uitgewerkt in ‘AORTA on FHIR specificaties’. De toelichting GBx-systeemrolprofielen beschrijft hoe een GBx-systeemrol geïnterpreteerd dient te worden.