|
AORTA 2012 (v6·11) |
|
|
|
|
|
Datum: |
5 december 2012 |
|
Versie: |
6.11.0.0 |
|
Referentie: |
|
|
|
|
Nictiz is het landelijke
expertisecentrum dat ontwikkeling van ICT in de zorg faciliteert. |
|
AORTA 2012 (v6·11) |
|
|
|
|
|
Datum: |
5 december 2012 |
|
Versie: |
6.11.0.0 |
|
Referentie: |
|
|
|
|
Nictiz is het landelijke
expertisecentrum dat ontwikkeling van ICT in de zorg faciliteert. |
1 Inleiding 9
1.1 Doel en scope 9
1.2 Doelgroep voor dit document 9
1.3 Leeswijzer 9
1.4 Toelichting op de gebruikte notatie 10
1.5 Documenthistorie 10
2 Samenvatting 12
2.1 Primaire interacties 12
2.2 Ondersteunende interacties 12
2.3 Authenticatie en autorisatie 12
2.4 Betrokken informatiesystemen 12
2.5 Berichtuitwisseling 13
2.6 Non-functionele aspecten en beveiliging 14
3 Inleiding en context 15
3.1 Achtergrond 15
3.2 Wettelijk kader 16
3.2.1 Wet op de geneeskundige behandelingsovereenkomst [WGBO] 16
3.2.2 Wet beroepen in de individuele gezondheidszorg [WBIG] 16
3.2.3 Kwaliteitswet zorginstellingen [KWZi] 16
3.2.4 Wet bescherming persoonsgegevens [WBP] 16
3.2.5 Wet gebruik burgerservicenummer in de zorg Wbsn-z 17
3.3 Architectuurprincipes 17
4 Primaire interacties: het opvragen en sturen van patiëntgegevens 19
4.1 Interacties 19
4.2 Actoren 19
4.2.1 Zorgverlener 20
4.2.2 Zorgaanbieder 20
4.2.3 Medewerker van een zorgaanbieder 20
4.2.4 Patiënt 20
4.2.5 Goed Beheerde Organisatie 21
4.3 Toekenning van rollen aan actoren 21
4.3.1 Opvragen van patiëntgegevens 21
4.3.2 Sturen van patiëntgegevens 22
4.3.3 Toegangsbeperkingen 22
4.4 Toegangsmodel 24
4.4.1 Opt-in van de patiënt 24
4.4.2 Behandelrelatie 24
4.4.3 Bevoegdheid op basis van BIG-titel en het autorisatieprotocol 25
4.4.4 Patiëntbezwaar en het autorisatieprofiel 25
4.4.5 Mandatering 25
4.4.6 Vertegenwoordiging 26
4.4.7 Samenwerkingsverband 26
4.5 Identificatie en authenticatie 26
4.6 Patiëntgegevens 27
4.7 Het zoeken van gegevenshouders en gegevensontvangers 28
5 Ondersteunende interacties 30
5.1 Ondersteunende interacties 30
5.2 Actoren en rollen 32
5.2.1 SBV-Z 32
5.2.2 Landelijk schakelpunt 32
5.2.3 Klantenloket en Medewerker klantenloket 32
5.2.4 Autorisatiecommissie 32
5.2.5 Toezichthouder 32
5.2.6 Rollen 33
5.2.7 Mandatering 33
5.3 Opvragen/verifiëren BSN en controleren omloopstatus WID 33
5.4 Aan- en afmelden van patiëntgegevens 33
5.5 Raadplegen verwijsindex 34
5.6 Bijhouden van abonnementen en signaleren van gebeurtenissen 34
5.7 Selecteren van zorgaanbieders, zorgverleners en zorgaanbiederapplicaties 34
5.8 Raadplegen toegangslog 35
5.9 Bewerken autorisatieprofiel 35
5.10 Vastleggen autorisatieprotocollen 35
5.11 Signaleringen 35
5.11.1 Signaleringen eerste aanmelding 35
5.11.2 Signaleren verwijderde indexgegevens 35
6 Informatiesystemen 37
6.1 Inleiding 37
6.2 Zorginformatiemakelaar 38
6.2.1 Opvraag patiëntgegevens 39
6.2.2 Sturen patiëntgegevens 39
6.2.3 Verwijsindex 40
6.2.4 Zorgadresboek 40
6.2.5 Applicatieregister 40
6.2.6 Abonnementenregister 40
6.2.7 Authenticatie 40
6.2.8 Autorisatieprotocol 40
6.2.9 Autorisatieprofiel 40
6.2.10 Toegangslog 41
6.2.11 Gebeurtenisverdeler en gebeurtenisafhandelaars 41
6.3 Goed beheerd informatiesysteem (GBx) 41
6.4 zorginformatiesystemen (XIS) en het Goed beheerd zorgsysteem (GBZ) 41
6.5 Goed beheerd patiëntportaal (GBP) 42
6.6 Goed beheerd klantenloketsysteem (GBK) 43
6.7 Goed beheerde organisatie (GBO) 43
6.8 Basisregistraties en vertrouwensmiddelen 44
6.8.1 UZI-register 44
6.8.2 PKIO 44
6.8.3 DigiD 44
6.8.4 SBV-Z 45
7 Beheerinteracties 46
7.1 Actoren en rollen 46
7.1.1 GBx-beheerder en GBZ-beheerder 46
7.1.2 Beheerder ZIM 46
7.2 Toegang van GBZ-beheerders tot primaire en ondersteunende interacties 46
7.3 Beheer van aansluitingen 47
7.4 Beheer van de verwijsindex 47
7.5 Beheer van het zorgadresboek 48
8 Interacties tussen informatiesystemen 49
8.1 Algemene beschrijving van interacties 49
8.2 Systeemrollen 50
8.3 Zorgtoepassingen 51
9 Primaire informatiesysteeminteracties – opvragen en sturen van gegevens 52
9.1 Opvragen van patiëntgegevens 52
9.1.1 Interface LSP.OPV.i1010: opvragen van patiëntgegevens 53
9.1.2 Toelichting bij controle op totaalbezwaar bij het opvragen van patiëntgegevens 53
9.2 Versturen van patiëntgegevens 54
9.2.1 Interface LSP.STU.i1010: sturen van patiëntgegevens 54
10 Ondersteunende informatiesysteeminteracties 56
10.1 Aan- en afmelden van patiëntgegevens 56
10.1.1 Interface LSP.VWI.i1010: Aanmelden van gegevens 57
10.1.2 Interface LSP.VWI.i1020: Heraanmelden van gegevens 57
10.1.3 Interface LSP.VWI.i1030: Afmelden van gegevens 57
10.1.4 Notificatiesignalen 58
10.1.4.1 Interface GBX.VWI.i1010: Signalering eerste aanmelding 58
10.1.4.2 Interface GBX.VWI.i1020: Signalering verwijderde indexgegevens 58
10.1.5 Controle op opt-in bij het aanmelden van patiëntgegevens 58
10.2 Raadplegen van de verwijsindex 59
10.2.1 Interface LSP.VWI.i1040: opvragen index 60
10.2.2 Interface LSP.VWI.i1050: opvragen index met gegevensbeheerder 60
10.2.3 Interface LSP.VWI.i1060: opvragen eigen verwijzingen 60
10.3 Bijhouden van abonnementen en signaleren van gebeurtenissen 61
10.3.1 Interface LSP.ABR.i1010: Registreren abonnement 61
10.3.2 Interface LSP.ABR.i1020: Beëindigen abonnement 61
10.3.3 Interface LSP.ABR.i1030: Opvragen abonnementen 61
10.3.4 Interface GBX.SGL.i1050: Verwerken abonnementsignaal 61
10.4 Selecteren van zorgaanbieders, zorgverleners en zorgaanbiederapplicaties 63
10.4.1 Interface LSP.ZAB.i1010: opvragen van zorgaanbiederkandidaten 63
10.4.2 Interface LSP.ZAB.i1020: opvragen van zorgaanbiederdetails 63
10.4.3 Interface LSP.ZAB.i1030: opvragen van zorgverlenerdetails 64
10.4.4 Interface LSP.APR.i1040: opvragen van zorgaanbiederapplicatie. 64
10.5 Raadplegen van de toegangslog 65
10.5.1 Interface LSP.TLG.i1010: raadplegen toegangslog 65
10.5.2 ZIM-interne service: registreren toegangsgebeurtenis 65
10.6 Bewerken van het autorisatieprofiel 67
10.6.1 Interface LSP.APF.i1010: opvragen autorisatieprofiel 67
10.6.2 Interface LSP.APF.i1020: wijzigen autorisatieprofiel 68
10.6.3 ZIM-interne service: controle op totaalbezwaar 68
10.6.4 ZIM-interne service: controle op gedifferentieerd bezwaar 69
10.7 Vastleggen autorisatieprotocollen 69
10.7.1 ZIM-interne service: autoriseren van rol voor interactie 70
10.7.2 ZIM-interne service: autoriseren van applicatie voor interactie 70
10.7.3 Beheerfunctie ‘raadplegen autorisatiebestand’ 70
10.7.4 Beheerfunctie ‘laden autorisatiebestand’ 70
10.7.5 Beheerfunctie ‘rapporteren autorisaties’ 71
10.8 Opvragen/verifiëren BSN en controleren omloopstatus WID 71
11 Applicatie-interacties voor beheer 72
11.1 Raadplegen en bewerken van het applicatieregister 72
11.1.1 Interface LSP.APR.i1010: verifiëren communicatiekoppeling (tick-tock) 73
11.1.2 Interface LSP.APR.i1020: verifiëren applicatiekoppeling (ping-pong) 74
11.1.3 Interface LSP.APR.i1030: wijzigen applicatie 74
11.1.4 Interface LSP.APR.i1040: opvragen zorgaanbiederapplicatie 74
11.1.5 Interface LSP.APR.i1050: opvragen zorgaanbiederapplicatiedetails 74
11.1.6 Interface LSP.APR.i1060: Opvragen interactieversie 74
11.1.7 Interface LSP.APR.i1080: Toevoegen applicatiesysteemrol 74
11.1.8 Interface LSP.APR.i1070: Wijzigen applicatiesysteemrol 74
11.1.9 Rol van het APR bij beperking van het opleveren van gegevens tot een beperkte groep van zorgverleners (regionale beperking) 75
11.2 Beheer van de verwijsindex 75
11.2.1 Beheer van het zorgadresboek 76
11.2.2 beheerfunctie ‘initieel vullen van het zorgadresboek’ 76
11.2.3 Beheerfunctie ‘synchroniseren van het zorgadresboek’ 76
11.2.4 Beheer van overige aspecten van de ZIM 77
12 Overzicht van systeemrollen 79
13 Berichtafhandeling 80
13.1 Protocollen 80
13.2 Berichtafhandeling door de ZIM 82
13.2 Berichtafhandeling door de ZIM 82
13.2.1 Validatie van de berichtsyntax 82
13.2.2 Authenticatie en autorisatie van de zorgverlenerapplicatie 82
13.2.3 Authenticatie van de gebruiker / pashouder 82
13.2.4 Autorisatie op basis van het autorisatieprotocol 84
13.2.5 Autorisatie op basis van het autorisatieprofiel 85
13.2.6 Inhoudelijke verwerking van het bericht 85
13.2.7 Loggen van het bericht 87
13.3 Foutafhandeling 87
13.4 Afhandelen van berichtversies 88
13.4.1 Berichten van het type opvragen 88
13.4.2 Berichten van het type versturen 89
14 Infrastructurele aspecten 90
14.1 Conceptueel overzicht infrastructuur 90
14.1.1 Initiërende systemen 90
14.1.2 Communicatienetwerken 90
14.1.2.1 Zorg Service Provider (ZSP) 90
14.1.2.2 Domain Name Service 90
14.1.2.3 Domein aorta-zorg.nl 90
14.1.2.4 IP-adresreeksen 92
14.1.2.5 Internet-koppeling 92
14.1.2.6 Protocollen 92
14.1.3 Centrale infrastructuur 93
14.1.4 Reagerende systemen 93
14.1.5 Basisregistraties en certificatiediensten 93
14.2 Operationele aspecten 93
14.2.1 Beschikbaarheid 93
14.2.2 Capaciteit en schaalbaarheid 95
14.2.3 Responstijden 95
15 Beveiliging 96
Bijlage A Referenties 98
Dit document behandelt de architectuur van AORTA.
AORTA is de landelijk beschikbare infrastructuur voor berichtuitwisseling in de zorg in Nederland.
Dit document is gericht op zorgaanbieders, leveranciers van zorginformatiesystemen en de leverancier van het landelijk schakelpunt en geeft deze partijen een overzicht van de belangrijkste aspecten van de generieke functionaliteit van AORTA.
De architectuurbeschrijving in dit document is niet zozeer gericht op specifieke zorgprocessen, maar in meer algemene zin op het op generieke wijze faciliteren van informatieuitwisseling in de zorg. De architectuurbeschrijving in dit document is globaal onder te verdelen in vier secties, namelijk de ‘business’ architectuur, de informatiesysteemarchitectuur, de technische of infrastructuurarchitectuur en een aparte bespreking van de beveiligingsaspecten.
De ‘business’ architectuur behandelt op een abstract niveau enkele belangrijke architectuurprincipes, de actoren en rollen die betrokken zijn bij informatieuitwisseling in de zorg, de interacties tussen deze actoren en de randvoorwaarden die een rol spelen bij de uitwisseling van informatie. De business architectuur is opgenomen in hoofdstukken 3, 4, 5 en 7, en wordt zoveel mogelijk behandeld zonder in te gaan op de informatiesystemen die bij het uitwisselen van informatie een rol spelen.
De informatiesysteemarchitectuur is opgenomen in 6 tot en met 13 (met uitzondering van hoofdstuk 7) en gaat in op de informatiesystemen waarmee binnen de AORTA-architectuur de uitwisseling van informatie tussen zorgverleners wordt gefaciliteerd. Daarbij geeft hoofdstuk 6 een overzicht van de betrokken informatiesystemen en worden in hoofdstuk 8 tot en met 11 de relevante interacties tussen deze informatiesystemen beschreven. Hoofdstuk 12 geeft een samenvattend overzicht van de diverse rollen die de betrokken informatiesystemen hebben in de systeeminteracties binnen AORTA. Hoofdstuk 13 gaat meer in detail in op enkele bijzonderheden van de berichtuitwisseling binnen de AORTA-architectuur.
De technische of infrastructuurarchitectuur wordt in dit document alleen op conceptueel niveau behandeld in hoofdstuk 14. Hierbij wordt echter niet in detail ingegaan op implementatiekeuzes zoals specifieke productkeuzes, toewijzing van functionaliteit aan gespecialiseerde technische componenten of uitwerking van de netwerkinfrastructuur. Hiervoor wordt verwezen naar de technische beschrijvingen die zijn gemaakt in het kader van de fysieke implementatie van de infrastructuur, gebaseerd op de architectuur.
In hoofdstuk 15 wordt tenslotte een globaal samenvattend overzicht gegeven van beveiligingsaspecten, waarvan de meeste aspecten ook al in eerdere hoofdstukken zijn behandeld.
Tekst tussen vierkante haken [] verwijst naar referenties in bijlage A.
Architectuurprincipes en een beperkte groep van belangrijke centrale definities zijn voorzien van een kader.
Om te komen tot standaardisatie in notatie van architectuurdiagrammen wordt in dit document gebruik gemaakt van een beperkt aantal notatietechnieken.
Overwegend wordt gebruik gemaakt van de in Nederland ontwikkelde modelleertaal voor architectuur ‘ArchiMate’, die onder beheer staat van “The Open Group”. Behoudens enkele uitzonderingen volgen alle diagrammen de ArchiMate-notatie. Voor een overzicht van de relevante concepten wordt verwezen naar [ArchiMate].
Daarnaast wordt in hoofdstuk 13 gebruik gemaakt van activiteitendiagrammen volgens de modelleertaal UML van de “Object Management Group” (zie [UML]).
Voor de nummering van diagrammen, architectuurprincipes, eisen en tabellen is een coderingstelsel gekozen dat tot doel heeft om deze artefacten binnen de gehele AORTA-documentatieset één uniek nummer te geven.
|
Versie |
Datum |
Omschrijving |
|
6.10.0.0 |
12-okt-2011 |
RFC 34508 – van toepassing verklaren NEN 7510 op LSP |
|
6.10.0.0 |
12-okt-2011 |
RFC 35171 - Versiebeheer |
|
6.10.0.0 |
12-okt-2011 |
RFC 35179 – Authenticatie patiënt voor ZA portaal |
|
6.10.0.0 |
12-okt-2011 |
RFC 35181 – Opnemen “fictieve BSN’s” |
|
6.10.0.0 |
12-okt-2011 |
RFC 35188 – Signalering / abonneefunctie |
|
6.10.0.0 |
12-okt-2011 |
RFC 36012 – Synchronisatie GBZ en VWI |
|
6.10.0.0 |
12-okt-2011 |
RFC 42826 – Verwijderen BOV uit AORTA 7 |
|
6.10.0.0 |
12-okt-2011 |
RFC 42949 – Wijzigen datamodel applicatieregister |
|
6.10.0.0 |
12-okt-2011 |
RFC 33574 – Uitgifte hostnamen door LSP ipv ZSP |
|
6.10.0.0 |
12-okt-2011 |
RFC 46035 – Opt-in voor beschikbaar maken en opvragen van gegevens via AORTA |
|
6.11.0.0 |
5-dec-2012 |
RFC
51921 - ZSP label in GBZ-domeinnaam corrigeren |
AORTA is de landelijk beschikbare infrastructuur voor gegevensuitwisseling in de zorg in Nederland, met behulp waarvan zorgverleners onderling patiëntgegevens kunnen uitwisselen en patiënten hun eigen gegevens kunnen raadplegen.
AORTA ondersteunt als primaire interacties[1] het opvragen van patiëntgegevens en het versturen van patiëntgegevens. Hierbij maakt AORTA gebruik van een intermediair, het Landelijk Schakelpunt (LSP); het LSP houdt een verwijsindex bij, waarbij de gegevenshouders kunnen aanmelden dat zij over patiëntgegevens beschikken. Vervolgens kunnen zorgverleners en patiënten via het LSP gegevens opvragen zonder dat zij elke afzonderlijke gegevenshouder apart hoeven te benaderen. Ook bij het versturen van gegevens treedt het LSP op als intermediair en ondersteunt hierbij de adressering van gegevens.
AORTA ondersteunt het opvragen en versturen van gegevens met de volgende interacties:
AORTA authenticeert zorgverleners en patiënten die via AORTA gegevens uitwisselen. Zorgverleners moeten hiertoe beschikken over een UZI-pas, die hun unieke zorgverleneridentificatie bevat. Patiënten moeten beschikken over een DigiD.
AORTA regelt ook de autorisatie van betrokken zorgverleners en patiënten. De autorisatie houdt rekening met diverse aspecten, namelijk actieve instemming door de patiënt met het ter beschikking stellen van gegevens door de zorgaanbieder (opt-in), het bestaan van een behandelrelatie tussen zorgverlener en patiënt, het beroep van de zorgverlener en eventueel bezwaar van de patiënt tegen uitwisseling van gegevens. Ook is er de mogelijkheid voor de zorgverlener om andere medewerkers te mandateren, waarbij de medewerker gegevens kan uitwisselen onder verantwoordelijkheid van de zorgverlener.
Patiënten die niet zelf over de mogelijkheden beschikken om toegang tot AORTA te verkrijgen, kunnen zich wenden tot een Klantenloketorganisatie. Klantenloketmedewerkers kunnen hierbij enkele gegevens namens de patiënt opvragen. Klantenloketmedewerkers identificeren zich met een PKIO-pas.
AORTA.ALG.d1000 geeft een vereenvoudigd overzicht van de informatiesystemen die betrokken zijn bij AORTA.
Het LSP maakt gebruik van een centraal berichtuitwisselingsplatform, de Zorginformatiemakelaar (ZIM). De ZIM is verantwoordelijk voor de berichtuitwisseling tussen initiërende systemen en reagerende systemen.
Alle informatiesystemen die op de ZIM worden aangesloten moeten aan een stelsel van implementatie- en exploitatie-eisen voldoen, waarna ze worden aangeduid als ‘goed beheerd’ informatiesysteem, aangeduid met de afkorting GBx.
Tot de groep van GBx’en behoren:
Voor systeemauthenticatie moeten systemen beschikken over een UZI-servercertificaat (GBZ) of een servercertificaat van PKIoverheid (partijen die geen UZI abonnee kunnen worden, zoals ZIM, GBP, GBK, GBO).
Zowel de GBx’en als de ZIM hebben toegang tot de services van een aantal basisregistraties.
Diagram AORTA.ALG.d1000– overzicht AORTA
Om de interacties tussen zorgverleners onderling en tussen patiënt en zorgverlener te ondersteunen, is een reeks van interfaces gedefinieerd op de ZIM. Deze interfaces zijn beschikbaar voor GBZ’en, GBO’s en gedeeltelijk voor GBP’en en GBK.
Voor berichtuitwisseling tussen GBx en ZIM wordt gebruik gemaakt van berichten die gebaseerd zijn op de internationale medische berichtenstandaard HL7v3. HL7-berichten worden verstuurd over SOAP over HTTPS. GBx en ZIM worden gekoppeld via datacommunicatienetwerken (DCN’s) op basis van TCP/IP. De leveranciers van deze DCN’s moeten aan speciale eisen voldoen om zich te kwalificeren als Zorg Service Provider (ZSP).
De ZIM is ten behoeve van beschikbaarheid en continuïteit redundant en op gescheiden locaties geïmplementeerd. Voor beschikbaarheid, responstijden, capaciteit en schaalbaarheid zijn richtlijnen opgesteld die zijn vastgelegd in een programma van eisen (zie [PvE ZIM]) en in beheerafspraken.
Beveiliging van AORTA is een centraal aspect van de architectuur en is gebaseerd op een [Vertrouwensmodel], dat een geheel vormt van technische, organisatorische en juridische waarborgen. In de architectuur komen vooral de technische waarborgen aan de orde.
Zorgverleners in Nederland zijn op grond van de [WGBO] verplicht tot het inrichten van een dossier waarin alle gegevens omtrent de behandeling en de gezondheid van de patiënt worden opgenomen. Zorgverleners maken hiertoe niet alleen gebruik van papieren dossiers, maar ook van verschillende gespecialiseerde informatiesystemen zoals huisartsinformatiesystemen (HIS) en ziekenhuisinformatiesystemen (ZIS).
Vaak worden gegevens over dezelfde patiënt opgenomen in meerdere informatiesystemen, doordat de patiënt behandeld wordt door meerdere zorgverleners, bijvoorbeeld de huisarts, de vervangende huisarts, de apotheker en de medisch specialist. De verschillende behandelaars hebben hierbij niet altijd direct inzicht in elkaars gegevens. Dit kan ertoe leiden dat behandelaars niet beschikken over voor hen relevante informatie over eerdere of gelijktijdige behandelingen of medicatie.
Uitwisseling van patiëntgegevens tussen zorgverleners is in het belang van zowel patiënt als behandelaar. In veel situaties is voor de behandelaar belangrijke informatie namelijk al bij andere zorgverleners aanwezig; inzicht in de actuele medicatiestatus bij huisartswaarneming of in spoedgevallen is een klassiek voorbeeld. Indien deze uitwisseling elektronisch kan plaatsvinden kan dit de snelheid, doelmatigheid en betrouwbaarheid van gegevensuitwisseling bevorderen. Elektronische uitwisseling van gegevens is echter complex om een aantal redenen:
Elk initiatief tot informatie-uitwisseling in de zorg wordt geconfronteerd met deze aspecten. Vanuit het oogpunt van doelmatigheid is het zinvol om te komen tot een gezamenlijke aanpak tussen meerdere zorgpartijen, waaronder zorgverleners, koepelorganisaties, patiëntenorganisaties en leveranciers van ICT-systemen, waarbij gedeelde en toekomstvaste oplossingen worden gezocht. AORTA, de infrastructuur voor berichtenuitwisseling in de zorg, is tot stand gekomen in samenwerking met vertegenwoordigers van elk van deze partijen in het zorgveld.
AORTA adresseert de bovengenoemde uitdagingen door een aantal belangrijke uitgangspunten te kiezen ten aanzien van de architectuur:
Elk van deze aspecten wordt in dit architectuurdocument en de hieraan gerelateerde documenten (zie bijlage A) verder uitgewerkt.
De zorg in Nederland is in belangrijke mate wettelijk gereguleerd. Ook bij vastlegging en uitwisseling van informatie in de zorg speelt wetgeving een rol. Een uitgebreide behandeling hiervan valt buiten de reikwijdte van architectuurdocumentatie, maar aangezien enkele wetten voor een begrip van de architectuurcontext relevant zijn, worden ze hier kort genoemd.
De WGBO regelt de privaatrechtelijke verhouding tussen hulpverlener en patiënt. Voor de hulpverlener geldt een dossierplicht. Inzage in het dossier voor andere hulpverleners dan diegenen die betrokken zijn bij de behandeling is alleen mogelijk met toestemming van de patiënt. Inzage zonder toestemming is mogelijk als wet- of regelgeving daartoe verplicht. De patiënt zelf heeft recht op inzage in diens dossier en recht op een afschrift hiervan. De WGBO stelt tevens bewaartermijnen vast voor dossiergegevens.
De WBIG bevat een systeem van titelbescherming voor een aantal beroepsgroepen in de zorg. Personen die deze titels mogen voeren, worden opgenomen in het BIG-register, een register onder beheer van het CIBG, een uitvoeringsorganisatie van het ministerie van Volksgezondheid, Welzijn en Sport (VWS).
De KWZi bevat normen voor het bieden van verantwoorde zorg door zorginstellingen. De wet is van toepassing op alle instellingen waar in georganiseerd verband zorg wordt aangeboden, zoals ziekenhuizen en verpleeghuizen, maar ook bijvoorbeeld groepspraktijken van samenwerkende fysiotherapeuten. Solistisch werkende beroepsbeoefenaren, zoals een huisarts met een assistent, vallen niet onder de KWZi. In de KWZi worden onder meer eisen gesteld ten aanzien van de organisatie en het kwaliteitssysteem. Het gebruik van AORTA kan worden beschouwd als onderdeel van het verlenen van verantwoorde zorg in de zin van de KWZi.
De WBP stelt regels voor het verwerken van persoonsgegevens. Alle verwerkingen van persoonsgegevens moeten worden aangemeld bij de toezichthouder, het College Bescherming Persoonsgegevens, behalve als de verwerking is vrijgesteld van aanmelding. Verwerking van persoonsgegevens moet verder aan een aantal eisen voldoen. Verwerking moet op behoorlijke en zorgvuldige wijze plaatsvinden en moet een welbepaald en nadrukkelijk omschreven doel hebben. Naast het doel moet er ook een grondslag zijn voor verwerking. Er zijn zes mogelijke grondslagen, waaronder ondubbelzinnige toestemming van de betrokkene, en noodzaak ter uitvoering van een wettelijke plicht.
De Wbsn-z regelt dat in alle berichtgeving tussen zorgaanbieders het burgerservicenummer aanwezig moet zijn om persoonsverwisseling en daardoor (mogelijke) medische fouten te voorkomen. Een burgerservicenummer mag pas door de zorgaanbieder worden gebruikt nadat de patiënt zich heeft gelegitimeerd met een wettelijk identificatiedocument.
Aan AORTA liggen enkele belangrijke architectuurprincipes ten grondslag. Deze principes worden hier behandeld, waarbij de achterliggende argumentatie en de implicaties worden aangegeven.
AORTA.ALG.p1000: patiëntgegevens worden steeds bij het bronsysteem opgevraagd.
Het primaire doel van AORTA is het faciliteren van de uitwisseling van patiëntgegevens tussen zorgverleners. Er wordt een transportfaciliteit beoogd en niet een vervanging van het bronsysteem. Er wordt dus geen medisch inhoudelijke informatie vastgelegd in een (nieuwe) centrale bron buiten de bronsystemen van de zorgaanbieders.
Voor zover (niet medische) gegevens op een centrale plek worden opgeslagen dient dit uitsluitend om:
Er zijn diverse argumenten om patiëntgegevens bij het bronsysteem op te vragen:
AORTA.ALG.p1010: aan aangesloten zorgsystemen worden uitsluitend eisen gesteld die noodzakelijk zijn voor veilige gestandaardiseerde uitwisseling van gegevens.
Zorgverleners werken met diverse zorginformatiesystemen die zij afnemen van verschillende marktpartijen. AORTA is bedoeld om de uitwisseling van patiëntgegevens tussen deze systemen te faciliteren met behoud van marktwerking. Daarom moeten eisen aan de systemen waartussen gegevens worden uitgewisseld zoveel mogelijk worden beperkt tot het strikt noodzakelijke om te komen tot:
AORTA.ALG.p1020: voor toegang tot patiëntgegevens moeten zorgverleners persoonlijk worden geïdentificeerd en geauthenticeerd[3].
Het is uitsluitend voor zorgverleners waarvan de identiteit eenduidig is vastgesteld en bewezen toegestaan om patiëntgegevens te raadplegen.
AORTA.ALG.p1030: de mate van toegang van zorgverleners tot patiëntgegevens wordt bepaald door de rol van de zorgverlener.
Niet alle vastgelegde gegevens zijn noodzakelijkerwijs relevant voor andere zorgverleners. Met het oog op privacy is het niet wenselijk om gegevens uit te wisselen die niet nodig zijn voor de behandeling van de patiënt door een zorgverlener. Daarom wordt de toegang voor zorgverleners beperkt aan de hand van hun rol.
AORTA.ALG.p1040.1: gegevens worden slechts beschikbaar gesteld door zorgaanbieders via AORTA na toestemming van de patiënt; bovendien kunnen patiënten de toegang van (specifieke) zorgverleners tot hun gegevens inperken.
Elektronische uitwisseling van patiëntgegevens tussen zorgverleners is privacygevoelig. Het is op basis van bestaande wetgeving (behoudens enkele uitzonderingen) nodig, maar ook maatschappelijk wenselijk dat de patiënt expliciet instemt met het beschikbaar maken van zijn gegevens via AORTA, ook al wordt deze beschikbaarheid van gegevens geacht in het belang te zijn van de patiënt.
Patiënten hebben verder de mogelijkheid om uitwisseling via AORTA desgewenst voor specifieke zorgverleners toe te staan of te blokkeren.
AORTA.ALG.p1050: patiënten hebben via AORTA toegang tot hun eigen gegevens.
Patiënten hebben in de “papieren wereld” op grond van de [WGBO] het recht op inzage in en afschrift van hun dossier dat individuele zorgverleners over hen bijhouden. Het ligt daarom voor de hand dat gegevens die elektronisch beschikbaar worden gesteld voor uitwisseling via AORTA, ook via AORTA beschikbaar worden gesteld aan de patiënt. Hierdoor wordt het eenvoudiger voor de patiënt om gebruik te maken van het recht op inzage in en afschrift van zijn dossier.
AORTA.ALG.p1060: toegang tot patiëntgegevens wordt vastgelegd en is hierdoor traceerbaar.
Patiëntgegevens zijn privacygevoelige gegevens die alleen toegankelijk mogen zijn voor de behandelende zorgverleners en de patiënt zelf. Daarom is het van belang dat precies kan worden vastgesteld wie deze gegevens heeft geraadpleegd of verstuurd.
Het primaire doel van AORTA is het ondersteunen van informatie-uitwisseling tussen zorgverleners. Hiertoe ondersteunt AORTA een tweetal primaire interacties[4], zoals weergegeven in diagram AORTA.ALG.d1010:
In dit hoofdstuk wordt een aantal algemene aspecten van deze primaire interacties besproken, los van de implicaties op informatiesysteemniveau.
Diagram AORTA.ALG.d1010 - primaire interacties van AORTA
Gegevenshouder, gegevensraadpleger, gegevenszender en gegevensontvanger zijn algemene rollen en worden geconcretiseerd door aan te geven welke actoren deze rollen kunnen vervullen. Hiertoe is het noodzakelijk eerst een aantal actoren te introduceren die binnen de context van AORTA van belang zijn.
Binnen de context van AORTA zijn de volgende actoren van belang, namelijk:
In AORTA een ‘zorgverlener’ gedefinieerd als een individuele uitoefenaar van een medisch beroep zoals bedoeld in artikel 3 of 34 van de Wet op de beroepen in de individuele gezondheidszorg. Een zorgverlener kan uniek worden geïdentificeerd en beschikt over één of meer wettelijk beschermde beroepstitels.
In AORTA wordt verstaan onder een ‘zorgaanbieder’:
Een individuele zorgverlener kan dus ook een zorgaanbieder zijn, bijvoorbeeld in het geval van een huisarts met een eigen praktijk. Zorgaanbieder en zorgverlener kunnen dan dezelfde persoon zijn.
Een zorgaanbieder kan zorgverleners in dienst hebben en medewerkers die geen zorgverlener zijn. Dit geldt ook als de zorgaanbieder een individuele zorgverlener is: een huisarts kan bijvoorbeeld een verpleegkundige in dienst hebben en een huisartsassistente.
Deze relaties worden geïllustreerd in diagram AORTA.ALG.d1020. Dit toont dat een zorgaanbieder ‘gerealiseerd’ kan worden door een zorgverlener of een zorginstelling en dat zorgaanbieders (zowel zorginstellingen als zorgverleners) zorgverleners en medewerkers in dienst kunnen hebben.
Diagram AORTA.ALG.d1020 - illustratie van het begrip zorgaanbieder
In AORTA wordt bedoeld met een ‘medewerker van een zorgaanbieder’ een persoon die werkt voor een zorgaanbieder en zelf geen zorgverlener is. Een medewerker is uniek identificeerbaar en er kan worden vastgesteld voor welke zorgaanbieder de medewerker werkt.
Het begrip ‘patiënt’ wordt in AORTA niet beperkt tot personen die behandeld worden voor een aandoening, maar wordt meer algemeen opgevat. De patiënt is een uniek-identificeerbare natuurlijke persoon over wie informatie kan worden uitgewisseld. Omdat in de Wbsn-z is vastgelegd dat bij alle berichtgevingen tussen zorgaanbieders onderling het burgerservicenummer aanwezig moet zijn, kan de patiënt in de praktijk elke persoon zijn aan wie een burgerservicenummer is toegekend. Dat desondanks gesproken wordt over de patiënt en niet over ‘de burger’ heeft te maken met het feit dat in het kader van zorgprocessen de term ‘patiënt’ meer herkenning oproept.
Goed beheerde organisaties (GBO) zijn instellingen die niet beschreven staan in de Kwaliteitswet zorginstellingen. Deze instellingen kunnen als gevolg niet beschikken over UZI authenticatiemiddelen. Om toch gebruik te kunnen maken van de AORTA infrastructuur dient de instelling voorzien te worden van PKIoverheid certificaten. In geval een instelling is voorzien van PKIoverheid certificaten gelden dezelfde uitgangspunten als voor een zorgaanbieder.
Nu de actoren ‘zorgaanbieder’, ‘zorgverlener’ en ‘patiënt’ zijn geïntroduceerd, kunnen de rollen behorend bij de primaire interacties worden geconcretiseerd. Hierbij geldt voor de actor GBO hetzelfde als voor de actor ‘zorgaanbieder’.
De rollen behorend bij de interactie ‘opvragen van patiëntgegevens’ worden getoond in diagram AORTA.OPV.d1010.
Diagram AORTA.OPV.d1010 - opvragen van patiëntgegevens
Bij het opvragen van patiëntgegevens heeft een zorgaanbieder de rol van gegevenshouder. De opslag van dossiergegevens is namelijk in het algemeen gemeenschappelijk georganiseerd door de zorgaanbieder voor (groepen van) zorgverleners die bij de zorgaanbieder werkzaam zijn; toegang tot de dossiergegevens moet daarom op het niveau van de zorgaanbieder worden geregeld. Meerdere zorgaanbieders kunnen gegevenshouder zijn van gegevens van een bepaalde patiënt.
Een individuele zorgverlener behorend bij een zorgaanbieder (in het algemeen een andere zorgaanbieder dan de gegevenshouder) heeft de rol van gegevensraadpleger.
Ook de patiënt kan optreden als gegevensraadpleger van zijn eigen gegevens.
De rollen behorend bij de interactie ‘sturen van patiëntgegevens’ worden getoond in diagram AORTA.STU.d1010.
Diagram AORTA.STU.d1010 - Sturen van patiëntgegevens
Bij het sturen van patiëntgegevens heeft een zorgverlener die hoort bij een zorgaanbieder de rol van gegevenszender.
De gegevensontvanger kan een individuele zorgverlener zijn die hoort bij een zorgaanbieder (in het algemeen een andere zorgaanbieder dan de zorgaanbieder waartoe de gegevenszender behoort). Het is echter ook mogelijk dat de gegevenszender op het moment van verzenden nog niet kan vaststellen welke zorgverlener bij de ontvangende zorgaanbieder de behandeling van de patiënt zal uitvoeren en daartoe de gegevens zal raadplegen. In dit geval is de gegevensontvanger de zorgaanbieder, waarbij het aan de zorgaanbieder is om de gegevens beschikbaar te maken aan de individuele zorgverlener die de patiënt zal behandelen.
De modellen in paragraaf 4.3.1 en 4.3.2 houden niet in dat een zorgverlener die optreedt als gegevensraadpleger automatisch toegang kan hebben tot alle patiëntgegevens van alle patiënten waarover de gegevenshouder beschikt, of dat iedere zorgverlener die optreedt als gegevenszender de gegevens van elke willekeurige patiënt kan versturen. Een nadere inperking door een model van toegangsregels is vereist in de vorm van een toegangsmodel.
Het model van toegangsregels is het toegangsmodel. Om het toegangsmodel te bespreken is het noodzakelijk om enkele aanvullende begrippen te introduceren, namelijk:
De [WBP] en [WGBO] bieden het wettelijk kader voor het uitwisselen van gegevens in de zorg. Op grond van deze wetgeving geldt voor uitwisseling van medische gegevens onder de in dit document beschreven condities[5], dat expliciete toestemming nodig is van de patiënt voor het beschikbaar stellen van gegevens door een gegevenshouder aan een gegevensraadpleger.
Hierbij zijn de volgende uitgangspunten gehanteerd:
· De opt-in-vraag is nodig voor het beschikbaar stellen van gegevens aan andere zorgaanbieders.
· De opt-in-vraag wordt gesteld door elke zorgaanbieder die patiëntgegevens beschikbaar wil stellen.
· Het vooraf vastleggen van de toestemming van de patiënt is bedoeld voor het beschikbaar stellen van patiëntgegevens door gegevenshouders voor opvragen door gegevensraadplegers; de gegevenshouder kan hierbij namelijk geen toestemming vragen op het moment van opvragen. Bij sturen van patiëntgegevens kan per geval toestemming worden gevraagd en is vastlegging van toestemming vooraf niet nodig.
Het bestaan van een behandelrelatie tussen de zorgverlener en de patiënt is een voorwaarde voor toegang van de zorgverlener tot patiëntgegevens.
De volgende zorgaanbieders[6] of zorgverleners hebben een behandelrelatie volgens de [WGBO]:
Bij het opvragen van gegevens moet de zorgverlener die de rol heeft van gegevensraadpleger een behandelrelatie hebben. Bij het verzenden van gegevens geldt dit voor de zorgverlener die de gegevens verstuurt én voor de zorgverlener of zorgaanbieder die de ontvangen gegevens raadpleegt.
Zoals vastgelegd in de definitie van het begrip zorgverlener oefent de zorgverlener een beroep uit zoals bedoeld in de wet BIG. Niet alle patiëntgegevens zijn voor iedere zorgverlener relevant. Bij het uitwisselen van patiëntgegevens kunnen daarom gegevens worden afgestemd op het beroep en specialisme[8] van de betrokken zorgverleners. Het resultaat van deze afstemming wordt vastgelegd in een autorisatieprotocol.
Tot versie 6.0.5.0 van AORTA werd uitgegaan van een opt-out systeem, waarbij de toestemming van de patiënt voor het beschikbaar maken van gegevens via AORTA impliciet volgde uit het feit dat de patiënt geen bezwaar aantekende. Patiënten hadden dan ook de mogelijkheid om op een centraal punt bezwaar aan te tekenen tegen opvragen van gegevens en sturen van gegevens via AORTA. In de praktijk waren twee verschillende vormen van bezwaar mogelijk:
Met de overgang naar een opt-in model, dat uitgaat van expliciete toestemming, zal het mechanisme van totaalbezwaar verdwijnen en alleen nog worden toegepast gedurende een overgangssituatie, waarbij echter expliciet verkregen toestemming van de patiënt voorrang zal hebben. Het gedifferentieerd bezwaar blijft mogelijk; dit is eigenlijk geen algemeen bezwaar tegen gegevensuitwisseling, maar een middel voor de patiënt om nader te specificeren wie gegevens (niet) mag raadplegen.
De verzameling van gegevens over bezwaar van individuele patiënten wordt het autorisatieprofiel genoemd.
Zoals uitgelegd in subparagraaf 4.3.1 kan een zorgverlener patiëntgegevens opvragen bij een zorgaanbieder.
In de praktijk van de zorg komt het regelmatig voor dat een medewerker van de zorgaanbieder onder verantwoordelijkheid van de zorgverlener patiëntgegevens moet opvragen of verzenden. Voorbeelden zijn vervangingssituaties, opleidingssituaties en gevallen waarin medewerkers zonder BIG-titel gegevens moeten opzoeken voor een arts. Hierbij is het mogelijk dat de zorgverlener andere zorgverleners of medewerkers van de zorgaanbieder mandateert om onder zijn verantwoordelijkheid gegevens op te vragen of te verzenden. De zorgverlener die verantwoordelijkheden overdraagt is de mandaterende, de andere zorgverleners of medewerkers zijn de gemandateerden. Mandaten gelden binnen de context van de zorgaanbieder waaronder de mandaten zijn verstrekt.
Bij opvragen van gegevens door een gemandateerde moet duidelijk zijn:
De controle van de autorisatie moet hierbij worden toegepast alsof de mandaterende zorgverlener zelf de opvraag uitvoert. Dit geldt zowel voor de toepassing van de regels van het autorisatieprotocol (4.4.3), als voor toepassing van het autorisatieprofiel (4.4.4). Daarnaast geldt dat als de gemandateerde is uitgesloten door patiëntbezwaar, deze ook geen toegang tot de gegevens krijgt.
Zoals beschreven in subparagraaf 4.3.1 kan een patiënt de eigen patiëntgegevens opvragen bij een zorgaanbieder.
Hierbij moet rekening worden gehouden met enkele uitzonderingen, waarbij:
Zie de tekst van de [WGBO] voor een precieze beschrijving van deze uitzonderingssituaties. Bij de bespreking van de informatiesystemen voor patiënttoegang in paragraaf 6.5 en 6.6 wordt aangegeven in hoeverre deze uitzonderingen in de architectuur een rol spelen.
Zoals uitgelegd in subparagraaf 4.3.1 kan een zorgverlener patiëntgegevens opvragen bij een zorgaanbieder.
Hierbij moet rekening worden gehouden dat opvragingen alleen gedaan kunnen worden bij bronsystemen waarmee het opvragende systeem een samenwerkingsverband heeft. Alle samenwerkingsverbanden zijn in het applicatieregister vastgelegd. Bij elke opvraging wordt gecontroleerd of de organisatie, behorend bij het initiërende systeem, voorkomt in een (of één van de) samenwerkingsverband(en) die aan het te bevragen bronsysteem gekoppeld is. Een zorgaanbieder kan in meerdere samenwerkingsverbanden voorkomen of er voor kiezen om zijn patiëntgegevens landelijk beschikbaar te stellen.
Voor het sturen van patiëntgegevens wordt niet gekeken naar de samenwerkingsverbanden. Ook een opvraging van een ziekenhuis zal niet worden geautoriseerd op basis van een samenwerkingsverband. Ziekenhuizen mogen vanwege de continuïteit van de zorg, bij elke zorgaanbieder patiëntgegevens opvragen. Uiteraard moet wel voldaan worden aan de overige bovenstaande toegangsregels.
Alle actoren die betrokken zijn bij het opvragen en sturen van gegevens moeten geïdentificeerd kunnen worden om de volgende redenen:
De betrokken actoren kunnen op de volgende wijze kunnen worden geïdentificeerd:
In dit architectuurdocument wordt onder ‘patiëntgegevens’ verstaan: medisch inhoudelijke gegevens en administratieve gegevens over een patiënt. In de praktijk gebruiken gegevenshouders voor het bewaren van patiëntgegevens verschillende informatiesystemen die elk een andere systematiek kunnen hanteren bij de keuze voor de gegevensopslagstructuur.
Bij het opvragen en versturen van patiëntgegevens is het echter van belang dat overeenstemming bestaat over de structuur en betekenis van de uitgewisselde gegevens.
In de praktijk bestaan diverse gestandaardiseerde methoden om medische gegevens te modelleren maar zijn voor concrete uitwisselingssituaties nadere afspraken nodig tussen partijen welke van deze gestandaardiseerde methoden zullen worden ingezet en op welke wijze.
Binnen de architectuur van AORTA is er voor gekozen om gegevensberichten te baseren op HL7v3, een internationaal geaccepteerde open standaard voor uitwisseling van medische informatie. In paragraaf 13.1 wordt nader ingegaan op enkele aspecten van de HL7v3 berichtstructuur.
Bij het opvragen van patiëntgegevens door een gegevensraadpleger kan er sprake zijn van meerdere gegevenshouders en hoeven de gegevenshouders in de praktijk niet bekend te zijn bij de gegevensraadpleger.
AORTA adresseert dit probleem door het introduceren van een intermediair, het Landelijk Schakelpunt (LSP).
Het Landelijk Schakelpunt is een intermediaire organisatie die diensten verleend aan zorgaanbieders die zorginformatie willen uitwisselen en waarbij de gegevenshouders de beschikbaarheid van gegevens over patiënten kunnen aanmelden.
Door het aanmelden worden deze locatiegegevens opgenomen in een Verwijsindex.
De Verwijsindex (VWI) is een register waarin vastligt welke gegevenshouders over patiëntgegevens van specifieke patiënten beschikken.
Vervolgens kunnen gegevensraadplegers via de intermediair de beschikbare gegevens opvragen, zonder dat de gegevensraadpleger elke gegevenshouder afzonderlijk hoeft te benaderen.
Overigens is voor het aanmelden van gegevens bij de verwijsindex het verkrijgen van toestemming vooraf van de patiënt (opt-in) vereist.[10]
De gegevensraadplegers en de gegevenshouders maken bij dit mechanisme één set van afspraken met de intermediair over uitwisselingsformaten, beveiligingsaspecten en dergelijke.
De voordelen van deze oplossing zijn:
Bij het versturen van gegevens is het minder waarschijnlijk dat de gegevenszender de gegevensontvanger niet kent, maar er doen zich wel soortgelijke vraagstukken voor:
Door ook bij het verzenden van gegevens gebruik te maken van het LSP als intermediair, kunnen de wijze van adressering en de technische aspecten van gegevensuitwisseling worden gestandaardiseerd.
Bij de bespreking van de informatiesysteemsaspecten van de architectuur (vanaf hoofdstuk 6) worden de concepten van gegevensuitwisseling via een intermediair en verwijsindex verder uitgewerkt.
Naast de primaire interacties van opvragen en sturen van patiëntgegevens, biedt AORTA een aantal ondersteunende (‘secundaire’) interacties, die behandeld worden in dit hoofdstuk, vooralsnog los van de implicaties op informatiesysteemniveau (deze komen aan de orde in hoofdstuk 6 en 7). Een overzicht van de ondersteunende interacties wordt gegeven in diagram AORTA.ALG.d1030.4.
Diagram AORTA.ALG.d1030.4 - overzicht van ondersteunende interacties
Bij de volgende ondersteunende interactie wisselen eindgebruikers gegevens uit met de Sectorale Berichten Voorziening in de Zorg (SBV-Z) (zie 5.2.1):
Bij de volgende ondersteunende interacties wisselen eindgebruikers gegevens uit met het LSP, in plaats van met een andere eindgebruiker:
De ondersteunende interacties worden vanaf paragraaf 5.3 besproken.
In aanvulling op de ondersteunende interacties, is sprake van een aantal notificatiesignaal-interacties die automatisch plaatsvinden. Een overzicht hiervan wordt gegeven in diagram AORTA.ALG.d1040.1.
Diagram AORTA.ALG.d1040.1 - overzicht van notificatiesignaal-interacties
De automatische notificatiesignaal-interacties zijn:
Daarnaast kunnen eindgebruikers door gebruik van een abonnementfunctie aangeven dat zij in bepaalde situaties een abonnementsignaal willen ontvangen van het LSP.
In AORTA is een notificatiesignaal een signaal dat door het LSP wordt verstrekt aan een actor zonder dat deze actor een abonnement heeft. Een abonnementsignaal is een signaal dat door het LSP wordt verstrekt aan een actor die een abonnement heeft genomen op dergelijke signalen (zie verder paragraaf 5.6).
De actoren ‘zorgverlener’ en ‘patiënt’ zijn geïntroduceerd in paragraaf 4.2. Aanvullende actoren worden hier besproken.
De Sectorale Berichtenvoorziening in de Zorg (SBV-Z) is een onderdeel van het agentschap CIBG, uitvoeringsorganisatie van het ministerie van VWS. De SBV-Z vormt voor de zorgsector de toegangspoort tot de Beheervoorziening BSN (BVBSN), de organisatie die primair verantwoordelijk is voor de uitgifte en het beheer van het burgerservicenummer (BSN). Bij deze instantie kunnen burgerservicenummers van patiënten opgevraagd en geverifieerd worden. Ook biedt de SBV-Z een dienst om de omloopstatus van een wettelijk identificatiedocument (WID) te controleren.
Het Landelijk Schakelpunt (LSP) (geïntroduceerd in paragraaf 4.7) is een intermediaire organisatie die diensten verleend aan zorgaanbieders die zorginformatie willen uitwisselen en waarbij de gegevenshouders de beschikbaarheid van gegevens over patiënten kunnen aanmelden. Het LSP treedt op als intermediair tussen gegevensraadplegers en gegevenshouders, en tussen gegevenszender en gegevensontvanger.
Een uitgangspunt van AORTA is dat de patiënt volledig inzicht moet kunnen krijgen in de uitwisseling van de eigen patiëntgegevens. Er is voorzien dat patiënten, die zelf geen toegang hebben tot de daarvoor benodigde technische voorzieningen, toch een aanspreekpunt hebben dat dit inzicht kan verschaffen; dit aanspreekpunt is het klantenloket. Een medewerker van het klantenloket kan de patiënt van informatie voorzien over de uitwisseling van zijn patiëntgegevens via AORTA, overigens zonder dat de klantenloketmedewerker de uitgewisselde patiëntgegevens zelf kan inzien (de klantenloketmedewerker heeft uitsluitend toegang tot verwijsindexgegevens en toegangsloggegevens, zie 5.5 en 5.8). Klantenloketmedewerkers worden geïdentificeerd aan de hand van een PKIoverheidscertificaat (zie subparagraaf 6.8.2).
De autorisatiecommissie is een commissie met diverse vertegenwoordigers uit het zorgveld die per beroep en specialisatie van zorgverleners vaststelt wie welke gegevens mag raadplegen, versturen en/of ontvangen via AORTA. Deze commissie stelt dus het autorisatieprotocol vast dat is beschreven in subparagraaf 4.4.3. De autorisatiemanager is een rol van de voorzitter van de autorisatiecommissie. De autorisatiemanager zorgt ervoor dat de afgesproken autorisatieprotocollen worden vastgelegd bij het landelijk schakelpunt.
De toezichthouder op het correct gebruik van AORTA:
De rol van toezichthouder wordt vervuld door het College Bescherming Persoonsgegevens (CBP) en de Inspectie voor de Gezondheidszorg (IGZ).
In het overzichtsdiagram AORTA.ALG.d1030.4 worden diverse rollen geïntroduceerd, zoals ‘bewerker verwijsindex’ en ‘raadpleger verwijsindex’. Deze rollen worden geïntroduceerd om modeltechnische redenen (om het telkens herhalen van alle betrokken actoren te voorkomen) en impliceren niet dat voor iedere actor die een bepaalde rol vervult exact dezelfde autorisatie-eisen gelden; voor de rol van ‘raadpleger verwijsindex’ geldt bijvoorbeeld dat een zorgverlener toegang krijgt tot andere indexgegevens dan een patiënt.
De mogelijkheid van mandatering die is geïntroduceerd in subparagraaf 4.4.5 voor de interacties ‘opvragen van patiëntgegevens’ en ‘sturen van patiëntgegevens’ strekt zich ook uit tot de ondersteunende interacties die een zorgverlener mag uitvoeren. Waar sprake is van ‘zorgverlener’ kan dit, tenzij anders vermeld, dus worden geïnterpreteerd als ‘zorgverlener’ of een door de zorgverlener gemandateerde zorgverlener of medewerker.
De Wbsn-z regelt dat in alle berichtgeving tussen zorgaanbieders het burgerservicenummer (BSN) aanwezig moet zijn, om persoonsverwisseling en daardoor (mogelijke) medische fouten te voorkomen. Verder regelt de Wbsn-z dat de zorgaanbieder bij het eerste patiëntcontact de identiteit van de patiënt moet vaststellen aan de hand van een wettelijk identificatiedocument.
Een zorgverlener kan aan de hand van een aantal persoonsgegevens bij de SBV-Z controleren dat een BSN bij een bepaalde persoon hoort.[11] Ook kan een zorgverlener de omloopstatus van een aan hem aangeboden identificatiedocument bij de SBV-Z controleren.
Opvragen van patiëntgegevens vindt plaats via het LSP, zodat de zorgverlener niet op de hoogte hoeft te zijn welke zorgaanbieders gegevens hebben over de patiënt. Om het opvragen van patiëntgegevens via AORTA door andere zorgverleners mogelijk te maken, moet een zorgverlener de aanwezigheid van patiëntgegevens (in het informatiesysteem van de zorgaanbieder waartoe hij behoort) aanmelden bij het Landelijk Schakelpunt.
Aanmelding leidt tot het opnemen van een nieuwe verwijzing in een verwijsindex. Deze verwijzing kan later geactualiseerd worden door middel van een zogenaamde ‘heraanmelding’. De aanwezigheid van gegevens moet overigens ook weer afgemeld kunnen worden.
De zorgverlener die (her)aanmeldt of afmeldt heeft hierbij de rol van ‘bewerker verwijsindex’.
Voor het aanmelden van patiënten bij het LSP moet aan de voorwaarde worden voldaan dat, voorafgaand aan het aanmelden van de gegevens, expliciet toestemming van de patiënt is gevraagd (opt-in); dit moet blijken uit een registratie bij de zorgverlener.
Het raadplegen van de verwijsindex is nodig om vast te stellen welke zorgaanbieders hebben aangegeven over patiëntgegevens voor een specifieke patiënt te beschikken, zodat deze gegevens kunnen worden opgevraagd. Het betreft hier metagegevens, dus de medisch inhoudelijke informatie is niet in de verwijsindex terug te vinden.
De rol van ‘raadpleger verwijsindex’ kan worden vervuld door:
Voor een behandelend zorgverlener kan het van belang zijn om zo snel mogelijk op de hoogte te zijn van patiëntgegevens die door een andere zorgverlener over een patiënt worden vastgelegd. Daarom kan een zorgverlener, in de rol van ‘bewerker abonnementen’, zich abonneren op specifieke gebeurtenissen die in het LSP plaatsvinden, zoals bijvoorbeeld het aanmelden van nieuwe gegevens over een patiënt bij de verwijsindex. De abonnementhouder ontvangt dan een abonnementsignaal indien de gebeurtenis optreedt, en kan vervolgens actie ondernemen naar aanleiding van het abonnementsignaal, bijvoorbeeld opnieuw patiëntgegevens opvragen via het LSP.
Bij het versturen van gegevens moet de gegevenszender patiëntgegevens kunnen adresseren aan een gegevensontvanger.
Aangezien ook bij het versturen van gegevens het LSP als intermediair optreedt, biedt het LSP aan de gegevenszender de mogelijkheid om voorafgaand aan het sturen van gegevens de gewenste ontvanger op te zoeken in een zorgadresboek (ZAB). De zorgverlener die het zorgadresboek raadpleegt neemt de rol aan van ‘raadpleger zorgveldgegevens’.
Aangezien de beoogde ontvanger van de te versturen patiëntgegevens zowel een zorgaanbieder als een individuele zorgverlener kan zijn (zie subparagraaf 4.3.2) zijn zowel zorgaanbieders als zorgverleners opgenomen in dit adresboek.
De gegevenszender moet ook de zorgaanbiederapplicatie (het informatiesysteem[12] van een zorgaanbieder) waarnaar de gegevens daadwerkelijk worden gestuurd kunnen opzoeken. Hiertoe houdt het LSP in aanvulling op een zorgadresboek een applicatieregister (APR) bij.
Patiëntgegevens zijn privacygevoelige gegevens die alleen toegankelijk zijn voor de behandelende zorgverleners en de patiënt zelf. Daarom is het van belang dat precies kan worden vastgesteld wie patiëntgegevens heeft geraadpleegd of verstuurd. Omdat het LSP optreedt als intermediair bij raadplegen en sturen van patiëntgegevens kan het LSP nauwkeurig bijhouden in een log wie bij raadplegen en sturen betrokken is geweest. Deze log-informatie wordt vervolgens beschikbaar gemaakt aan de volgende actoren in de rol van ‘raadpleger toegangslog’:
Zoals besproken in subparagraaf 4.4.4 kan de patiënt bezwaar maken tegen uitwisseling van gegevens via AORTA en wordt dit vastgelegd in een autorisatieprofiel. Dit autorisatieprofiel kan worden bewerkt door een ‘beheerder autorisatieprofiel’. Deze rol kan worden vervuld door:
Zoals beschreven in subparagraaf 4.4.3 wordt een autorisatieprotocol vastgesteld waarin wordt vastgelegd per zorgverlenerberoep- en specialisatie welke gegevens kunnen worden uitgewisseld via AORTA. Een autorisatiecommissie stelt deze autorisatieprotocollen vast en laat deze via de autorisatiemanager vastleggen door het LSP.
Aangezien patiëntgegevens privacygevoelig zijn, is het van belang dat de patiënt zich ervan bewust is dat zijn gegevens opvraagbaar zijn via AORTA. Daarom is vastgesteld dat bij een eerste aanmelding van gegevens bij de verwijsindex van het LSP de patiënt hiervan in kennis wordt gesteld. In de praktijk gebeurt dit door een medewerker van het klantenloket, die over de aanmelding wordt genotificeerd door het LSP.
Zoals besproken in subparagraaf 4.4.4 kan de patiënt bezwaar maken tegen uitwisseling van zijn gegevens via AORTA. Indien de patiënt totaalbezwaar maakt worden de verwijzingen voor de desbetreffende patiënt uit de verwijsindex verwijderd, voorzover zij niet door expliciete toestemming van de patiënt bij de zorgverlener zijn verkregen[13]. Voor de zorgverlener die eventueel gegevens had aangemeld is het belangrijk om te weten dat deze gegevens niet langer in de verwijsindex zijn opgenomen. Daarom worden de zorgverleners die gegevens hadden aangemeld hiervan in kennis gesteld.
In dit hoofdstuk worden de verschillende informatiesystemen besproken, die betrokken zijn bij de uitwisseling van gegevens via AORTA.
AORTA.INF.d1020 geeft in een vereenvoudigd infrastructuurdiagram[14] een overzicht van de informatiesystemen die elk afzonderlijk in dit hoofdstuk worden besproken.
Diagram AORTA.INF.d1020 – overzicht informatiesystemen AORTA
Centraal in AORTA staat de Zorginformatiemakelaar (ZIM) (zie paragraaf 6.2), die verantwoordelijk is voor de berichtuitwisseling tussen opvragende systemen en bronsystemen (en tussen sturende en ontvangende systemen).
Alle informatiesystemen die op de ZIM worden aangesloten moeten aan een set implementatie- en exploitatie-eisen voldoen, waarna ze worden aangeduid als ‘goed beheerd’ informatiesysteem, aangeduid met de afkorting GBx (zie paragraaf 6.3).
Tot de groep van GBx’en behoren:
· een goed beheerd zorgsysteem (GBZ, zie paragraaf 6.4), een informatiesysteem dat door een zorgverlener wordt gebruikt om een patiëntdossier in te richten;
· een goed beheerd patiëntportaal (GBP, zie paragraaf 6.5), een portaal dat patiënten toegang geeft tot hun eigen gegevens;
· het goed beheerd klantenloketsysteem (GBK, zie paragraaf 6.6), het toegangssysteem van de klantenloketorganisatie.
Daarnaast hebben zowel de GBx’en als de ZIM toegang tot de services van een aantal basisregistraties en certificatiediensten, namelijk:
De GBx heeft aanvullend nog toegang tot de service van de Sectorale Berichten Voorziening in de Zorg (SBV-Z, reeds geïntroduceerd in subparagraaf 5.2.1; zie paragraaf 6.8.4 voor de systeemdiensten van SBV-Z).
De ‘Zorginformatiemakelaar’ (ZIM) is een centraal berichtuitwisselingsplatform, waarop de informatiesystemen van zorgaanbieders kunnen worden aangesloten. De ZIM wordt gebruikt door het LSP om invulling te geven aan de functie van intermediair tussen gegevenshouders en gegevensraadplegers. De term ‘informatiemakelaar’ is van toepassing omdat het platform in feite optreedt als een ‘makelaar’[15] van informatie.
De ZIM heeft binnen AORTA de volgende taken:
De ZIM is hiertoe samengesteld uit een aantal logische componenten waaraan deelverantwoordelijkheden zijn toegekend. Diagram LSP.ZIM.d1010.4 geeft hiervan een overzicht. Deze componenten worden hier kort behandeld. Meer informatie wordt gegeven in hoofdstuk 7 en in de ontwerpdocumenten van de individuele componenten.
De ZIM beschikt naast de logische componenten over een orchestratieservice[16]. Deze zorgt ervoor dat een bericht dat binnenkomt bij de ZIM in een aantal logische stappen wordt afgehandeld, waarbij de verschillende deelcomponenten in de juiste volgorde een bijdrage leveren aan de afhandeling van het bericht. Deze orchestratie wordt in detail behandeld in paragraaf 13.2.
Diagram LSP.ZIM.d1010.4 - systeemcomponenten binnen de Zorginformatiemakelaar
Deze component is verantwoordelijk voor het afhandelen van verzoeken van gegevensraadplegers en verzamelt daartoe per verzoek de gevraagde gegevens uit de informatiesystemen waarin volgens de verwijsindex gegevens aanwezig zijn.
Deze component is verantwoordelijk voor het doorsturen van patiëntgegevens van een aangesloten gegevenszender naar de juiste aangesloten gegevensontvanger.
Deze component houdt bij per patiënt in welke bij de ZIM aangesloten informatiesystemen patiëntgegevens aanwezig zijn. Deze gegevens moeten overigens eerst bij de verwijsindex worden aangemeld voordat ze geraadpleegd kunnen worden. De verwijsindex houdt geen medische informatie bij, deze blijft in het aangesloten zorgsysteem.
Deze component houdt informatie bij over zorgaanbieders en zorgverleners die betrokken kunnen zijn bij uitwisseling van informatie via de ZIM. Deze informatie is afkomstig uit het UZI-register.
Het zorgadresboek is vooral bedoeld als hulpmiddel voor gegevenszenders, om hen bij het versturen van gegevens via AORTA in staat te stellen om het informatiesysteem te vinden waarnaar zij een bericht willen sturen. Om dit te bereiken kan de gegevenszender via het zorgadresboek eerst de zorgaanbieder of zorgverlener zoeken die eigenaar is van het informatiesysteem. Het zorgadresboek is dus niet zozeer opgezet als een algemene zorgaanbiedergids om zorgaanbieders ook buiten AORTA om te kunnen bereiken.
Anders dan de naam van deze component kan suggereren gaat het bij ‘adressen’ dan ook
primair om identificatienummers van zorgverleners en zorgaanbieders, waarmee vervolgens in het applicatieregister (zie 6.2.5) het adres van een informatiesysteem kan worden gezocht.
Deze component houdt relevante gegevens bij over de informatiesystemen van zorgaanbieders die op de ZIM zijn aangesloten.
Het abonnementenregister houdt bij welke zorgverleners abonnementen hebben geregistreerd op bepaalde gebeurtenissen in de ZIM. Deze component maakt het mogelijk voor zorgverleners om vanuit op de ZIM aangesloten informatiesystemen abonnementen te registreren, op te vragen en te beëindigen.
Deze component is betrokken bij de afhandeling van elk bericht dat bij de ZIM binnenkomt vanuit een op de ZIM aangesloten informatiesysteem, zoals bij het opvragen en versturen van patiëntgegevens. De component identificeert en authenticeert hierbij de initiator van het bericht, aan de hand van informatie die in het bericht is meegegeven.
Het authenticatiemechanisme wordt in algemene zin besproken in hoofdstuk 13.2.3 en verder uitgewerkt in [Ontw Authenticatie].
Deze component is betrokken bij de afhandeling van elk bericht dat bij de ZIM binnenkomt vanuit een op de ZIM aangesloten informatiesysteem en controleert of het beroep en specialisatie of de rol van de initiator van het bericht in overeenstemming is met de gegevens die door middel van het bericht worden gevraagd of uitgewisseld.
Deze component is betrokken bij de afhandeling van elk bericht dat bij de ZIM binnenkomt vanuit een op de ZIM aangesloten informatiesysteem, voor zover dit betrekking heeft op informatie over een individuele patiënt. De component controleert hierbij of de patiënt in enige vorm bezwaar heeft gemaakt tegen de gegevensuitwisseling (‘totaal’ bezwaar of ‘gedifferentieerd’ bezwaar).
De mogelijkheid om ‘totaalbezwaar’ te maken is in deze versie van AORTA vervangen door de mogelijkheid actief toestemming te geven voor het beschikbaar maken van gegevens via AORTA (opt-in). Hierbij wordt de patiënt door de zorgaanbieder verzocht om toestemming voorafgaand aan het beschikbaar maken van informatie door de zorgaanbieder. Tijdens een nog vast te stellen overgangsperiode kan ‘totaalbezwaar’ nog wel worden geregistreerd, maar een eventuele expliciet gegeven toestemming (opt-in) door de patiënt bij een zorgverlener krijgt hierboven voorrang; deze toestemming kan uiteraard wel weer door de patiënt bij deze zelfde zorgverlener worden ingetrokken (zie ook subparagraaf 9.1.2). Het uitgangspunt hierbij is dat de registratie van toestemming een verantwoordelijkheid is van de zorgverlener in overleg met zijn patiënt.
Deze component is betrokken bij de afhandeling van elk bericht dat bij de ZIM binnenkomt vanuit een op de ZIM aangesloten informatiesysteem en registreert enkele kerngegevens waardoor elk uitwisseling achteraf controleerbaar is.
De gebeurtenisverdeler is het centrale meldpunt voor gebeurtenissen voor de overige componenten van de ZIM. De gebeurtenisverdeler zorgt ervoor dat gebeurtenissen worden doorgegeven aan alle gebeurtenisafhandelaren die in een bepaalde gebeurtenis geïnteresseerd zijn. Gebeurtenisafhandelaren zijn technische componenten die specifieke acties kunnen ondernemen, zoals het sturen van signaleringen. Concrete gebeurtenisafhandelaren zijn de Signaleringsafhandelaar en de Afhandelaar Bezwaar Patiënt.
De Signaleringsafhandelaar is een gebeurtenisafhandelaar die signalen stuurt naar een op de ZIM aangesloten informatiesysteem als een gebeurtenis plaatsvindt waarvoor het aangesloten systeem een abonnement heeft geregistreerd. De signaleringsafhandelaar gebruikt hierbij het abonnementenregister (zie subparagraaf 6.2.6) om te controleren welke systemen een abonnement hebben voor een bepaalde gebeurtenis.
De Afhandelaar Bezwaar Patiënt is een gebeurtenisafhandelaar die de gevolgen verwerkt van een gebeurtenis waarbij het autorisatieprofiel van een patiënt wordt gewijzigd in ‘totaalbezwaar’. Hierbij moeten onder meer de bestaande verwijzingen uit de verwijsindex worden gewist en de bestaande abonnementen worden opgeheven.
Een goed beheerd informatiesysteem (GBx) binnen AORTA is een concrete implementatie van een softwareproduct die voldoet aan een set van eisen voor de aansluiting op de ZIM. Deze eisen raken zowel het gebruikte softwareproduct als het beheer en exploitatie van de concrete implementatie van het softwareproduct.
GBx wordt gebruikt als een groeperende term voor alle concrete installaties van systemen van verschillende aard, dus niet uitsluitend zorgsystemen, die aan de eisen voor aansluiting op de ZIM voldoen.
Een ‘XIS’ is een verzamelterm voor informatiesystemen in het zorgveld, zoals bijvoorbeeld Huisartsinformatiesystemen (HIS) en Apotheekinformatiesystemen (AIS). In de praktijk beschikken zorgaanbieders, afhankelijk van hun werkzaamheden, over verschillende typen informatiesystemen. Dit zijn veelal implementaties van commercieel verkrijgbare informatiesystemen gebouwd door gespecialiseerde softwareleveranciers, maar kunnen ook in eigen beheer zijn ontwikkeld.
Een Goed Beheerd Zorgsysteem (GBZ) is een concrete installatie van een XIS of verzameling XIS’en, elk met een XIS-typekwalificatie (zie verderop in deze paragraaf), in gebruik bij één zorgaanbieder, die voldoet aan de implementatie- en exploitatie-eisen voor aansluiting op de ZIM[17]. Het begrip GBZ is een deelverzameling van het begrip GBx en is in feite een goed beheerd informatiesysteem (GBx) dat gebruikt wordt door een zorgaanbieder.
Om een XIS in te zetten als GBZ moet aan twee soorten eisen worden voldaan:
Het GBZ heeft in het kader van berichtenuitwisseling via AORTA enkele belangrijke verantwoordelijkheden[18]:
Een Goed Beheerd Patiëntportaal (GBP) is een (web)portaal voor patiënten die voldoet aan software-specifieke eisen om berichten uit te wisselen met de ZIM én aan implementatie- en exploitatie-eisen die voorwaardelijk zijn voor aansluiting op de ZIM.
Zoals besproken in subparagraaf 4.3.1 kan de patiënt optreden als gegevensraadpleger en heeft de patiënt hierbij toegang tot de eigen gegevens zoals die bij AORTA door zorgverleners zijn aangemeld. De patiënt krijgt toegang via een GBP.
Een inhoudelijke uitwerking van de architectuur van een GBP valt buiten de scope van AORTA. Wel is voor AORTA van belang dat voor een GBP verschillende implementatievormen mogelijk zijn:[19]
Op dit moment biedt de ZIM nog geen ondersteuning voor vertegenwoordiging van patiënten door andere personen (zie subparagraaf 4.4.6). Eventuele vertegenwoordigers zijn daarom aangewezen op het klantenloket.
Een goed beheerd klantenloketsysteem (GBK) is een informatiesysteem voor klantenloketmedewerkers, dat voldoet aan software-specifieke eisen én aan beheereisen die voorwaardelijk zijn voor aansluiting op de ZIM.
Hiermee kan een medewerker van het klantenloket namens een patiënt een beperkte set van (niet medisch inhoudelijke) gegevens opvragen, zoals besproken in subparagraaf 5.2.3.
In plaats van de patiënt kan ook een wettelijk vertegenwoordiger van de patiënt contact opnemen met het klantenloket. De regels uit de [WGBO] worden dan procedureel gecontroleerd door de klantenloketmedewerker, eventueel daarin ondersteund door applicatiefunctionaliteit in het GBK. De ZIM voert geen controles uit op vertegenwoordigingsrelaties, het GBK vraagt de ZIM immers om gegevens van de patiënt, niet om gegevens van diens vertegenwoordiger.
Een inhoudelijke uitwerking van de architectuur van een GBK valt buiten de scope van AORTA.
Een goed beheerde organisatie (GBO) is een informatiesysteem voor organisaties die geen UZI-abonnee kunnen worden. Een GBO moet voldoen aan software-specifieke eisen én aan beheereisen die voorwaardelijk zijn voor aansluiting op de ZIM.
Of een organisatie mag communiceren over de AORTA infrastructuur met alleen een PKIO-certificaat (anders dan UZI-certificaat), wordt voor elke organisatie apart bepaald. Een organisatie kan alleen worden aangesloten als er ook daadwerkelijk een businesscase is.
Het
Unieke Zorgverlener Identificatie register (kortweg UZI-register)
is het door de Minister van VWS aangewezen register van zorgaanbieders zoals
vermeld in artikel 14 van de Wbsn-z. Het UZI-register
wordt beheerd door het CIBG, een uitvoeringsorganisatie van het ministerie van
VWS.
Het UZI-register
is de certificatiedienstverlener (ook wel Certificate Service Provider of CSP)
die certificaten uitgeeft voor de unieke identificatie en authenticatie van
zorgaanbieders en indicatieorganen in de zorg.
Het UZI-register
koppelt hiertoe uniek de fysieke identiteit aan een elektronische identiteit en
legt deze vast in certificaten. De certificaten en de hierbij behorende cryptografische
sleutels bevinden zich op een smartcard, de UZI-pas.
Het
UZI-register
geeft UZI-passen uit voor door de minister van VWS bij wet en regelgeving
aangewezen partijen. Zorgverleners en medewerkers worden door het UZI-register
voorzien van een UZI-pas, informatiesystemen van een UZI-servercertificaat. De
UZI-pas is binnen AORTA nodig voor authenticatie van zorgverleners en
medewerkers van zorgaanbieders, het UZI-servercertificaat is nodig voor
authenticatie van GBZ’en.
Een
UZI-pas is een vertrouwensmiddel op basis van PKIO-certificaten (Private Key
Infrastructure Overheid, zie [PKIO]). Er zijn
aparte passen voor zorgverleners, medewerkers en medewerkers-niet-op-naam. De
pas faciliteert bij elektronisch verkeer authenticatie, versleuteling en het
plaatsen van een elektronische handtekening (dit laatste alleen met passen op
naam). De pas bevat een apart certificaat voor elk van deze drie functies.
Een UZI-pas bevat o.a. het UZI-nummer, beroep en specialisatie van de pashouder.
Ook bevat de pas het nummer van de zorgaanbieder die de pas heeft aangevraagd,
het UZI-register
abonneenummer (URA).
Een UZI-servercertificaat is eveneens een vertrouwensmiddel op basis van de PKIO. Het is nodig
voor het identificeren van een informatiesysteem en het opzetten van een
beveiligde elektronische verbinding. Het servercertificaat
bevat eveneens het URA van
de zorgaanbieder.
De
Public Key Infrastructure Overheid (PKIO) is een
infrastructuur voor het uitgeven en beheren van digitale certificaten.
PKIoverheid heeft een hiërarchische structuur van certificaten. Het ankerpunt
van vertrouwen binnen PKIoverheid, het stamcertificaat Staat der Nederlanden,
valt onder verantwoordelijkheid van de Nederlandse overheid.
PKIO verstrekt zowel
persoonlijke vertrouwensmiddelen op naam (PKIO-passen), als
systeemvertrouwensmiddelen (servercertificaten).
PKIO-passen worden gebruikt voor de identificatie van medewerkers van het
klantenloket.
PKIO-servercertificaten worden gebruikt door de ZIM, door het GBK,door GBP’en
en door niet UZI-abonnees (GBO). Ze zijn nodig voor het identificeren van het
informatiesysteem en het opzetten van een beveiligde elektronische verbinding.
Het
DigiD-register (zie [DigiD]) is een
ICT-voorziening onder beheer van ‘Logius’, de dienst digitale overheid van het
ministerie van Binnenlandse Zaken en Koninkrijksrelaties. In het DigiD-register
worden personen geregistreerd die door het DigiD-register zijn voorzien van een
vertrouwensmiddel.
Personen die vervolgens hun DigiD gebruiken om
zich te identificeren, kunnen door het DigiD-register worden geauthenticeerd.
Hierbij geeft het DigiD-register een elektronisch ondertekende bewering af over
de mate waarin het de authenticiteit van de gebruiker waarborgt. DigiD treedt hierbij
dus op als ‘identity provider’.
Authenticatie met behulp van DigiD is van toepassing voor patiënten die gebruikmaken van een GBP (zie ook hoofdstuk 13.2.3). Hierbij kan door GBP’en gebruik worden gemaakt van een intermediaire ‘identity provider’ tussen het DigiD-register en het GBP, zolang deze ‘identity provider’ identiteits-tokens afgeeft in een door de ZIM geaccepteerd formaat (zie [IH BA DigiD]).
De SBV-Z biedt toegang tot de volgende BSN-diensten die voor AORTA relevant zijn:
Deze diensten kunnen worden aangeroepen vanuit een GBZ wanneer de zorgverlener de identiteit van de patiënt verifieert (zie ook paragraaf 6.4).
In hoofdstuk 5 werden de ondersteunende interacties geïntroduceerd, die nodig zijn om de primaire interacties (het sturen en opvragen van patiëntgegevens) te ondersteunen. Enkele ondersteunende interacties tussen de partijen die betrokken zijn bij AORTA hebben betrekking op beheerwerkzaamheden voor informatiesystemen.
Nu de informatiesystemen zijn geïntroduceerd in hoofdstuk 6, kunnen ook de beheerinteracties kort worden geïntroduceerd. Deze worden echter alleen behandeld voor zover zij leiden tot eisen aan de functionaliteit van de ZIM. Een uitgebreide analyse van beheerprocessen valt buiten de reikwijdte van dit document. Hiervoor wordt verwezen naar de operationele uitwerking van beheerprocedures zoals vastgelegd in [AORTA DAP].
Ten behoeve van beheer worden de volgende aanvullende rollen onderscheiden.
De ‘GBx-beheerder’ draagt de verantwoordelijkheid voor het zorgvuldig beheren van een GBx dat op de ZIM wordt aangesloten en is contactpersoon voor de beheerder van de ZIM op het gebied van systeemtechnische zaken die de communicatie tussen aangesloten informatiesysteem en de ZIM beïnvloeden. In het geval van een goed beheerd zorgsysteem (GBZ) spreken we van een GBZ-beheerder. De rol van GBZ-beheerder wordt uitgevoerd onder de verantwoordelijkheid van de zorgaanbieder die eigenaar is van het GBZ en kan zonodig worden uitbesteed aan een externe beheerpartij, mits nog steeds aan de eisen wordt voldaan die worden gesteld aan een GBZ.
Vooralsnog is voor GBZ-beheerders geen eigen identificatiemiddel ontwikkeld.
De ‘beheerder ZIM’ draagt de verantwoordelijkheid voor het zorgvuldig beheren van de ZIM en de connecties met de daarop aangesloten informatiesystemen. De beheerder ZIM draagt daarmee zorg voor het dagelijks functioneren van AORTA als geheel. Aan de rol van beheerder ZIM kunnen nadere eisen worden gesteld die de rol verder onderverdelen in deelrollen. De rol van beheerder ZIM valt onder de eindverantwoordelijkheid van de LSP-organisatie (zie subparagraaf 5.2.2).
In hoofdstuk 4 en in hoofdstuk 5 zijn de primaire en ondersteunende interacties besproken die ondersteund worden door AORTA.
Ter ondersteuning van het functioneren van AORTA moeten GBZ-beheerders ook in staat zijn om primaire en ondersteunende interacties uit te voeren die normaal gesproken door zorgverleners worden uitgevoerd, bijvoorbeeld om problemen te onderzoeken. GBZ-beheerders mogen echter geen toegang krijgen tot medische gegevens. Om deze reden is een reeks van niet werkelijk bestaande patiënten gedefinieerd met een speciale reeks burgerservicenummers, die “fictieve BSN’s” worden genoemd. Interacties met betrekking op patiëntgegevens mogen door GBZ-beheerders alleen worden uitgevoerd in relatie tot fictieve BSN’s.
De volgende reeds behandelde interacties zijn toegankelijk voor GBZ-beheerders onder gebruik van fictieve BSN’s:
NB:
vanwege het feit dat vooralsnog geen identificatiemiddel voor GBZ-beheerders
voorhanden is, kan de beheerder in de praktijk nog niet zelfstandig van deze
functionaliteit gebruik maken; het gebruik van fictieve BSN’s is al wel
toegankelijk met een UZI-zorgverlenerpas, waardoor deze BSN’s wel voor
testdoeleinden bruikbaar zijn.
De volgende reeds behandelde interacties zijn niet gerelateerd aan
patiëntgegevens en zijn toegankelijk voor GBZ-beheerders:
Diagram AORTA.APR.d1010 - interactie voor het beheren van aansluitingen
De ZIM bewaart informatie over aangesloten informatiesystemen in het APR (zie paragraaf 5.7). Opname in het APR is een voorwaarde voor berichtenuitwisseling met de ZIM. De beheerder van een aangesloten GBx moet gegevens uitwisselen met de beheerder van de ZIM om aansluitgegevens van het systeem actueel te houden.
Diagram AORTA.VWI.d1030 – beheren van de verwijsindex
In de VWI van de ZIM staan alle aanmeldingen van alle GBZ’en. Wanneer een GBZ-beheerder vermoedt dat de in de VWI opgenomen verwijzingen uit de pas lopen met het beeld dat men vanuit het eigen informatiesysteem van aanmeldingen heeft, kan de GBZ-beheerder dit controleren door de volledige inhoud van de VWI voor het eigen informatiesysteem op te vragen.
NB: vanwege het nog niet beschikbaar zijn van een identificatiemiddel voor beheerders, is deze functionaliteit vooralsnog alleen beschikbaar met een UZI-zorgverlenerpas.
De gegevens over zorgaanbieders en zorgverleners in het ZAB (zie paragraaf 5.7) worden overgenomen uit een centraal zorgaanbieder/zorgverlenerregister, namelijk het UZI-register (zie paragraaf 4.5).
Diagram LSP.ZAB.d1010 - interactie voor het beheer van het adresboek
Wijzigingen in het UZI-register moeten regelmatig worden verwerkt in het ZAB, aangezien anders zorgaanbieders en zorgverleners in het ZAB kunnen ontbreken of een onjuiste status kunnen hebben.
Hiertoe moet de beheerder van de ZIM gegevens uitwisselen met de beheerder van het UZI-register.
De volgende hoofdstukken (9 tot en met 11) beschrijven hoe binnen AORTA de interacties uit hoofdstuk 4, 5 en 7 worden gerealiseerd door de informatiesystemen uit hoofdstuk 6. Hierbij ligt de nadruk op de generieke interfaces die de ZIM aanbiedt aan aangesloten informatiesystemen.
Diagram AORTA.ALG.d1060.1 is een algemene weergave van een berichtinteractie tussen een “initiërend systeem” (bijvoorbeeld een GBZ) en de ZIM, waarbij het initiërend systeem via de ZIM communiceert met een reagerend systeem (bijvoorbeeld een ander GBZ). Het diagram illustreert tevens de in de volgende hoofdstukken gebruikte notatie.
De ZIM biedt een interface (“door ZIM aangeboden interface”) aan het initiërend systeem. Dit systeem heeft een service om deze interface te gebruiken (“gebruiken van door ZIM geboden interface”).
De verantwoordelijkheid voor de afhandeling van de interface door de ZIM is toegekend aan de orchestratieservice van de ZIM. De orchestratieservice volgt hierbij ten dele een vast patroon, omdat een aantal taken bij elke berichtuitwisseling moet plaatsvinden. Hierbij maakt de orchestratieservice gebruik van de componenten Applicatieregister, Authenticatie, Autorisatieprotocol, Autorisatieprofiel en Toegangslog. Dit vaste verwerkingspatroon wordt verder uitgewerkt in paragraaf 13.2.
Diagram AORTA.ALG.d1060.1 – algemene beschrijving van interacties met de ZIM
Een deel van de berichtafhandeling is echter per interactietype verschillend en is in het diagram aangegeven met de service “inhoudelijk afhandelen van door ZIM geboden interface”. Deze inhoudelijke afhandeling wordt uitgevoerd door wisselende componenten van de ZIM, afhankelijk van het type bericht. In de volgende hoofdstukken zal per type interactie worden aangegeven welke component van de ZIM verantwoordelijk is voor de inhoudelijke afhandeling. Tijdens deze inhoudelijke verwerking kunnen ook reagerende systemen buiten de ZIM (bijvoorbeeld andere aangesloten GBZ’en) worden aangeroepen, die hiertoe dan ook een interface moeten implementeren (in het diagram aangegeven met “door reagerend systeem geboden interface”).
De volgende hoofdstukken concentreren zich op de door de ZIM aangeboden interfaces en de componenten die binnen de ZIM verantwoordelijk zijn voor de inhoudelijke afhandeling. Daarom worden de orchestratieservice en het vaste patroon van aanroepen van componenten niet steeds opnieuw getoond. Het diagram AORTA.ALG.d1060.1 kan versimpeld worden weergegeven zoals getoond in diagram AORTA.ALG.d1070. Hierbij zijn de orchestratieservice en overige componenten weggelaten en wordt de service van de component die verantwoordelijk is voor de inhoudelijke afhandeling van de door de ZIM geboden interface direct toegekend aan de door de ZIM geboden interface. Dit is de notatieconventie die verder in de hoofdstukken 9 tot en met 11 wordt gevolgd.
Diagram AORTA.ALG.d1070 – vereenvoudigde weergave van AORTA.ALG.d1060.1
De ZIM ondersteunt diverse soorten berichten, onder meer voor het opvragen en sturen van patiëntgegevens. Niet voor elk op de ZIM aangesloten GBx zijn alle berichten relevant, zo kunnen niet bij ieder GBx patiëntgegevens worden opgevraagd.
Een “systeemrol” binnen AORTA is een deelverzameling van berichtuitwisselingen die functioneel verwant zijn. Een voorbeeld van een dergelijke systeemrol is ‘verwijsindex raadplegend systeem’; hieronder vallen uitsluitend berichtuitwisselingen die te maken hebben met het raadplegen van de verwijsindex. Voor softwareleveranciers (bv. XIS-leveranciers) is het mogelijk om voor hun softwareproduct (bv. een XIS) een kwalificatie te behalen voor specifieke combinaties van systeemrollen.
In hoofdstukken 9 tot en met 11 worden de verschillende berichtuitwisselingen besproken die behoren bij de AORTA-basisinfrastructuur. Hierbij worden ook de bijbehorende systeemrollen benoemd. Een totaaloverzicht van systeemrollen wordt tenslotte gegeven in hoofdstuk 12.
De ZIM biedt een basisinfrastructuur voor berichtuitwisseling in de zorg. Over deze basisinfrastructuur kunnen berichten worden uitgewisseld die relevant zijn binnen bepaalde ketenprocessen in de zorg, bijvoorbeeld het medicatieproces, waarbij o.a. huisartsen en apotheken zijn betrokken. De groep van berichten die relevant is voor een bepaald ketenproces in de zorg, wordt samen een zorgtoepassing genoemd; een voorbeeld is de groep van berichten die bedoeld is voor communicatie tussen huisartsen en apotheken voor de uitwisseling van medicatiegegevens.
Bij deze zorgtoepassingen horen specifieke systeemrollen. Een voorbeeld van een dergelijke systeemrol is ‘medicatie-voorschrijvend-systeem’; hieronder vallen uitsluitend berichtuitwisselingen die behoren bij de zorgtoepassing medicatiegegevens en die relevant zijn voor de informatiesystemen van medicatievoorschrijvers (bijvoorbeeld huisartsen). Aan een XIS kan een kwalificatie worden toegekend voor één of meer van dergelijke systeemrollen. Specifieke zorgtoepassingen worden behandeld in aparte ontwerpdocumenten; aan zorgtoepassingen gerelateerde systeemrollen worden daarom niet in dit document behandeld.
In dit hoofdstuk wordt uitgewerkt hoe de primaire interacties, zoals besproken in hoofdstuk 4, worden uitgewerkt op informatiesysteemniveau.
AORTA koppelt patiëntgegevens raadplegende systemen via de ZIM aan bronsystemen voor patiëntgegevens. Zorgverleners zijn zo in staat om via hun eigen GBZ gegevens over hun patiënten uit de GBZ’en van andere zorgverleners op te vragen. Hiertoe moet hun informatiesysteem gekoppeld zijn aan de ZIM. De zorgverlener hoeft niet zelf te weten in welke andere informatiesystemen gegevens over zijn patiënten zijn opgeslagen. Dit wordt bijgehouden in de Verwijsindex (VWI), die onderdeel is van de ZIM. Er kunnen dan ook alleen gegevens worden opgevraagd die eerder bij de VWI zijn aangemeld (zie subparagraaf 10.1).
De ZIM biedt voor het opvragen één interface:
Patiënten kunnen hun eigen patiëntgegevens opvragen, voor zover deze bij de VWI zijn aangemeld. Dit kan via een GBP, met gebruikmaking van dezelfde interface[21].
Deze situatie is weergegeven in diagram AORTA.OPV.d1050.
Diagram AORTA.OPV.d1050 - informatiesysteeminteracties voor het opvragen van patiëntgegevens
Het opvragen van patiëntgegevens kan vanuit een op de ZIM aangesloten patiëntgegevens raadplegend systeem worden geïnitieerd. Deze interface wordt gebruikt om de inhoudelijke gegevens van een patiënt op te vragen zoals die in andere op de ZIM aangesloten informatiesystemen aanwezig zijn. Wanneer patiëntgegevens via de ZIM worden opgevraagd, stuurt de ZIM-component ‘Opvraag patiëntgegevens’ (OPV) de opvraag door naar alleen die GBZ’en die volgens de Verwijsindex over de gevraagde gegevens beschikken.[22] De OPV component verzamelt vervolgens de resultaten en beantwoordt het oorspronkelijke verzoek.[23]
Om het doorsturen van opvraagverzoeken mogelijk te maken moet een op de ZIM aangesloten informatiesysteem de benodigde interface implementeren, GBX.OPV.i1010; deze is structureel gelijk aan LSP.OPV.i1010, maar het doorgestuurde opvraagverzoek bevat nu de ZIM als afzender.
Zie voor een verdere uitwerking van de aspecten van deze interface het ontwerp van de component ‘Opvraag patiëntgegevens’ (OPV) (zie [Ontw OPV]).
N.B. De ‘opvragen van patiëntgegevens’ interface is een abstracte interface; er bestaat dus geen concreet geïmplementeerde interface met deze naam. De abstracte interface bestaat enkel op ontwerpniveau om het beschrijven van een aantal generieke aspecten van deze interface mogelijk te maken, zodat de ZIM verschillende concrete opvraagberichten op een generieke wijze behandelt. In de uitwerking van concrete zorgtoepassingen (bijvoorbeeld medicatieproces, huisartswaarneemgegevens) worden concrete implementaties ontworpen van deze interface (bijvoorbeeld ‘opvragen medicatievoorschriften’). Waar sprake is van abstracte interfaces wordt dit expliciet benoemd.
Tot aan deze versie van AORTA werd toestemming van de patiënt voor uitwisseling van medische gegevens verondersteld, tenzij de patiënt actief bezwaar had aangetekend. Vanaf deze versie van AORTA is dit niet langer het geval. In plaats daarvan wordt actief toestemming gevraagd.
Indien een patiënt in het verleden ‘totaalbezwaar’ maakte, werden automatisch alle verwijzingen uit de verwijsindex verwijderd. Ook werden voor deze patiënten nieuwe aanmeldingen automatisch geblokkeerd. Om deze reden konden nooit gegevens in de verwijsindex voorkomen van patiënten die bezwaar hadden aangetekend. Desalniettemin werd ook bij het opvragen van patiëntgegevens op de aanwezigheid van ‘totaalbezwaar’ gecontroleerd.
In deze versie van AORTA wordt overgegaan op een systeem van expliciete toestemming (opt-in), waardoor het aanmelden van patiënten pas mogelijk wordt na expliciete toestemming. Tijdens een nog vast te stellen overgangsperiode kan een eerder geregistreerd totaalbezwaar in de ZIM aanwezig zijn. Indien een patiënt die eerder totaalbezwaar heeft laten registreren in de nieuwe opzet alsnog expliciet toestemming (opt-in) geeft voor het beschikbaar maken van gegevens, krijgt deze expliciete wilsverklaring voorrang op het gemaakte bezwaar.[24] Daarom wordt de controle op totaalbezwaar bij het opvragen van gegevens opgeheven.
In de praktijk zal dit niet leiden tot de situatie dat ongewenst gegevens worden opgevraagd, want:
AORTA stelt zorgverleners in staat om via hun eigen informatiesysteem gegevens over de door hen behandelde patiënten op te sturen naar de informatiesystemen van andere zorgverleners.
Hiertoe moeten de informatiesystemen van zender en ontvanger gekoppeld zijn aan de ZIM. Voorafgaand aan het verzenden heeft de zender de mogelijkheid om via de ZIM de voor het adresseren benodigde informatie op te zoeken over de ontvanger (zie hiervoor subparagraaf 10.3).
De ZIM biedt voor het sturen één interface:
Een systeem dat deze interface implementeert heeft de systeemrol ‘gegevensversturend systeem’.
Deze situatie is weergegeven in diagram AORTA.STU.d1050.
Het sturen van patiëntgegevens kan vanuit een op de ZIM aangesloten informatiesysteem worden geïnitieerd. Deze interface biedt de mogelijkheid om de inhoudelijke gegevens van een patiënt te versturen naar een op de ZIM informatiesysteem dat behoort aan een andere zorgaanbieder. Wanneer patiëntgegevens via de ZIM worden verstuurd, stuurt de ZIM-component ‘Sturen patiëntgegevens’ (STU) de verzonden gegevens door naar het informatiesysteem dat in de adressering van het bericht is gespecificeerd. Om dit doorsturen mogelijk te maken moeten de aangesloten informatiesystemen de benodigde interface implementeren, GBX.STU.i1010; deze is structureel gelijk aan LSP.STU.i1010; ook inhoudelijk wordt de boodschap niet aangepast. De ZIM acteert dus alleen als intermediair.
Zie voor een verdere uitwerking van de aspecten van deze interface het ontwerp van de component ‘Sturen patiëntgegevens’ (STU) (zie [Ontw STU]).
N.B. De ‘sturen van patiëntgegevens’ interface is een abstracte interface; er bestaat dus geen concreet geïmplementeerde interface met deze naam. De abstracte interface bestaat enkel op ontwerpniveau om het beschrijven van een aantal generieke aspecten van deze interface mogelijk te maken, zodat de ZIM verschillende concrete opvraagberichten op een generieke wijze behandelt. In de uitwerking van concrete zorgtoepassingen (bijvoorbeeld medicatieproces, huisartswaarneemgegevens) worden concrete implementaties ontworpen van deze interface (bijvoorbeeld ‘versturen medicatievoorschrift’).
Diagram AORTA.STU.d1050 - informatiesysteeminteracties voor het sturen van patiëntgegevens
In dit hoofdstuk wordt uitgewerkt hoe de ondersteunende interacties, zoals besproken in hoofdstuk 5, worden uitgewerkt op informatiesysteemniveau.
Om het opvragen van patiëntgegevens via AORTA door andere zorgverleners mogelijk te maken, moet een zorgverlener het bestaan van patiëntgegevens in zijn eigen informatiesysteem aanmelden bij het Landelijk Schakelpunt.
Deze aanmelding leidt tot het opnemen van een nieuwe verwijzing in de Verwijsindex (VWI) die onderdeel is van de ZIM. Deze verwijzing bevat geen medisch inhoudelijke informatie, maar bevat metagegevens over de informatie die in het systeem van de aanmeldende zorgverlener aanwezig is, waaronder het patiëntnummer (BSN) en gegevenssoort. De gegevenssoort is een aanduiding van een categorie van medische gegevens. Het onderscheid in verschillende gegevenssoorten wordt onder meer gebruikt om toegang van zorgverleners te kunnen beperken tot specifieke categorieën van medische informatie (zie verder 10.7) .
De aanmelding bij de VWI kan op twee manieren plaatsvinden:
De wijze van aanmelding maakt voor de werking van het opvragen van gegevens overigens vrijwel geen verschil aangezien de gegevens in de verwijsindex alleen worden gebruikt om te selecteren welke systemen door de ZIM zullen worden bevraagd. Bij het zoeken naar één specifiek patiëntstuk kan in het geval van atomair aanmelden gericht één systeem worden geraadpleegd. Categoraal aanmelden zorgt echter voor een meer compacte verwijsindex. De standaard wijze van aanmelden is categoraal.
De ZIM biedt voor de aanmelding een drietal interfaces die zijn toegekend aan services van de Verwijsindex:
Daarnaast zijn twee automatische notificatiesignalen gerelateerd aan het gebruik van de Verwijsindex.
Deze situatie is weergegeven in diagram AORTA.VWI.d1010. De interfaces worden hier kort behandeld, zie [Ontw VWI] voor details.
Diagram AORTA.VWI.d1010 - informatiesysteeminteracties voor het beschikbaar maken van patiëntgegevens
Een aanmelding wordt geïnitieerd vanuit het informatiesysteem van de zorgverlener. De aanmelding leidt tot toevoegen van een verwijzing in de Verwijsindex (VWI). Een voorwaarde voor aanmelden is dat de zorgverlener de identiteit en burgerservicenummer van de patiënt heeft geverifieerd.
Een heraanmelding wordt geïnitieerd vanuit het informatiesysteem van de zorgverlener en leidt tot het bijwerken van een verwijzing in de VWI. Verwijzingen in de VWI bevatten onder meer gegevens over het tijdsinterval waarover gegevens beschikbaar zijn. Heraanmelding van gegevens geeft de mogelijkheid om dit interval te actualiseren. Ook andere attributen binnen de verwijzing kunnen worden aangepast.
Een zorgverlener heeft de mogelijkheid om eerder aangemelde gegevens weer af te melden. Hierbij wordt de desbetreffende verwijzing uit de VWI verwijderd.
Er bestaan twee automatische notificatiesignalen die naar aanleiding van het aanmaken of verwijderen van verwijzingen in de VWI kunnen worden verstuurd. Om het notificatiesignaal te kunnen ontvangen moet het ontvangende systeem de overeenkomstige interface implementeren.
N.B.: hiernaast bestaan nog abonnementsignalen (zie behandeling in subparagraaf 10.3); bij een heraanmelding volgt niet automatisch een notificatiesignaal, maar heraanmelding is wel een gebeurtenistype waarop een abonnement mogelijk is, waardoor abonnementsignalen ontvangen kunnen worden.
De eerste keer dat van een patiënt een aanmelding in de VWI wordt opgenomen, moet de patiënt geïnformeerd worden. Daarom stuurt de ZIM bij een eerste aanmelding van een gegevenssoort voor een patiënt een ‘signalering eerste aanmelding’ naar het GBK, zodat de patiënt kan worden geïnformeerd.
De VWI biedt de mogelijkheid om alle bestaande verwijzingen voor een patiënt te verwijderen, voorzover die niet zijn gedaan na expliciete opt-in[26]. In dit geval stuurt de ZIM een ‘signalering verwijderde indexgegevens’ naar de informatiesystemen van waaruit gegevens zijn aangemeld. Voor informatiesystemen die niet zijn gekwalificeerd om dergelijke signalen te verwerken worden deze berichten naar het GBK gestuurd.
Deze functie van de VWI wordt alleen uitgevoerd wanneer de ZIM een totaalbezwaar van een burger verwerkt in het autorisatieprofiel (zie subparagraaf 10.6).
Bij het aanmelden van patiëntgegevens voor uitwisseling via AORTA is het van belang dat vooraf door de gegevenshouder toestemming (‘opt-in’) is verkregen van de patiënt voor het beschikbaar maken van zijn gegevens. Daarom wordt bij het (her)aanmelden door de gegevenshouder gecontroleerd of de vereiste opt-in van de patiënt is verkregen. Dit moet gebeuren in het GBZ dat een (her)aanmelding verricht.
Diagram AORTA.VWI.d1060 beschijft globaal het proces en de controles die van toepassing zijn bij het aanmelden van patiëntgegevens. Een nadere uitwerking hiervan op systeemniveau is opgenomen in het [Ontw VWI].
Diagram AORTA.VWI.d1060 - Opt-in en het aanmeldproces
1. Elke zorgverlener die als gegevenshouder verantwoordelijk is voor het beschikbaar stellen van gegevens via het Landelijk Schakelpunt vraagt (eenmalig) toestemming aan de patiënt voor het beschikbaar stellen van diens patiëntgegevens.
2. De patiënt geeft (eenmalig per zorgverlener) toestemming voor het beschikbaar stellen van patiëntgegevens. Uiteraard kan de patiënt ook besluiten hiervoor geen toestemming te geven of deze later in te trekken.
3. De gegevenshouder registreert het geven van toestemming (of het niet geven van toestemming) door de patiënt.
4. De gegevenshouder meldt de gegevens van de patiënt aan bij het Landelijk Schakelpunt, dat optreedt als bewerker van de verwijsindex.[27] Aanmelden mag alleen indien toestemming verkregen is en dit uit de eigen registratie blijkt. De verantwoordelijkheid voor het correct aanmelden ligt bij de gegevenshouder. De gegevenshouder kan ervoor kiezen om aanmeldingen automatisch te laten uitvoeren door het eigen informatiesysteem (XIS), mits dit alleen aanmeldingen uitvoert voor patiënten waarvoor een opt-in in de registratie is opgenomen.
5. De bewerker van de verwijsindex neemt de verwijzing op (waarbij expliciet wordt vastgelegd dat de verwijzing onder opt-in is verkregen).
De Verwijsindex (VWI), die onderdeel is van de ZIM, houdt bij in welke informatiesystemen gegevens over patiënten zijn opgeslagen.
De ZIM biedt de volgende interfaces voor de bevraging van de verwijsindex:
Deze situatie is weergegeven in diagram AORTA.VWI.d1020.2.
Diagram AORTA.VWI.d1020.2 - informatiesysteeminteracties voor het raadplegen van de verwijsindex
De ‘opvragen index’ interface biedt de mogelijkheid om een overzicht op te vragen van de verwijzingen zoals die aanwezig zijn in de VWI van de ZIM voor een specifieke patiënt. Het opvragen van de index kan vanuit een op de ZIM aangesloten informatiesysteem (GBZ, GBP[28], GBK) plaatsvinden. Een verwijzing bevat onder meer de gegevenssoort, de zorgaanbieder die de gegevens heeft aangemeld en een tijdsinterval waarover gegevens beschikbaar zijn (zie [Ontw VWI] voor details).
Nadat het GBx heeft vastgesteld welke verwijzingen in de VWI aanwezig zijn, kan het GBx meer gericht naar inhoudelijke gegevens vragen.
De ‘opvragen index met gegevensbeheerder’ interface is gelijk aan LSP.VWI.i1040 interface maar levert meer informatie over de verwijzing. De verwijsindex maakt namelijk onderscheid tussen de zorgverlener die inhoudelijk verantwoordelijk is voor de gegevens (de ‘inhoudsverantwoordelijke’) en de zorgverlener die verantwoordelijk is voor het bewaren van de gegevens (de ‘beheerverantwoordelijke’). Naast de inhoudsverantwoordelijke levert deze interface ook de beheerverantwoordelijke voor de gegevens op.
De ‘opvragen index met gegevensbeheerder’ interface biedt de mogelijkheid om alle vanuit de eigen zorgaanbiederapplicatie opgegeven verwijzingen op te vragen (dit is hoofdzakelijk bedoeld als beheerinterface).
Zorgverleners kunnen zich abonneren op het optreden van specifieke gebeurtenissen in de ZIM, zoals bijvoorbeeld het optreden van wijzigingen in de verwijsindex voor een bepaalde patiënt. De ZIM stuurt dan automatisch een abonnementsignaal indien de gebeurtenis optreedt. Bij het aangaan van het abonnement kan het abonnerend systeem het informatiesysteem opgeven (binnen dezelfde zorgaanbieder) waarvoor het signaal bedoeld is. Het informatiesysteem dat het signaal ontvangt moet hiertoe beschikken over een module die wordt aangeduid als ‘abonnementsignaal ontvangend systeem’.
De systeemrollen ‘abonnerend systeem’ en ‘abonnementsignaal ontvangend systeem’ kunnen door hetzelfde informatiesysteem worden gerealiseerd, maar dit hoeft niet, zolang de informatiesystemen maar onder dezelfde zorgaanbieder vallen.
De ZIM biedt de volgende interfaces voor het bijhouden van abonnementen:
De ZIM beschikt over een abonnementsignaleringsafhandelaar die zorgt voor het sturen van berichten in het geval een gebeurtenis zich voordoet (zie voor details het [Ontw Sgl GBV]).
Om signaleringen van opgetreden gebeurtenissen te kunnen ontvangen moet het abonnementsignaal ontvangend systeem in staat zijn om abonnementsignaal-berichten te verwerken. Hiervoor moet het de volgende interface aanbieden:
Deze situatie is weergegeven in diagram AORTA.ABR.d1010.
De ‘registreren abonnement’ interface biedt de mogelijkheid om een abonnement te registreren voor een specifieke gebeurtenis in de ZIM, zoals het optreden van een nieuwe aanmelding van gegevens van een patiënt. Het registreren van een abonnement vindt plaats vanuit een abonnerend systeem.
De ‘beëindigen abonnement’ interface biedt de mogelijkheid om een eerder geregistreerd abonnement te beëindigen. Eventueel kan het abonnerend systeem vooraf de geregistreerde abonnementen opvragen via LSP.ABR.i1030.
De ‘opvragen abonnementen’ interface biedt de mogelijkheid om een lijst op te vragen van de gebeurtenissen waarop het abonnerend systeem een abonnement heeft genomen. Een abonnerend systeem kan via deze interface de eigen abonnementen van een zorgverlener opvragen.
De interface ‘verwerken abonnementsignaal’ moet door een abonnementsignaal-ontvangend systeem geïmplementeerd worden zodat het signalen kan ontvangen indien één van de gebeurtenissen optreedt waarop via het abonnerend systeem een abonnement is genomen. Een abonnementsignaal-bericht bevat geen medisch inhoudelijke informatie. Het ontvangen van een abonnementsignaal-bericht kan eventueel aanleiding zijn om vervolgens medisch inhoudelijke informatie via de ZIM op te vragen.
Diagram AORTA.ABR.d1010 – informatiesysteeminteracties – abonnementen en signaleringen
Zie voor een verdere behandeling van het abonnementenregister en de signaleringsafhandelaar de ontwerpen [Ontw Sgl ABR] en [Ontw Sgl GBV].
De ZIM stelt aangesloten informatiesystemen in staat om beschrijvende gegevens te achterhalen over de zorgaanbieder of zorgverlener, bijvoorbeeld de naam van een zorgaanbieder voor presentatie aan de eindgebruiker. Ook kunnen gegevens van aangesloten GBZ’en worden opgevraagd.
Deze functionaliteit is onder meer nodig bij het versturen van informatie via de ZIM naar het informatiesysteem van een andere zorgaanbieder. Hiervoor heeft de zendende partij het unieke applicatie-identificatienummer nodig van het informatiesysteem van de ontvanger. De zendende partij heeft dan de mogelijkheid om achtereenvolgens de juiste zorgaanbieder en het juiste unieke applicatie-identificatienummer op te zoeken.
De ZIM stelt hiertoe interfaces beschikbaar die toegang geven tot informatie uit twee ondersteunende componenten van de ZIM, het Zorgadresboek (ZAB) en het Applicatieregister (APR).
De ZIM biedt om het ZAB en APR te raadplegen vier interfaces, waarvan de eerste drie worden afgehandeld door het ZAB, en de vierde door het APR:
Binnen het goed beheerd zorgsysteem van de opvragende zorgverlener moeten hiertoe modules aanwezig zijn die het gebruik van deze interface ondersteunen. Deze modules zijn hier aangeduid als ‘zorgadresboek raadplegend systeem’ en ‘applicatieregister raadplegend systeem’.
Deze situatie is weergegeven in diagram AORTA.ALG.d1080.1. De interfaces worden hier kort behandeld, zie voor details het [Ontw ZAB] en het [Ontw APR].
Het opvragen van zorgaanbiederkandidaten wordt geïnitieerd vanuit het zorgadresboek raadplegend systeem en levert, op basis van één of meer zoekcriteria, een lijst van zorgaanbieders op.
Het opvragen van zorgaanbiederdetails wordt geïnitieerd vanuit het zorgadresboek raadplegend systeem en levert, op basis van een uniek zorgaanbiederidentificatienummer, meer gegevens over de zorgaanbieder (o.a. naam en type).
Diagram AORTA.ALG.d1080.1: informatiesysteeminteracties voor het bevragen van zorgadresboek en applicatieregister
Het opvragen van zorgverlenerdetails wordt geïnitieerd vanuit het zorgadresboek raadplegend systeem en levert, op basis van één of meer zoekcriteria, meer informatie over één of meer specifieke zorgverleners op (dit is dus een verschil met LSP.ZAB.i1020, waar details van één zorgaanbieder worden opgeleverd).
Het opvragen van de zorgaanbiederapplicatie wordt geïnitieerd vanuit het applicatieregister raadplegend systeem en levert, op basis van een uniek zorgaanbiederidentificatienummer en enkele mogelijke aanvullende zoekcriteria, een lijst van gegevens op uit het applicatieregister (waaronder een uniek applicatie-identificatienummer) van alle zorgaanbiederapplicaties die voldoen aan de zoekcriteria.
De toegangslog (TLG), die onderdeel is van de ZIM, houdt bij welke toegangsgebeurtenissen hebben plaatsgevonden waarbij berichten met de ZIM zijn uitgewisseld door op de ZIM aangesloten informatiesystemen.
De ZIM biedt één interface voor het raadplegen van de toegangslog:
Deze interface is toegankelijk voor de patiënt via een GBP[30] en voor medewerkers van het Klantenloket via het GBK. Deze informatiesystemen moeten hiertoe een module implementeren die aangemerkt wordt als ‘toegangslog raadplegend systeem’.
De ZIM stelt aan informatiesystemen die op de ZIM zijn aangesloten geen externe interface beschikbaar om rechtstreeks te communiceren met de daadwerkelijke loggingservice van de toegangslog. In plaats daarvan wordt de loggingservice aangeroepen als onderdeel van het afhandelen van andere berichtuitwisselingen tussen ZIM en aangesloten informatiesystemen, zoals het opvragen van patiëntgegevens. Hiertoe biedt de loggingcomponent één service aan andere componenten binnen de ZIM aan:
Deze situatie is weergegeven in een diagram AORTA.TLG.d1010. De interfaces worden hier kort behandeld. Zie voor meer detail het [Ontw TLG].
De interface ‘raadplegen toegangslog’ biedt de mogelijkheid om op te vragen welke berichten met de ZIM zijn uitgewisseld door aangesloten informatiesystemen over een specifieke patiënt. Het opvragen van het toegangslog kan vanuit een op de ZIM aangesloten GBP of GBK plaatsvinden.
De toegangslog biedt deze service aan andere componenten binnen de ZIM om gegevens over het uitwisselen van berichten met informatiesystemen te registreren. De ZIM gebruikt deze service tijdens elke berichtafhandeling waarbij een informatiesysteem betrokken is. Dit legt de basis voor inzicht in de traceerbaarheid van gegevensuitwisseling via AORTA.
Diagram AORTA.TLG.d1010 - informatiesysteeminteracties voor raadplegen van de toegangslog
Het autorisatieprofiel (APF) is een component van de ZIM die voorkeuren vastlegt van individuele patiënten over de uitwisseling van hun patiëntgegevens via AORTA. De patiënt kan hierbij op verschillende manieren bezwaar vastleggen tegen uitwisseling van de gegevens behorende bij zijn burgerservicenummer:
De ZIM stelt de volgende externe interfaces beschikbaar aan op de ZIM aangesloten informatiesystemen om het autorisatieprofiel op te vragen en te wijzigen:
Deze interfaces zijn toegankelijk voor medewerkers van het Klantenloket via het GBK en voor de patiënt via een GBP[31]. Deze informatiesystemen moeten hiertoe een module implementeren die aangemerkt wordt als ‘autorisatieprofiel bewerkend systeem’.
De ZIM stelt vooralsnog geen externe interface beschikbaar aan op de ZIM aangesloten informatiesystemen om direct te communiceren met de autorisatieservice van het autorisatieprofiel. In plaats daarvan wordt het autorisatieprofiel gecontroleerd als onderdeel van het afhandelen van berichtuitwisselingen tussen ZIM en aangesloten informatiesystemen, zoals het opvragen van patiëntgegevens. Hiertoe biedt het autorisatieprofiel een tweetal services aan andere componenten binnen de ZIM:
Deze situatie is weergegeven in diagram AORTA.APF.d1010. De interfaces worden hier kort behandeld. Zie voor meer detail het [Ontw APF].
Deze interface maakt het mogelijk om de gegevens op te vragen die in het autorisatieprofiel voor een specifiek burgerservicenummer zijn vastgelegd. Hierbij kan ook een tijdsperiode worden opgegeven om na te gaan wat op een bepaald moment het autorisatieprofiel was.
Deze interface maakt het mogelijk om het in het autorisatieprofiel vastgelegde uitwisselingsbeperkingen te wijzigen.
Diagram AORTA.APF.d1010 - informatiesysteeminteracties voor het beheren van het autorisatieprofiel
De autorisatieprofiel component biedt deze service aan andere componenten binnen de ZIM om te bepalen of een inkomend bericht is toegestaan volgens de ingestelde voorkeuren van de patiënt. De ZIM gebruikt deze service tijdens elke (her)aanmelding vanuit systemen waarvoor niet expliciet opt-in is geregistreerd[32]. Deze controle veroorzaakt een foutbericht indien de bezwaarcriteria van de patiënt de aanmelding verbieden.
De autorisatieprofiel component biedt deze service aan andere componenten binnen de ZIM om te bepalen of een inkomend bericht is toegestaan volgens de ingestelde voorkeuren van de patiënt. De ZIM gebruikt deze service tijdens elke berichtafhandeling waarbij het bericht betrekking heeft op een specifieke patiënt. Deze controle veroorzaakt een foutbericht indien de bezwaarcriteria van de patiënt de uitwisseling verbieden.
Het autorisatieprotocol (APT) is een component van de ZIM die:
Daarnaast legt de ZIM in het Applicatieregister (APR) vast voor welke interacties de op de ZIM aangesloten informatiesystemen zijn geautoriseerd, door een aangesloten informatiesysteem te koppelen aan een zogenaamde ‘HL7v3 conformancetabel’. Deze tabel wordt bij autorisatie gebruikt om te controleren of een applicatie een bepaald bericht mag verzenden en/of mag ontvangen.
De gewenste instellingen voor het autorisatieprotocol worden vastgesteld door een autorisatiecommissie waarin medische beroepsverenigingen en patiëntenverenigingen vertegenwoordigd zijn. Deze instellingen worden op last van de autorisatiemanager in het systeem aangebracht door een medewerker van het landelijk schakelpunt in de rol van autorisatiebeheerder van de ZIM.
Hiertoe is een beheerderinterface op de ZIM beschikbaar die toegang geeft tot een beheerservice voor autorisatieprotocol. Deze beheerservice ondersteunt twee functies, namelijk:
De ZIM stelt vooralsnog geen externe interface beschikbaar aan op de ZIM aangesloten informatiesystemen om direct te communiceren met de services van het autorisatieprotocol. In plaats daarvan wordt het autorisatieprotocol gecontroleerd als onderdeel van het afhandelen van berichtuitwisselingen tussen ZIM en aangesloten informatiesystemen, zoals het opvragen van patiëntgegevens. Hiertoe biedt het autorisatieprotocol twee services aan andere componenten binnen de ZIM aan:
Deze situatie is weergegeven in diagram AORTA.APT.d1010.1.
Diagram AORTA.APT.d1010.1 - informatiesysteeminteracties voor het beheer van het autorisatieprotocol
De autorisatieprotocolcomponent biedt aan andere componenten binnen de ZIM een service ‘autoriseren van rol voor interactie’ om te bepalen of een inkomend bericht is toegestaan voor de rolcode van de afzender van het bericht. De ZIM gebruikt deze service tijdens elke berichtafhandeling (behoudens enkele uitzonderingssituaties, zie [Ontw APT]). Deze controle veroorzaakt een foutbericht indien het te controleren bericht een onbekende zorgverlenerfunctie of rolcode bevat of indien de rolcode niet is geautoriseerd voor het berichttype.
De autorisatieprotocolcomponent biedt aan andere componenten binnen de ZIM een service ‘autoriseren van applicatie voor interactie’ om te bepalen of een inkomend bericht is toegestaan voor de applicatie die het bericht heeft gestuurd. De ZIM gebruikt deze service tijdens elke berichtafhandeling (behoudens enkele uitzonderingssituaties, zie [Ontw APT]). Deze controle veroorzaakt een foutbericht indien de verzendende applicatie niet is geautoriseerd voor het desbetreffende berichttype.
Met de functie ‘raadplegen autorisatiebestand’ kan de autorisatiebeheerder de instellingen van het autorisatieprotocol raadplegen. Hierbij is de ingangsdatum vast te stellen van elke autorisatie van een specifieke rolcode voor een specifiek berichttype.
Met de functie ‘laden autorisatiebestand’ kan de autorisatiebeheerder (op last van de autorisatiemanager namens de autorisatiecommissie) de instellingen van het autorisatieprotocol wijzigen. Hiermee kunnen specifieke rolcodes geautoriseerd worden voor specifieke berichttypes, of kan deze autorisatie juist worden ingetrokken.
Met de functie ‘rapporteren autorisaties’ kan de autorisatiebeheerder de instellingen van het actuele autorisatiebestand rapporteren.
N.B. De geautoriseerde interactiesoorten kunnen per informatiesysteem worden aangepast via een interface van de ZIM die toegang geeft tot de instellingen van het applicatieregister (zie subparagraaf 6.2.5).
De functionaliteit van het autorisatieprotocol wordt verder uitgewerkt in [Ontw APT].
De SBV-Z (zie subparagraaf 6.8.4) biedt interfaces voor:
De systeemrol die deze interfaces gebruikt wordt aangeduid als ‘patiëntadministrerend systeem’. Omdat binnen AORTA bij communicatie over patiënten een correct BSN nodig is, moet een GBZ beschikken over een ‘patiëntadministrerend systeem’.
Deze interfaces vallen buiten de specificaties van AORTA, aangezien de specificaties worden beheerd door de SBV-Z (zie [SBV-Z]). Voor AORTA is nog relevant dat van deze interfaces twee implementatievarianten bestaan, waarvan één gebaseerd op HL7v3-berichten. Het GBZ kan met beide interface-varianten direct de SBV-Z raadplegen.
In dit hoofdstuk wordt uitgewerkt hoe de beheersmatige interacties, zoals besproken in hoofdstuk 7, worden uitgewerkt op informatiesysteemniveau.
De ZIM bewaart de informatie over aangesloten informatiesystemen (‘applicaties’) in een applicatieregister. Opname in het applicatieregister is een voorwaarde voor berichtenuitwisseling met de ZIM. Hiertoe bevat het applicatieregister kerngegevens van het GBx, waaronder één zorgaanbiederidentificatie, één of meer unieke applicatie-identificatienummers en - per applicatie - een URI[33] waarop de applicatie bereikbaar is.
De ZIM biedt, om het APR te raadplegen en te bewerken, de volgende interfaces, die worden afgehandeld door het APR:
Voor het gebruik van deze interfaces moeten binnen een op de ZIM aangesloten informatiesysteem modules aanwezig zijn die het gebruik van deze interfaces ondersteunen. Deze modules zijn hier aangeduid als:
· applicatieregister raadplegend systeem; dit gebruikt interface LSP.APR.i1040 en interface LSP.APR.i1060;
· applicatieregister bewerkend systeem; dit gebruikt interface LSP.APR.i1030, LSP.APR.i1050, LSP.APR.i1070 en LSP.APR.i1080;
· koppeling verifiërend systeem; dit gebruikt interfaces LSP.APR.i1010 en LSP.APR.i1020.
Omdat de ZIM op kan treden als intermediair voor koppeling verificatie tussen een koppeling verifiërend systeem en een koppeling bevestigend systeem, moet een GBx om te kunnen optreden als koppeling bevestigend systeem de volgende interfaces implementeren. Deze zijn functioneel gelijk aan LSP.APR.i1010 en LSP.APR.i1020 maar hebben de ZIM als afzender:
Deze situatie is weergegeven in diagram AORTA.APR.d1010.2.
Diagram AORTA.APR.d1010.2 - applicatie-interacties voor het beheer van het applicatieregister
De interface ‘verifiëren communicatiekoppeling’ wordt aangeroepen vanuit de module ‘koppeling verifiërend systeem’ van een GBx en dient om het bestaan van een communicatiekoppeling met de ZIM of een reagerend GBx te controleren. Een ‘tick’-bericht test of het ‘koppeling bevestigend systeem’ in staat is om HL7-berichten te ontvangen.
De interface ‘verifiëren applicatiekoppeling’ wordt aangeroepen vanuit de module ‘koppeling verifiërend systeem’ van een GBx en dient om het bestaan van een applicatiekoppeling met de ZIM of een reagerend GBx te controleren. Een ‘ping’-bericht test of het ‘koppeling bevestigend systeem’ in staat is om HL7-berichten inhoudelijk te verwerken.
De interface ‘wijzigen applicatie’ kan worden aangeroepen vanuit de module ‘applicatieregister bewerkend systeem’ van een op de ZIM aangesloten GBx en geeft de mogelijkheid aan een beheerder van het aangesloten informatiesysteem om een beperkt aantal parameters initieel in te stellen of te wijzigen die over dat systeem in het applicatieregister zijn opgenomen, waaronder de status van de applicatie.
Deze interface is reeds behandeld in subparagraaf 10.4.4.
De interface ‘opvragen zorgaanbiederapplicatiedetails’ kan worden aangeroepen vanuit de module ‘applicatieregister bewerkend systeem’ van een op de ZIM aangesloten GBx en geeft de mogelijkheid om de in het applicatieregister opgenomen details over een aangesloten applicatie op te vragen. Een deel van deze informatie is alleen opvraagbaar voor de beheerder van het systeem waarover informatie wordt opgevraagd.
De interface ‘opvragen interactieversie’ kan worden aangeroepen vanuit de module ‘applicatieregister raadplegend systeem’ van een op de ZIM aangesloten GBx en geeft de mogelijkheid om voor een set van aangesloten informatiesystemen op te vragen wat de hoogste versie is van een bepaalde interactie die door die gehele set van aangesloten systemen én het interactie-initiërend systeem wordt ondersteund. Op deze wijze kan bij opvragen of sturen van patiëntgegevens vooraf worden vastgesteld welke interactieversie succesvol door alle betrokken systemen kan worden verwerkt.
De set van aangesloten informatiesystemen waarvan de versie moet worden bepaald kan hierbij expliciet worden opgegeven of kan door de ZIM worden afgeleid uit de verwijsindex op basis van een patiëntnummer.
Zie voor verdere uitwerking van de interfaces het [Ontw APR].
De interface ‘toevoegen applicatiesysteemrol’ kan worden aangeroepen vanuit de module ‘applicatieregister bewerkend systeem’ van een op de ZIM aangesloten GBx en geeft de mogelijkheid aan een beheerder van het aangesloten informatiesysteem om aan te geven dat het GBx een nieuwe systeemrol ondersteunt.[34]
De
interface ‘wijzigen applicatiesysteemrol’ kan worden aangeroepen vanuit de
module ‘applicatieregister
bewerkend systeem’ van een op de ZIM aangesloten GBx en geeft de mogelijkheid
aan een beheerder van het aangesloten informatiesysteem om de status van een
aan de applicatie toegekende systeemrol te
wijzigen. Daarnaast biedt deze interface de mogelijkheid om de geregistreerde
XIS-kwalificatie van het aangesloten GBx te wijzigen (bv. bij migratie naar een
XIS-versie met een nieuwe kwalificatie).
Zie voor verdere uitwerking van de interfaces het [Ontw
APR].
Het APR biedt een faciliteit om per organisatie een expliciete lijst bij te houden van zorgaanbieders die gegevens kunnen opvragen bij de desbetreffende organisatie. Een lijst voor een samenwerkingsverband bestaat uit een naam van het samenwerkingsverband, de gegevenssoort(en) die betrekking hebben op het samenwerkingsverband en een lijst met zorgaanbieders die het samenwerkingsverband vormen. Op deze lijst worden zorgaanbieders geplaatst, geïdentificeerd met hun UZI-registerabonneenummer (URA). Indien een dergelijke lijst is opgenomen worden opvraagberichten alleen gehonoreerd indien ze afkomstig zijn van de zorgaanbieders op de lijst en als het de gegevenssoort betreft die bij het samenwerkingsverband is opgenomen. Dit is een mechanisme dat bijvoorbeeld kan worden toegepast om uitwisseling regionaal te beperken.
Voor het beheren van deze lijsten worden geen speciale (bericht-)interfaces beschikbaar gesteld, maar zijn wel beheerfaciliteiten vereist op het niveau van de ZIM. Zie voor verdere uitwerking van dit aspect het [Ontw APR].
In de VWI van de ZIM staan alle aanmeldingen afkomstig uit GBZ-applicaties. Om te controleren of het beeld van de aangemelde gegevens dat bij de GBZ-beheerder bestaat overeenkomt met de werkelijke situatie in de VWI, kan de GBZ-beheerder de verwijzingen opvragen die vanuit een door hem beheerde applicatie zijn aangemeld. Hiertoe kan de GBZ-beheerder gebruik maken van de eerder beschreven interface LSP.VWI.i1060, ‘opvragen eigen verwijzingen’ (zie subparagraaf 10.2.3), waarbij het eigen applicatie-id als selectiecriterium voor de op te vragen verwijzingen kan worden opgegeven.
NB: omdat nog geen identificatiemiddel voor de GBZ-beheerder beschikbaar is, kan deze functionaliteit vooralsnog alleen worden gebruikt met een UZI-zorgverlenerpas.
Daarnaast kent de VWI, evenals andere componenten van de ZIM (zie subparagraaf 11.2.4), een beheerservice die toegankelijk is voor een beheerder van de ZIM via een beheerder user interface. Deze geeft de beheerder de mogelijkheid om onderhoud te plegen op de verwijsindex (zie [Ontw VWI]).
Deze situatie is weergegeven in diagram AORTA.VWI.d1040.1.
Diagram AORTA.VWI.d1040.1 – beheren verwijsindex
De gegevens over zorgaanbieders en zorgverleners in het zorgadresboek (ZAB) worden deels overgenomen uit een centraal zorgaanbieder/zorgverlenerregister, namelijk het UZI-register. Wijzigingen in het UZI-register moeten periodiek worden verwerkt in het ZAB, aangezien anders zorgaanbieders en zorgverleners in het ZAB kunnen ontbreken of een onjuiste status kunnen hebben.
Hiertoe is een beheerderinterface op de ZIM beschikbaar die toegang geeft tot een beheerservice voor het zorgadresboek. Deze beheerservice ondersteunt een tweetal functies, te weten:
Deze situatie is weergegeven in diagram AORTA.ZAB.d1100.
Het ZAB stelt een functie beschikbaar aan een beheerder van de ZIM om het ZAB initieel te vullen met gegevens van alle zorgaanbieders en zorgverleners uit het UZI-register. Details over het gegevensmodel van het ZAB worden uitgewerkt in het ontwerp ZAB, zie [Ontw ZAB].
Het ZAB stelt een functie beschikbaar aan een beheerder van de ZIM om het ZAB periodiek te synchroniseren met informatie uit het UZI-register. Details over het gegevensmodel van het ZAB en de synchronisatieregels worden uitgewerkt in het ontwerp ZAB, zie [Ontw ZAB].
Diagram AORTA.ZAB.d1100 - applicatie-interacties voor het beheren van het zorgadresboek
Diagram LSP.ZIM.d1020.3 toont op conceptueel niveau de beheerfaciliteiten van de ZIM. De ZIM beschikt over een gebruikersinterface die toegang geeft aan een beheerder voor het uitvoeren van beheeracties op elk van de componenten binnen de ZIM. Deze gebruikersinterface geeft de mogelijkheid om de toegang tot specifieke beheeracties te beperken tot beheerders in een meer specifieke rol. Weliswaar is op logisch niveau sprake van één beheerderinterface, op fysiek niveau kan sprake zijn van afzonderlijke interfaces voor deelcomponenten van de ZIM.
Elke component binnen de ZIM biedt een beheerservice die het voor een beheerder mogelijk maakt om configuratieparameters van de component in te stellen en eventuele storingen op te sporen en op te lossen. Per component kunnen in ontwerpdocumenten configuratieparameters en beheeracties worden geïdentificeerd.
Beheeracties worden gelogd in een beheerlog, met vastlegging van beheerderidentificatie, tijdstip en aanduiding van de beheergebeurtenis. Per component kunnen in ontwerpdocumenten beheergebeurtenissen worden geïdentificeerd die in de beheerlog moeten worden vastgelegd. Op basis van de beheerlog kan inzicht worden verkregen in de beheergebeurtenissen die hebben plaatsgevonden. De beheerlog dient als basis voor rapportages over beheergebeurtenissen, waarbij selecties mogelijk zijn per periode, gebeurtenistype of beheerder. In logische zin is sprake van één log, in technische zin kan sprake zijn van diverse aparte logs, die echter wel als één (eventueel virtueel) log benaderbaar zijn.
Analoog aan de beheerlog kent de ZIM een systeemlog, waarin alle foutsituaties worden gelogd die binnen de ZIM worden gedetecteerd. Foutafhandeling wordt verder besproken in paragraaf 13.3. Ook overschrijdingen van ingestelde grenswaarden van kritische systeemvariabelen worden in de systeemlog opgeslagen.
Op basis van het systeemlog kan inzicht worden verkregen in de foutgebeurtenissen die hebben plaatsgevonden. Het systeemlog dient als basis voor rapportages over foutgebeurtenissen, waarbij selecties mogelijk zijn tenminste per periode en gebeurtenistype.
Diagram LSP.ZIM.d1020.3– beheer services, beheerlog en systeemlog
Diagram GBX.ALG.d1010.3 geeft een samenvattend overzicht van de systeemrollen die zijn geïntroduceerd in de hoofdstukken 9, 10 en 11. Samen representeren deze systeemrollen de set van mogelijke interacties tussen GBx’en en de ZIM die vallen binnen de basisinfrastructuur van AORTA. Het diagram geeft tevens aan welke systeemrollen kunnen worden gerealiseerd door alle GBx’en en welke zijn voorbehouden aan GBZ’en, GBP en GBK.
Diagram GBX.ALG.d1010.3 – overzicht systeemrollen basisinfrastructuur AORTA
De applicatie-interacties die zijn beschreven in hoofdstuk 7 worden gerealiseerd door uitwisseling van berichten tussen de applicaties. Voor uitwisseling van medische gegevens wordt binnen AORTA gebruik gemaakt van de internationale HL7v3 standaard. Voor het transport van HL7v3 berichten over internetprotocollen zijn aanvullende keuzen nodig ten aanzien van transport- en beveiligingsprotocollen.
Hiertoe worden de aanbevelingen gevolgd uit het [WS-I basic profile] en [WS-I basic security profile]. WS-I(nteroperability) basic profile is een richtlijn voor de toepassing van SOAP 1.1 en WSDL 1.1. WS-I basic security profile is een richtlijn voor het toepassen van onder meer de standaarden WS-security, XML-signature en XML-encryption.
Diagram AORTA.BTP.d1010 - overzicht berichtprotocol-‘stack’
Diagram AORTA.BTP.d1010 geeft een overzicht van de protocollen die gebruikt worden voor berichtuitwisseling op de applicatielaag. Tussen applicatielaag en transportlaag (van het TCP/IP model) wordt gebruik gemaakt van Transport Layer Security (TLS).[35]
De HL7 payload is de eigenlijke berichtinhoud en bevat de medische gegevens die tussen de betrokkenen wordt uitgewisseld. De structuur van de medische gegevens is sterk afhankelijk van het soort gegevens dat wordt uitgewisseld. Hiertoe worden binnen HL7v3 verschillende informatiemodellen gebruikt, aangeduid met de term RMIM (refined message information model) die zijn toegespitst op de medische context van de gegevensuitwisseling.
De HL7v3 Trigger Event Control Act (TECA) wrapper bevat gegevens over de gebeurtenis die aanleiding was het bericht te versturen. Een belangrijk aspect van deze wrapper in het geval van verzoeken is dat deze wrapper aangeeft wie het verzoek heeft verzonden (de ‘auteur’) en wie verantwoordelijk is voor het zenden van het verzoek (de ‘eindverantwoordelijke’)[36]; dit legt de basis voor autorisatie, inclusief mandateringsaspecten. Zie het ontwerp autorisatie [Ontw APT] voor details.
De HL7v3 TECA wrapper en payload worden opgenomen in een HL7v3 transmission wrapper, die gegevens bevat over het berichttransport. Overigens kunnen meerdere HL7v3 transmission wrappers worden gecombineerd in een HL7v3 batch wrapper (niet getoond in het diagram).
Het HL7v3 bericht als geheel bevindt zich in de SOAP-body. Deze bevindt zich samen met de SOAP-header in de SOAP envelope. De SOAP-header bevat instructies over de wijze waarop het bericht moet worden afgehandeld, onder meer op het gebied van beveiliging. De SOAP-envelope als geheel is opgenomen in een HTTP-header.
Diagram AORTA.BTP.d1010 gaat niet in op de gebruikte SOAP-headerprotocollen. Hiervoor wordt verwezen naar de implementatiehandleiding [IH Transport].
Meer gedetailleerde informatie over de protocollen en de samenstelling van HL7-berichten is opgenomen in de implementatiehandleidingen [IH Transport] en [HL7v3 IH Wrp].
Voor protocollen onder de applicatielaag wordt verwezen naar subparagraaf 14.1.2.
Bij het afhandelen van de berichten afkomstig van aangesloten GBx’en door de ZIM wordt een vast patroon gevolgd waarbij verschillende componenten binnen de ZIM betrokken zijn. Dit patroon is weergegeven in diagram AORTA.ZIM.d1050.2.
Het GBx dat de berichtuitwisseling initieert met een bericht naar de ZIM wordt in deze beschrijving aangemerkt als ‘initiërend systeem’.
Een (eventueel) systeem dat tijdens de berichtafhandeling door de ZIM wordt geraadpleegd, wordt in deze beschrijving aangemerkt als ‘reagerend systeem’.
De ZIM controleert (een gedeelte van) het bericht op geldigheid ten opzichte van XML schema’s[37]. Indien het ontvangen bericht syntactisch ongeldig is, retourneert de ZIM een foutmelding en breekt de afhandeling af. Berichten bestemd voor volledige afhandeling binnen de ZIM, worden geheel gevalideerd. Berichten die door de ZIM worden doorgestuurd naar een reagerend GBZ worden alleen gevalideerd voor zover nodig voor de verdere berichtverwerking; deze validatie strekt zich niet uit tot de HL7-payload (zie paragraaf 13.1) van het bericht.
De ZIM controleert dat het applicatie-id, genoemd als afzender van het bericht, in het applicatieregister is geregistreerd onder de organisatie die opgenomen is in servercertificaat[38]. Indien dit niet het geval is of indien de applicatie volgens het applicatieregister niet gekwalificeerd of geconfigureerd is voor het interactie-id, retourneert de ZIM een foutmelding en breekt de afhandeling af.
Indien de applicatie een status ‘onderhoud’ of ‘storing’ heeft in het applicatieregister, retourneert de ZIM een foutmelding, breekt de afhandeling af en neemt een gebeurtenis op in het systeemlog.[39]
Bij uitwisseling van gegevens met of via de ZIM moet de authenticiteit van de gebruiker van de applicatie die gegevens uitwisselt met voldoende waarborg worden vastgesteld. Hiertoe heeft de gebruiker een vertrouwensmiddel aan de hand waarvan de gebruiker kan worden geauthenticeerd (zie paragraaf 6.8). Een zorgverlener maakt hiertoe gebruik van een UZI-pas. Een klantenloketmedewerker maakt gebruik van een PKIoverheidpas. De patiënt kan zich authenticeren door middel van DigiD.
Diagram AORTA.ZIM.d1050.2 - standaard berichtafhandeling door de ZIM
Bij authenticatie bestaat de keuze tussen tokenauthenticatie of sessie-authenticatie.
Tokenauthenticatie is flexibeler dan sessie-authenticatie omdat de authenticatie van de gebruiker uit het in het bericht opgenomen token kan worden afgeleid en de authenticatie niet afhankelijk is van een TLS-verbinding die moet worden opgebouwd vanaf het werkstation van de gebruiker. Sessie-authenticatie zal in een volgende versie van AORTA om deze reden worden afgeschaft. Zie voor een verdere discussie van dit aspect het [Ontw Authenticatie].
Bij het uitwisselen van berichten met de ZIM zijn twee vertrouwensniveaus mogelijk, ‘laag’ en ‘midden’[42]. Het vereiste vertrouwensniveau wordt per berichttype vastgesteld.
Zie voor een verdere discussie van dit aspect het [Ontw Authenticatie].
Het autorisatieprotocol controleert of de zorgverlenerfunctie is geautoriseerd voor de combinatie van de gegevenssoort en de specifieke interactie tussen GBx en ZIM.
In het geval van patiënttoegang of toegang van een klantenloketmedewerker wordt de combinatie van berichtuitwisseling en rolcodes gecontroleerd.
Zie voor een verdere discussie van autorisatie op basis van het autorisatieprotocol het [Ontw APT].
Het autorisatieprofiel controleert of de patiënt een vorm van bezwaar heeft laten vastleggen en stelt vast of dit bezwaar van toepassing is op het onderhavige bericht. Zie voor een verdere discussie van dit aspect het [Ontw APF].
Het controleren op totaalbezwaar wordt uitgefaseerd vanwege de overgang naar een model van expliciete toestemming. Daarom is deze controle geen onderdeel meer van de standaard berichtafhandeling. Deze controle vindt wel nog plaats onder specifieke omstandigheden bij aanmelden van gegevens (zie hiervoor het ontwerp [Ontw VWI]).
De controle op gedifferentieerd bezwaar vindt nog wel standaard plaats omdat dit een wijze is waarop de patiënt nader kan specificeren welke zorgverleners (geen) informatie mogen uitwisselen.[44]
De acties die nodig zijn voor de inhoudelijke verwerking van het bericht door de ZIM zijn afhankelijk van het type bericht (zie de bespreking in hoofdstuk 7 voor de mogelijke berichten). Enkele aspecten hiervan zijn echter generiek; deze zijn weergegeven in diagram AORTA.ZIM.d1060.
Inhoudelijke afhandeling binnen de ZIM
Een deel van de berichttypen kan door de ZIM zelf inhoudelijk worden afgehandeld (bijvoorbeeld het aanmaken van een nieuwe verwijzing in de verwijsindex). De ZIM kan dan direct het antwoordbericht opstellen (waarin eventuele foutmeldingen kunnen worden opgenomen).
ZIM stuurt berichten naar ander systeem
Voor de overige berichten zijn interacties nodig met één of meer reagerende systemen (meestal GBZ’en). De manier waarop wordt bepaald welke reagerende systemen dit zijn is afhankelijk van het scenario (bijvoorbeeld gegevens opvragen versus gegevens sturen).
In verband met het minimaliseren van de tijd nodig voor beantwoording moeten meerdere reagerende systemen parallel kunnen worden benaderd. Voor elk reagerend systeem worden globaal dezelfde stappen doorlopen:
Bij het raadplegen van elk reagerend systeem kunnen zich problemen voordoen: indien de uitslag van de controle van het applicatieregister negatief is, geen sessie kan worden opgebouwd of zich een fout voordoet bij de berichtuitwisseling met het reagerend systeem, neemt de ZIM een regel op in het systeemlog en stelt een partieel antwoord samen waarin een foutmelding wordt opgenomen.
Diagram AORTA.ZIM.d1060 - generieke aspecten van inhoudelijke afhandeling bericht door ZIM
In het geval dat sprake is van ‘opvragen van patiëntgegevens’ moeten de antwoorden van de verschillende reagerende systemen worden gecombineerd tot één samengesteld (‘batch’-)antwoord aan het initiërende systeem (zie voor details [HL7v3 IH Wrp]; ook indien in werkelijkheid slechts één systeem is benaderd wordt de berichtstructuur van een samengesteld antwoord gebruikt). In het geval van ‘sturen van patiëntgegevens’, waarbij nooit meer dan één reagerend systeem betrokken is, hoeft geen samengesteld antwoord gemaakt te worden.
Na de inhoudelijke afhandeling (hetzij volledig door de ZIM of in samenwerking met reagerende systemen) wordt het uiteindelijke antwoord aan het initiërend systeem gestuurd (zie diagram AORTA.ZIM.d1050.2).
Indien een inhoudelijke berichtverwerking heeft plaatsgevonden wordt een regel opgenomen in de toegangslog zodat alle toegang tot inhoudelijke gegevens traceerbaar is.
Er wordt een regel weggeschreven in de toegangslog indien de afhandeling niet in een eerder stadium is afgebroken met opname van een regel in het systeemlog. Er wordt ook een regel weggeschreven in de toegangslog indien de afhandeling is afgebroken vanwege het bezwaar van de patiënt zoals vastgelegd in het autorisatieprofiel. Zodoende is ook zichtbaar in de toegangslog welke toegang op basis van patiëntwensen is geweigerd.
In de berichtafhandeling zoals beschreven in paragraaf 13.2 is aangegeven dat op meerdere momenten in de berichtafhandeling fouten kunnen optreden. Een fout is een gebeurtenis die afwijkt van de verwachte of gewenste wijze van afhandeling van het bericht. Dergelijke fouten worden zoveel mogelijk teruggemeld aan het initiërend systeem.
Indien een bericht de ZIM bereikt (zie diagram AORTA.ZIM.d1050.2), kan een fout plaatsvinden tijdens de berichtvalidatie, de controle van het applicatieregister, de authenticatie of de autorisatie. Deze fouten gaan vooraf aan de inhoudelijke afhandeling van het bericht en leiden tot het staken van de verdere berichtafhandeling. De fout wordt opgenomen in een systeemlog en het initiërend systeem ontvangt een foutmelding, zo mogelijk op HL7v3 niveau.
Indien de ZIM overgaat tot inhoudelijke afhandeling van het bericht, zijn voor de meeste berichten interacties nodig met reagerende systemen (zie diagram AORTA.ZIM.d1060).
Interacties met meerdere reagerende systemen vinden parallel plaats. In deze gevallen ontvangt de ZIM per reagerend systeem een resultaat of een foutmelding. Bij fouten in reagerende systemen zet de ZIM de uitwisseling met de andere systemen voort totdat ook de communicatie met deze systemen is afgehandeld. De ZIM combineert de deelresultaten tot een samengesteld antwoord, dat dus voor een deel uit foutmeldingen kan bestaan. Het samengestelde antwoord wordt teruggemeld aan het initiërend systeem. Omdat de uitwisseling met andere systemen parallel verloopt, is in het geval van meerdere foutmeldingen in de reagerende systemen de volgorde van foutmeldingen in het samengestelde antwoord aan het initiërend systeem willekeurig.
Voor de foutafhandeling in situaties waarbij de ZIM optreedt als intermediair tussen initiërend en reagerend systeem gelden de volgende regels:
De [Foutentabel] geeft een lijst van mogelijke foutcondities per berichttype. De [Foutentabel] geeft per foutconditie:
De specificaties van de AORTA-infrastructuur en bijbehorende zorgtoepassingen vallen onder versiebeheerprocedures[47]; met regelmaat worden nieuwe versies gepubliceerd. Door het toevoegen van nieuwe functionaliteit aan AORTA kunnen meerdere versies van een interactietype ontstaan, waarbij verschillen kunnen optreden in de interface-definitie. Omdat aangesloten informatiesystemen een kwalificatietraject moeten doorlopen voor nieuwe AORTA-functies (zie paragraaf 6.4), worden nieuwe berichtversies niet in gelijk tempo door alle aangesloten informatiesystemen geadopteerd.
De ZIM ondersteunt steeds de berichtversies die horen bij twee opeenvolgende versies van een zorgtoepassing. Bij het verwerken van berichten door de ZIM afkomstig van een initiërend systeem geldt het volgende.
Bij het opvragen van patiëntgegevens geeft de ZIM de opvraagberichten van het initiërend systeem door aan reagerende systemen in de versie van initiërend systeem of, indien het reagerende systeem de versie van het initiërend systeem volgens het applicatieregister nog niet ondersteunt, de eerst lagere versie. Dit kan dus één versie lager zijn dan die van het initiërend systeem. Zie diagram AORTA.OND.d1010.
De ZIM bundelt de antwoorden voor het initiërend systeem, dat daarom rekening moet houden met het voorkomen van maximaal twee verschillende berichtversies in het gebundelde antwoord. Een initiërend systeem kan er ook voor kiezen om vooraf te controleren wat de hoogst ondersteunde gemeenschappelijke berichtversie is (zie subparagraaf 11.1.6) en vervolgens bij het opvragen die berichtversie gebruiken.
Diagram AORTA.OND.d1010 – afhandeling van berichtversies bij opvragen
Bij het versturen van patiëntgegevens moet een GBZ rekening houden met de interactieversie die de ontvanger ondersteunt, die kan worden afgeleid uit het antwoord op een ‘opvragen zorgaanbiederapplicatie’ bericht (zie subparagraaf 11.1.4).
Details van het omgaan met berichtversies zijn beschreven in het [Ontw OPV], het [Ontw STU] en het [Ontw APR].
Diagram AORTA.INF.d1010.2 geeft een conceptueel overzicht van de infrastructuur van AORTA. Hierin wordt weergegeven op welke wijze de informatiesystemen die zijn beschreven in hoofdstuk 6 logisch worden gekoppeld om berichtenuitwisseling tussen deze systemen te faciliteren.
Voor de duidelijkheid is de figuur opgedeeld in lagen.
De bovenste laag toont de informatiesystemen die een interactie via AORTA kunnen initiëren. Zoals besproken in de systeeminteracties in hoofdstuk 7 zijn dit GBZ’en, GBP’en en het GBK, samen aangeduid als GBx.
Opvragende systemen en bronsystemen worden gekoppeld aan de centrale infrastructuur via een datacommunicatienetwerk (DCN). Onder een DCN wordt hier verstaan: een netwerk van datacommunicatieverbindingen, inclusief de daarvoor benodigde voorzieningen op de locatie van de aangesloten partijen, dat door één datacommunicatiedienstverlener wordt geëxploiteerd en beheerd. In technisch opzicht is een DCN een privaat of virtueel privaat TCP/IP-netwerk.
Indien dit voor het bereiken van het juiste beschikbaarheidsniveau noodzakelijk is, kan een GBx door middel van redundante verbindingen aan een DCN gekoppeld worden. DCN’s worden door middel van redundante verbindingen gekoppeld aan de centrale infrastructuur.
Binnen AORTA worden aan het DCN eisen gesteld voor onder meer functionaliteit, beschikbaarheid en beveiliging; daarnaast worden eisen gesteld aan de dienstverlening van de datacommunicatiedienstverlener die optreedt als leverancier van het DCN. Een datacommunicatiedienstverlener die voldoet aan dit programma van eisen en hiervoor een kwalificatie behaalt wordt binnen AORTA aangeduid als een Zorg Service Provider (ZSP). Een GBx kan uitsluitend gekoppeld worden aan de ZIM via het DCN van een ZSP.[48]
Elke ZSP beheert een eigen Domain Name Service (DNS) die de hostnaam van elk aangesloten GBx vertaalt naar het IP-adres waarop het GBx bereikbaar is. Uit het oogpunt van beschikbaarheid biedt het LSP een gemeenschappelijke secundaire DNS voor alle aangesloten ZSP’s. Systemen binnen AORTA dienen elkaar te benaderen via de
DNS en niet rechtstreeks op IP-adres.
Het ZSP kent aan een GBx een hostnaam toe, zodat de ZSP het IP-adres kan wijzigen zonder dat dit effect heeft op de bereikbaarheid van de GBx voor de buitenwereld (waaronder de ZIM). Deze hostnaam wordt ook vastgelegd in servercertificaten van het UZI-register als ‘Fully Qualified Domain Name’ (FQDN). Wijzigingen van het IP-adres zijn overigens beperkt tot de door het LSP toegekende reeks, zie hieronder bij ‘IP-adresreeksen’.
Diagram AORTA.INF.d1010.2: conceptueel overzicht van de AORTA infrastructuur
Het UZI-register eist dat de relatie tussen FQDN en zorgaanbieder kan worden getoetst bij de Stichting Internet Domeinregistratie Nederland (SIDN) of bij het LSP. Daarom krijgt elk op de ZIM aangesloten informatiesysteem een hostnaam onder het geregistreerde domein ‘aorta-zorg.nl’. De FQDN wordt tevens vastgelegd als URI van het GBx in het applicatieregister van de ZIM.
Een GBx dat via het DCN van een ZSP wordt aangesloten op de centrale infrastructuur krijgt een IP-adres toegekend door de ZSP. Aan een ZSP wordt hiertoe een reeks van IP-adressen toegekend door het Landelijk Schakelpunt (LSP), die vervolgens aan specifieke GBx’en kunnen worden toegekend. Elk GBx moet binnen het DCN bereikbaar zijn op het toegekende IP-adres (maar moet via de DNS benaderd worden).
Het kan voorkomen dat het door het ZSP toegekende IP-adres botst met adressen binnen het locale netwerk van het GBx of dat de door het LSP toegekende reeks van IP-adressen botst met adressen binnen het DCN van de ZSP. In deze gevallen moet op het koppelvlak van het LAN waartoe het GBZ behoort en het DCN en/of op de grens van DCN en het externe netwerk van het LSP een vorm van adresconversie worden toegepast, zoals NAT (Network Address Translation).
GBx’en hebben toegang nodig tot het internet om een aantal redenen:
· de services van de SBV-Z voor verificatie van het burgerservicenummer en wettelijk identificatiedocument (zie subparagraaf 6.8.4) worden via het internet geleverd. Overigens kunnen deze services ook benaderd worden via de ZIM; de ZIM heeft een private verbinding naar de SBV-Z.
· GBZ’en moeten in staat zijn om de digitale certificaten op de UZI-passen van hun gebruikers op geldigheid te controleren; daartoe moeten zij controleren of deze certificaten zijn ingetrokken. Om dit te kunnen controleren moeten zij toegang hebben tot de ‘certificate revocation lists’ (CRL) die op het internet worden gepubliceerd door de ‘certificate authority’ (CA), in dit geval het UZI-register.
· Volgens de regels van PKIO moet ook de geldigheid van het certificaat van de CA zelf worden gecontroleerd en deze keten van CA’s moet worden gevolgd tot aan de ‘Root CA van de Staat der Nederlanden’. Hiertoe moeten ook de CRL’s van deze CA’s worden gecontroleerd, die op het internet worden gepubliceerd.
· GBZ, GBP en GBK moeten in staat zijn om het PKIO-certificaat van de ZIM op geldigheid te controleren en moeten daartoe controleren of dit certificaat is ingetrokken. Om dit te kunnen controleren moeten zij toegang hebben tot de CRL van de CA die het ZIM-certificaat uitgeeft.
De ZSP kan een ontsluiting bieden naar het internet via een beveiligde netwerkpoort in het DCN. Overigens kan deze ontsluiting naar het internet ook via een andere service provider worden geleverd.[49]
Voor de datacommunicatie tussen GBx en ZIM wordt, ter bevordering van interoperabiliteit, gebruik gemaakt van gangbare internetprotocollen, namelijk HTTP met TLS (HTTPS) over TCP/IP (de applicatie-protocollen boven de HTTP-laag zijn reeds besproken in paragraaf 13.1). Voor het opzetten van een beveiligde verbinding tussen GBZ en ZIM volgens het TLS protocol met wederzijdse authenticatie moet het GBZ over een UZI-servercerficaat of een PKIO-servercertificaat beschikken en de ZIM over een PKIO-servercertificaat. Een GBP moet beschikken over een PKIO-servercertificaat. Het GBK heeft evenals de ZIM een PKIO-servercertificaat.
De ZIM is de belangrijkste component in de centrale infrastructuur. Vanuit het oogpunt van continuïteit en beschikbaarheid voorziet de architectuur in twee instanties van de ZIM, verspreid over rekencentra op afzonderlijke locaties, gekoppeld door een netwerk. Het bestaan van meerdere instanties van de ZIM dient functioneel transparant te zijn voor informatiesystemen die communiceren met de ZIM, dat wil zeggen dat de instanties van de ZIM zich dienen te gedragen als ware er één ZIM.
In de rekencentra van het LSP zijn tevens netwerkdiensten aanwezig die zorgdragen voor het functioneren van de AORTA-infrastructuur als geheel:
Diverse XIS-systemen (huisartsinformatiesystemen, apotheekinformatiesystemen, ziekenhuisapotheekinformatiesystemen, etc.) waarvoor een XIS-typekwalificatie is verkregen en waarvan de implementatie voldoet aan de eisen voor een GBZ, kunnen fungeren als reagerende systemen in interacties die via AORTA verlopen.
Een GBZ kan meerdere XIS-applicaties omvatten, zoals aangegeven in het diagram met het voorbeeld van een GBZ dat bestaat uit een ziekenhuisapotheekinformatiesysteem en patiëntadministratiesysteem.
Een GBZ kan overigens in de ene interactie het initiërend systeem zijn en in een andere interactie het reagerend systeem.
Onder basisregistraties en certificatiediensten vallen de infrastructuren van UZI-register (zie 6.8.1), PKIoverheid (zie 6.8.2), DigiD (zie 6.8.3) en SBV-Z (zie 6.8.4). Deze zijn beschikbaar via het internet voor zowel de ZIM (met uitzondering van het SBV-Z) als voor GBx’en. UZI-register en PKIoverheid zijn voor GBx’en adresseerbaar via het internet óf via de netwerkinfrastructuur van de ZIM.
Zorgverleners kunnen idealiter 7 dagen per week en 24 uur per dag patiëntgegevens opvragen en versturen. Dit geldt ook voor patiënttoegang via een GBP. Dit stelt hoge eisen aan verschillende platformen in de basisinfrastructuur, waaronder de aangesloten GBZ’en en DCN’en. Immers, als één GBZ patiëntgegevens opvraagt die verspreid liggen bij andere GBZ’en, moeten deze ook beschikbaar en bereikbaar zijn.
Beschikbaarheid wordt in het algemeen uitgedrukt in percentages van de totale mogelijke beschikbaarheid, waarbij geplande niet-beschikbaarheid wegens onderhoud niet wordt meegerekend. Voor onderhoud worden in het algemeen vaste tijdsintervallen ingesteld. In een keten van systemen is de totale beschikbaarheid het product van de beschikbaarheidspercentages van de individuele componenten.
In het geval van AORTA hangt de samenstelling van de keten af van het gebruiksscenario, maar bestaat meestal uit:
Ten aanzien van de individuele componenten in de keten worden eisen gesteld in programma’s van eisen.
Enkele belangrijke maatregelen binnen AORTA ten aanzien van beschikbaarheid zijn:
Voor GBx’en zijn twee statussen gedefinieerd die gerelateerd zijn aan de beschikbaarheid:
Voor de individuele applicaties die zijn geregistreerd onder een GBx zijn vier statussen gedefinieerd die gerelateerd zijn aan de beschikbaarheid. Deze zijn:
De actuele beschikbaarheidstoestand van elk GBx en applicatie onder een GBx wordt centraal in het applicatieregister van de ZIM geregistreerd.
De beheerder van het GBx dient de beheerder van de ZIM te informeren over de actuele status. De ZIM kent dezelfde vier statussen als een applicatie: gereed, actief, storing en onderhoud. De beheerder van de ZIM informeert de beheerders van informatiesystemen over de actuele status.
Om te komen tot een schatting van de vereiste capaciteit voor de AORTA infrastructuur is een schatting gemaakt van de aantallen te verwachten gebruikersinteracties voor de zorgtoepassingen ‘medicatieproces’ en ‘huisartswaarneemgegevens’. Dergelijke schattingen zijn vertaald naar ‘service level agreements’ met de leverancier van de ZIM.
Aan de leverancier van de ZIM en beheerders van aangesloten DCN’en en GBx’en
worden eisen gesteld ten aanzien van de schaalbaarheid van de systemen. De
schaalbaarheid van een systeem is de mate waarin het systeem is voorbereid op
toename van het gebruik zonder merkbare verslechtering van het functioneren van
het systeem.
Net als bij het onderwerp beschikbaarheid geldt dat de snelheid van AORTA als geheel afhangt van de snelheid van de componenten in de keten. Ten aanzien van de gemiddelde responstijden van AORTA zijn gebruikerswensen geïnventariseerd en zijn streefgetallen vastgesteld. Gewenste responstijden worden vastgelegd in programma’s van eisen.
Vanwege het vertrouwelijke karakter van patiëntgegevens is beveiliging een centraal aspect van de AORTA-architectuur dat verweven is met andere aspecten van de architectuur. Diverse aspecten van beveiliging zijn dan ook al in voorgaande hoofdstukken aangestipt. Dit hoofdstuk heeft dan ook het karakter van een overzicht.
De [WBP] vereist bij de verwerking van persoonsgegevens een passend beveiligingsniveau gelet op de risico’s die de verwerking en de aard van de te
beschermen gegevens met zich meebrengen. In [AV23] worden vier risicoklassen voor persoonsgegevens opgevoerd (publiek niveau, basisniveau, verhoogd risico en hoog risico). Volgens de in [AV23] gestelde criteria valt de verwerking van persoonsgegevens in AORTA onder risicoklasse III (hoog risico) omdat sprake is van:
De beveiligingsmaatregelen van AORTA moeten daarom zijn afgestemd op een hoog risico.
De beveiliging van AORTA is gebaseerd op een [Vertrouwensmodel]. Dit model is het geheel van technische, organisatorische en juridische waarborgen voor het vertrouwen in de landelijke elektronische uitwisseling van medische gegevens.
In dit hoofdstuk wordt vooral ingegaan op de technische waarborgen. Details van diverse beveiligingsaspecten worden daarnaast verder uitgewerkt in de ontwerpdocumenten van deelcomponenten van de ZIM [Ontw Authenticatie], [Ontw APF], [Ontw APT] en [Ontw APR].
Er is sprake van technische beveiligingswaarborgen in drie fases van het gebruik van de AORTA infrastructuur:
Voorafgaand aan het aansluiten op de infrastructuur moet voor een XIS een XIS-typekwalificatie worden behaald (zie paragraaf 6.4). Hiervoor moet worden voldaan aan een programma van eisen, waarvan beveiligingseisen een onderdeel zijn. Voordat een specifieke implementatie van een XIS bij een zorgaanbieder daadwerkelijk kan worden aangesloten, moet voldaan worden aan de implementatie-eisen voor een GBZ (zie paragraaf 6.4. Ook voor GBP en GBK gelden dergelijke eisen.
Een GBx moet bij aansluiting worden geregistreerd in het applicatieregister van de ZIM (zie subparagraaf 6.2.5). Binnen dit register krijgt het systeem een status toegekend en wordt per interactietype vastgelegd of het systeem dit type interactie mag uitvoeren. Een GBx dat niet de status actief heeft en dat niet geregistreerd is voor het deelnemen aan de juiste interactietypen zal geen gegevens kunnen uitwisselen.
Het GBx zelf moet van de juiste servercertificaten worden voorzien, afkomstig van UZI-register of, in het geval van GBP, GBK en niet UZI-abonnee, PKIoverheid (zie paragraaf 6.8). De gebruikers van een GBZ moeten beschikken over UZI-passen (voor inhoudelijke interacties UZI-passen op naam), voor het GBK moeten gebruikers beschikken over PKIO-passen. Voorafgaand aan de verstrekking van dergelijke passen worden controles uitgevoerd om vast te stellen of de gebruiker voor de pas in aanmerking komt. Passen kunnen centraal worden gedeactiveerd in geval van vermissing. Het gebruik van de pas vereist de kennis van een beveiligingscode.
Bij het uitwisselen van gegevens met de ZIM wordt de vertrouwelijkheid gegarandeerd doordat het GBx een beveiligde verbinding opbouwt op basis van TLS, waarbij het GBx en de ZIM wederzijdse authenticatie uitvoeren op basis van certificaten (zie subparagraaf 13.2.3).
Bij het uitwisselen van patiëntgegevens worden aan het GBZ onder meer eisen gesteld ten aanzien van (zie paragraaf 6.4):
Bij elke berichtuitwisseling tussen GBx en de ZIM geldt een vaste reeks van controles (zie ook 13.2):
· de geldigheid van de berichtsyntax wordt gecontroleerd;
Niet alleen voor de implementatie en exploitatie van GBx’en, maar ook op de implementatie en exploitatie van de ZIM is een programma van eisen van toepassing, waarvan beveiligingseisen een onderdeel zijn. Onder meer wordt van de beheerorganisatie van de ZIM verlangd dat deze voldoet aan de [NEN 7510].
Als wordt geconstateerd dat een GBx afwijkt van het programma van eisen, kan in het uiterste geval door de ZIM-beheerder worden overgegaan tot het tijdelijk uitsluiten van gegevensuitwisseling via de ZIM – en uiteindelijk zelfs tot definitieve afsluiting. Daarbij wordt het belang van continuïteit van de zorgcommunicatie nadrukkelijk meegewogen.
In de ZIM bevinden zich geen inhoudelijke patiëntgegevens. De ZIM houdt uitsluitend bij welke aangesloten informatiesystemen gegevens bevatten over patiënten. De GBZ-gebruiker kan op elk gewenst moment de beschikbaarheid van gegevens aanmelden of afmelden. Bij eerste aanmelding van gegevens worden patiënten hiervan schriftelijk in kennis gesteld.
Na afloop van elke interactie die verloopt via de ZIM wordt de interactie geregistreerd in een toegangslog, zodat achteraf exact kan worden nagegaan welke toegangsgebeurtenissen hebben plaatsgevonden. Er zijn maatregelen getroffen om ongebruikelijke interactiepatronen te signaleren.
|
Referentie |
Document |
Versie |
|
AORTA dossier afspraken en procedures (“DAP Nictiz”) |
Augustus 2011 |
|
|
http://www.opengroup.org/archimate/doc/ts_archimate/ |
- |
|
|
G.W. van Blarkom en drs. J.J. Borking; Beveiliging van persoonsgegevens - Achtergrondstudie en verkenning nr. 23; Registratiekamer, April 2001 |
April 2001 |
|
|
http://www.logius.nl/producten/toegang/digid |
- |
|
|
Foutentabel |
6.11.0.0 |
|
|
HL7v3 implementatiehandleiding berichtwrappers |
6.11.0.0 |
|
|
Implementatiehandleiding berichtauthenticatie met DigiD |
6.11.0.0 |
|
|
6.11.0.0 |
||
|
Ministerie van VWS, directie voorlichting en communicatie - Kwaliteitswet zorginstellingen |
- |
|
|
NEN 7510 – Medische informatica – Informatiebeveiliging in de zorg – Algemeen, NNI, april 2004 |
April 2004 |
|
|
6.11.0.0 |
||
|
6.11.0.0 |
||
|
6.11.0.0 |
||
|
Ontwerp authenticatie |
6.11.0.0 |
|
|
6.11.0.0 |
||
|
6.11.0.0 |
||
|
Ontwerp abonnementenregister |
6.11.0.0 |
|
|
6.11.0.0 |
||
|
6.11.0.0 |
||
|
6.11.0.0 |
||
|
6.11.0.0 |
||
|
6.11.0.0 |
||
|
Programma van eisen zorginformatiemakelaar |
6.11.0.0 |
|
|
6.11.0.0 |
||
|
http://www.logius.nl/producten/toegang/pkioverheid |
- |
|
|
http://www.sbv-z.nl/diensten |
- |
|
|
http://www.uml.org/ |
- |
|
|
http://www.uziregister.nl |
- |
|
|
A.Ekker; Vertrouwensmodel landelijke infrastructuur voor gegevensuitwisseling; Nictiz publicatie 10041, november 2010 |
Nov. 2010 |
|
|
Wet op de beroepen in de gezondheidszorg |
- |
|
|
Wet bescherming persoonsgegevens |
- |
|
|
[Wbsn-z] |
Wet gebruik burgerservicenummer in de zorg |
- |
|
Wet op de geneeskundige behandelingsovereenkomst |
- |
|
|
Web Services Interoperability basic profile |
1.0 |
|
|
Web Services Interoperability basic security profile |
1.0 |
|
|
College Bescherming Persoonsgegevens; Zienswijze CBP over doorstartmodel voor landelijke uitwisseling medische gegevens; 9 augustus 2011 |
9-aug-2011 |
[1] Een interactie is een wisselwerking tussen organisaties, personen en/of systemen, waarbij gegevens kunnen worden uitgewisseld.
[2] Hoewel de ZIM is voorbereid op berichten vanuit een GBP, is op het moment van publicatie nog geen concreet GBP gerealiseerd, waardoor daadwerkelijke patiënttoegang tot AORTA via een GBP nog niet mogelijk is.
[3] Identificatie is het vaststellen van de identiteit van een gebruiker. Authenticatie is het geven van een bevestiging dat de persoon in kwestie inderdaad degene is voor wie hij zich uitgeeft, op grond van een bewijs van identiteit.
[4] Een ‘interactie’ is een wisselwerking tussen organisaties, personen en/of systemen, waarbij gegevens kunnen worden uitgewisseld.
[5] Zie voor een uitgebreide interpretatie van de wettelijke condities de [Zienswijze CBP].
[6] De WGBO spreekt eigenlijk over ‘hulpverlener’; de hulpverlener is een natuurlijke of rechtspersoon die een geneeskundig beroep of bedrijf uitoefent. Omdat sprake kan zijn van een natuurlijke of rechtspersoon spelen in AORTA-terminologie zowel de zorgverlener als de zorgaanbieder een rol in de behandelingsovereenkomst. De behandelingsovereenkomst komt van rechtswege tot stand zodra medische handelingen worden verricht of hierover afspraken worden gemaakt, ook als de partijen zich hiervan niet bewust zijn.
[7] Zie [WGBO] (artikel 7:446 BW)
[8] Hiermee wordt een beroep en specialisme bedoeld uit de officiële lijst van beroepen zoals bedoeld in artikel 3 en 34 van de wet BIG. Een voorbeeld van een beroep is arts, een voorbeeld van een specialisme is huisarts.
[9] Gedifferentieerd bezwaar is op het moment van publicatie weliswaar technisch gerealiseerd, maar wordt nog niet aan patiënten aangeboden.
[10] Aangezien deze verplichting geldt met ingang van deze versie van AORTA, geldt hiervoor een nader vast te stellen overgangsperiode gedurende welke de betrokken zorgaanbieders deze toestemming kunnen vragen aan onder het oude ‘opt-out’ regime aangemelde patiënten.
[11] Wanneer de zorgverlener het BSN van een patiënt die in zijn eigen administratie voorkomt, heeft gecontroleerd via de SBV-Z, dan wordt binnen AORTA gesproken van ‘gekoppelde’ patiëntgegevens (het lokale administratienummer van de patiënt is als het ware ‘gekoppeld’ aan het BSN). Als de patiënt zich nog niet heeft gelegitimeerd met een geldig wettelijk identificatiedocument, is sprake van ‘voorlopig gekoppelde’ patiëntgegevens; na legitimatie is sprake van ‘definitief gekoppelde’ patiëntgegevens.
[12] De termen ‘informatiesysteem’ en ‘applicatie’ worden in dit document beide gebruikt voor het aanduiden van een systeem voor gegevensverwerking.
[13] vanwege de overgang naar een opt-in systematiek krijgt expliciete toestemming voorrang.
[14] Zie voor een meer uitgebreide bespreking van de infrastructuur hoofdstuk 14
[15] Parallel aan de Engelse term ‘message broker’
[16] Zowel de componenten en orchestratieservice worden op logisch niveau beschreven. Over de fysieke implementatievorm van componenten en orchestratieservice worden geen uitspraken gedaan.
[17] Het voldoen aan de implementatie- en exploitatie-eisen wordt getoetst door een eigen verklaring van de beheerorganisatie en uitvoering van steekproefsgewijze schouwingen.
[18] Deze lijst van verantwoordelijkheden is niet limitatief. Hier worden enkele kernverantwoordelijkheden genoemd die bij het GBZ worden belegd in tegenstelling tot de ZIM.
[19] Op het moment van publicatie bestaan nog geen concrete GBP-implementaties.
[20] In operationele zin wordt de beheerderrol per betrokken organisatie verder uitgewerkt in [AORTA DAP].
[21] Hier wordt bedoeld dat in principe zowel een GBZ als een GBP kan optreden als patiëntgegevens-raadplegend systeem. Op het moment van publicatie zijn nog geen GBP’s gerealiseerd die deze functionaliteit bieden.
[22] Omdat de ZIM hierbij de vraag afkomstig van één applicatie uitzet naar meerdere applicaties wordt gesproken van ‘divergeren’ van een verzoek.
[23] Omdat hierbij de antwoorden afkomstig van meerdere applicaties weer worden gebundeld, wordt gesproken van ‘convergeren’ van antwoorden.
[24] Tijdens de overgangsperiode kan theoretisch alsnog totaalbezwaar worden gemaakt nadat bij een individuele zorgverlener toestemming is gegeven. In dit geval moet de gegeven toestemming alsnog door de patiënt weer bij dezelfde zorgverlener worden ingetrokken. Aangezien het mechanisme van totaalbezwaar wordt uitgefaseerd, heeft opt-in bij de zorgverlener voorrang en moet desgewenst worden gevolgd door opt-out bij dezelfde zorgverlener.
[25] De granulariteit van die gegevensset hangt overigens sterk af van de zorgtoepassing. Bij medicatiegegevens is elke medicatieverstrekking een apart patiëntstuk, maar bij huisartswaarnemingsgegevens is het hele dossier één enkel patiëntstuk.
[26] Dergelijke verwijzingen kunnen overigens alleen zijn aangemaakt voorafgaand aan de invoering van het opt-in mechanisme en blijven slechts tijdens een nader te bepalen overgangsperiode in de verwijsindex.
[27] Ook indien een eenmalige ‘opt-in’ is verkregen, geeft de gegevenshouder de patiënt nog steeds bij elk contact de mogelijkheid om specifieke gegevens niet beschikbaar te maken (dus niet aan te melden).
[28] Op het moment van publicatie zijn nog geen GBP’s gerealiseerd die deze functionaliteit bieden.
[29] De term ‘kandidaten’ is mogelijk verwarrend. Er wordt gesproken van ‘kandidaten’ omdat bij deze interface op basis van de waarden van de zoekcriteria mogelijk meer zorgaanbieders kunnen worden gevonden dan door de opvrager beoogd; dit zijn dus ‘kandidaten’ die aan de zoekcriteria voldoen.
[30] Hier wordt bedoeld dat een GBP de systeemrol van toegangslog-raadplegend systeem kan implementeren. Op het moment van publicatie zijn nog geen GBP’s gerealiseerd die deze functionaliteit bieden.
[31] Hier wordt bedoeld dat een GBP de systeemrol van autorisatieprofiel-bewerkend systeem kan implementeren. Op het moment van publicatie zijn nog geen GBP’s gerealiseerd die deze functionaliteit bieden.
[32] Dit is alleen van toepassing op patiënten die al waren aangemeld bij AORTA onder het systeem van veronderstelde toestemming voorafgaand aan de instelling van het moratorium op nieuwe aanmeldingen van april 2011. Tijdens een (nog vast te stellen) overgangsperiode blijft voor deze groep patiënten (her)aanmelden mogelijk vanuit systemen die nog geen opt-in registratie gerealiseerd hebben, mits geen totaalbezwaar is gemaakt. Na de overgangsperiode is alleen nog aanmelden mogelijk na expliciete toestemming, ook voor deze groep van patiënten.
[33] Uniform Resource Identifier, in dit geval het webadres waaronder de applicatie bereikbaar is
[34] Het gaat hier dus om het aanbrengen van een logische koppeling tussen een systeemrol en een applicatie, ‘applicatiesysteemrol’ is geen nieuw concept.
[35] Het UZI-registerabonneenummer (URA) wordt afgeleid uit het servercertificaat van het initiërend systeem tijdens het tot stand komen van de TLS-handshake en wordt vervolgens op het niveau van de applicatielaag gebruikt (zie verder 13.2.3).
[36] Auteur en eindverantwoordelijke kunnen dezelfde personen zijn.
[37] Deze schema’s zijn gebaseerd op normatieve beschrijvingen in implementatiehandleidingen.
[38] Voor een GBZ wordt deze organisatie afgeleid uit het UZI-abonneenummer op het servercertificaat van het GBZ waarmee de SSL-verbinding tot stand kwam, voor een GBP,GBK of een niet UZI-abonnee de organisatie genoemd op het PKIO-servercertificaat.
[39] Berichten voor beheer van het applicatieregister (zie hoofdstuk 11.1) zijn hierop een uitzondering, indien hiermee de applicatie weer actief wordt gemeld na een onderhoud of storing.
[40] Een voordeel hiervan is dat het hierdoor mogelijk wordt dat de organisatie vermeld op het servercertificaat van het GBx afwijkt van de naam van de organisatie op het certificaat van de persoonlijke gebruikerspas, hetgeen ‘gastgebruik’ van passen mogelijk maakt; een zorgverlener die werkzaam is bij meer dan één zorgaanbieder heeft dan maar één persoonlijke UZI-pas nodig.
[41] Vanuit infrastructureel oogpunt is dit complex omdat dit betekent dat de SSL-verbinding niet kan starten vanaf de server van het GBx, maar moet starten bij het werkstation van de gebruiker.
[42] Het [Ontw EH] (ontwerp elektronische handtekening) voegt hier nog een niveau ‘hoog’ aan toe, waarbij (een deel van) de inhoud wordt ondertekend. Het is echter niet gebruikelijk om andere aspecten dan authenticatie te betrekken in het definiëren van vertrouwensniveaus. Zie ook volgende voetnoot.
[43] De hier gehanteerde definities van ‘laag’ en ‘midden’ zijn niet geheel in lijn met de niveaus van vergelijkbare indelingen zoals die van STORK (http://www.eid-stork.eu) en zullen naar verwachting op termijn worden herzien. Gezien de waarborgen die gelden bij de uitgifte van de UZI-pas en het gebruik van twee-factor authenticatie geldt in feite dat bij authenticatie op basis van een UZI-pas de identiteit van de eindgebruiker met hoge betrouwbaarheid wordt vastgesteld.
[44] In de praktijk is op dit moment nog geen geval van gedifferentieerd bezwaar geregistreerd. In technische zin ondersteunt de ZIM de controle op gedifferentieerd bezwaar wel.
[45] Er is een lijst van HL7-v3 meldingscodes gedefinieerd die is opgenomen in de [HL7v3 IH Wrp].
[46] Het initiërend systeem is vrij om de ontvangen meldcode te verrijken met een zelfgekozen tekst voor presentatie aan de eindgebruiker.
[47] Een beschrijving van deze versiebeheerprocedures valt buiten de reikwijdte van dit architectuurdocument.
[48] Strikt genomen geldt deze eis niet voor het GBK, maar het datacommunicatienetwerk waarmee het GBK wordt gekoppeld aan de ZIM, evenals het beheer van dit netwerk worden wel gehouden aan dezelfde eisen als die gelden voor een ZSP, waardoor ook deze netwerkdienst als een ZSP kan worden beschouwd.
[49] In theorie kunnen de UZI- en PKIO-services ook benaderd worden via de centrale infrastructuur omdat ook daar een internetkoppeling aanwezig is om deze zelfde services te bereiken. Hiervoor zijn binnen het lokale netwerk van het GBZ in het algemeen configuratiehandelingen nodig om internetverkeer met UZI- en PKIO-register om te leiden ten opzichte van overig internetverkeer. In het algemeen loopt de toegang van het GBZ tot deze services niet via de centrale infrastructuur.
[50] Dit is een voorbereiding op eventuele rechtstreekse gegevensuitwisseling tussen aangesloten GBZ’en zonder tussenkomst van de ZIM, bijvoorbeeld van multimediale bestanden op basis van het DICOM-protocol.
