PvE Basisgegevenset Zorg MSZ - Overdragend systeem

Datum:

13-1-2025

Status:

Definitief

Versie:

2.3.0

Eigenaar:

VZVZ

Revisie:

1

Datum

Status

Versie

Omschrijving

28-5-2023

Definitief

1.0.0

Definitieve versie van PvE BGZ Overdragend 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.

27-10-2024

Definitief

2.2.0

Verwijderd eis GBX.OPV.e4670.2.

Aangepast verwijzing AORTA access token eis GBX.BGZ.e4030.1 en toevoeging alternatief ZORG-AB.

13-1-2025

Definitief

2.3.0

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

Details

Eis:

In een inschrijftoken moeten de volgende gegevens opgenomen worden:

• BSN van de specifieke patiënt;

• UZI-nummer van de persoon die het inschrijftoken heeft aangemaakt; het UZI-nummer kan worden afgeleid uit het certificaat waarmee het token is ondertekend;

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

• Datum en tijdstip waarop inschrijftoken is aangemaakt;

• Datum en tijdstip van registreren BSN; t.b.v. het werkproces mag dit ook het tijdstip van aanmaken van het inschrijftoken zijn;

• Geldigheidsduur.

Toelichting:

De technische specificaties van het inschrijftoken zijn uitgewerkt in de [IH Inschrijftoken].

Details

Eis:

Een inschrijftoken heeft een maximale geldigheidsduur van 1,5 jaar.

Toelichting:

Een inschrijftoken kent een beperkte geldigheidsduur. Het is echter mogelijk om dezelfde informatie in het inschrijfttoken opnieuw te onderteken (zie eis GBX.OPV.e4050).

De geldigheid van het UZI-certificaat waarmee het inschrijftoken is ondertekend heeft geen invloed op de geldigheid van het inschrijftoken.

Een inschrijftoken heeft een maximale geldigheidsduur van 1,5 jaar.

Details

Eis:

Alleen daarvoor geautoriseerde rol(len)/perso(o)n(en) moet(en) een inschrijftoken (conform eis GBX.OPV.e4060) kunnen creëren en voor gebruik kunnen ondertekenen met het authenticatiecertificaat van de UZI-pas.

Het authenticatiecertificaat waarmee het inschrijftoken wordt ondertekend moet geldig zijn op het moment van ondertekenen.

Toelichting:

Het inschrijftoken moet waarborgen dat een patiënt in behandeling is bij een zorgorganisatie en dat de BSN van een patiënt is gevalideerd bij het SBV-Z.

Om het proces m.b.t. het aanmaken van inschrijftokens te controleren is het zaak om alleen geautoriseerde rollen en/of personen te autoriseren om een inschrijftoken aan te maken. Dit kunnen zorgverleners, zorgverlenerassistenten en/of baliemedewerkers zijn.

Details

Eis:

Inschrijftokens mogen binnen de AORTA-omgeving alleen meegestuurd worden met die interacties zoals beschreven in de AORTA-documentatie.

Toelichting:

Het LSP is niet voorbereid op het verwerken van een inschrijftoken indien dit niet expliciet is opgenomen in de AORTA-documentatie. Het LSP zal bij een onterecht meegestuurd inschrijftoken een foutmelding (XXXX) genereren.

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:

Inschrijf- en mandaattokens mogen alleen verstuurd worden over beveiligde verbindingen.

Toelichting:

Om te voorkomen dat (bepaalde) tokens worden afgevangen en misbruikt door een kwaadwillende moeten (bepaalde) 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:

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:

Het is aan de XIS-leverancier om een juiste melding of indicatie in het systeem te tonen om de gebruiker te waarschuwen.

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:

Voor gegevens versturende systemen o.b.v. FHIR geldt:

• Dat het systeem na ontvangst van een foutmelding, waaruit blijkt dat de afwijzing van het bericht van tijdelijke aard is, een duplicaatbericht nogmaals kan versturen binnen een tijdsbestek van 5 seconden tot 15 minuten.

• Dat het AORTA Access Token hergebruikt kan worden bij het versturen van een duplicaatbericht indien de geldigheidsduur van het token nog niet is verstreken.

• Dat het systeem een duplicaatbericht niet meer dan drie keer mag insturen, alvorens het sturen te staken.

• Dat wanneer op een nieuwe poging tot toevoegen van gegevens een antwoord 'bestaat al' wordt ontvangen, het systeem dit als succes mag interpreteren. Immers, de unieke identifier van de resource garandeert dat het om de juiste gegevens gaat.

• Dat wanneer op een nieuwe poging tot verwijderen van gegevens een antwoord 'bestaat niet' wordt ontvangen, het systeem dat als succes mag interpreteren.

• Dat op een nieuwe poging tot wijzigen van gegevens alleen een antwoord dat expliciet 'succes' aanduidt als succes geïnterpreteerd mag worden.

Toelichting bij eis:

Een retry-mechanisme dient om de gebruiker niet te vermoeien met foutmeldingen in geval van een incidentele communicatiestoring.

Op basis van de diverse foutcodes kan worden geïnterpreteerd of een aangemaakte resource al bestaat of niet.

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 (alleen indien XIS-leverancier gegevens beschikbaar wil stellen aan MedMij via LSP+).

De volgende organisaties moeten door het bronsysteem worden ondersteunt als organisatie vanuit waar opgevraagd wordt:

• Resource Broker VnC;

• Patiëntenportaal (GBP);

• Goed beheerde organisatie (GBO).

Details

Eis:

Het systeem dient de FHIR-resources op te leveren zoals is opgenomen in de betreffende zorgtoepassing.

Toelichting bij eis:

In de zorgtoepassing is beschreven welke FHIR-resources een systeem moet kunnen opleveren als gevolg van een bevraging.

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:

Afgeschermde gegevens dienen niet opgeleverd te worden.

Toelichting bij eis:

De zorgtoepassing vereist zelf geen specifieke afscherming van gegevens. Echter, mogelijk afgeschermde gegevens t.b.v. andere zorgtoepassingen, dienen ook niet opgeleverd te worden.

Details

Eis:

Patiëntgegevens moeten na vastlegging, automatisch of op commando van de gebruiker, vrijgegeven kunnen worden.

Na het vrijgeven van patiëntgegevens dient, indien van toepassing, de verwijsindex te 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.

Indien het systeem gebruik maakt van het VWI bewerkende systeem, dan is het bijwerken van de verwijsindex ook van toepassing.

Details

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.

Details

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.

Details

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;

• Fysieke Adresgegevens van de organisatie.

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.

Condities:

Indien er sprake is van een gerichte bevraging of verzending van patiëntgegevens.

Details

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.

Condities:

Indien er sprake is van een gerichte bevraging of verzending van patiëntgegevens.

Details

Beginsituatie:

• Er is een behandelrelatie vastgelegd met de mandaterende zorgverlener en de betreffende patiënt, en

• Er is een geldig consenttoken aangemaakt, en

• Er is en AORTA access token verkregen conform de specificaties waarnaar wordt verwezen in eis AOF.UC.e4010, en

• ZORG-AB of een andere betrouwbare bron (conform eis GBX.ADR.e4020) is geraadpleegd voor de juiste adressering.

Trigger:

Een gebruiker initiëert het proces om een bericht te versturen naar een specifieke zorgaanbieder.

Interacties:

• Het systeem verzendt de interacties in combinatie met een consenttoken en een AORTA access token naar de Resource Broker VnC.

• Het systeem ontvangt de antwoorden op de diverse interacties die uitgestuurd zijn.

Resultaat:

De opgeleverde gegevens zijn door het systeem:

• gepresenteerd aan de gebruiker, of

• verwerkt tot een beslissing die is gepresenteerd aan de gebruiker, of

• opgeslagen t.b.v. latere inzage door gebruiker.

Uitzonderingen:

Uitzonderingen zijn beschreven in de confluencepagina 'Publieke omgeving AORTA on FHIR' onder Common/Interfaces_Common.

Opties:

-

Responsetijd:

-

Betrouwbaarheid:

-

Toelichting bij eis:

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:

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:

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:

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:

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:

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 welk 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 BSNs 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 BSNs 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:

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

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

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

4. 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:

Lokaal opgeslagen zorgaanbiedergegevens dienen actueel te zijn, voordat het gebruikt wordt ten behoeve van communicatie via de AORTA infrastructuur.

Toelichting bij eis:

Er moet voorkomen worden dat medische informatie naar een verkeerde en/of niet bestaande zorgaanbieder wordt verstuurd. Het is daarom van belang dat met name adresseringsgegevevens van de te adresseren zorgaanbieder actueel worden gehouden.

Details

Eis:

Gegevens bij een persoon mogen alleen zichtbaar zijn indien de persoon daar toestemming voor heeft gegeven.

Toelichting bij eis:

De organisatie waar een zorgverlener werkzaam is dient een koppeling te maken met alle zorgverleners die werkzaam zijn binnen de organisatie. Deze koppeling kan alleen worden gelegd zodra een zorgverlener daar toestemming voor heeft gegeven.

De wijze waarop toestemming van de zorgverlener wordt verkregen is de verantwoordelijkheid van de organisatie.

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 applicatie-id worden verzonden. Hiermee worden onnodige foutmeldingen en onnodig verkeer voorkomen.

Details

Functie

Opvragen van zorgverleners o.b.v. identificerende zorgverlenerrol- en locatiegegevens waar de zorgverlener werkzaam is.

Karakter

Conditioneel

Condities

In het geval deze eis is opgenomen in een PvE <Zorgtoepassing> is deze eis verplicht.

Beginsituatie

• De gebruiker is lokaal ingelogd op vertrouwensniveau laag of hoger (trigger a), of

• Het systeem beschikt over de voor deze functie vereiste vertrouwensmiddelen (trigger b).

Trigger

• De gebruiker initieert de functie via het systeem, of

• Het systeem initieert de functie automatisch.

Interacties

• Het systeem verzendt een REST-Request naar de ZAB.

• Het systeem ontvangt een REST-Response van de ZAB.

Resultaat

De opgeleverde gegevens zijn door het systeem:

• gepresenteerd aan de gebruiker, of

• verwerkt tot een beslissing (die is gepresenteerd aan de gebruiker).

Uitzonderingen

Uitzonderingen zijn beschreven in de Foutentabel

Toelichting

Het moet mogelijk zijn om op basis van locatiegegevens en op basis van identificerende zorgverlenerrolgegevens (in ieder geval rolcode) te bevragen binnen welke zorgaanbieder(s) een zorgverlener werkzaam is. Alle zoekcriteria zijn opgenomen in de [IH ZAB].

Het is alleen maar mogelijk om zorgverleners op te vragen die een relatie hebben met (werkzaam zijn bij) een bepaalde zorgaanbieder.

Het aantal resultaten is beperkt tot <ZAB_Max_Zorgverleneraantal>.

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 ZORG-AB.

2. Het systeem ontvangt een REST-Response van de ZORG-AB.

Resultaat

De opgeleverde gegevens zijn door het systeem:

a. gepresenteerd aan de gebruiker

Uitzonderingen

Uitzonderingen zijn beschreven in de ‘ZORG-AB specificaties’.

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.

Alle specifieke zoekcriteria zijn opgenomen in de ‘ZORG-AB specificaties’.

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 ZORG-AB.

2. Het systeem ontvangt een REST-Response van de ZORG-AB.

Resultaat

De opgeleverde gegevens zijn door het systeem:

a. gepresenteerd aan de gebruiker

Uitzonderingen

Uitzonderingen zijn beschreven in de ‘ZORG-AB specificaties’.

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 ‘ZORG-AB specificaties’

Het is mogelijk dat op basis van de zoekcriteria meerdere zorgaanbieders worden geretourneerd. Het aantal resultaten is beperkt tot de waarde zoals is opgenomen in de ‘ZORG-AB specificaties’

Details

Functie

Opvragen van technische adresseringsgegevens o.b.v. zorgaanbiedergegevens.

Karakter

Conditioneel

Condities

In het geval deze eis is opgenomen in een PvE is deze eis verplicht.

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. verwerkt tot een beslissing (die is gepresenteerd aan de gebruiker).

Uitzonderingen

Uitzonderingen zijn beschreven in de Foutentabel.

Toelichting

Het moet mogelijk zijn om op basis van locatiegegevens en/of op basis van naamgeving van de zorgaanbieder technische adresseringsgevens op te vragen. Alle specifieke zoekcriteria zijn opgenomen in de implementatiehandleiding van ZORG-AB (https://www.vzvz.nl/diensten/gemeenschappelijke-diensten/zorg-ab/releases).

Het is mogelijk dat op basis van de zoekcriteria meerdere zorgaanbieders met hun (technische) identificeergegevens worden geretourneerd. Het aantal resultaten is beperkt tot het aantal zoals is opgenomen in de gebruikershandleiding van ZORG-AB (https://www.vzvz.nl/diensten/gemeenschappelijke-diensten/zorg-ab/releases).

Details

Eis:

Het bijwerken, aanvullen en verwijderen van informatie is beperkt tot de informatie zoals is opgenomen in de ‘ZORG-AB specificaties’

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 ‘ZORG-AB specificaties’ 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.

Details

Functie

Aanvullen Zorgaanbiedergegevens

Karakter

Optioneel

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 ZORG-AB conform de ‘ZORG-AB specificaties’.

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.

Details

Functie

Aanvullen Zorgverlenergegevens

Karakter

Conditioneel

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 te wijzigen gegevens zijn verwerkt in het ZAB.

Toelichting

Er dient voor de zorgverlener functionaliteit te zijn om de eigen gegevens aan te passen in het ZAB. Het betreft hier exclusief de gegevens die betrekking hebben op zijn rol als zorgverlener (er mogen dus geen aanvullingen in de zorgaanbiedergegevens aangebracht worden door een zorgverlener).

Een lokale ZAB-beheerder of het systeem mag na toestemming van een specifieke zorgverlener, diens gegevens aanvullen in het ZAB.

Details

Functie

Verwijderen zorgaanbiedergegevens

Karakter

Optioneel

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 ZORG-AB.

Resultaat

a. De te verwijderen gegevens zijn uit het ZORG-AB verwijderd.

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 ‘ZORG-AB specificaties’).

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 ZORG-AB de ‘ZORG-AB specificaties’).

Het is alleen mogelijk om de gegevens te laten verwijderen door een lokale ZORG-AB-beheerder of automatisch door een systeem.

Details

Functie

Verwijderen Zorgverlenergegevens

Karakter

Conditioneel

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 na toestemming van een specifieke zorgverlener.

Interacties

1. Het systeem verzendt een REST-DELETE naar de ZIM conform .

Resultaat

a. De te verwijderen gegevens zijn uit het ZAB verwijderd.

Uitzonderingen

Het UZI-nummer en de bijbehorende rolcode zijn vaste waarden en het is niet mogelijk om deze via het zorgadresboek bewerkend systeem te verwijderen.

Toelichting

Er dient voor de zorgverlener functionaliteit te zijn om de eigen gegevens te verwijderen. Het is niet mogelijk om een UZI-nummer en/of rolcode te verwijderen (zie voor de CRUD-autorisaties van de specifieke velden in het ZAB de [IH ZAB]).

In het kader van het voldoen aan de WBP moet een gebruiker deze functionaliteit zelf kunnen initiëren.

Een lokale ZAB-beheerder mag na toestemming van een specifieke zorgverlener, diens gegevens verwijderen.

Details

Functie

Bijwerken Zorgaanbiedergegevens

Karakter

Optioneel

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 het 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 ‘ZORG-AB specificaties).

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.

Details

Functie

Bijwerken Zorgverlenergegevens

Karakter

Conditioneel

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-PATCH naar de ZIM conform .

Resultaat

a. De te wijzigen gegevens zijn verwerkt in het ZAB.

Uitzonderingen

Het UZI-nummer en de bijbehorende rolcode zijn vaste waarden 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 ZAB de [IH ZAB]).

Toelichting

Er dient voor de zorgverlener functionaliteit te zijn om de eigen gegevens aan te passen in het ZAB. Het betreft hier exclusief de gegevens die betrekking hebben op zijn rol als zorgverlener (er mogen dus geen wijzigingen in de zorgaanbiedergegevens aangebracht worden door een zorgverlener).

Een lokale ZAB-beheerder of het systeem mag na toestemming van een specifieke zorgverlener, diens gegevens wijzigen in het ZAB.

Details

Eis:

AGB codes die zijn opgehaald bij ZORG-AB en die beginnen met 71 dienen niet te worden getoond richting de eindgebruiker.

Toelichting bij eis:

AGB codes die beginnen met 71 zijn niet bedoeld om te worden gebruikt door een eindgebruiker. Zij dienen er alleen voor om op technisch niveau een relatie te kunnen leggen uit diverse gegevens uit Vektis. Wanneer een organisatie een code heeft beginnend met 71, dan is dit een vestiging van een organisatie die zelf geen AGB code heeft aangevraagd, maar er is door Vektis wel een AGB toegewezen om de vestiging te kunnen identificeren.

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:

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 gehandhaafd. Het DVZA zal in dat geval na 60 seconden een time-out versturen naar het PGO.

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:

Door VZVZ verstrekte nieuwe gegevens met betrekking tot vertrouwde issuers en clients dienen binnen 24 uur geconfigureerd te worden.

Het is mogelijk dat er meerdere instanties met dezelfde functionaliteit, maar met verschillende configuratiegegevens naast elkaar bestaan.

Aanpassingen van configuratiegegevens dient te gebeuren door een daarvoor geautoriseerd persoon met een geldig tweefactormiddel.

Toelichting bij eis:

Om het zorgproces niet in gevaar te brengen is het noodzaak om medische gegevens beschikbaar te houden. Het is dan ook zaak om de configuratiegegevens actueel te houden om geen onterechte berichtafwijzingen te laten ontstaan.

De verschillende componenten binnen AORTA zijn niet perse beperkt tot één instantie. Het is bijvoorbeeld mogelijk dat er meerdere autorisatieservers en VnC's zijn. Deze kunnen verschillende configuratiegegevens hebben en dienen ook als zodanig geconfigureerd te kunnen worden.

Het aanpassen van configuratiegegevens door een kwaadwillende kan leiden tot een datalek(ken). Het is dan ook zaak om alleen geautoriseerde personen met een tweefactormiddel aanpassingen te kunnen laten doen.

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 NEN 7510).

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 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:

Toegang tot medische gegevens en LSP-functionaliteit kan door een systeemgebruiker alleen verkregen worden door middel van het inloggen met tweefactorauthenticatie.

Toelichting bij eis:

Conform de NEN 7510 (9.4.1 Beperking toegang tot informatie) moet een gebruiker voor toegang tot medische gegevens gebruik maken van een tweefactorauthenticatiemiddel. Hiervoor kan de UZI-pas worden gebruikt, maar ook andere tweefactorauthenicatiemiddelen zijn toegestaan.

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 server certificaten (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 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.

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ënverwijderd/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 tweefactor authenticatie 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 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.

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 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 patiënt 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.

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:

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:

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:

• NP Verzendend Systeem (versie 1);

• ZA Opleverend 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.