Eis: Het systeem moet alle systeemfunctionaliteiten ondersteunen voor de infrastructurele systeemrol(len) waarin het systeem voorziet. De verschillende systeemfunctionaliteiten zijn opgenomen in het stroomdiagram zoals opgenomen onder sectie 'Berichtenstroom'.
Toelichting bij eis: In het stroomdiagram zullen de verschillende systeemfuntionaliteiten inzichtelijk worden gemaakt door middel van een aanroep van het eigen systeem. Indien een systeemfuntionaliteitaanroep optioneel of conditioneel is, dan zal dit in het stroomdiagram aangegeven zijn. De beschrijving zal in het ontwerp van de betreffende toepassing opgenomen zijn. Het is mogelijk dat er met betrekking tot de specificatie een best practice document is toegevoegd.
Eis: Het systeem moet alle interfaces ondersteunen voor de infrastructurele systeemrol(len) waarin het systeem voorziet.
De verschillende interfaces zijn opgenomen in het stroomdiagram zoals opgenomen onder sectie 'Berichtenstroom'.
Toelichting bij eis: In het stroomdiagram zullen de verschillende interfaces inzichtelijk worden gemaakt. Indien een stroomdiagram optioneel of conditioneel is, dan zal dit in het stroomdiagram aangegeven zijn. De beschrijving en de specificaties van de interfaces zullen respectievelijk in het ontwerp en de implementatiehandleiding van de betreffende toepassing opgenomen zijn.
Garantie geven dat versturen van gegevens niet zonder kennisgeving gestaakt wordt
Alias: GBX.BTW.e4080.1
Details
Eis: Voor gegevens versturende systemen geldt dat bij falende communicatie, eventueel na herhaalde pogingen, gestopt mag worden met herzenden. De gebruiker moet in dat geval gewaarschuwd worden dat de communicatie niet gelukt is.
Toelichting bij eis: Er moet voorkomen worden dat een systeem blijft proberen een bericht te verzenden en hiermee de infrastructuur onnodig belast. GBZ-beheerders dienen in overleg het probleem te achterhalen en op te lossen. Indien de oplossing in plaats is, is het mogelijk om het bericht opnieuw te verzenden.
Bij falende communicatie, eventueel na herhaalde pogingen als bedoeld in
Automatisch herhalen van verstuurde
, mag niet gestopt worden, maar dienen deze stappen herhaald te worden tot er een uitkomst is die als succes geïnterpreteerd mag worden. Dat mag na tussenkomst van een gebruiker of systeembeheerder.
Toelichting bij eis: Deze eis voorkomt dat een bericht vergeten wordt wanneer het niet succesvol verstuurd kan worden.
Deze eis kan bijvoorbeeld worden geïmplementeerd door:
gebruikers bij de eerstvolgende keer inloggen te informeren over niet bevestigde berichten;
gebruikers de mogelijkheid te bieden een lijst met niet bevestigde berichten te bekijken.
In geval van bijvoorbeeld aanmelden gegevens moet er uiteindelijk succes geboekt worden, anders raakt de verwijsindex corrupt.
Gebruik van (tokens bij verzenden) (duplicaat)bericht
Alias: GBX.BTW.e4010
Details
Eis: Ieder initiërend systeem:
moet bij tokenauthenticatie ieder nieuw bericht voorzien van een nieuw authenticatietoken;
moet ieder duplicaatbericht identiek maken aan het originele bericht (inclusief alle identificerende gegevens);
kan bij tokenauthenticatie ieder duplicaatbericht ook voorzien van een identiek authenticatietoken;
mag een antwoord 'token reeds gebruikt' niet als succes interpreteren.
Toelichting bij eis: Deze eis is onder andere nodig om:
eventuele retry-mechanismen correct te laten werken;
de opdrachtnemende applicatie (waaronder de ZIM) in staat te stellen duplicaatdetectie te doen.
Duplicaatdetectie dient onder andere om zeker te stellen dat een opdracht maximaal één keer wordt uitgevoerd.
Voor raadplegingen hoeft geen duplicaatdetectie uitgevoerd te worden door de ontvanger. Bij raadplegingen maakt het voor het resultaat dan ook niet uit of duplicaten of nieuwe opvragingen gebruikt worden.
Bij het versturen van een duplicaatbericht is het mogelijk om een duplicaat-authenticatietoken mee te sturen. Het is echter ook mogelijk om een nieuw authenticatietoken te maken.
Eis: Een reagerend systeem moet na het ontvangen van een verstuurbericht, anders dan een opvraagbericht, aan de hand van het patiëntstuk-id bepalen of het om een nieuw of om een reeds verwerkt bericht gaat. Een reeds verwerkt bericht moet worden beantwoord met een fout.
Toelichting bij eis: Voor interacties die idempotent zijn (deze kunnen zonder neveneffecten meerdere malen uitgevoerd worden) is duplicaatdetectie niet nodig. Voor niet-idempotente interacties is dit wel nodig.
Deze eis dient om te voorkomen dat opdrachten onterecht meerdere malen worden uitgevoerd.
Automatisch herhalen van verstuurde, niet-bevestigde, berichten
Alias: GBX.BTW.e4050
Details
Eis: Voor gegevens versturende systemen geldt het volgende:
Het systeem mag tot een maximum van één aantal pogingen doen met een duplicaatbericht in een tijdspanne van vijf seconden tot 15 minuten.
Wanneer het systeem na bovenstaande poging(en) geen afdoende antwoord heeft ontvangen, mag het een nieuwe poging uitvoeren met een nieuw bericht, waarin dezelfde inhoud en dus ook hetzelfde patiëntstuk-id is opgenomen. Dit wordt beschouwd als een nieuwe transactie, waarbij dus ook punt 1 weer geldig is.
Wanneer op een nieuwe poging tot toevoegen van gegevens, als bedoeld in punt 2 een antwoord 'bestaat al' wordt ontvangen, mag het systeem dit als succes interpreteren. Immers, de unieke patiëntstuk-id's garanderen dat het om de juiste gegevens gaat.
Wanneer op een nieuwe poging tot verwijderen van gegevens, als bedoeld in punt 2, een antwoord 'bestaat niet' wordt ontvangen, mag het systeem dat als succes interpreteren.
Op een nieuwe poging tot wijzigen van gegevens, als bedoeld in punt 2, mag alleen een antwoord dat expliciet 'succes' aanduidt als succes geïnterpreteerd worden.
Een nieuwe poging als bedoeld in punt 2 mag ook uitgevoerd worden direct na de eerste poging, het is dus niet verplicht om eerst een nieuwe poging uit te voeren met een duplicaatbericht.
Toelichting bij eis: Een retry-mechanisme dient om de gebruiker niet te vermoeien met foutmeldingen in geval van een incidentele communicatiestoring.
Wanneer de ZIM bij tokenauthenticatie een bericht verwerkt, wordt het authenticatietoken gecontroleerd en kan dit token niet nogmaals gebruikt worden. Een nieuwe poging met een duplicaatbericht is bij tokenauthenticatie dan ook alleen zinvol wanneer het originele bericht niet bij de ZIM is aangekomen.
De ZIM initieert zelf geen retries naar ontvangende systemen. Iedere poging van het versturend systeem resulteert in maximaal één poging van de ZIM per ontvangend systeem.
Eis: Het XIS moet een applicatiekoppelingverificatie-bericht kunnen ontvangen en/of versturen. Hiervoor dient de implementatie gevolgd te worden zoals beschreven in de implementatiehandleiding van het applicatiekoppelingverificatie-bericht. Toelichting bij eis: Momenteel wordt nog gewerkt aan de implementatiehandleiding voor de implementatie van het applicatiekoppelingverificatie-bericht.. Deze eis dient dan ook vooralsnog als 'kapstokeis' en kan worden uitgebreid en/of aangescherpt.
Eis: Het XIS moet op basis van het beherenTKID-bericht aangeven welke FHIR resources de bron kan opleveren en/of kan verwerken. Hiervoor dient de implementatie gevolgd te worden zoals beschreven in de implementatiehandleiding van het TKID-bericht. Toelichting bij eis: Momenteel wordt nog gewerkt aan de implementatiehandleiding voor de implememantie van het TKID-bericht. Deze eis dient dan ook vooralsnog als 'kapstokeis' en kan worden uitgebreid en/of aangescherpt.
Eis: Het XIS moet een applicatiekoppelingverificatie-bericht kunnen versturen. Hiervoor dient de implementatie gevolgd te worden zoals beschreven in de implementatiehandleiding van het applicatiekoppelingverificatie-bericht. Toelichting bij eis: Momenteel wordt nog gewerkt aan de implementatiehandleiding voor de implementatie van het applicatiekoppelingverificatie-bericht.
Compatibiliteit bieden met de diverse (zorg)toepassingen
Alias: GBX.OPV.e4550.1
Details
Eis: Een bronsysteem moet bevragingen van diverse actoren en vanuit diverse organisaties kunnen verwerken.
Toelichting bij eis: De volgende actoren of groep van actoren moeten door het bronsysteem worden ondersteunt als opvrager (of opvraagverantwoordelijke):
Een zorgverlener op basis van UZI;
Een burger op basis van BSN.
De volgende organisaties moeten door het bronsysteem worden ondersteunt als organisatie vanuit waar opgevraagd wordt:
Eis: Vrijgegeven patiëntgegevens moeten op verschillende aggregatieniveaus kunnen worden afgeschermd. De aggregatieniveaus zijn beschreven in de domeinspecificatie waartoe de gegevens behoren. Na het afschermen van patiëntgegevens moet zo nodig (conform Bijhouden van de verwijsindex) de verwijsindex worden bijgewerkt.
Toelichting bij eis: Afgeschermde patiëntgegevens kunnen niet via AORTA worden opgevraagd. Deze eis is nodig zodat een zorgverlener op verzoek van een patiënt bepaalde gegevens kan afschermen.
Eis: Patiëntgegevens moeten na vastlegging, automatisch of op commando van de gebruiker, vrijgegeven kunnen worden. Vrijgeven moet kunnen op verschillende aggregatieniveaus, zoals beschreven in de domeinspecificatie waartoe de gegevens behoren. Na het vrijgeven van patiëntgegevens moet zo nodig (conform Bijhouden van de verwijsindex) de verwijsindex worden bijgewerkt.
Toelichting bij eis: Slechts vrijgegeven patiëntgegevens kunnen via AORTA worden opgevraagd.
Het vrijgeven van patiëntgegevens kan zowel op commando als automatisch gebeuren. Als op commando vrijgeven onwerkbaar is, mag dit automatisch gebeuren. Het is aan te raden de gebruiker hierover te informeren.
Het XIS dient een foutmelding te retourneren indien er een AORTA access token wordt ontvangen met een attest claim met de waarde 'BRON'.
Toelichting bij eis:
In sommige situaties maakt een XIS geen gebruik van een lokale opt-in registratie. Denk bijvoorbeeld aan de situatie waarin gemigreerd is naar Mitz of waarbij er sprake is van een bevraging n.a.v. een notified pull. In deze situaties kan er geen lokale patiënttoestemmingscontrole gedaan worden. In het geval dit wel vereist wordt volgens de attest claim, dient de opvraag afgebroken te worden en een foutmelding teruggestuurd te worden.
De specificaties van het AORTA access token is gespecificeerd in de confluencepagina 'Publieke omgeving AORTA on FHIR' in de sectie 'Common/Token specificaties'. Hieruit is af te leiden welk veld getest dient te worden.
Condities:
Deze eis geldt indien het XIS niet beschikt over een lokale opt-in registratie conform GBX.IDA.e4100.
Eis: Het systeem dient de FHIR-resources op te leveren zoals is opgenomen in de betreffende zorgtoepassing. Toelichting bij eis: Een verwijzing naar de FHIR-resources zijn opgenomen in de publicatiepagina op Confluence.
Eis: Het systeem mag alleen patiëntgegevens versturen indien voor die patiëntgegevens sprake is van een definitieve koppeling met het BSN.
Toelichting bij eis: Deze eis zorgt ervoor dat een gebruiker conform Wbsn-z artikel 9 alleen patiëntgegevens kan versturen nadat de vereiste BSN-verificatie en eventueel benodigde WID-controle is gedaan.
Eis: Het consenttoken moet een geldigheidsduur van minimaal 7 dagen hebben, gerekend vanaf het moment van uitgifte van het token. De maximale geldigheidsduur is 1 jaar, conform veldnorm. Toelichting bij eis: De geldigheidsduur van het consenttoken wordt bepaald door de elementen Conditions.@NotBefore en Conditions.@NotOnOrAfter. De waarde van de NotBefore mag niet na de uitgiftetijd van het token (@IssueInstant) liggen. De waarde van de NotOnOrAfter moet minimaal 7 dagen na de uitgiftetijd van het token (@IssueInstant) liggen.
Het is mogelijk dat een zorgverlener pas op een later moment in het zorgproces een opvraag doet van de BGZ-gegevens in combinatie met het consenttoken. Een consenttoken moet dus een relatief lange geldigheidsduur kennen. Echter, om te voorkomen dat een consenttoken geen einddatum kent, is hier een vaste waarde aan toegekend.
Het systeem dient vóór communicatie binnen de AORTA infrastructuur een AORTA access token te verkrijgen bij de AORTA Autorisatieserver voor zorgaanbieders.
Afhankelijk van de wijze waarop geautoriseerd moet worden, worden de volgende tokens meegestuurd:
In het geval van VGU:
Transactietoken getekend met UZI-servercertificaat;
Mandaattoken;
Inschrijftoken (of in plaats daarvan een consenttoken indien er sprake is van een opvraag als gevolg van een notified pull);
Zonder VGU:
Transactietoken getekend met authenticatiecertificaat van zorgverlenerspas;
Mandaattoken indien er sprake is van het versturen/opvragen onder mandaat;
Consenttoken indien er sprake is van een opvraag als gevolg van een notified pull.
Toelichting bij eis:
Het proces met betrekking tot het verkrijgen van AORTA access token staat beschreven in de confluencepublicatie 'Publieke omgeving AORTA on FHIR'.
Eis: Een systeemgebruiker moet een organisatie kunnen selecteren waaraan hij een bericht wil versturen. Het moet voor een systeemgebruiker duidelijk zijn aan welke organisatie hij een bericht richt. Hiervoor dienen minimaal de volgende gegevens getoond te kunnen worden:
Organisatienaam;
Adresgegevens.
Toelichting bij eis: Een systeemgebruiker moet door het systeem ondersteund worden in het kunnen zoeken en selecteren van een te adresseren organisatie. Om adresseringsfouten te voorkomen, is het niet toegestaan om adresgegevens door een systeemgebruiker zelf in te laten vullen.
Eis: Het systeem dient een actuele URA van de te adresseren organisatie te verkrijgen via een betrouwbare bron. Hierbij dient een URA onweerlegbaar te zijn gekoppeld aan de functionele naam van de organisatie zoals vastgelegd bij het CIBG. Toelichting bij eis: Er moet voorkomen worden dat een kwaadwillende adresgegevens in die mate muteert, dat medische gegevens naar een andere organisatie dan de door de systeemgebruiker bedoelde organisatie kunnen worden gestuurd. Hiervoor dienen adresgegevens alleen door een daarvoor geautoriseerde bron te kunnen worden aangepast.
Een betrouwbare bron is een bron, waarin de CIBG-gegevens onweerlegbaar zijn vastgelegd en waarin die gegevens alleen gemuteerd kunnen worden door daarvoor geautoriseerde personen. Het ZORG-AB wordt gezien als een betrouwbare bron.
Toelichting bij eis: Berichten die onder mandaat naar het LSP worden verstuurd, dienen te worden voorzien van een mandaattoken (zoals gespecifieerd in https://vzvz.atlassian.net/wiki/display/A8/GBZ+AORTA_Auth_IH_Mandaattoken ). Het LSP krijgt dan altijd op een uniforme wijze het mandaat aangeleverd en kan deze vervolgens ook controleren.
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 <GBx_verlopen_mandaat> 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.
Eis: Verlopen mandaten moeten in de volgende gevallen uit het systeem worden verwijderd:
De einddatum van het mandaat 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 mandaat.
Toelichting bij eis: Er moet voorkomen worden dat verlopen mandaten 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.
Echter, 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.
Eis: Met betrekking tot het mandaattoken dienen drie zaken gelogd te worden:
Mandaattoken; bij het aanmaken van een mandaattoken dienen de gegevens gelogd te worden zoals opgenomen in
GBX.AUT.e4511.
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 tijden 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 genoemd onder de punten a t/m c in één gecombineerde log op te nemen. Hierbij moet dan wel na elke aanpassing van een van de drie genoemde zaken opnieuw gelogd worden.
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.
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 tijden inzichtelijk gemaakt kunnen worden of een bepaalde zorgverlener gerechtigd was om gebruik te maken van een bepaald mandaattoken.
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 op vertrouwensniveau midden 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 rolcode's 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 ontegenzeggelijk te worden aangetoond welke UZI of rolcode er aan de waarde gekoppeld is.
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 b. 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. Deze mogen alleen door een geautoriseerde medewerker worden ingezien en aangepast.
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;
de autorisatieregel (zie eis
GBX.AUT.e4513
) op basis waarvan een mandaat verkregen kan worden;
een unieke identifier.
Toelichting bij eis: 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.
Een systeem die 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 benaderd, maar het is ook mogelijk dat de XIS-applicatie de statussen 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.
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 koppelen
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.
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 een behandelrelatie bestaat;
ten behoeve van welke zorgaanbieder (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.
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.
Definitief koppelen van patiëntgegevens aan een BSN
Alias: GBX.IDA.e4030
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;
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 geverifiëerd 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 geverifiëerd 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.
Voorlopig koppelen van patiëntgegevens aan een BSN
Alias: GBX.IDA.e4020
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.
Verwerken geboortedatums waarin nullen zijn opgenomen
Alias: GBX.IDA.e4015
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.
Toelichting bij eis: Deze eis leidt tot de volgende aanvullende eisen:
Alle XISsen moeten naast de mogelijkheid om een BSN op te vragen of te verifiëren op basis van de Zoekpaden 1 en 2, ook de dienst opvragen van persoonsgegevens op basis van een ingevoerd BSN inbouwen.
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.
Niet bevragen of versturen bij status "niet actief"
Alias: GBX.ZAB.e4050
Details
Eis: In het geval een applicatie van een opgevraagde zorgaanbieder niet de status 'actief' heeft, mag er geen bericht naar toe worden gestuurd.
Toelichting bij eis: Het ZAB heeft een real time koppeling met het APR. Informatie met betrekking tot een applicatie zal dan ook altijd actueel zijn.
In het geval, na een bevraging van het ZAB, blijkt dat een bepaalde applicatie niet de status actief heeft, dan mag er geen bericht aan het specifieke applicatieID worden verzonden. Hiermee worden onnodige foutmeldingen en onnodig verkeer voorkomen.
Opvragen van zorgaanbieder o.b.v. identificerende gegevens
Alias: GBX.ZAB.e4020.1
Details
Functie Opvragen van zorgaanbieders o.b.v. identificerende gegevens
Karakter Conditioneel
Condities In het geval er geen andere bron voor adressering aanwezig is, dan is deze eis verplicht. Een alternatieve bron dient actuele en onweerlegbare informatie te bevatten.
Beginsituatie a. De gebruiker is lokaal ingelogd op vertrouwensniveau laag of hoger (trigger a), of b. Het systeem beschikt over de voor deze functie vereiste vertrouwensmiddelen (trigger b).
Trigger a. De gebruiker initieert de functie via het systeem, of b. Het systeem initieert de functie automatisch. Interacties 1. Het systeem verzendt een REST-Request naar de ZAB. 2. Het systeem ontvangt een REST-Response van de ZAB.
Resultaat De opgeleverde gegevens zijn door het systeem: a. gepresenteerd aan de gebruiker
Uitzonderingen Uitzonderingen zijn beschreven in de Foutentabel.
Toelichting Het moet mogelijk zijn om op basis van identificerende zorgaanbiedergegevens (in ieder geval o.b.v. de URA) de naam en NAW-gegevens van de betreffende Zorgaanbieder op te vragen.
Opvragen van zorgaanbieders o.b.v. zorgaanbiedertype
Alias: GBX.ZAB.e4015.1
Details
Functie Opvragen van zorgaanbieders o.b.v. zorgaanbiedertype
Karakter Conditioneel
Condities In het geval er geen andere bron voor adressering aanwezig is, dan is deze eis verplicht. Een alternatieve bron dient actuele en onweerlegbare informatie te bevatten..
Beginsituatie a. De gebruiker is lokaal ingelogd op vertrouwensniveau laag of hoger (trigger a), of b. Het systeem beschikt over de voor deze functie vereiste vertrouwensmiddelen (trigger b).
Trigger a. De gebruiker initieert de functie via het systeem, of b. Het systeem initieert de functie automatisch. Interacties 1. Het systeem verzendt een REST-Request naar de ZAB. 2. Het systeem ontvangt een REST-Response van de ZAB.
Resultaat De opgeleverde gegevens zijn door het systeem: a. gepresenteerd aan de gebruiker
Uitzonderingen Uitzonderingen zijn beschreven in de Foutentabel.
Toelichting Het moet mogelijk zijn om op basis van zorgaanbiedertype een lijst met alle zorgaanbieders van een bepaald type op te vragen. Het moet mogelijk zijn om hierbij bepaalde filterparameters toe te passen. Alle specifieke zoekcriteria zijn opgenomen in de implementatiehandleiding van ZORG-AB (https://www.vzvz.nl/diensten/gemeenschappelijke-diensten/zorg-ab/releases).
Toelichting bij eis: Gegevens uit het UZI-register en uit de VZVZ administratie kunnen niet door een zorgaanbieder worden bijgewerkt, aangevuld of verwijderd. Hiervoor dient het reguliere proces via VZVZ of UZI te worden doorlopen.
Hiermee wordt voorkomen dat er verwarring ontstaat over de juistheid van de bij VZVZ geregistreerde informatie.
In de implementatiehandleiding ZORG-AB (https://www.vzvz.nl/diensten/gemeenschappelijke-diensten/zorg-ab/releases) is opgenomen aan welke eisen bepaalde velden moeten voldoen. Het is mogelijk dat er alleen maar waardes voor bepaalde velden mogen worden ingevuld die voorkomen in voorgedefinieerde waardelijsten.
Condities In geval van gebruik van het Zorgadresboek raadplegend systeem door een GBZ Beginsituatie a. De gebruiker is lokaal ingelogd op vertrouwensniveau laag of hoger (trigger a), of b. Het systeem beschikt over de voor deze functie vereiste vertrouwensmiddelen (trigger b).
Trigger a. De gebruiker initieert de functie via het systeem, of b. Het systeem initieert de functie na toestemming van een specifieke zorgverlener.
Interacties 1. Het systeem verzendt een REST-POST naar de ZIM conform .
Resultaat a. De aan te vullen gegevens zijn verwerkt in het ZORG-AB.
Toelichting Er dient voor de zorgaanbieder functionaliteit te zijn om de gegevens met betrekking tot de organisatie aan te vullen. Het betreft hier exclusief de gegevens die betrekking hebben op de eigen organisatie.
Een lokale ZORG-AB beheerder of het systeem mag na toestemming de gewenste aanvullingen naar het ZORG-AB versturen.
Beginsituatie a. De gebruiker is lokaal ingelogd op vertrouwensniveau laag of hoger (trigger a), of b. Het systeem beschikt over de voor deze functie vereiste vertrouwensmiddelen (trigger b).
Trigger a. De gebruiker initieert de functie via het systeem, of b. Het systeem initieert de functie na toestemming van een specifieke zorgverlener.
Interacties 1. Het systeem verzendt een REST-DELETE naar de ZAB.
Resultaat a. De te verwijderen gegevens zijn uit het ZAB verwijderd.
Uitzonderingen Het URA-nummer kan niet worden verwijderd door een zorgadresboek bewerkend systeem.
Toelichting Er dient functionaliteit te zijn om de zorgaanbiedergegevens te verwijderen. Er mogen alleen zorgaanbiedergegevens verwijderd worden behorende bij de organisatie waar het zorgadresboek bewerkende systeem is geïmplementeerd (zie voor de CRUD-autorisaties van de specifieke velden in het ZAB de [IH ZAB]).
Het is alleen mogelijk om de gegevens te laten verwijderen door een lokale ZAB-beheerder of automatisch door een systeem.
Condities In geval van gebruik van het Zorgadresboek raadplegend systeem.
Beginsituatie a. De gebruiker is lokaal ingelogd op vertrouwensniveau laag of hoger (trigger a), of b. Het systeem beschikt over de voor deze functie vereiste vertrouwensmiddelen (trigger b).
Trigger a. De gebruiker initieert de functie via het systeem, of b. Het systeem initieert de functie automatisch.
Interacties • Het systeem verzendt een REST-PATCH naar de ZORG-AB.
Resultaat a. De te wijzigen gegevens zijn verwerkt in het ZORG-AB.
Uitzonderingen Het URA-nummer is een vaste waarde en het is niet mogelijk om deze via het zorgadresboek bewerkend systeem aan te passen (zie voor de CRUD-autorisaties van de specifieke velden in het ZORG-AB de implementatiehandleiding (https://www.vzvz.nl/diensten/gemeenschappelijke-diensten/zorg-ab/releases).
Toelichting Er dient functionaliteit te zijn om de zorgaanbiedergegevens aan te passen. Er mogen alleen zorgaanbiedergegevens aangepast worden behorende bij de organisatie waar het zorgadresboek bewerkende systeem is geïmplementeerd.
Bijwerken van gegevens kan automatisch gebeuren door het systeem. Hiervoor dient de te wijzigen informatie wel beschikbaar te zijn in het systeem. Het is ook mogelijk om de gegevens te laten wijzigen door een lokale ZORG-AB beheerder.
Eis: Het bronsysteem moet binnen 60 seconden na ontvangst van een opvraagbericht een antwoord gegeven. Indien het bronsysteem constateert dat het niet binnen 60 seconden kan antwoorden, dan dient het bronsysteem een foutmelding te genereren. Toelichting bij eis: Om te voorkomen dat TLS-verbindingen onnodig lang tussen het LSP en GBx-en blijven bestaan, worden de TLS-verbindingen automatisch door het LSP verbroken. Het LSP zal na 60 seconden de verbinding met een bronsysteem verbreken en een foutmelding (time-out) terugsturen naar het initiërende systeem.
Indien het bronsysteem zelf kan vaststellen dat er niet binnen de in de eis opgegeven tijd een antwoord verstuurd kan worden, dan dient het bronsysteem een foutmelding (timeout) te versturen. Op deze manier kan voorkomen worden, dat een initiërend systeem onnodig lang hoeft te wachten.
De waarde voor de time-out is gebaseerd op voorgaande AORTA-versies. Hierbij is nog geen rekening gehouden met aansluiting op MedMij, die vereist dat een DVZA binnen 60 seconden een antwoord moet geven aan een PGO. Vooralsnog blijft de waarde zoals opgenomen in deze eis gehandhaaft. Het DVZA zal in dat geval na 60 seconden een time-out versturen naar het PGO.
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.
Eis: Een GBx dient minimaal de hieronder genoemde snelheden te halen voor de hieronder genoemde interactiemechanismen.
Interactiemechanisme Minimale verwerkingssnelheid Sturen van gegevens <GBx-verwerkingssnelheid-sturen> Opvragen van gegevens <GBx-verwerkingssnelheid-opvragen>
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.
De waarden <GBx-verwerkingssnelheid-sturen> en <GBx-verwerkingssnelheid-opvragen> kunnen verschillen per gebruikte technologie. Voor de HL7v3-berichten gelden de waarden zoals opgenomen in de het configuratieinstellingendocument. Met betrekking tot FHIR dienen deze waarden nog afgestemd te worden met de diverse leveranciers. Deze waarden dienen vastgesteld te worden na afloop van de PoC.
Figure 9 : AORTA Eisen Kwaliteit aangesloten systemen - Betrouwbaarheid ISO 25010 definieert Betrouwbaarheid als: De mate waarin een systeem, product of component gespecificeerde functies uitvoert onder gespecificeerde condities gedurende een gespecificeerde hoeveelheid tijd.
Borgen van de betrouwbaarheid bij grote storingen
Alias: GBX.BET.e4020.1
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 gedefineerd. 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.
Borgen van de betrouwbaarheid bij kleine storingen
Alias: GBX.BET.e4010.1
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.
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.
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.
Figure 10 : AORTA Eisen Kwaliteit aangesloten systemen - Beveiligbaarheid ISO 25010 definieert Beveiligbaarheid als: De mate waarin een product of systeem informatie en gegevens beschermt zodat personen, andere producten of systemen de juiste mate van gegevenstoegang hebben passend bij hun soort en niveau van autorisatie.
Dit schema toont de subcategorieën van Beveilgbaarheid volgens ISO 25010.
Beveiligde opslag
Alias: SYS.BVL.e4010.1
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ëncrypted. 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 overlegt te worden met VZVZ.
Een GBx beschikt over een geldig UZI/PKIO-servercertificaat
Alias: GBX.BVL.e4080 (voorheen GBX.BVL.e4080.1)
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.
Borgen van plicht tot uitwisselen van patiëntgegevens
Alias: GBX.BVL.e4070
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.
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.
Borgen betrouwbare koppeling tussen pas en applicatie
Alias: GBX.BVL.e4050.1
Details
Eis: Een GBx moet zodanig zijn ingericht dat:
passen met SHA-256-certificaten gelezen en gebruikt kunnen worden;
paslezers gekoppeld zijn aan werkplekken van gebruikers;
de PIN-code die ten behoeve van een authenticatiemiddel wordt ingetoetst op een werkplek, exclusief wordt aangeboden aan de gekoppelde paslezer,
{GBx} alle gegevens in berichten die ten behoeve van een gebruiker worden ontvangen exclusief aan die gebruiker worden gepresenteerd;
{GBK} alle gegevens in HL7-berichten die ten behoeve van een patiëntopdracht worden ontvangen exclusief gekoppeld worden aan de betreffende patiëntopdracht.
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.
Figure 11 : AORTA Eisen Kwaliteit aangesloten systemen - Uitwisselbaarheid ISO 25010 definieert Uitwisselbaarheid als: De mate waarin een product, systeem of component informatie uit kan wisselen met andere producten, systemen of componenten, en/of het de gewenste functies kan uitvoeren terwijl het dezelfde hard- of software-omgeving deelt. Dit diagram toont de subcategorieën zoals gedefinieerd door ISO 25010.
Aansluiting op productie-omgeving LSP
Alias: GBX.CON.e4120
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.
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.
{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.
Figure 12 : AORTA Eisen Kwaliteit applicatie - Beveiligbaarheid ISO 25010 definitieert Beveiligbaarheid als: De mate waarin een product of systeem informatie en gegevens beschermt zodat personen, andere producten of systemen de juiste mate van gegevenstoegang hebben passend bij hun soort en niveau van autorisatie.
Toegangslog bijhouden (FHIR)
Alias: GBX.LOG.e4016
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 gebruikersinteractieID. 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;
de bericht-id van het ontvangen/verstuurde bericht. Dit is het messageID in de HTTP header;
het initiële bericht-id van het ontvangen/verstuurde bericht. Dit is het initialMessageID 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 enventuele 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.
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.
Opzetten beveiligde verbinding vanuit de ZIM met een GBx
Alias: GBX.CON.e4090.2
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 ten hoogste 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.
Seperate certificaten voor verschillende doeleinden
Alias: GBX.BVL.e4100.1
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 server certificaten 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.
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.
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: 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 vanwege het voorkomen van misbruik van de tokens beperkt zijn tot daarvoor aangewezen rollen.
Eis: Binnen het GBx dient te worden bijgehouden welke UZI-passen worden toegelaten voor gebruik. Deze gebruikersregistratie is uitsluitend toegankelijk voor gebruikers van de gastheerinstelling, na authenticatie op basis van een sterk authenticatiemiddel (2 factorauthenticatie bijvoorbeeld via een UZI-pas) van diezelfde gastheerinstelling.
Toelichting bij eis: Dit is nodig om te voorkomen dat een willekeurig persoon de gebruikersregistratie kan aanpassen. Deze bevoegdheid komt bij een specifiek persoon te liggen.
Dit betekent voor de zorgaanbieder dat hij moet zorgen dat de bovenstaande rol van autorisatiebeheerder door een van zijn medewerkers wordt ingevuld.
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
(indien tokenauthenticatie) het servercertificaat van het GBx voor vertrouwensniveau midden
het servercertificaat van het GBx voor vertrouwensniveau laag {GBK} en midden 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 ondersteunt; 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.
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 syteem, 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.
Blokkeren van ingetrokken, verlopen en niet authentieke passen
Alias: GBX.IDA.e4085.2
Details
Eis: Het GBx dient het starten van een gebruikersessie 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, kan een geldig transactietoken genereren.
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 authenticeren.
{GBx} Een GBx dient hierbij een UZI-pas toe te laten indien:
de UZI-pas is vastgelegd in de gebruikerstabel (zie ook eis GBX.FBH.e4030);
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 levert gratis generiek tooling in de vorm van Zorg-ID om de implementatie van het authenticeren met de UZI-pas te ondersteunen.
Figure 13 : AORTA Eisen Kwaliteit applicatie - Uitwisselbaarheid ISO 25010 definieert Uitwisselbaarheid als: De mate waarin een product, systeem of component informatie uit kan wisselen met andere producten, systemen of componenten, en/of het de gewenste functies kan uitvoeren terwijl het dezelfde hard- of software-omgeving deelt.
Afhandelen transactietoken
Alias: GBX.CON.e4140.3
Details
Eis:
Het XIS moet een ontvangen AORTA access token correct kunnen verwerken. Hierbij dient het token gecontroleerd te worden op basis van de invulling zoals is opgenomen in de specificaties van het AORTA access token op de confluencepagina 'Publieke omgeving AORTA on FHIR'.
Indien een FHIR-search niet wordt begeleid door een AORTA access token, dan dient de bevraging beantwoord te worden met een foutmelding.
Toelichting bij eis:
In combinatie met bepaalde berichten is het mogelijk dat er AORTA access tokens worden toegevoegd. De specificatie en de juiste technische verwerking van het AORTA access token staat beschreven in de confluencepagina 'Publieke omgeving AORTA on FHIR'
Het doel van het AORTA access token is tweeledig:
Ten eerste is het bedoeld als gegevensdrager. Er worden een aantal gegevenselementen opgenomen, die niet in het bericht zitten. Deze gegevenselementen dienen uit het token gehaald te worden en te worden gebruikt in de verdere verwerking van het bericht.
Ten tweede kan het token gebruikt worden t.b.v. authenticatie of als bewijs van autorisatie. Het is mogelijk om op basis van de certificaatreferenties te controleren of het token van de juiste afzender afkomstig is en dat de opvrager geautoriseerd is voor bevraging van specifieke patiëntgegevens.
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.
Ondersteunen servercertificaten en ondertekeningalgoritmen
Alias: GBX.CON.e4110.2
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.
Figure 14 : Eisen aan de beheerorganisatie van een GBX
Zelftoetsingvragenlijst
Alias: GBX.SBH.e4100
Details
Eis: Een zorgaanbieder is verplicht om vóór in gebruik name van de conditionele query (CQ) functionaliteit een zelftoetsingvragenlijst 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.
Het zelftoetsingvragenlijst wordt door VZVZ ter beschikking gesteld aan een zorgaanbieder.
De GBZ-beheerder kan een zorgaanbieder begeleiden bij het invullen van het 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.
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 server certificaten (volgens eis GBX.SBH.e4080)
HSM's voor opslag symmetrische key tbv 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.
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 BSNs 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 BSNs 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.
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.
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 reservekopieen verwijderd/vernietigd/volledig overschreven zijn. Toestemming 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.
Eis: Directe toegang tot loggegevens en tot zoekvragen moet alleen mogelijk zijn op basis van twee factor authenticatie en expliciete autorisatie. Alleen de rol toegangslogbeheerder kan geautoriseerd worden voor toegang tot loggegevens waarin echte patiëntgegevens voorkomen of kunnen worden afgeleid.
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.
Eis: Rechtmatigheid. 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.
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.
Vzvz_Moscow: Verplicht Vzvz_Req_Verificatie: Monitoring Vzvz_Req_Soort: Non-Functional Vzvz_Req_Type: Business
Voldoen aan wet- en regelgeving
Alias: GBX.ALG.e4010
Details
Eis: Een GBX dient te voldoen aan de NEN7510, NEN7512 en NEN7513 normen.
Toelichting bij eis:
In de wet gebruik BSN in de zorg Artikel 2 Lid 4a is afgedwongen dat de gegevensverwerking, zoals bedoelt in de bijbehorende wet, aantoonbaar moet voldoen aan de NEN7510.
In de concept AMvB aanvullende bepalingen verwerking persoonsgegevens in de zorg wordt in artikel 5 gesteld dat de netwerkverbindingen (intern netwerk en GZN) moeten voldoen aan het bepaalde in NEN 7512 en in artikel 7 wordt gesteld dat de logging van zorgaanbieders moet voldoen aan het bepaalde in NEN 7513.
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 DoD 5220.22-M (E). Te vervangen fysieke opslagmedia dienen gecontroleerd vernietigd te worden volgens DIN 32757.
Toelichting bij eis: Er is een proces nodig dat controleert of gegevens nog noodzakelijk zijn en te verwijderen gegevens voorgoed vernietigt.
Vzvz_Moscow: Verplicht (Must) Vzvz_Req_Verificatie: Eigenverklaring Vzvz_Req_Soort: Functional Vzvz_Req_Type: Business
Een GBx valt onder Nederlandse wet- en regelgeving
Alias: GBX.CON.e4050.1
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 organisatie's 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 om er voor te zorgen dat 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 te voldoen aan de privacy wetgeving.
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.
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 welke systeembeheerder 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.
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.
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.
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 het LSP 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.
Beheren van en toegang verschaffen tot de toegangslog
Alias: GBX.SBH.e4010
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 Logbeheerder dient vóór de aansluiting aan het LSP te worden doorgegeven aan VZVZ.
Toekennen functiescheiding tussen systeemgebruikers
Alias: GBX.FBH.e4025
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.
Toekennen functiescheiding tussen systeemgebruikers m.b.t. inschrijftokens
Alias: GBX.FBH.e4020
Details
Eis: Er moet functiescheiding toegepast worden tussen systeemgebruikers die gerechtigd zijn om inschrijftokens op te stellen en gebruikers die het LSP kunnen bevragen. Toelichting: Deze eis moet de kans verlagen dat gegevens van een oneigenlijke patient worden bevraagd, doordat medewerkers niet zowel patiënten mogen inschrijven als betrokken zijn bij de medische processen.
Met name bij zorgaanbieders van een grotere omvang zal dit goed toe te passen zijn en aansluiten bij de bestaande werkprocessen. De aanpassingen zijn vooral beleidsmatig en procedureel van aard. Het toepassen van deze maatregel is mogelijk al bestaande praktijk of kan anders wellicht met beperkte inspanning worden gerealiseerd. Voor kleine zorgaanbieders is dit mogelijk niet altijd haalbaar.
Condities: Deze eis zal verplicht zijn voor grote zorgorganisaties. In overleg met VZVZ kan bepaald worden of deze eis verplicht zal zijn.
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: 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.
Instrueren systeemgebruikers over beveiligingsbeleid
Alias: GBX.FBH.e4015
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: 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.
Ondersteuning van gebruikers bij problemen met de landelijke uitwisseling van informatie
Alias: GBX.FBH.e4010
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.
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 in de toekomst op te stellen DAP.
Vzvz_Moscow: Verplicht Vzvz_Req_Verificatie: Monitoring Vzvz_Req_Soort: Non-Functional Vzvz_Req_Type: Business
Gebruik Supportal
Alias: XIS.SVD.e4020
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.
Vzvz_Moscow: Verplicht Vzvz_Req_Verificatie: Monitoring Vzvz_Req_Soort: Non-Functional Vzvz_Req_Type: Business
Inrichten XIS-servicedesk
Alias: XIS.SVD.e4030.2
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.
Vzvz_Moscow: Verplicht Vzvz_Req_Verificatie: Monitoring Vzvz_Req_Soort: Non-Functional Vzvz_Req_Type: Business
JavaScript errors detected
Please note, these errors can depend on your browser setup.
If this problem persists, please contact our support.
