Technische architectuur AORTA

Technische architectuur AORTA

postadres: Postbus 19121, 2500 CC Den Haag bezoekadres: Oude Middenweg 55, 2491 AC Den Haag telefoon: (070) 317 34 50; fax: (070) 320 74 37; e-mail: ser vice de sk@ in foEP D.n l www.nictiz.nl

Versie Datum

: 6.0.0.0 : 31 oktober 2008

Inhoudsopgave 1

Inleiding ..................................................................................................... 6 1.1 Doel...................................................................................................... 6 1.2 Doelgroep.............................................................................................. 6 1.3 Versie, status en wijzigingshistorie ........................................................... 6 1.4 Achtergrond........................................................................................... 7 1.5 Reikwijdte ............................................................................................. 8 1.6 Structuur............................................................................................... 9 1.7 Samenhang met andere documenten .......................................................10

2

Uitgangspunten ..........................................................................................11 2.1 Normatieve referenties...........................................................................11 2.2 Informatieve referenties .........................................................................11 2.3 Afkortingen...........................................................................................12 2.4 Begrippen.............................................................................................12

3

ICT-voorzieningen (ICT) ..............................................................................13 3.1 Inleiding...............................................................................................13 3.2 Sectorale BerichtenVoorziening ...............................................................14 3.3 UZI-register..........................................................................................14 3.4 UZI-pas en UZI-servercertificaat .............................................................14 3.4.1 Normaal gebruik van UZI-passen .......................................................15 3.4.2 Gastgebruik van UZI-passen .............................................................15 3.5 Zorgadresboek ......................................................................................17 3.6 Zorg Informatie Makelaar .......................................................................17 3.7 RouteerFunctie......................................................................................18 3.8 DataCommunicatieNetwerken .................................................................18 3.9 Goed Beheerd Zorgsysteem ....................................................................19 3.10 LSP-portaal...........................................................................................22 3.11 {toekomst} XIS-leverancier/ASP-portaal ..................................................22 3.12 Samenhang tussen ICT-voorzieningen .....................................................22

4

Berichtuitwisseling (BUW) ............................................................................25 4.1 Overzicht van gebruikersinteracties .........................................................25 4.2 Indirect versturen..................................................................................34 4.3 Indirect opvragen ..................................................................................36 4.4 Beheeroverdracht ..................................................................................40

5

Berichttransport (BTP) .................................................................................44 5.1 Inleiding...............................................................................................44 5.2 Indirect versturen..................................................................................46 5.3 Indirect opvragen ..................................................................................48 5.4 Beheeroverdracht ..................................................................................50

6

Connectiviteit (CNV)....................................................................................52 6.1 IP-koppeling tussen GBZ en ZIM .............................................................52 6.2 Aansluiting van applicatie op schakelpunt .................................................54 6.3 IP-koppeling tussen GBZ’en ....................................................................55 6.4 IP-koppeling tussen GBZ en CA’s.............................................................56 6.5 IP-koppeling tussen GBZ en SBV-Z ..........................................................58 6.6 Koppeling tussen GBZ en webportaal .......................................................59

7

Beveiliging (BVL) ........................................................................................61 7.1 Inleiding...............................................................................................61


7.1.1 Vertrouwensniveau laag....................................................................62 7.1.2 Vertrouwensniveau midden ...............................................................62 7.1.3 Combinatie van vertrouwensmiddelen in de beveiligingsketen ...............65 7.2 Beveiliging tussen GBZ-gebruikers en GBZ-applicaties ...............................66 7.2.1 Authenticatie met wachtwoord...........................................................66 7.2.2 Authenticatie met UZI-pas niet op naam .............................................66 7.2.3 Authenticatie met UZI-pas op naam ...................................................66 7.2.4 Authenticatie van gast-GBZ-gebruikers...............................................67 7.3 Beveiliging tussen GBZ-applicaties en ZIM ................................................67 7.3.1 Authenticatie met het UZI-servercertificaat .........................................67 7.3.2 Authenticatie met de UZI-pas niet op naam ........................................69 7.3.3 Authenticatie met de UZI-pas op naam...............................................69 7.3.4 Vertrouwelijkheid tussen GBZ-applicaties en ZIM .................................71 7.3.5 Architectuurbeslissingen ...................................................................72 7.4 Beveiliging tussen GBZ-gebruikers en ZIM ................................................73 7.4.1 Geen authenticatie van de GBZ-gebruiker ...........................................73 7.4.2 Tokenauthenticatie van de GBZ-gebruiker...........................................74 7.4.3 Sessieauthenticatie van de GBZ-gebruiker ..........................................76 7.5 Beveiliging tussen GBZ-dossiers/postbussen en ZIM ..................................81 7.6 Beveiliging tussen registers en ZIM..........................................................84 7.7 Interne beveiliging GBZ..........................................................................84 7.8 Interne beveiliging ZIM ..........................................................................85 8

Beschikbaarheid (BSK) ................................................................................86 8.1 Beschikbaarheid van een GBZ .................................................................86 8.2 Beschikbaarheid van de ZIM ...................................................................87 8.3 Beschikbaarheid van een DCN .................................................................89 8.4 Beschikbaarheidstoestanden ...................................................................90 8.5 Samenvatting .......................................................................................92

9

Capaciteit en schaalbaarheid (CAP) ...............................................................93 9.1 Inleiding...............................................................................................93 9.2 Capaciteitschatting ................................................................................95 9.3 Dempende maatregelen tbv ZIM .............................................................97 9.3.1 SSL/TLS-sessies ..............................................................................97 9.3.2 HL7v3-verzoekberichten ...................................................................97 9.4 Dempende maatregelen tbv GBZ .............................................................98 9.4.1 SSL/TLS-sessies ..............................................................................98 9.4.2 HL7v3-verzoekberichten ...................................................................99

10 Responstijden (RPT) ...............................................................................100 10.1 Inleiding.............................................................................................100 10.2 Indirect versturen................................................................................102 10.3 Indirect opvragen ................................................................................103 11 Betrouwbaarheid (BTW) ..........................................................................104 11.1 Inleiding.............................................................................................104 11.2 Uitzonderingen in de keten ...................................................................106 11.3 Detecteren van uitzonderingen..............................................................108 11.4 Bundelen van uitzonderingen ................................................................110 11.5 Melden van uitzonderingen ...................................................................112 11.6 Afhandelen van uitzonderingen .............................................................114 11.7 Indirect versturen................................................................................116 11.8 Indirect opvragen ................................................................................119 11.9 Beheeroverdracht ................................................................................122

4 van 150


11.10 {toekomst} Identificatie van berichten...................................................126 11.11 Identificatie van patiëntstukken ............................................................128 Bijlage A - Bundelen, groeperen, doseren, etc. ...................................................129 A.1 Inleiding.............................................................................................129 A.2 Achtergrond........................................................................................129 A.3 Vraagstelling.......................................................................................130 A.3.1 Groeperen ..........................................................................................130 A.3.2 Bundelen ............................................................................................131 A.3.3 Doseren .............................................................................................132 A.3.4 Sorteren.............................................................................................134 A.4 Scenario’s van bundelen en doseren ......................................................135 A.4.1 Niet bundelen, niet doseren ..................................................................136 A.4.2 Niet bundelen, wel doseren...................................................................137 A.4.3 Wel bundelen, niet doseren ..................................................................138 A.4.4 Wel bundelen, wel doseren ...................................................................139 Bijlage B.1 B.2 B.3 B.4 B.5 B.6 B.7

B - Adresseren.....................................................................................141 Inleiding.............................................................................................141 Inhoud: HL7v3 Payload en ControlAct Wrapper .......................................142 Envelop: HL7v3 Transmission Wrapper...................................................144 Transport: HTTP-header/SOAP-envelop ..................................................145 Verbinding: TCP-header / IP-header ......................................................146 Versturen van patiëntgegevens .............................................................148 Opvragen van patiëntgegevens .............................................................149


1 1.1

Inleiding Doel

Dit document is de technische architectuur van AORTA. AORTA gaat over de basisinfrastructuur in de zorg en de wijze waarop landelijke zorgtoepassingen daarvan gebruik kunnen maken. De basisinfrastructuur omvat gemeenschappelijke ICT-voorzieningen die algemeen toegankelijk zijn voor partijen in de zorg. Deze vormt de basis voor het doelmatige en beveiligd uitwisselen van gegevens tussen die partijen. De technische architectuur definieert en analyseert het werkgebied van AORTA in termen van: • de ICT-voorzieningen die de basisinfrastructuur gaan vormen: de SBV-Z, het UZIregister, de ZIM, de RF en de DCN’en, • de ICT-voorzieningen van de afzonderlijke zorgpartijen: de GBZ’en met de XISapplicaties, • de ICT-technologie die gebruikt wordt voor de communicatie tussen al die ICTvoorzieningen: HL7v3, Web Services, etc. Deze technische architectuur is nodig om de documenten [PvE LSP], [PvE ZSP] en [PvE GBZ] te kunnen schrijven.

1.2

Doelgroep

Dit document is bedoeld voor partijen die zich bezighouden met de ontwikkeling van ICT-toepassingen in de zorg, zoals ontwikkelaars, leveranciers, onderzoekers, etc. De lezer wordt verondersteld een ICT-achtergrond en enige kennis van UML en HL7v3 te hebben. Voor een goed begrip van dit document, is het raadzaam eerst het document “Bedrijfsarchitectuur AORTA” te lezen, aangezien dit document daarop gebaseerd is

1.3

Versie, status en wijzigingshistorie

Ten opzichte van de “Technische architectuur AORTA” versie 3 zijn hier de volgende inhoudelijke wijzigingen doorgevoerd: • 1088: verduidelijking verschil eenmalig en tijdelijk aan- en afsluiten van GBZapplicaties. • 1303: aansluiten en beheren GBZ-applicaties • 1532: aanpassingen ten behoeve van het gastgebruik van een UZI-pas. • 1939: aanpassingen ten behoeve van authenticatie door middel van tokens. • 1482: Nieuw CA-model, pasmodel, certificaat- en CRL-profielen. Aanpassing van normatieve referentie. • 1642: enkele puur tekstuele foutjes. • 1494, 1236, 1475: toevoegen van berichten QUMT_IN0220011NL en QUMT_IN020021NL aan gebruikersscenario tabel paragraaf 4.1. • 1011: Wijziging van de manier waarop foutmeldingen terug gemeld worden. • 1502: generieke foutafhandeling, zie paragraaf 11.1 tot en met 11.6. • 2066: bundelen i.p.v. groeperen van foutmeldingen, zie paragraaf 11.4.

6 van 150


• 1586: kleine tekstuele wijziging. • 1106, 1410, 1589 en 1598: Wijziging van de manier waarop de time-outs bij het indirect opvragen werken. • 1947 v0.9: diverse aanpassingen ten behoeve van het Zorgadresboek. • 2213: Wijzigingen in paragraaf 4.3 LSP mag in principe niet in payload van berichten kijken. • 1938: Wijzigingen in het kader van medicatiebewaking • 1390: beheeroverdracht, daarvoor zijn de nieuwe paragrafen 4.4, 5.4 en 11.9 toegevoegd.

1.4

Achtergrond

Nicitz werkt aan een landelijke basisinfrastructuur in de zorg, AORTA genaamd, die mogelijk moet maken dat zorgaanbieders en later ook patiënten en mogelijk andere partijen in de zorg, ten behoeve van verschillende zorgtoepassingen op landelijke schaal patiëntgegevens kunnen uitwisselen. Centraal in AORTA staat de zorginformatiemakelaar (ZIM), die wordt geëxploiteerd door het landelijke schakelpunt (LSP). Daarop kunnen zorgaanbieders hun bestaande zorginformatiesystemen (ook wel XIS´en genoemd) aansluiten, mits zij voldoen aan de eisen van een goed beheerd zorgsysteem (GBZ). Die aansluiting vindt plaats via datacommunicatienetwerken (DCN), die worden geëxploiteerd door zorgserviceproviders (ZSP). Voor het uniek identificeren van patiënten, zorgaanbieders, zorgverleners en zorgsystemen wordt gebruik gemaakt van landelijke registers: het UZI–register (Unieke Zorgverleners Identificatie) en de SBV-Z (Sectorale BerichtenVoorziening in de Zorg van het BSN-stelsel). De onderstaande figuur toont op vereenvoudigde wijze hoe zorgaanbieders met hun XIS via het DCN van een ZSP worden aangesloten op de ZIM van het LSP, opdat zorgverleners en hun medewerkers, met behulp van hun UZI-pas, vanuit hun eigen XIS op landelijke schaal patiëntgegevens kunnen uitwisselen met andere zorgaanbieders.


CIBG UZISBV-Z register

LSP VWI ZIM I&A AUT SCH LOG

ZSP

zorgaanbieder UZI

UZI

DCN

DCN

zorgaanbieder UZI

UZI

zorgaanbieder UZI

GBZ

GBZ

GBZ

XIS

XIS XIS

XIS

XIS

zorg verlener

mede werker

zorg verlener

mede werker

zorgaanbieder UZI

GBZ

zorg verlener

ZSP

UZI

UZI

GBZ mede werker

XIS

zorg verlener

mede werker

Voorbeelden van landelijke zorgtoepassingen die gebruik maken van AORTA zijn: • Medicatiegegevens, voorheen elektronisch medicatiedossier (EMD) genoemd, • Huisartswaarneemgegevens, voorheen waarneemdossier huisartsen (WDH) genoemd, • spoedeisende-hulpdossier, • elektronisch pathologiedossier.

1.5

Reikwijdte

Omdat het toepassingsgebied van ICT in de zorg zeer groot is, beperkt AORTA zich voorlopig tot het landelijke elektronische patiëntdossier (EPD), m.a.w. de uitwisseling van patiëntgegevens tussen zorgaanbieders en hun patiënten/cliënten. Later zal de uitwisseling van informatie met zorgverzekeraars en andere zorgpartijen worden uitgewerkt. Naar verwachting zijn de meeste architectuurprincipes in dit document ook toepasbaar voor de zorgverzekeraars. AORTA richt zich voornamelijk op de eisen voor de basisinfrastructuur, dus de gemeenschappelijke ICT-voorzieningen en het beheer daarvan en bemoeit zich niet onnodig met de gang van zaken binnen zorginstellingen of de functionaliteit van hun ICT-voorzieningen. Toch is het onvermijdelijk ook eisen te stellen aan de individuele ICT-voorzieningen binnen zorginstellingen en het beheer daarvan. Daarbij gaat het zowel om technische eisen, inzake de wijze waarop zorgsystemen dienen te communiceren met de basisinfrastructuur, als om organisatorische eisen, inzake het daadwerkelijke gebruik en beheer van die zorgsystemen. Als aan die eisen wordt

8 van 150


voldaan, krijgt de individuele ICT-voorziening binnen de zorginstelling het predikaat goed beheerd zorgsysteem (GBZ). Daarnaast concentreert dit document zich op de generieke functionaliteit die de basisinfrastructuur biedt aan de vele verschillende zorgtoepassingen: faciliteiten voor het uitwisselen van patiëntgegevens tussen zorginformatiesystemen. Binnen AORTA worden generieke berichten gedefinieerd, ter ondersteuning van de specifieke berichten voor de verschillende, bestaande en toekomstige zorgtoepassingen. De invulling van deze specifieke berichten is het werkterrein van het programma Zorgtoepassingen. Toch worden deze specifieke berichten in dit document in generieke zin meegenomen, om duidelijk te maken hoe de basisinfrastructuur deze afhandelt. De generieke functionaliteit omvat verder de verwijs-, de identificatie-, authenticatie-, autorisatie- en loggingfuncties, en wordt ondergebracht bij de Zorg Informatie Makelaar (ZIM). Tenslotte richt de AORTA-architectuur zich vooral op de gewenste, toekomstige situatie van ICT in de zorg. Voorlopig heeft de zorgsector te maken met zeer verschillende, gesloten zorginformatiesystemen, die op één of andere manier moeten kunnen worden aangesloten op de basisinfrastructuur. Derhalve dient de basisinfrastructuur flexibel genoeg te zijn om bestaande zorginformatiesystemen te accommoderen én mee te buigen met toekomstige ontwikkelingen.

1.6

Structuur

Hoofdstuk 3 geeft een overzicht van de gemeenschappelijke ICT-voorzieningen als onderdeel van de basisinfrastructuur resp. de afzonderlijke ICT-voorzieningen van de aangesloten zorgpartijen. Hoofdstuk 4 tot en met 6 definiëren hoe al die ICT-voorzieningen met elkaar communiceren in termen van interacties, berichtinhoud, berichttransport en connectiviteit. Hoofdstuk 7 en verder definiëren eisen met betrekking tot beveiliging, beschikbaarheid, capaciteit, schaalbaarheid, responstijden en betrouwbaarheid. Een rode draad door de architectuur van AORTA wordt gevormd door een stelsel van: • gebruiks-scenario’s, binnen het document [Informatiesysteemarchitectuur] gemarkeerd met cccSnn waarbij ccc een categorie aanduidt en nn een nummer is. Buiten dat document wordt hiernaar verwezen met [AORTAIAcccSnn]. • architectuur-eisen, binnen dit document gemarkeerd met cccEnn waarbij ccc een categorie aanduidt en nn een nummer is. Buiten dit document kan hiernaar worden verwezen met [AORTATAcccEnn]. • architectuur-beslissingen, binnen dit document gemarkeerd met ccc.Bnn waarbij ccc een categorie aanduidt en nn een volgnummer is. Buiten dit document kan hiernaar worden verwezen met [AORTATAcccBnn]. De verschillende categorieën ccc komen terug in de desbetreffende hoofdstuktitels en zijn derhalve gemakkelijk terug te vinden in de inhoudsopgave.


Scenario’s, eisen en beslissingen die niet op korte termijn kunnen worden gerealiseerd, hebben het predikaat {toekomst} gekregen.

1.7

Samenhang met andere documenten

Voor AORTA is een architectuur ontwikkeld en ondergebracht in de volgende documenten: volgens de Architecture Development Cycle van TOGAF, bestaande uit de volgende onderdelen: • Architectuurvisie AORTA • Bedrijfsarchitectuur AORTA • Informatiesysteemarchitectuur AORTA • Technische architectuur AORTA Deze indeling is gebaseerd op de Architecture Development Cycle van TOGAF, zie de onderstaande figuur.

Tenslotte is dit document onderdeel van de AORTA-baseline zoals gedefinieerd in het document [Documentatieoverzicht].

10 van 150


2

Uitgangspunten

2.1

Normatieve referenties

De onderstaande documenten zijn beschouwd als leidend voor dit document: Identificatie

Titel

Bron

[Architectuurvisie]

Architectuurvisie AORTA

Nictiz

[Bedrijfsarchitectuur]

Bedrijfsarchitectuur AORTA

Nictiz

[Informatiesysteemarchitec tuur]

Informatiesysteemarchitectuur AORTA

Nictiz

[Technische architectuur BijlageC]

Technische architectuur AORTA Bijlage C

Nictiz

[HL7v3]

HL7 Version 3 Standard

www.hl7.org

[BSN]

een verzameling documenten m.b.t. het BSN-stelsel

[SBV-Z]

een verzameling documenten m.b.t. de SBV-Z

[UZI]

een verzameling documenten m.b.t. het UZI-register

www.programma bsn.nl www.sbv-z.nl onder “Technische specificaties” www.uziregister. nl

[WBP]

“Wet Bescherming Persoonsgegevens”

CBP

“Wet op de geneeskundige behandelingsovereenkomst” “Nederlandse norm NEN7510 (nl), Medische Informatica – Informatiebeveiliging in de zorg Algemeen”

[WGBO] [NEN7510]

2.2

Versie Datum 6.0.0.0 31 oktober 2008 6.0.0.0 31 oktober 2008 6.0.0.0 31 oktober 2008 6.0.0.0 31 oktober 2008

VWS

NEN

Informatieve referenties

De onderstaande documenten hebben gediend als bron voor dit document: Identificatie

Titel

Bron

[Documentatieoverzicht]

Documentatieoverzicht AORTAbasisinfrastructuur

Nictiz

[Verklarende woordenlijst]

Verklarende woordenlijst AORTA

Nictiz


Versie Datum 6.0.0.0 31 oktober 2008 6.0.0.0 31 oktober 2008

Identificatie

Titel

Bron

[PvE GBZ]

Programma van eisen voor een goed beheerd zorgsysteem

Nictiz

[PvE LSP] **

Programma van eisen aan het landelijk schakelpunt

Nictiz

[IH generieke berichten]

Implementatiehandleiding generieke berichten

Nictiz

[AO Medicatiegegevens]

Architectuurontwerp Medicatiegegevens

Nictiz

[AO Huisartswaarneemgegevens ]

Architectuurontwerp Huisartswaarneemgegevens

Nictiz

[AO Medicatiebewaking]

Architectuurontwerp Medicatiebewaking

Nictiz

Versie Datum 6.0.0.0 31 oktober 2008 6.0.0.0 31 oktober 2008 6.0.0.0 31 oktober 2008 6.0.0.0 31 oktober 2008 6.0.0.0 31 oktober 2008 6.0.0.0 31 oktober 2008

** Dit document wordt niet gepubliceerd.

2.3

Afkortingen

Zie het document [Verklarende woordenlijst]

2.4

Begrippen

Zie het document [Verklarende woordenlijst] NB De in dit document gebruikte begrippen sluiten aan op binnen de ICT gebruikelijke terminologie. De lezer dient ze dan ook niet te verwarren met de begrippen zoals deze in weten regelgeving gehanteerd worden. Onder identificatie wordt in dit document bijvoorbeeld iets anders verstaan dan onder de definitie binnen het wettelijk kader.

12 van 150


3

ICT-voorzieningen (ICT)

3.1

Inleiding

In het document [Architectuurvisie] is reeds aangegeven dat de strategie van Nicitz zich richt op de totstandkoming van: • een basisinfrastructuur • goed beheerde zorgsystemen (GBZ) De basisinfrastructuur omvat de gemeenschappelijke ICT-voorzieningen, inclusief organisatorische voorzieningen, die nodig zijn om de individuele ICT-voorzieningen van verschillende zorgpartijen (zorgaanbieders, zorgverzekeraars, etc.) onderling te kunnen koppelen. Deze basisinfrastructuur zal bestaan uit: • een landelijke ZIM (Zorg Informatie Makelaar) met RF (RouteerFunctie) • een landelijke SBV-Z (Sectorale BerichtenVoorziening in de Zorg van het BSNstelsel) • een landelijk UZI-register (Unieke Zorgverlener Identificatie) • verscheidene regionale DCN’en (datacommunicatienetwerken) • een landelijk Zorgadresboek (ZAB) als onderdeel van het Landelijk SchakelPunt. De onderstaande figuur toont hoe deze ICT-voorzieningen onderling in principe worden verbonden in een variant op een UML deployment diagram:

CIBG UZI register

Nationaal

SBV-Z

LSP ZAB

Nationaal

ZIM RF

ZSP Regionaal

Lokaal

ZSP DCN

ZA GBZ

ZA GBZ

DCN

ZA GBZ

ZA GBZ

ZA GBZ

ZA GBZ

De bovengenoemde ICT-voorzieningen worden in de volgende paragrafen nader uitgewerkt. Een ICT-voorziening kan een netwerk van datacom-verbindingen zijn of een systeem bestaande uit één of meer hardware-platformen met softwarecomponenten.


3.2

Sectorale BerichtenVoorziening

De Sectorale BerichtenVoorziening – Zorg (SBV-Z) van het BSN-stelsel is een gemeenschappelijke ICT-voorziening ten behoeve van het gebruik van het BSN in de Nederlandse zorgsector. De SBV-Zlevert of verifieert op verzoek van zorgpartijen het BSN op basis van een set identificerende gegevens. Zorgpartijen kunnen rechtstreeks contact zoeken met de SBV-Z via een webservice en door middel van bestandsuitwisseling. De ZIM heeft een koppeling met de SBV-Z zodat zorgpartijen ook met hun GBZ via de ZIM de SBV-Zbevragen. Als zodanig kan de SBV-Z dienst doen als landelijk patiëntenregister. De exploitatie en het beheer van de SBV-Z valt onder verantwoordelijkheid van het CIBG. Zie verder [BSN].

3.3

UZI-register

Het (Unieke Zorgverlener Identificatie) UZI-register is een gemeenschappelijke ICTvoorziening waarin zorgaanbieders met hun zorgverleners en medewerkers en systemen worden geregistreerd die door het UZI-register zijn voorzien van een UZIpas of UZI-servercertificaat. Het UZI-register realiseert het zorgverlenerregister en het zorgaanbiederregister zoals benoemd in de [Informatiesysteemarchitectuur]. Het UZI-register levert of verifieert op verzoek van zorgpartijen het UZI-nummer van een zorgverlener op basis van een set identificerende gegevens. Daarvoor kunnen zorgpartijen rechtstreeks contact zoeken met het UZI-register via een webservice. Het UZI-register publiceert regelmatig lijsten van ingetrokken certificaten (CRL), biedt de mogelijkheid van on-line controle van certificaten (OCSP) en geeft uitsluitsel omtrent wie de houder van een UZI-pas is, welke zorgverlenerfunctie hij heeft en voor welke zorgaanbieder hij werkt. Het UZI-register levert op verzoek ook certificaten van publieke sleutels, indien de gebruiker daarin toestemt. De exploitatie van de CA- en RA-diensten en het beheer van het UZI-register valt onder verantwoordelijkheid van het CIBG. Zie verder [UZI]. Architectuurbeslissingen: ICT·b01

Een zorgverlener wordt geidentificeerd door het UZI-nummer. Het UZInummer is het zorgverlener-id.

ICT·b02

Een zorgaanbieder wordt geidentificeerd door het UZI-Register Abonneenummer (URA). De URA is het zorgaanbieder-id.

3.4

UZI-pas en UZI-servercertificaat

De UZI-pas is een vertrouwensmiddel op basis van PKIO en ETSI. Dat betekent onder meer dat de UZI-pas aparte sleutelparen bevat voor authenticatie, versleuteling en handtekening. Er zijn ook UZI-passen niet op naam, waarvoor de zorgaanbieder zelf moet bijhouden wie de houder is. Die UZI-passen niet op naam bevatten geen

14 van 150


sleutelpaar voor handtekening. Als zodanig kunnen beide UZI-passen dienst doen als persoonsvertrouwensmiddel (PVM). Het UZI-servercertificaat is een vertrouwensmiddel op basis van PKIO. Het bevat slechts een sleutelpaar voor authenticatie. Als zodanig kan het UZI-servercertificaat dienst doen als systeemvertrouwensmiddel (SVM). Opmerkingen: • Het UZI-servercertificaat wordt, indien een GBZ zich daarmee op eigen initiatief authenticeert aan een ander systeem, feitelijk gebruikt als “client”-certificaat. Hoewel de naam “UZI-servercertificaat” anders doet vermoeden, staat het UZIregister toe dat het certificaat hiervoor gebruikt wordt. Merk op dat dit gebruik van een UZI-servercertificaat als “client”-certificaat niet nieuw is; bij het doen van BSNopvragingen was dit al toegestaan.

3.4.1 Normaal gebruik van UZI-passen Gewoonlijk vraagt de zorgaanbieder als abonnee de UZI-passen aan voor zijn zorgverleners en medewerkers. Daardoor geeft een UZI-pas aan voor wie de zorgverlener/medewerker werkt. Een zorgverlener kan ook zelf een UZI-pas aanvragen. In dat geval is de zorgverlener zelf de abonnee van diens UZI-pas. Aldus heeft een UZI-pas twee verschillende abonnement-typen: Organisatie. De zorgaanbieder is abonnee. Zorgverlener. De zorgverlener is abonnee. Gewoonlijk heeft een zorgverlener/medewerker die voor meerdere zorgaanbieders werkt ook voor ieder van die zorgaanbieders een UZI-pas verstrekt gekregen.

3.4.2 Gastgebruik van UZI-passen Om het praktisch gebruik van UZI-passen te bevorderen is het gastgebruik van een UZI-pas mogelijk. Daarmee kan worden voorkomen dat een zorgverlener/medewerker die bij verschillende zorgaanbieders werkt meerdere UZI-passen bij zich moet dragen en de UZI-pas voor gebruik moet verwisselen. Zie ook de [Bedrijfsarchitectuur] paragraaf 11.2. Optioneel mag een zorgaanbieder zijn GBZ geschikt maken voor het toelaten van UZIpassen waarvan de zorgaanbieder niet zelf de abonnee is. Maar waarvan bijvoorbeeld de zorgverlener die bij hem werkt zelf de abonnee is of een andere zorgaanbieder de abonnee is. Iedere zorgaanbieder kan zorgverleners en/of medewerkers aanstellen, die namens/onder de verantwoordelijkheid van die zorgaanbieder mogen optreden binnen zijn GBZ. In geval van toegestaan gastgebruik kan dit ondanks dat zij met een UZIpas optreden met een URA van een andere abonnee. Een GBZ dat gastgebruik toelaat moet door middel van lokale toegangscontrole het gebruik van gast UZI-passen bewaken. Zie de [Informatiesysteemarchitectuur] paragraaf 4.17. Van die passen moet het GBZ tevens de geldigheid van de passen


bewaken. De zorgaanbieder dient zijn GBZ te voorzien van een toegangtabel. Tevens dient hij bij het LSP aan te geven dat het GBZ het gastgebruik van de UZI-passen toestaat. Aanvullend dient voor gastgebruik van een UZI-pas de betrokken GBZ-applicatie voor tokenauthenticatie (zie paragraaf 7.4.2) te zijn gekwalificeerd en ingesteld. Alleen bij tokenauthenticatie kan het vertrouwensmiddel waarmee de GBZ-applicatie wordt geauthenticeerd, verschillen van het vertrouwensmiddel waarmee de GBZ-gebruiker wordt geauthenticeerd. Bij gastgebruik zou onduidelijkheid kunnen ontstaan omdat de URA op UZI-pas (de abonnee) afwijkt van de URA van de afzendende zorgaanbieder in het bericht en/of de URA op het UZI-server-certificaat van de zorgaanbieder. Doordat de ZIM beiden in geval van tokenauthenticatie kan onderscheiden, wordt bij communicatie via de ZIM deze onduidelijkheid voorkomen. Behalve bij toepassing van een UZI-pas bij het zetten van een elektronische handtekening. In dat geval moeten beide URA’s ofwel aan elkaar gelijk zijn danwel moet de URA betrekking hebben op een zorgverlener die zijn UZI-pas zelf aangevraagd heeft. Om die reden moeten in de nabije toekomst zorgverleners voor gastgebruik zelf hun UZI-pas aanvragen. Tot die tijd is er een overgangsregeling in verband met reeds uitgegeven passen aan huisartsen. Medewerkers kunnen niet zelf een UZI-pas aanvragen, aangezien zij geen zorgverlener of zorgaanbieder zijn kunnen zij immers geen zelfstandig abonnee zijn van het UZI-register. Voor medewerkers dienen dergelijke passen altijd door een zorgaanbieder te zijn aangevraagd. Medewerkers kunnen en hoeven binnen AORTA geen elektronische handtekening te zetten. De zorgaanbieder dient bij het LSP aan te geven dat het gastgebruik in zijn instelling voor bepaalde GBZ-applicaties is toegestaan. Ook de abonnee van de UZI-passen moet bij het LSP aangeven dat het gebruik van zijn passen voor gastgebruik in andere zorginstellingen is toegestaan. Bij gastgebruik werkt de zorgverlener/medewerker bij de gastheerzorgaanbieder. Daarbij ontstaat de vraag welk URA geldt voor de verantwoordelijke of de auteur in het HL7v3-bericht aan de ZIM. Het URA op de UZI-pas van de gast zal immers afwijken van het URA van de gastheerzorgaanbieder. Architectuurbeslissing: ICT·b03

Het URA van de verantwoordelijke en die van de auteur in een HL7v3-bericht moet de gastheerzorgaanbieder representeren waar zij op dat moment hun werk doen. Het hoeft niet gelijk te zijn aan het URA die op de UZI-pas van de gastzorgverlener/medewerker staat.

16 van 150


3.5

Zorgadresboek

Het Zorgadresboek (ZAB) wordt een gemeenschappelijke ICT-voorziening waarin alle zorgaanbieders in Nederland kunnen worden gepubliceerd met de bereikbaarheidsgegevens van hun zorginformatiediensten. Het ZAB wordt als component opgenomen in het LSP. Het adresboek biedt zorgpartijen de mogelijkheid om te bladeren en bijvoorbeeld het HL7v3-adres van een zorgverlener op te zoeken. Het ZAB is aangesloten op de ZIM, op dat zorgpartijen ook met hun GBZ via de ZIM het adresboek kunnen bevragen. Merk op dat het UZI-register geen dienst kan doen als landelijk zorgaanbiederregister, omdat de WBP het bladeren daarin niet toelaat en omdat CIBG garant wil staan voor alle daarin opgenomen gegevens.

3.6

Zorg Informatie Makelaar

Een Zorg Informatie Makelaar (ZIM) is een gemeenschappelijke ICT-voorziening die nodig is voor alle zorgaanbieders en andere zorgpartijen in Nederland om via hun GBZ’en onderling patiëntgegevens te kunnen uitwisselen. Om te kunnen voldoen aan de hoge eisen die worden gesteld door de aangesloten GBZ’en, dient de ZIM te worden beheerd door een onafhankelijke partij die de belangen van alle aangesloten zorgpartijen zo goed mogelijk kan dienen. Deze onafhankelijke partij wordt het Landelijk Schakelpunt (LSP) genoemd. Een ZIM zal de volgende software-componenten bevatten: • SCH – Schakelpunt • APT – AutorisatieProTocol • APF – AutorisatieProFiel • LOG – ToegangsLOG • I&A – Identificatie & Authenticatie • SVM – SysteemVertrouwensMiddel waarmee de ZIM zich kan authenticeren aan GBZ’en • CFG - ConFiGuratietabel • VWI – VerWijsIndex • GGS – GeGevenSoortentabel • ZAB - Zorgadresboek en diverse beheerapplicaties. De onderstaande figuur toont dit in een UML deployment diagram:

ZAB I&A

APT APF LOG


SCH

CFG VWI

SVM

ZIM GGS

De figuur toont de meest eenvoudige configuratie van de ZIM. Later in dit hoofdstuk zal blijken dat de ZIM om reden van schaalbaarheid op verscheidene hardwareprocessoren of –platformen moet kunnen draaien en dus verscheidene instanties van het schakelpunt kan hebben. Of van de andere software-componenten ook verscheidene instanties nodig zijn, zal afhangen van de gebruikte technologie en is dus aan de ZIM-leverancier. Ook zal blijken dat er naast een operationele ZIM nog een ontwikkel-, testen demoZIM zal moeten komen. Deze zullen allemaal door het LSP worden beheerd. De eisen die worden gesteld aan de functies van een ZIM worden gespecificeerd in het document [PvE LSP]. De operationele ZIM hoeft niet meteen alle beveiligingsniveaus te ondersteunen, omdat er voorlopig geen GBZ’en zullen zijn met het hoogste beveiligingsniveau. Anderzijds zal de ZIM in de loop van de tijd steeds meer nieuwe functies en HL7v3berichtsoorten gaan ondersteunen. Daarom zullen verschillende ZIM-kwalificatieniveaus worden gedefinieerd. Elke nieuwe versie van de ZIM zal grondig getest en gekwalificeerd moeten worden alvorens operationeel te mogen gaan.

3.7

RouteerFunctie

Een RouteerFunctie (RF) is een gemeenschappelijke ICT-voorziening die nodig is om onderling IP-verkeer tussen GBZ’en aangesloten op verschillende DCN’en mogelijk te maken. Deze zogenaamde interconnectiviteit is niet nodig voor de uitwisseling van patiëntgegevens m.b.v. HL7v3-berichten via de ZIM, maar wordt wel noodzakelijk als GBZ’en rechtstreeks bestanden gaan uitwisselen, bijv. multimediale bestanden m.b.v. DICOM, zie paragraaf 6.3. In de praktijk zal deze voorziening van het LSP als IPingang voor de ZIM gaan dienen. Gemakshalve zal de RF vaak als onderdeel van de ZIM worden beschouwd. Echter, wanneer duidelijk onderscheid nodig is tussen HL7v3-verkeer via de ZIM en IP-verkeer via de RF, zullen zij als aparte componenten worden beschouwd. In veel figuren zal de RF niet zichtbaar zijn, omdat netwerkrouters gewoonlijk transparant zijn voor interacties tussen applicaties.

3.8

DataCommunicatieNetwerken

Een DataCommunicatieNetwerk (DCN) is een gemeenschappelijke ICT-voorziening die nodig is om de GBZ’en van verschillende zorgpartijen (zorgaanbieders, zorgverzekeraars, etc.) te kunnen aansluiten op de ZIM. Zo’n DCN kan een VPN, zolang deze voldoet aan de gestelde eisen m.b.t. beveiliging en dienstverlening. In Nederland zijn diverse netwerkdienstverleners actief die zo’n DCN kunnen aanbieden, zie ook [Bedrijfsarchitectuur] paragraaf 12.2. De opzet van de basisinfrastructuur biedt de ruimte aan verscheidene, concurrerende netwerkdienstverleners om een regionale of categorale groep van samenwerkende zorgaanbieders deze faciliteit aan te bieden. Om een DCN te mogen aansluiten op de ZIM zal de netwerkdienstverlener bovendien een aantal ondersteunende diensten moeten bieden aan zorgaanbieders die hun GBZ willen aansluiten. Deze diensten omvatten:

18 van 150


• de uitgifte van hostnamen en IP-adressen aan GBZ’en op basis van een IPadresblok toegekend door het LSP, • de aanlevering van routeringsgegevens aan het LSP voor uitgegeven IP-adressen, • hulp aan zorgaanbieders bij het aansluiten van hun GBZ’en, • de eerste-lijns hulp aan zorgaanbieders bij incidenten, • de bewaking van de prestaties van het DCN, • etc. Een DCN hoeft niet slechts het berichtenverkeer tussen de ZIM en de GBZ’en te verzorgen. In principe kan het DCN willekeurige datacom-behoeften van een zorgaanbieder ondersteunen. Omdat verschillende DCN’en op basis van verschillende VPN-technieken niet altijd gemakkelijk onderling gekoppeld kunnen worden, zal het LSP die zogenaamde interconnectiviteit bieden d.m.v. een Routeer Functie (RF). Zo’n DCN geeft de netwerkdienstverlener tenslotte de mogelijkheid om extra diensten te leveren aan zorgaanbieders, bijv. ondersteuning van een DNS, beheer van GBZ’en, gemeenschappelijke applicaties, toegang tot het openbare internet, maar ook installatie, advies, etc. Op deze wijze wordt een netwerkdienstverlener een zogenaamde ZorgServiceProvider (ZSP), die de aangesloten zorgaanbieders kan ondersteunen met een compleet pakket van samenhangende diensten.

3.9

Goed Beheerd Zorgsysteem

Een goed beheerd zorgsysteem (GBZ) is een zorgapplicatie of een verzameling zorgapplicaties, inclusief de bijbehorende patiëntdossiers en zorgaanbiederpostbussen, die ter beschikking staat van een zorgpartij (zorgaanbieder, zorgverzekeraar, etc.) en die voldoet aan een aantal eisen om te mogen worden aangesloten op de ZIM. Voorbeelden van een GBZ zijn een HIS, AIS, ZIS, LIS, etc. dat dan wel moet voldoen aan minimumeisen met betrekking tot connectiviteit, beveiliging, beschikbaarheid, betrouwbaarheid, actualiteit en goed beheer. Daarnaast dient een GBZ bepaalde patiëntgegevens te kunnen uitwisselen conform de HL7v3-berichtenstandaard. De meeste bestaande XIS’en voldoen nog niet aan die eisen en zullen moeten worden aangepast. Binnen een ziekenhuis kan ook het gehele stelsel van ZIS, ZAIS, LIS, RIS, PACS, etc. worden beschouwd als één GBZ, maar het is ook mogelijk delen daarvan als aparte GBZ aansluiten op de ZIM. Veelal zal een XIS bestaan uit een of meer zorgaanbiederapplicatie (ZA), postbussen (PB), patiëntdossiers (PD) en veelal een patiëntenindex (PI). Om tot GBZ te worden opgewaardeerd, zal een XIS veelal moeten worden voorzien van: • GP – een GegevensPoort die alle patiëntgegevens in het dossier kan vertalen naar HL7v3-formaat en als bericht kan versturen naar de ZIM en andersom. • APB – een interne autorisatietabel indien het GBZ ook interne uitwisseling van patiëntgegevens ondersteunt. • APF – interne autorisatieprofielen indien het GBZ ook interne uitwisseling van patiëntgegevens ondersteunt.


• TGT – een toegangtabel indien het GBZ het gebruik van UZI-passen toe wil laten waarvan de verantwoordelijke zorgaanbieder niet de abonnee is. • MDT – een mandateringstabel. • LOG – een lokale toegangslog. • SVM – een SysteemVertrouwensMiddel waarmee het GBZ zich kan authenticeren aan de ZIM. • BRW – een webbrowser. • Kaartlezers waarin de GBZ-gebruikers hun Persoonlijke vertrouwensmiddel (PVM) kunnen invoeren om zich te authenticeren aan het GBZ. • Randapparatuur als firewall, router, modem, etc. voor zover niet reeds aanwezig. De onderstaande figuur toont dit in een UML deployment diagram:

Kaartlezer Kaart

LOG

GP

APB

BRW

SVM MDT

APF

PD

PI

GBZ

PVM PB

ZA

TGT

De figuur toont de meest eenvoudige configuratie van een GBZ. Later zal blijken dat een GBZ kan bestaan uit één of meer applicaties en andere software-componenten, die draaien op één of meer hardware-platformen. Zowel het PVM als het SVM moeten volgens PKIO op een fysiek beveiligd hardwaremedium (ook wel hard token of hardwarecertificaat genoemd) staan. Echter, het UZIregister staat tijdelijk toe een SVM (ook servercertificaat genoemd) op een computerschijf te plaatsen (ook wel soft token of softwarecertificaat genoemd), mits deze goed is afgeschermd. De eisen die worden gesteld aan de functies van een GBZ worden gespecificeerd in het document [PvE GBZ]. Een GBZ kan op twee manieren worden gerealiseerd: • door de XIS bij een zorgaanbieder te vervangen door een nieuwe versie die door en bij de XIS-leverancier is opgewaardeerd tot een GBZ. Dit kan werken voor zorgaanbieders die een enkele XIS-leverancier hebben. • door de operationele XIS bij een zorgaanbieder stapsgewijs op te waarderen naar een GBZ. Dit zal gelden voor zorgaanbieders die vele, verschillende XIS-leveranciers hebben.

20 van 150


De eisen die worden gesteld aan de diensten te leveren door een GBZ worden vastgelegd in een apart te verschijnen Programma van Eisen voor een GBZ. Voor veel XIS’en zal het moeilijk zijn om te worden opgewaardeerd tot het gewenste beveiligingsniveau. Ook hoeven niet alle XIS’en meteen alle HL7v3-berichtsoorten te ondersteunen. Bovendien zullen in de loop van de tijd steeds meer nieuwe functies en HL7v3-berichtsoorten worden ontwikkeld. Daarom zullen verschillende GBZkwalificatieniveaus worden gedefinieerd. Tenslotte kunnen ook systemen van zorgverzekeraars, applicatieaanbieders, etc. als GBZ worden aangesloten op de ZIM, maar dat is in deze versie van dit document nog niet uitgewerkt.


3.10 LSP-portaal Het LSP-portaal biedt GBZ-(applicatie)beheerders de mogelijkheid om GBZ-applicaties te beheren. De onderstaande figuur toont deze situatie in een variant op een UML deployment diagram.

ZAB

APT APF

I&A

LSP portaal

SVM

ZIM

CFG SCH

ABH

LOG

VWI

GGS

3.11 {toekomst} XIS-leverancier/ASP-portaal Voor het beheer van GBZ-applicaties zijn sommige zorgaanbieders aangewezen op hun XIS-leverancier of ASP. De XIS-leverancier/ASP kan meerdere diensten aan hun klanten aanbieden en gebruiken daar vaak een webportaal voor. Dit webportaal zou ook gebruikt kunnen worden om zorgaanbieders hun GBZ-applicaties te kunnen beheren. Het portaal werkt dan als vervanging voor het LSP-portaal. Om een verbinding met de ZIM te leggen is er wel een PKI-overheidcertificaat nodig, waar een GBZ een UZI-servercertificaat zou gebruiken.

Kaartlezer Kaart

LOG

GP

MDT

APB

BRW

SVM APF

GBZ

PVM PB

ZA

PD

PI

TGT

ABH

SVM

XISleverancier/ASP portaal

3.12 Samenhang tussen ICT-voorzieningen In deze paragraaf wordt beschreven hoe de hierboven beschreven ICT-voorzieningen samenwerken. Daarbij worden de verschillende software-componenten (feitelijk de objecten uit [Informatiesysteemarchitectuur] hoofdstuk 5, zie aldaar voor een nadere verklaring) als volgt afgekort: PD – een PatiëntDossier PB – een zorgaanbiederPostBus ZA – een ZorgaanbiederApplicatie GP – GegevensPoort SVM - SysteemVertrouwensMiddel SCH – Schakelpunt VWI – VerWijsIndex I&A – Identificatie & Authenticatie LOG – toegangsLOG

22 van 150


CFG - ConFiGuratietabellen APT – AutorisatieProTocol APB – (lokale) Autorisatietabel APF – AutorisatieProFiel TGT – Toegangtabel MDT - ManDateringsTabel PR – (landelijke) PatiëntenRegister PI – (lokale) PatiëntenIndex ZR – ZorgaanbiederRegister ZAB – Zorgadresboek BRW – Internetbrowser ABH - Applicatiebeheer De onderstaande figuur toont deze situatie in een variant op een UML deployment diagram:

PR

ZR

SBV

UZI

APT

ZAB

APF

I&A CFG

SVM

ZIM

SCH LOG

LSP portaal

ABH VWI

GGS

DCN

Kaartlezer Kaart

LOG

GP

MDT

APB

BRW

SVM APF

GBZ

PVM PB

ZA

PD

PI

TGT

ABH

SVM

XISleverancier/ASP portaal

De figuur toont de eenvoudige situatie van een ZIM met één schakelpunt. Als de ZIM verscheidene schakelpunten bevat, verdeeld over verscheidene ZIM-platformen, moet de ZIM zich naar de GBZ’en nog steeds gedragen als één logische ZIM. De figuur toont ook een eenvoudige GBZ met slechts één zorgaanbiederapplicatie, één patiëntdossier en één zorgaanbiederpostbus. In de praktijk zal een GBZ vele applicaties hebben met vele dossiers en postbussen. De figuur toont niet de directe uitwisseling van bestanden tussen een GBZ en de SBV-Z t.b.v het koppelen van bestaande patiëntdossiers met het BSN. Überhaupt kan niet worden uitgesloten dat systemen buiten de ZIM om met elkaar communiceren, maar dat valt buiten het aandachtsgebied van Nicitz.


Belangrijk is op te merken dat de ZIM een centrale rol speelt in de communicatie tussen de aangesloten systemen. De onderstaande tabel toont met welke protocollen die communicatie plaatsvindt.

GBZ SBV-Z UZI-register LSP-portaal {toekomst} XIS-leverancier/ASP portaal

24 van 150

ZIM HL7v3 HL7v3 LDAP HL7v3 HL7v3

GBZ {toekomst} multimediale bestandsoverdracht HL7v3, HTML, XML-bestandsoverdracht LDAP, HTML HTML HTML


4

Berichtuitwisseling (BUW)

Als gevolg van de keuzes gemaakt in de vorige paragraaf inzake de verdeling van software-componenten over hardware-platformen, zullen de interacties van [Informatiesysteemarchitectuur] hoofdstuk 6 voor een deel tussen verschillende hardware-platformen moeten plaatsvinden. Dit wordt hier voor alle gebruikersinteracties uitgewerkt.

4.1

Overzicht van gebruikersinteracties

Voor de uitwisseling van patiëntgegevens tussen GBZ en ZIM is reeds gekozen voor HL7v3, zie [Architectuurvisie]. HL7v3 definieert een scala aan zorginhoudelijke berichten voor directe 1-op-1 communicatie tussen twee zorgsystemen, gewoonlijk binnen zorginstellingen. In het geval van de basisinfrastructuur gaat het om indirecte communicatie tussen zorginstellingen via een ZIM. In geval van opvragen van patiëntgegevens is bovendien sprake van 1-op-N communicatie. Deze kwestie is uitgewerkt in bijlage A. De adressering dient op meerdere niveaus geregeld te worden: op berichtniveau (met nader onderscheid tussen inhoudniveau en envelopniveau), transportniveau en verbindingniveau, zie bijlage B. Als gevolg daarvan kan één gebruikersinteractie leiden tot één of meer HL7v3gebeurtenissen (HL7v3 events): • de gebruikersinteractie aansluiten/wijzigen GBZ-applicatie leidt tot: - één HL7v3-gebeurtenis tussen de meldende GBZ en de ZIM. • de gebruikersinteractie aan/afmelden patiëntgegevens leidt tot: - één HL7v3-gebeurtenis tussen de meldende GBZ en de ZIM. • de gebruikersinteractie opvragen index leidt tot: - één HL7v3-gebeurtenis tussen de opvragende GBZ en de ZIM. • de gebruikersinteractie versturen patiëntgegevens leidt tot: - één HL7v3-gebeurtenis tussen de versturende GBZ en de ZIM, - één HL7v3-gebeurtenis tussen de ZIM en de ontvangende GBZ. • de gebruikersinteractie opvragen patiëntgegevens leidt tot: - één HL7v3-gebeurtenis tussen de opvragende GBZ en de ZIM, - X HL7v3-gebeurtenissen tussen de ZIM en X opleverende GBZ’en. Aldus wordt bij een gebruikersinteractie voortaan onderscheid gemaakt naar de volgende interactiemechanismen: • direct versturen: van agerende GBZ aan ZIM, • indirect versturen: van agerende GBZ via ZIM aan andere, reagerende GBZ, • direct opvragen: van agerende GBZ aan ZIM, • indirect opvragen: van agerende GBZ aan ZIM en van ZIM aan andere, reagerende GBZ’en of PR of ZR of ZG.


In geval van indirect versturen moet de ZIM berichten doorsturen. In geval van indirect opvragen treedt de ZIM eigenlijk op als virtuele beantwoorder, die van een GBZ een opvraag krijgt, deze opvraag opnieuw stelt aan andere GBZ’en of een register, de resultaten verzamelt en de verzameling van resultaten oplevert alsof de ZIM deze zelf had. Elke HL7v3-gebeurtenis kan bestaan uit één of meer HL7v3-interacties, bijvoorbeeld een HL7v3-verzoekbericht en een HL7v3-antwoordbericht. HL7v3-berichten worden opgebouwd uit de volgende onderdelen: • Payload bevat inhoudelijke patiëntgegevens van een bepaalde gegevenssoort. • Control Act Wrapper bevat gegevens over de interactie die moet worden uitgevoerd met de payload, bijv. het aantal resultaten dat voor een opvraag moet worden opgeleverd. • Transmission Wrapper bevat gegevens over het transport, bijv. van welke applicatie naar welke applicatie het bericht moet worden gestuurd. • Batch Wrapper kan gebruikt worden om meerdere berichten in te pakken. De onderstaande figuur toont met getrokken lijnen welke onderdelen altijd aanwezig zijn en met gestippelde lijnen welke onderdelen niet altijd aanwezig zijn:

HL7v3 batch wrapper HL7v3 transmission wrapper HL7v3 control act wrapper HL7v3 payload

Op initiatief van Nicitz is de HL7v3-standaard uitgebreid met een aantal berichtdefinities die toepasbaar zijn voor de Nederlandse basisinfrastructuur. De onderstaande tabel geeft een overzicht van de HL7v3-interacties die plaatsvinden tussen een GBZ en de ZIM en tussen de ZIM en de SBV-Z en het UZI-register als gevolg van de mogelijke gebruikersinteracties.

26 van 150


Gebruiksscenario Gebruikersinteractie Berichtnaam

HL7v3-

HL7v3

HL7v3

HL7v3

HL7v3

Ge-

Mecha-

interactie

payload

controlact

transmiss

batch

gevens-

nisme

wrapper

wrapper

wrapper

soort

[INL] in/uitloggen gebruiker Inloggen gebruiker

Geen

Uitloggen gebruiker

Geen

Toepassingsrol

[SPA] selecteren patient/cliënt Opvragen PatiëntIdentificatie opvragenPatiëntIdentificatie QUPA_IN 101103 opleverenPatiëntIdentificatie QUPA_IN 101104 Opvragen Omloop status WID

QUPA_MT 101103 QUPA_MT 101104

QUQI_MT 020001 MFMI_MT 700711

MCCI_MT 000100 MCCI_MT 000300

indirect opvragen

opvragenOmloopStatusWID PRPA_IN 900222NL opleverenOmloopStatusWID PRPA_IN 900112NL Opvragen PatiëntIdentificatie




indirect opvragen




indirect opvragen

QUPA_MT 101103 QUPA_MT 101104 PRPM_MT 405010

QUQI_MT 020001 MFMI_MT 700711 QUQI_MT 121001

MCCI_MT 000100 MCCI_MT 000300 MCCI_MT 000100

opvragenPersoonsGegevens QUPA_IN 101101 opleverenPersoonsGegevens QUPA_IN 101102

alle alle

alle alle

alle alle

[SZA] Selecteren zorgaanbieder Opvragen Zorgadresboek opvragenZorgverlenerDetails PRPM_IN 306050NL opleverenZorgverlenerDetails PRPM_IN 306051NL opvragenZorgaanbiederDetails PRPM_IN 405010


27 van 150

Gebruiksscenario

HL7v3-

HL7v3

HL7v3

HL7v3

HL7v3

Ge-

Mecha-

interactie

payload

controlact

transmiss

batch

gevens-

nisme

wrapper opleverenZorgaanbiederDetails PRPM_IN PRPM_MT MFMI_MT 405110 405110 700711 opvragenZorgaanbiederOrganisatie- Zie [IH Generieke berichten] deelDetails opleverenZorgaanbiederOrganisatie- Zie [IH Generieke berichten] deelDetails opvragenZorgaanbiederApplicatieDe Zie [IH Generieke berichten] tails opleverenZorgaanbiederApplicatieDe Zie [IH Generieke berichten] tails Bijwerken Zorgadresboek

wrapper MCCI_MT 000300

wrapper

soort

Gebruikersinteractie Berichtnaam

bijwerkenZorgaanbiederDetails Zie [IH Generieke bijwerkenZorgverlenerDetails Zie [IH Generieke bijwerkenZorgaanbiederOrganisatie Zie [IH Generieke deelDetails bijwerkenZorgaanbiederApplicatieDe Zie [IH Generieke tails [BIJ] bijhouden patiëntgegev. Geen

Toepassingsrol

berichten] berichten] berichten] berichten]

[PUB] publiceren patiëntgegev. Publiceren MedicatieVoorschriften Publiceren MedicatieVerstrekkingen Publiceren EerstelijnsDossier

28 van 150

MFMT_IN aanmeldenGegevens 002101

MFMT_MT 002002

MFMI_MT 700702

MCCI_MT 000100

SBADM SPLY PCPR

direct versturen

MFMT_IN

MFMT_MT

MFMI_MT

MCCI_MT

SBADM

direct

medicatievoorschrij vend en verstrekkend systeem Vaste huisarts systeem medicatievoorschrij



HL7v3-

HL7v3

HL7v3

HL7v3

HL7v3

Ge-

Mecha-

interactie

payload

controlact

transmiss

batch

gevens-

nisme

wrapper 700702

wrapper 000100

wrapper

002001

soort SPLY PCPR

versturen

MFMT_MT 002001

MFMI_MT 700702

MCCI_MT 000100

QUQI_MT 021001 MFMI_MT 700712 QUQI_MT0 21001

MCCI_MT 000100 MCCI_MT 000300 MCCI_MT0 00100

heraanmeldenGegevens 002102

MFMT_IN afmeldenGegevens 002103

[ABO] abonneren patiëntgegev.

SBADM SPLY PCPR

direct versturen

Toepassingsrol

vend en verstrekkend systeem Vaste huisarts systeem medicatievoorschrij vend en verstrekkend systeem Vaste huisarts systeem

Niet gedefinieerd

[OPV] opvragen patiëntgegev. Opvragen Index opvragenIndex QUMT_IN 020010 opleverenIndex QUMT_IN 020020 opvragenIndex (met QUMT_IN0 gegevensbeheerder) 20011NL

QUMT_MT 020020 MFMT_MT 002001 QUMT_MT 020021NL

opleverenIndex (met QUMT_IN0 MFMT_MT gegevensbeheerder) 20021NL 002003NL Opvragen MedicatieVoorschriften opvragenMedicatievoorschriften QURX_IN (eerste) 990001NL opleverenMedicatievoorschriften QURX_IN 990003NL opvragenMedicatievoorschriften QUQI_IN


QURX_MT 990001NL PORX_MT 932000NL n.v.t.

direct opvragen

alle

indirect opvragen

medicatievoorschrij vend systeem medicatievoorschrij vend systeem c

MFMI_MT7 MCCI_MT0 00712 00300 QUQI_MT 020001 QUQI_MT 120001 QUQI_MT

MCCI_MT 000100 MCCI_MT 000300 MCCI_MT

SBADM MCCIMT 200101 SBADM

29 van 150

Gebruiksscenario

HL7v3-

HL7v3

HL7v3

HL7v3

HL7v3

Ge-

Mecha-

interactie

payload

controlact

transmiss

batch

gevens-

nisme

wrapper 000100 MCCI_MT 000300

soort

PORX_MT 932000NL

wrapper 000001 QUQI_MT 120001

wrapper

(vervolg) 000003 opleverenMedicatievoorschriften QURX_IN 990003NL Opvragen MedicatieVerstrekkingen opvragenMedicatieverstrekkingen QURX_IN (eerste) 990011NL

QURX_MT 990011NL

QUQI_MT 020001

MCCI_MT 000100

opleverenMedicatieverstrekkingen QURX_IN 990013NL opvragenMedicatieverstrekkingen QUQI_IN (vervolg) 000003

PORX_MT 924000NL n.v.t.

QUQI_MT 120001 QUQI_MT 000001


opleverenMedicatieverstrekkingen QURX_IN 990013NL Opvragen Samenvatting DWH

PORX_MT 924000NL

QUQI_MT 120001

MCCI_MT 000300

opvragenSamenvattingVoorDWH QUPC_IN 990001NL opleverenSamenvattingVoorDWH QUPC_IN 990002NL

QUPC_MT 990001NL REPC_MT 004001NL -PS

QUQI_MT 021001 QUQI_MT 120001


QUMT_MT0 20099NL REPC_MT00 0003NL

QUQI_MT0 21001 QUOI_MT1 20001

MCCI_MT0 00100 MCCI_MT0 00300

Gebruikersinteractie Berichtnaam

MCCIMT 200101

medicatievoorschrij vend systeem SPLY

indirect opvragen

medicatievoorschrij vend en verstrekkend systeem medicatieverstrekk end systeem medicatievoorschrij vend en verstrekkend systeem

SPLY

MCCIMT 200101

medicatieverstrekk end systeem PCPR

MCCIMT 200101

Toepassingsrol

indirect opvragen

Waarnemende huisarts systeem Vaste huisarts systeem

Opvragen Contra-indicaties opvragenContra-indicaties REPC_IN0 00023NL opleverenContra-indicaties REPC_IN0 00024NL

30 van 150



HL7v3-

HL7v3

HL7v3

HL7v3

HL7v3

Ge-

Mecha-

interactie

payload

controlact

transmiss

batch

gevens-

nisme

wrapper

wrapper

wrapper

soort

Toepassingsrol

[STU] versturen patiëntgegev. Versturen MedicatieVoorschrift versturenMedicatievoorschrift PORX_IN 932000NL Versturen Medicatieverstrekking

PORX_MT 932000NL

MCAI_MT 700201

MCCI_MT 000100

indirect versturen

medicatieverstrekk end systeem

versturenMedicatieverstrekking PORX_IN 924000NL Versturen Waarneemverslag WDH

PORX_MT 924000NL

MCAI_MT 700201

MCCI_MT 000100

indirect versturen

medicatieverstrekk end systeem

versturenVerslagWDH REPC_IN 990003NL

REPC_MT 004001NL _WR

MCAI_MT 700201

MCCI_MT 000100

indirect versturen

Waarnemende huisarts systeem

overdrachtVerzoek COMT_IN 800100 Antwoorden Overdracht

COMT_MT 800100

MCAI_MT 700201

MCCI_MT 000100

overdrachtAntwoord (aanvaarding) COMT_IN 800110 overdrachtAntwoord (afwijzing) COMT_IN 800120 Intrekken Overdracht

COMT_MT 800110 COMT_MT 800120

MCAI_MT 700201 MCAI_MT 700201


intrekkingVerzoek COMT_IN 800300 intrekkingAntwoord (aanvaarding) COMT_IN 800310 intrekkingAntwoord (afwijzing) COMT_IN 800320 intrekkingKennisgeving COMT_IN

COMT_MT 800300 COMT_MT 800310 COMT_MT 800320 COMT_MT

MCAI_MT 700201 MCAI_MT 700201 MCAI_MT 700201 MCAI_MT

MCCI_MT 000100 MCCI_MT 000300 MCCI_MT 000300 MCCI_MT

[BOV] beheeroverdracht. Verzoeken Overdracht


31 van 150

Gebruiksscenario Gebruikersinteractie Berichtnaam [BZA] aansluitenGBZ-applicatie [BZA] wijzigenGBZ-applicatie

32 van 150

HL7v3-

HL7v3

HL7v3

HL7v3

HL7v3

Ge-

Mecha-

interactie

payload

controlact

transmiss

batch

gevens-

nisme

800400 PRPM_TE9 08100NL PRPM_TE9 08200NL

800400 PRPM_MT9 08100 PRPM_MT9 08200

wrapper 700201 MFMI_MT7 00701 MFMI_MT7 00701

wrapper wrapper 000100 MCCI_MT0 00100 MCCI_MT0 00100

Toepassingsrol

soort direct versturen direct versturen

Alle Alle


Voor de manier waarop van de verschillende, gestandaardiseerde HL7v3-interacties gebruik wordt gemaakt, zijn er enkele keuzes te maken. Die keuzes worden ingeleid in de navolgende paragrafen en nader uitgewerkt in de HL7v3-Implementatiehandleidingen. Ten behoeve van autorisatie en mandatering worden de volgende klassen van gebruikersinteracties onderkend: • Algemene: - Opvragen PatiëntIdentificatie - Opvragen WIDomloopstatus - Opvragen Zorgadresboek - Bijwerken Zorgadresboek • Medische: - Opvragen Index - Publiceren MedicatieVoorschriften - Publiceren MedicatieVerstrekkingen - Opvragen MedicatieVoorschriften - Opvragen MedicatieVerstrekkingen - Versturen MedicatieVoorschrift - Versturen MedicatieVerstrekking - Publiceren EerstelijnsDossier - Opvragen Samenvatting WDH - Versturen Verslag WDH • Toekomstige: - Opvragen Samenvatting SEH - Versturen Verslag SEH - Versturen PatiëntOverdracht - Versturen Verwijzing - Versturen BepalingOpdracht - Versturen BepalingResultaat Opmerkingen: • Ad [SPA]: De berichten voor het opvragen en verifiëren van het BSN van een patiënt zijn in de tabel opgenomen als opvragenPatiëntIdentificatie en opleverenPatiëntIdentificatie. • Ad [SZA]: er zijn aparte HL7v3-interacties voor het opvragen van zorginstellingen en voor het opvragen van zorgverleners, dus leidt dit gebruiksscenario tot twee verschillende HL7v3-interacties. • Ad [SZA]: voor gebruiksscenario [SPA.s01] zijn er geen HL7v3-interacties voor het uitsluitend ophalen van identificerende gegevens van zorgaanbieders, daarom worden aldaar HL7v3-interacties gebruikt die tegelijk ook de bereikbaarheidsdetails opvragen en opleveren. Dit betekent dat voor gebruiksscenario [SPA.s02]geen HL7v3-interacties meer nodig zijn.

Technische architectuur AORTA, v6.0.0.0

33 van 150

4.2

Indirect versturen

Wanneer een zorgaanbieder een opdracht (HL7v3: order) wil sturen naar een andere zorgaanbieder, kan de ZIM daarbij in principe de volgende opties bieden, die in een HL7v3-opdracht als parameter kunnen worden aangegeven: • wel/niet bevestigen van gelukte of mislukte aflevering (HL7v3: accept acknowledgement) • {toekomst} wel/niet onmiddellijk afleveren. De optie WEL bevestigen wordt hier verplicht gesteld voor opdrachtberichten zonder inhoudelijk antwoord (HL7v3: application response), omdat de opdrachtgever anders geen enkele zekerheid krijgt dat zijn opdrachtbericht is aangekomen. Momenteel zijn nog geen opdrachtberichten mét inhoudelijk antwoord gedefinieerd, dus zal altijd een bevestiging moeten plaatsvinden. Een HL7v3-ontvangstbevestiging mag overigens niet worden gegeven voordat de HL7v3-opdracht persistent is gemaakt. De optie WEL onmiddellijk afleveren valt momenteel niet te kiezen, maar wordt door de ZIM standaard uitgevoerd. Dit betekent dat de ZIM de opdracht van GBZ1 onmiddellijk probeert af te leveren bij GBZ2 en meteen bevestigt of het gelukt is. Als GBZ2 toevallig even niet beschikbaar is, moet GBZ1 het later maar opnieuw proberen. Dit is het instant messaging mechanisme en verschilt wezenlijk van het store & forward-mechanisme zoals bij e-mail.

:opdracht gever opdracht

:GBZ1

:ZIM

(oorspronkelijk) opdrachtbericht HL7-order-req

: GBZ2

:opdracht nemer

doorgestuurd opdrachtbericht HL7-order-req

doorgestuurd bevestigbericht presentatie bevestiging

(oorspronkelijk) bevestigbericht HL7-accept-ack

HL7-accept-ack

Merk op dat de positie van de ZIM tussen een versturend GBZ en een ontvangend GBZ wezenlijk anders is dan die bij het opvragen van patiëntgegevens. De ZIM fungeert hier als “bridge”, zie HL7v3 Abstract Transport Specification. Dit betekent dat de ZIM slechts HL7v3-berichten doorschuift zonder de HL7v3-inhoud te beroeren. Zo worden HL7v3opdrachten van GBZ1 door de ZIM afgeleverd bij GBZ2 alsof dat rechtstreeks ging. Hetzelfde geldt voor HL7v3-bevestigingen van GBZ2 die door de ZIM worden afgeleverd bij GBZ2. Alleen als er communicatieproblemen optreden tussen ZIM en GBZ2, zal de ZIM zelf een HL7v3-bevestiging genereren, zie paragraaf 11. Zie ook bijlage B. Er is echter één reden voor de ZIM om toch in de HL7v3-inhoud (HL7v3: payload) te kijken. Om een HL7v3-opdrachtbericht te kunnen autoriseren moet de ZIM immers uit de HL7v3-inhoud kunnen lezen: • patiëntnummer

34 van 150


• gegevenssoort • zorgverleneridentificatie • zorgverlenerfunctie Architectuurbeslissingen: BUW·b01 De ZIM moet op verzoek van een versturende applicatie de patiëntberichten

zowel onmiddellijk als {toekomst} op een aangegeven gewenst tijdstip kunnen afleveren. Daarnaast volgt uit de HL7v3-implementatiehandleidingen dat de ZIM bij het doorsturen van een opdracht- of bevestigbericht het volgende moet doen: • altijd de Transmission Wrapper canoniek ongewijzigd laten, evenals de eventuele ControlAct Wrapper en Payload. Met canoniek ongewijzigd wordt bedoeld dat de verschijningsvorm mag verschillen zolang de XML-inhoud semantisch gelijk blijft. De onderstaande figuur toont ten behoeve van [Informatiesysteemarchitectuur] paragraaf 5.8 de relaties tussen de verschillende berichten als gevolg van een opdracht door een gebruiker. HL7v3 Transmission Wrapper

1

1

Indirecte opdracht interactie

(Oorspronk.) opdracht bericht

Doorgestuurd opdracht bericht

HL7v3 ControlAct Wrapper

1 bevat >

Opdracht

HL7v3 Payload

1 bevat >

Patiënt stuk

^ is gelijk aan

leidt tot >

1

1

(Oorspronk.) bevestig bericht

Doorgestuurd bevestig bericht

^ is gelijk aan

De figuur toont onder meer: • dat één opdrachtbericht steeds tot één bevestigbericht leidt. • dat een oorspronkelijk bericht en een doorgestuurd bericht gelijk zijn op het niveau van: - de HL7v3 Transmission Wrapper (dus met dezelfde bericht-id), - de eventuele HL7v3 ControlAct Wrapper (dus met dezelfde gebeurtenis-id), - de eventuele HL7v3 Payload (dus met dezelfde patiëntstuk-id).


35 van 150

4.3

Indirect opvragen

Wanneer een zorgaanbieder patiëntgegevens wil opvragen (HL7v3: query) van andere zorgaanbieders, zal één opvraag al gauw leiden tot vele resultaten. Immers, een X-aantal opleverende GBZ’en kunnen ieder een Y-aantal resultaten opleveren, zie de onderstaande figuur. Daarbij kan de ZIM in principe de volgende opties bieden die in een HL7v3opvraagbericht als parameter kunnen worden aangegeven: • wel/niet doseren van het aantal resultaten per oplevering, • wel/niet bundelen van verschillende opleveringen in één gebundelde oplevering (HL7v3: batch), • wel/niet sorteren van resultaten, • wel/niet uitstellen van de oplevering (HL7v3: immediate vs. deferred). Het uitstellen van de oplevering kent momenteel geen toepassing en wordt daarom niet als optie geboden. In Bijlage A wordt onderbouwd dat de ZIM aan een opvragende GBZ slechts de volgende keuzevrijheid moet bieden: • wel/niet bundelen, • wel/niet doseren. In geval van WEL bundelen en NIET doseren zal één HL7v3-opvraagbericht (HL7v3: query request) altijd leiden tot één gebundelde HL7v3-oplevering (HL7v3: batch) met daarin één of meer HL7v3-opleveringen (HL7v3: query response) met ieder één of meer resultaten, zie de onderstaande figuur.

:gegevens opvrager opvraag

:GBZ0

:ZIM

: GBZx

:gegevens houder

(oorspronkelijk) opvraagbericht HL7-query-req (batch)

[voor elke GBZx vermeld in verwijsindex] gedivergeerd opvraagbericht HL7-query-req (oorspronkelijk) opleverbericht

geconvergeerd opleverbericht presentatie resultaten

HL7-query-rsp (resultaten)

HL7-batch (HL7-query-rsp (resultaten) )

Let op: anders dan de figuren suggereren, zijn het niet zozeer de GBZ’en maar de afzonderlijke applicaties binnen die GBZ’en die zijn vermeld in de verwijsindex.

36 van 150


In alle andere gevallen dan WEL bundelen en NIET doseren zal hetzelfde interactiemechanisme plaatsvinden, maar kan dat herhaald geschieden, afhankelijk van het aantal beschikbare resultaten en de gestelde maxima per oplevering. Merk op dat zowel een opvragend GBZ als een opleverend GBZ een maximum aantal resultaten kan hanteren en dus aanleiding kan geven tot vervolgopvragen. De eerste opvraag (HL7v3: query specification) bevat de opvraagcriteria; de daaropvolgende HL7v3-vervolgopvragen (HL7v3: query continuation) geven slechts aan dat de volgende resultaten moeten worden opgeleverd. Zie onderstaande figuur. De sessie eindigt na een HL7v3-eindeopvraag (HL7v3: query cancel) of wanneer alle resultaten zijn opgeleverd.

:GBZ0

:gegevens opvrager opvraag

:ZIM

: GBZx

:gegevens houder

(oorspronkelijk) eerste opvraagbericht HL7-query-spec (max N) of HL7-query-spec (batch, max N)

[voor elke GBZx vermeld in verwijsindex] gedivergeerd eerste opvraagbericht HL7-query-spec (max N) (oorspronkelijk) opleverbericht HL7-query-rsp (resultaten)

geconvergeerd opleverbericht HL7-query-rsp (resultaten) of HL7-batch (HL7-query-rsp (resultaten) )

presentatie resultaten

[voor elke opvraag van de volgende N antwoorden] (oorspronkelijk) vervolg opvraagbericht HL7-query-cont ()

[voor elke GBZx vermeld in verwijsindex] gedivergeerd vervolg opvraagbericht HL7-query-cont () (oorspronkelijk) opleverbericht HL7-query-rsp (resultaten)

geconvergeerd opleverbericht presentatie resultaten

HL7-query-rsp (resultaten) of HL7-batch (HL7-query-rsp (resultaten) )

afbreking origineel einde opvraagbericht HL7-query-cancel

Architectuurbeslissingen uit bijlage A: BUW·b02 De ZIM moet, indien een opvragende GBZ daarom verzoekt, de resultaten van

de opleverende GBZ’en bundelen tot één gebundeld opleverbericht aan dat GBZ. BUW·b03 De ZIM moet opleverende GBZ’en nooit om een gebundeld opleverbericht

vragen. BUW·b04 {toekomst} De ZIM moet opleveringen op verzoek van een opvragende GBZ

kunnen doseren. BUW·b05 {toekomst} De ZIM moet een gedoseerde opvraag ook gedoseerd divergeren

naar de opleverende GBZ’en, met hetzelfde maximum aantal resultaten.


37 van 150

BUW·b06 {toekomst} De ZIM moet een oplevering van een GBZ weigeren als deze meer

dan het gevraagde maximum aantal resultaten bevat. BUW·b07 {toekomst} De ZIM moet rekening houden met een GBZ dat ongevraagd

gedoseerd oplevert en zonodig vervolgopvraagberichten sturen. BUW·b08 {toekomst} De ZIM mag een vervolgvraag van een opvragende GBZ weigeren

indien deze een maximum aantal resultaten en/of een volgnummer zou bevatten. BUW·b09 De ZIM moet een verzoek van een opvragende GBZ voor het sorteren van

resultaten weigeren. BUW·b10 {toekomst} Het autoriseren en routeren van HL7v3 berichten mag niet

afhankelijk zijn van de payload. Merk op dat de positie van de ZIM tussen één opvragend GBZ en vele opleverende GBZ’en wezenlijk anders is dan die bij het versturen van patiëntgegevens. De ZIM fungeert hier als “gateway”, zie HL7v3 Abstract Transport Specification. Dit betekent dat de ZIM meer doet dan HL7v3-berichten één op één doorschuiven. De ZIM treedt eigenlijk op als tussenpersoon die van een GBZ een opvraag krijgt, deze opvraag opnieuw stelt aan andere GBZ’en, de resultaten verzamelt en de verzameling van resultaten oplevert alsof de ZIM deze zelf had. Om een HL7v3-opvraagbericht te kunnen divergeren naar een X-aantal andere GBZ’en aan de hand van de verwijsindex, moet de ZIM uit het HL7v3-bericht kunnen lezen: • patiëntnummer (uit de HL7v3 transmission wrapper) • gegevenssoort (uit de HL7v3 payload) Om een HL7v3-opvraagbericht vooraf te kunnen autoriseren, moet de ZIM bovendien uit de ControlAct Wrapper kunnen lezen: • id en functie van de gebruiker • id en functie van de mandaterende zorgverlener Evenwel kijkt de ZIM niet in HL7v3-inhoud (HL7v3: payload) van de HL7v3opleverberichten, zie ook bijlage B. Daarnaast volgt uit de HL7v3-implementatiehandleidingen dat de ZIM bij het doorschuiven van een bericht (meer specifiek: het divergeren van een opvraagbericht en het convergeren van een opleverbericht) het volgende moet doen: • altijd de Transmission Wrapper wijzigen en dus ook een nieuw bericht-id toekennen, ook als de berichten daarna nog worden gebundeld in een Batch Wrapper. • in het opvraag-specifieke deel van de ControlAct Wrapper wijzigen: - {toekomst} de opvraag-id - zonodig de tellers • de rest van de ControlAct Wrapper canoniek ongewijzigd laten, evenals de eventuele Payload.

38 van 150


De onderstaande figuur toont ten behoeve van [Informatiesysteemarchitectuur] paragraaf 5.8 de relaties tussen de verschillende berichten als gevolg van een opvraag door een gebruiker, in een UML class diagram. HL7v3 Transmission Wrapper Z

(Oorspronk.) opvraag bericht

HL7v3 ControlAct Wrapper

HL7v3 Payload

bevat > 1

Opvraag

1

X..*

Indirecte opvraag interactie

Gedivergeerd opvraag bericht

bevat >

leidt tot >

X..*

Z

Bundel oplever berichten

(Oorspronk.) oplever bericht

Einde Vervolgopvraag Eersteopvraag opvraag

bevat > 1

Oplevering

Resultaat

1

Geconverg. oplever bericht

1..X bevat >

Y bevat >

Enkel oplever bericht

bevat >

Patiëntstuk Patiënt identif.geg. Zorgaanb. bereikb.geg.

De figuur toont onder meer: • dat een opvraagsessie kan leiden tot Z opvraagberichten, • dat één opvraag kan leiden tot X opleveringen met ieder Y resultaten, • dat een opvraag kan zijn: - een eerste opvraag, of - een vervolg opvraag, of - een einde opvraag. • dat een resultaat kan zijn: - een patiëntstuk, of - identificerende gegevens van een patiënt, of - bereikbaarheidsgegevens van een zorgaanbieder, • dat een gedivergeerd opleverbericht kan zijn: - een enkel opleverbericht, of - een bundel van X opleverberichten, • dat een oorspronkelijk bericht en een gedivergeerd of geconvergeerd bericht verschillen op het niveau van: - de HL7v3 Transmission Wrapper (dus met een ander bericht-id), - het opvraag-specifieke deel van de HL7v3 ControlAct Wrapper (dus met een ander opvraag-id), maar gelijk zijn op het niveau van: - het generieke deel van de HL7v3 ControlAct Wrapper (dus met dezelfde gebeurtenis-id indien aanwezig), - de eventuele HL7v3 Payload (dus met dezelfde patiëntstuk-id).


39 van 150

4.4

Beheeroverdracht

Overdracht van beheerverantwoordelijkheid van patiëntgegevens vergt een complex samenspel tussen de overdrachtverzoeker en de overdrachtbeantwoorder, waarbij de ZIM optreedt als regisseur, zie [Informatiesysteemarchitectuur] bijlage D. Beheeroverdracht omvat een overdrachtVerzoek gevolgd door een overdrachtAntwoord en/of intrekkingVerzoek die alle via de ZIM worden verstuurd. Deze AORTA-interacties kunnen worden gerealiseerd via de volgende HL7-interacties: • overdrachtVerzoek, zowel aanbieden als vragen beheerverantwoordelijkheid, wordt HL7-request-change-of-custodian, • overdrachtAntwoord met aanvaarden beheerverantwoordelijkheid wordt HL7-accept-custodianship, • overdrachtAntwoord met afwijzen beheerverantwoordelijkheid wordt HL7-reject-custodianship, • intrekkingVerzoek, wordt HL7-cancel-change-of-custodian-request, • intrekkingAntwoord met aanvaarding wordt HL7-accept-cancellation-of-change-ofcustodian, • intrekkingAntwoord met afwijzing wordt HL7-reject-cancellation-of-change-ofcustodian, • intrekkingKennsigeving wordt HL7-cancellation-of-change-of-custodian-notification. Merk op dat geen van deze HL7-interacties de inhoud van de over te dragen patiëntgegevens bevat. De inhoudelijke gegevensoverdract vindt namelijk plaats via de HL7interacties voor opvragen en versturen van patiëntgegevens, zie paragraaf 4.2 en 4.3. Omdat alle interacties een toestandsverandering van de afzender inhouden, moet de afzender zeker weten dat het bericht door de bestemming goed is ontvangen en verwerkt kan worden. Dit betekent dat bijna alle HL7-interacties moeten worden beantwoord met een HL7-accept-ack, zie de onderstaande figuur. Uitzondering is het intrekkingVerzoek dat anders dan het overdrachtVerzoek niet pas later wordt beantwoord door het andere GBZ2 maar onmiddellijk door de ZIM met een intrekkingAntwoord, waarna het andere GBZ2 slechts een intrekkingKennsigeving krijgt. In eerste instantie lijkt het bij het overdrachtVerzoek en -Antwoord te gaan om afzonderlijke AORTA-interacties van het type indirect versturen, waarbij de ZIM slechts een doorgeefluik is. Echter, de ZIM moet voor een overdrachtVerzoek een verwijzing in de verwijsindex blokkeren, voor een positief overdrachtAntwoord daarvan de beheerverantwoordelijkheid wijzigen en voor de overige de verwijzing deblokkeren. Bovendien hoort bij ieder overdrachtVerzoek precies één overdrachtAntwoord en/of intrekkingVerzoek en de ZIM moet bij langdurig uitblijven daarvan de reservering opheffen. Dit betekent dat GBZ1 het overdrachtVerzoek qua applicatie-id moet richten aan de ZIM, die vervolgens een nieuw, maar gelijkluidend overdrachtVerzoek richt aan GBZ2. Voor het overdrachtAntwoord geldt een analoog principe.

40 van 150


:overdracht verzoeker

:GBZ1

overdrachtVerzoek

:ZIM

(oorspronkelijk) overdrachtVerzoek HL7-request-change-cust

: GBZ2

:overdracht beantwoorder

(doorgestuurd) overdrachtVerzoek HL7-request-change-cust

(doorgestuurde) bevestiging presentatie bevestiging

(oorspronkelijke) bevestiging HL7-accept-ack presentatie verzoek

HL7-accept-ack

(doorgestuurd) overdrachtAntwoord HL7-accept-cust or HL7-reject-cust (oorspronkelijke) bevestiging HL7-accept-ack presentatie antwoord

(oorspronkelijk) overdrachtAntwoord

overdrachtAntwoord

HL7-accept-cust or HL7-reject-cust

(doorgestuurde) bevestiging HL7-accept-ack

presentatie bevestiging

EN / OF intrekkingVerzoek intrekkingVerzoek HL7-cancel-change-cust-req intrekkingAntwoord (aanvaarding of afwijzing) presentatie bevestiging

HL7-accept-canc-change-cust-req of HL7-reject-canc-change-cust-req

[indien intrekkingAntwoord = aanvaarding] intrekkingKennisgeving HL7-canc-change-cust-notif bevestiging HL7-accept-ack presentatie intrekking

OF overdrachtAntwoord (afwijzing) HL7-reject-cust bevestiging HL7-accept-ack presentatie vervallen

intrekkingKennisgeving HL7-canc-change-cust-notif bevestiging HL7-accept-ack presentatie vervallen

Net als bij het mechanisme indirect versturen, is ook hier de keuzevrijheid om de ZIM een overdrachtVerzoek wel of niet onmiddellijk te laten doorsturen. Onmiddellijk doorsturen betekent dat de ZIM na uitblijven van een bevestiging van GBZ2 onmiddellijk meldt aan GBZ1 dat het mislukt is. Dit betekent dat GBZ1 het later opnieuw moet proberen. Het alternatief is dat de ZIM een overdrachtverzoek van GBZ1 meteen bevestigt en daarna probeert door te sturen naar GBZ2 en pas na lange tijd van mislukken terugmeldt aan GBZ1 dat GBZ2 onbereikbaar is. Die terugmelding zou in de vorm van een HL7 reject custodianship kunnen. Om het voorlopig eenvoudig te houden, is gekozen voor onmiddellijk doorsturen, waarbij de ZIM de agerende GBZ niet eerder bevestigt dan dat het reagerende GBZ2 heeft bevestigd.


41 van 150

Om een overdrachtAntwoord of intrekkingVerzoek te kunnen koppelen aan het bijbehorende overdrachtVerzoek, heeft de ZIM een gemeenschappelijk kenmerk nodig. Idealiter gebruiken we daarvoor een nieuw kenmerk, bijv. een overdracht-id, maar HL7 heeft daarvoor geen geschikt attribuut. Wel wordt ieder overdrachtVerzoek gekenmerkt door de patiëntgegevens-id van de verwijzing in de verwijsindex waarop de overdracht betrekking heeft. Omdat voor iedere verwijzing maximaal één overdrachtVerzoek mag uitstaan, kan deze patiëntgegevens-id fungeren als gemeenschappelijk kenmerk. Architectuurbeslissingen: BUW·b11

Een agerende GBZ1 zal een overdrachtVerzoek, overdrachtAntwoord of intrekkingVerzoek moeten adresseren aan de ZIM.

BUW·b12

de ZIM zal een ontvangen overdrachtVerzoek en overdrachtAntwoord onmiddellijk doorsturen, en de agerende GBZ1 pas bevestigen nadat het reagerende GBZ2 heeft bevestigd.

BUW·b13

de ZIM zal een ontvangen intrekkingVerzoek onmiddellijk beantwoorden met een intrekkingAntwoord (aanvaarding of afwijzing) en het reagerende GBZ2 zonodig een intrekkingKennisgeving sturen.

BUW·b14

de ZIM zal de patiëntgegevens-id genoemd in een overdrachtantwoord of intrekkingVerzoek hanteren om het bijbehorende overdrachtverzoek te vinden.

Merk op dat een GBZ een ontvangen overdrachtVerzoek, overdrachtAntwoord of intrekkingKennisgeving mag bevestigen aan de ZIM voordat het wordt gepresenteerd aan de zorgverlener/medewerker, zie ook bovenstaande figuren. Dit is omdat de bevoegde zorgverlener/medewerker niet altijd aanwezig is. Een GBZ moet echter wel altijd beschikbaar zijn om de ZIM te kunnen bevestigen. Tenslotte hoeft een intrekkingKennisgeving door het reagerende GBZ niet gepresenteerd te worden, als de zorgverlener het overdrachtVerzoek nog niet heeft gezien.

42 van 150


Merk op dat de ZIM kan arbitreren mocht GBZ1 een intrekkingVerzoek sturen tegelijk als GBZ2 een overdrachtAntwoord stuurt. De ZIM kan nl. bepalen welk bericht eerder was ontvangen (dus niet: welke eerder was verzonden). De ZIM moet dan alle overdrachtberichten serieel verwerken en het eerst ontvangen bericht normaal afhandelen en op het tweede bericht een foutmelding teruggeven, zie de onderstaande figuur. In het geval dat de ZIM wegens de vervaltijd zelf al berichten had gestuurd, moet de ZIM aan zowel GBZ1 als GBZ2 een foutmelding teruggeven.


:GBZ1

:ZIM

: GBZ2

intrekking


antwoord intrekkingVerzoek intrekkingAntwoord

(aanvaarding)

rd overdrachtAntwoo intrekkingKennisg eving

anniesgeving bevestiging intrekkingK foutmelding overd rachtAntwoord

melding “OK”

melding “reeds ingetrokken”

OF intrekking

antwoord intrekkingVerzoek

rd overdrachtAntwoo

overdrachtAntwoord bevestiging ove rdrachtAntwoord

melding “reeds beantwoord”

(afwijzing) intrekkingAntwoord


bevestiging overd rachtAntwoord

melding “OK”

43 van 150

5

Berichttransport (BTP)

5.1

Inleiding

Voor de datacommunicatie tussen GBZ en ZIM is reeds gekozen voor internetprotocollen: HTTP met SSL/TLS over TCP/IP, zie [Architectuurvisie AORTA]. Om de zorginhoudelijke HL7v3-berichten veilig te kunnen transporteren over een DCN gebaseerd op deze internet-protocollen, zijn aanvullende transportprotocollen nodig. De HL7v3-standaard noemt hier de volgende mogelijkheden: • Minimal Lower Layer Protocol (MLLP) • ebXML Messaging Service (ebMS) • Web Services Profile Web Services Profile is gebaseerd op: • SOAP 1.1, een XML-envelop om HL7v3-berichten over HTTP te kunnen versturen, • WSDL 1.1, een XML-definitietaal om de web services te definiëren, zodanig dat de benodigde software met geschikte gereedschappen deels automatisch ontwikkeld kan worden, • WS-I Basic Profile 1.0, een verzameling richtlijnen voor het gebruik van SOAP en WSDL. Aanvullend wordt het WS-I Basic Security profile (WS-I BSP) toegepast. Dit is een richtlijn voor het toepassen van de standaarden XML-signature, WS-Security en XMLencryption. Architectuurbeslissingen: BTP·b01

Voor het transport van HL7v3-berichten wordt gekozen voor Web Services Profile, wegens de mogelijkheden voor de beveiliging van berichten en de beschikbaarheid van gereedschappen voor softwareontwikkeling.

BTP·b02

Voor het transport van HL7v3-berichten wordt verder gekozen voor de Unicodetekenset en UTF-8 codering.

BTP·b03

Voor het realiseren van betrouwbaarheid wordt gebruik gemaakt van voorzieningen in HL7v3. SOAP-voorzieningen worden hiervoor niet gebruikt.

BTP·b06

Voor het realiseren van beveiliging wordt gebruik gemaakt van het WS-I Basic Security profile. Dit is een toepassingsrichtlijn voor de standaarden XMLEncryption en XML-Signature.

.

44 van 150


De onderstaande figuur toont hoe een HL7v3-bericht wordt ingepakt in een SOAPenvelop. HTTP header SOAP envelope SOAP header SOAP body HL7v3 message

Voor de manier waarop een HL7v3-interactie wordt gebonden op een HTTP/SOAPinteractie zijn er enkele keuzes te maken. Die keuzes worden ingeleid in de navolgende paragrafen en verder uitgewerkt in de [HL7v3 WSP]. Opmerkingen: • De keuze voor Web Services Profile is in 2003 gemaakt, omdat grote Amerikaanse softwareleveranciers zich toen richtten op WS-I ten koste van ebXML en omdat ebMS verregaande SOAP-functies bood, die overlappen met de transportfuncties die HL7v3 reeds bood. • In principe zullen alle GBZ’en voor een bepaalde HL7v3-interactie dezelfde WSDL hebben, behalve de URI. De ZIM-beheerder kan ieder kandidaat-GBZ een WSDLtemplate toesturen, die na invulling van de URI kan worden teruggestuurd als onderdeel van het contract. Publicatie van de WSDL in een UDDI is niet nodig, omdat alle GBZ’en uitsluitend via de ZIM communiceren met andere systemen. De ZIM houdt bij welke HL7v3-interacties ieder GBZ ondersteunt. • Bijlage B probeert op vereenvoudigde wijze inzichtelijk te maken hoe HL7v3, SOAP en HTTP zich tot elkaar verhouden in de concrete gevallen van opvragen en versturen van patiëntgegevens. • Bij gebruik van tokens voor authenticatie van de zorgverlener/medewerker wordt de SOAP-header gebruikt om tokens door te geven. Dat onderwerp wordt in hoofdstuk 7 behandeld.


45 van 150

5.2

Indirect versturen

Als gevolg van de architectuurbeslissingen in paragraaf 4.2 zal één HL7v3-opdracht altijd leiden tot één HL7v3-bevestiging. Dit biedt de keuzevrijheid om de HL7v3-opdracht en de HL7v3-bevestiging te binden op één paar van HTTP/SOAP-request en HTTP/SOAPrespons (enkelvoudige binding), zie onderstaande figuur,

:opdracht gever

:GBZ1

:ZIM

: GBZ2

:opdracht nemer

opdracht HTTP req (SOAP req (HL7 order req)) HTTP req (SOAP req (HL7 order req)) HTTP rsp (SOAP rsp (HL7 accept ack)) presentatie bevestiging

HTTP rsp (SOAP rsp (HL7 accept ack))

of op afzonderlijke paren (tweevoudige binding), zie onderstaande figuur.

:opdracht gever

:GBZ1

:ZIM

: GBZ2

:opdracht nemer

opdracht HTTP req (SOAP req (HL7 order req)) HTTP req (SOAP req (HL7 order req)) HTTP rsp (status) HTTP rsp (status) HTTP req (SOAP req (HL7 accept ack)) HTTP req (SOAP req (HL7 accept ack)) HTTP rsp (status) presentatie bevestiging

HTTP rsp (status)

In andere gevallen bestaat die keuzevrijheid niet en moet de HL7v3-interactie altijd worden gebonden op afzonderlijke paren van HTTP/SOAP-request en HTTP/SOAP-respons (tweevoudige binding). Die andere gevallen worden door de ZIM momenteel niet ondersteund. Wezenlijk verschil tussen de enkelvoudige en de tweevoudige binding is dat de laatste op HTTP-niveau extra ontvangstbevestigingen toevoegt, met meer mogelijkheden voor automatisch hernieuwde pogingen tot versturen. De tweevoudige binding vergt evenwel dat het versturende GBZ niet zich te beperken tot HTTP-client maar ook als HTTP-server moet kunnen fungeren. Voor het ontvangende GBZ geldt het omgekeerde.

46 van 150


Uit hoofdstuk 11 over betrouwbaarheid zal blijken: • geen van beide bindingen biedt 100% garantie dat een HL7v3-opdrachtbericht precies 1 keer wordt afgeleverd, • met de voorgeschreven foutafhandeling zijn beide bindingen voldoende betrouwbaar voor het versturen van HL7v3-opdrachtberichten, • in geval dat de communicatie probleemloos verloopt is de enkelvoudige binding doelmatiger, - in geval van communicatieproblemen is de tweevoudige binding doelmatiger, - aldus geeft de tweevoudige binding iets meer betrouwbaarheid, maar wel tegen de prijs van hogere systeem- en netwerkbelasting. Het hangt wellicht af van de toepassing en van de betrouwbaarheid van de verbindingen, welke HTTP/SOAP-binding de voorkeur heeft. Voor WEL onmiddellijk afleveren ligt enkelvoudige binding meer voor de hand, voor NIET onmiddellijk afleveren eerder de tweevoudige binding wegens de ruimere mogelijkheden voor automatisch hernieuwde pogingen, maar die optie wordt momenteel nog niet ondersteund. Omdat het beter is de reguliere gevallen te optimaliseren dan de uitzonderingsgevallen, heeft naar de huidige inzichten de enkelvoudige binding de voorkeur. Architectuurbeslissingen: BTP·b04

Voor het interactiemechanisme indirect versturen wordt een HL7v3-opdracht en bijbehorende HL7v3-bevestiging enkelvoudig gebonden op één paar van HTTP/SOAP-request en HTTP/SOAP-response.


47 van 150

5.3

Indirect opvragen

Als gevolg van de architectuurbeslissingen in paragraaf 4.3, zal één HL7v3-opvraag altijd leiden tot één HL7v3-oplevering (al of niet gebundeld). Dit biedt de keuzevrijheid om deze interactie te binden op één paar van HTTP/SOAP-request en HTTP/SOAP-respons (enkelvoudige binding), zie onderstaande figuur,

:gegevens opvrager

:GBZ0

:ZIM

: GBZx

:gegevens houder

opvraag HTTP req (SOAP req (HL7 query req)) [voor elke GBZx vermeld in verwijsindex] HTTP req (SOAP req (HL7 query req)) HTTP rsp (SOAP rsp (HL7 query rsp)) presentatie resultaten

HTTP rsp (SOAP rsp (HL7 query rsp))

of op afzonderlijke paren (Tweevoudige binding), zie onderstaande figuur.

:gegevens opvrager

:GBZ0

:ZIM

: GBZx

:gegevens houder

opvraag HTTP req (SOAP req (HL7 query req)) [voor elke GBZx vermeld in verwijsindex] HTTP rsp (status)

HTTP req (SOAP req (HL7 query req)) HTTP rsp (status) HTTP req (SOAP req (HL7 query rsp)) HTTP rsp (status)

HTTP req (SOAP req (HL7 query rsp)) presentatie resultaten

HTTP rsp (status)

Voordeel van de enkelvoudige binding is het zuinigere gebruik van systeem- en netwerkcapaciteit, doordat de helft van het aantal HTTP-berichten wordt uitgewisseld, met vermoedelijk een snellere responstijd als resultaat. Een ogenschijnlijk nadeel van de enkelvoudige binding is dat de afhandeling van de opvraagsessie minder betrouwbaar is. Echter, anders dan bij het versturen heeft het opvragen minder betrouwbaarheid nodig, zolang de gegevensopvrager duidelijkheid krijgt dat tijdens de opvraagsessie iets misgegaan is. Evenzo hoeft een HL7v3-opvraagbericht nooit persistent gemaakt te

48 van 150


worden, zolang de gegevensopvrager maar wordt geïnformeerd indien een opvraagsessie wordt onderbroken. Hij kan dan beter opnieuw de opvraag doen. Immers, als de gegevensopvrager merkt dat hij niet alle antwoorden heeft ontvangen, kan hij de gewenste gegevens gewoon opnieuw opvragen. Nadeel daarvan is de ondoelmatige belasting van de ZIM en de opleverende GBZ’en. Stel, de ZIM heeft tijdens een opvraagsessie alle antwoorden verzameld uit de opleverende GBZ’en. Vervolgens gaat er iets mis bij het afleveren van deze antwoorden aan het opvragende GBZ. Als de gegevensopvrager besluit de opvraagsessie te annuleren en opnieuw dezelfde gegevens op te vragen, moet de ZIM gegevens opvragen die hij reeds had klaar staan! Omdat het beter is de reguliere gevallen te optimaliseren dan de uitzonderingsgevallen, heeft naar de huidige inzichten de enkelvoudige binding de voorkeur. Architectuurbeslissingen: BTP·b05

Voor het interactiemechanisme indirect opvragen wordt een HL7v3-opvraag en bijbehorende HL7v3-oplevering enkelvoudig gebonden op één paar van HTTP/SOAP-request en HTTP/SOAP-response.


49 van 150

5.4

Beheeroverdracht

Eén overdrachtVerzoek (HL7-request-change-of-custodian) zal altijd leiden tot één bevestiging (HL7-accept-ack). Dit geldt ook voor beide soorten overdrachtAntwoord (HL7-accept-custodianship en HL7-reject-custodianship). Dit betekent dat ieder van deze HL7-interacties afzonderlijk kan worden gebonden op één paar van HTTP/SOAP-request en HTTP/SOAP-respons (enkelvoudige binding), zie onderstaande figuur:


:GBZ1

:ZIM

: GBZ2


overdracht Verzoek HTTP req (SOAP req (HL7-request-cust)) HTTP req (SOAP req (HL7-request-cust))

HTTP rsp (SOAP rsp (HL7-acc-ack)) HTTP rsp (SOAP rsp (HL7-acc-ack)) HTTP req (SOAP req (HL7-accept-cust))

overdracht Aanvaarding

HTTP req (SOAP req (HL7-accept-cust))

HTTP rsp (SOAP rsp (HL7-acc-ack)) HTTP rsp (SOAP rsp (HL7-acc-ack))

HTTP req (SOAP req (HL7-reject-cust))

overdracht Afwijzing


HTTP rsp (SOAP rsp (HL7-acc-ack)) HTTP rsp (SOAP rsp (HL7-acc-ack))

Zie verder de overwegingen genoemd in paragraaf 5.2.

50 van 150


Een intrekkingVerzoek (HL7-cancel-change-of-custodian-request) zal daarentegen onmiddellijk leiden tot een intrekkingAntwoord (HL7-accept-cancellation-of-change-ofcustodian-request or HL7-reject-cancellation-of-change-of-custodian-request). Aldus kunnen deze HL7-interacties gezamenlijk worden gebonden op één paar van HTTP/SOAPrequest en HTTP/SOAP-respons, zie onderstaande figuur: intrekking Verzoek HTTP req (SOAP req (HL7-canc-…-req))

HTTP rsp (SOAP rsp (HL7-acc-canc-… OF HL7-rej-canc-…)) HTTP req (SOAP req (HL7-canc-...-notif))

HTTP rsp (SOAP rsp (HL7-acc-ack))


HTTP req (SOAP req (HL7-canc-…-notif))



Architectuurbeslissingen: BTP·b06

Een overdrachtverzoek, een overdrachtantwoord en een intrekkingkennsigeving worden ieder afzonderlijk gebonden op één paar van HTTP/SOAP-request en HTTP/SOAP-response.

BTP·b06

Een intrekkingverzoek en een intrekkingantwoord worden gezamenlijk gebonden op één paar van HTTP/SOAP-request en HTTP/SOAP-response.


51 van 150

6

Connectiviteit (CNV)

Voor de HL7v3-berichtuitwisseling tussen GBZ en ZIM via een DCN is reeds gekozen voor internetprotocollen: HTTP, TCP, IP, zie [Architectuurvisie]. Connectiviteit wordt hier uitgewerkt op de volgende niveaus: • netwerkniveau: IP-koppelingen tussen een GBZ en de ZIM, tussen GBZ’en buiten de ZIM om, resp. tussen een GBZ en de CA’s. • applicatieniveau: aansluitingen van specifieke applicaties binnen een GBZ op specifieke schakelpunten binnen de ZIM.

6.1

IP-koppeling tussen GBZ en ZIM

Ieder GBZ wordt via een DCN aangesloten op de ZIM en krijgt daartoe een IP-adres toegekend door de ZSP die dat DCN beheert. Iedere ZSP krijgt daartoe een IPadresreeks van het LSP toegewezen. Een GBZ kan op diens interne netwerk vele andere IP-adressen gebruiken of andere netwerkprotocollen en adresseringswijzen toepassen, maar naar het LSP moet het GBZ zich altijd manifesteren met het toegekende IP-adres. In dergelijke gevallen zal het GBZ op het koppelvlak met het DCN een adresconversie moeten uitvoeren die overeenkomt met de eigen netwerkprotocollen en adresseringswijzen. Afhankelijk van de netwerkinrichting kunnen sommige GBZ’en volstaan met een vorm van netwerkadresvertaling (NAT), al of niet gecombineerd met een vorm van tunneling, zie de onderstaande figuur. Ook ZSP’s kunnen op hun DCN andere netwerkprotocollen en adresseringswijzen toepassen. In dat geval zal de ZSP een dergelijke adresconversie moeten uitvoeren op het koppelvlak met het LSP en misschien ook op de koppelvlakken met de aangesloten GBZ’en.

LSP ZIM secnd DNS

ZSP prim DNS

NAT ZSP

DCN NAT

GBZ

52 van 150

GBZ

prim DNS

DCN NAT

NAT

NAT

GBZ

GBZ

GBZ

GBZ


Daarnaast moet ieder GBZ een hostnaam hebben, opdat de ZSP netwerkaansluitingen kan onderhouden zonder dat andere partijen hoeven te worden ingelicht als een IP-adres is gewijzigd. Deze hostnamen kunnen worden gebruikt door systemen die met het GBZ communiceren: de ZIM, maar ook andere GBZ’en die rechtstreeks met deze GBZ willen communiceren, zie paragraaf 6.3. In de configuratietabel van de ZIM kan van iedere GBZ de URI worden vastgelegd, zie [Informatiesysteemarchitectuur] paragraaf 4.18). Bovendien kunnen de hostnamen worden vermeld als FQDN op de UZI-servercertificaten van die systemen en kunnen ze worden verwerkt in de webservice-namen. Het UZIregister eist echter dat de FQDN kan worden getoetst bij SIDN of bij het LSP als behorende toe aan de zorgaanbieder. Daartoe registreert het LSP hostnamen onder het domein AORTA-ZORG.NL. Zie echter ook paragraaf 6.5. Om hostnamen te kunnen vertalen naar IP-adressen is een DNS-dienst nodig. Deze zou zowel door het LSP als door iedere ZSP afzonderlijk kunnen worden geleverd. De laatste optie betekent een DNS-server met bijbehorende beheerinspanning per ZSP, maar heeft toch de voorkeur wegens de betere flexibiliteit en onderhoudbaarheid van hostnamen. Om ZSP’s niet onnodig op kosten te jagen, kan het LSP ten behoeve van de beschikbaarheid een gemeenschappelijke secundaire DNS-server inrichten voor alle primaire DNS-servers, zie de bovenstaande figuur. In geval van een ASP die meerdere zorgaanbieders bedient, zie paragraaf 7.7, zullen de afzonderlijke domeinen per zorgaanbieder ieder een eigen hostnaam kunnen krijgen, opdat zij afzonderlijk als GBZ kunnen worden geadresseerd en geconfigureerd in de ZIM. Overigens staat AORTA een ASP-dienstverlener toe om al die hostnamen naar één en dezelfde IP-adres te laten wijzen. Tot dusver is het gemakkelijker gebleken om voor ieder GBZ toch een apart IP-adres te nemen. Zoals beschreven in hoofdstuk 8, komt er een operationele ZIM een test-ZIM. Een GBZ moet van elk de hostnaam geconfigureerd hebben, want: • een GBZ kan meerdere applicaties bevatten waarvan de ene reeds operationeel is en de andere nog wordt getest. Iedere ZIM zal in principe alle operationele GBZ’en hebben geconfigureerd. De test-ZIM zal daarnaast ook zorgsystemen hebben geconfigureerd die nog bezig zijn een GBZstatus te verkrijgen. Iedere ZIM kan een geconfigureerde GBZ daarnaast openstellen of blokkeren. Zo kan een zorgsysteem dat zijn GBZ-status verliest, bijv. wegens ernstige gebreken, door de operationele ZIM tijdelijk worden geblokkeerd, zonder de configuratie geheel te verwijderen. Openstaande punten: • Momenteel wordt door Nicitz onderzocht of ZSP’s naast (of in plaats van) private ook publieke IP-adresreeksen toegewezen kunnen krijgen. Idealiter zou een ZSP zelf mogen kiezen tussen een publieke of private IP-adresreeks ten behoeve van de aangesloten of aan te sluiten GBZ’en. Daarvan is ook afhankelijk waar de hostnaam van een GBZ geregistreerd moet worden.


53 van 150

6.2

Aansluiting van applicatie op schakelpunt

Een GBZ kan meerdere zorgapplicaties bevatten die afzonderlijk kunnen worden aangesloten. Iedere applicatie krijgt een applicatie-id toegewezen door het LSP. In geval van een ASP die meerdere zorgaanbieders bedient, zie paragraaf 7.7, zullen de afzonderlijke domeinen per zorgaanbieder een eigen applicatie-id krijgen, opdat zij afzonderlijk als GBZ kunnen worden geadresseerd en aangesloten op de ZIM. Evenzo kan een ZIM bestaan uit meerdere schakelpunten, uit oogpunt van schaalbaarheid, zie hoofdstuk 9. Ook deze schakelpunten krijgen ieder een applicatie-id toegewezen. Aldus wordt iedere zorgapplicatie aangesloten op een schakelpunt, niet alleen van de operationele ZIM, maar een test-ZIM. Zo’n aansluiting wordt geconfigureerd door elkaars applicatie-id op te nemen. Afhankelijk van de koppeltoestand (test of operationeel) van de applicatie, zal het één van de schakelpunten gebruiken voor de uitwisseling van HL7v3-berichten. Merk op dat een GBZ meerdere applicaties kan bevatten waarvan de ene reeds operationeel is en de andere nog wordt getest, zie paragraaf 8.2. De applicatie-id’s worden gebruikt in de Transmission Wrapper van HL7v3-berichten om afzender en bestemming aan te duiden. De onderstaande figuur toont de relaties tussen een GBZ met alle zorgapplicaties en het LSP met de drie ZIM’s en alle schakelpunten in een UML class diagram.

Operationele ZIM

GBZ GBZ IP-adres

1

heeft koppeling met >

Test ZIM

1..3

* Applicatie Applicatie Applicatie-id

* 1

Koppeltoestand 1

54 van 150

ZIM ZIM IP-adres

heeft aansluiting met > wisselt HL7-berichten uit met >

1..3 1

Schakelpunt Schakel Applicatie-id punt


6.3

IP-koppeling tussen GBZ’en

Binnen één DCN kunnen de aangesloten GBZ’en ook rechtstreeks gegevens uitwisselen, bijv. multimediale bestanden m.b.v. DICOM. Als GBZ’en op een verschillend DCN met verschillende VPN-technieken zijn aangesloten, is IP-verkeer niet zo maar mogelijk. Om de zogenaamde interconnectiviteit tussen verschillende DCN’en mogelijk te maken, heeft het LSP een RouteerFunctie (RF) nodig, zie de onderstaande figuur. Deze RF dient alle DCN’en te koppelen op basis van statische routering, met floating static routing voor redundante routes. Op termijn zal de RF naar verwachting de routeringsprotocollen OSPF en IS-IS dienen te ondersteunen.

LSP ZIM RF

DNS

ZSP

ZSP DCN

DNS NAT

GBZ

GBZ

DCN NAT

NAT

NAT

GBZ

GBZ

GBZ

DNS

GBZ

Binnen DCN’s dient gebruik te worden gemaakt van unieke domeinnamen, die passen in een door ieder ZSP te beheren naamruimte. Daartoe dient een ZSP een DNS-dienst te leveren aan de op diens DCN’s aangesloten systemen. Voor tijdsynchronisatie dient het Network Time Protocol (NTP) te worden gebruikt, waarbij de ZIM een NTP-server onderhoudt en de GBZ’en als NTP-clients optreden.


55 van 150

6.4

IP-koppeling tussen GBZ en CA’s

Volgens PKI Overheid (PKIO) moet men van andermans PKI-certificaten controleren of deze niet zijn ingetrokken, door het raadplegen van de CRL die wordt gepubliceerd door de CA die de desbetreffende PKI-certificaten heeft uitgegeven. Bij de berichtuitwisseling tussen de ZIM en alle aangesloten GBZ’en speelt de ZIM steeds een centrale rol door de GBZ-gebruikers dan wel hun GBZ te authenticeren aan de hand van UZI-certificaten, zie paragraaf 7.1. GBZ’en hoeven dan alleen de ZIM te vertrouwen, na authenticatie van de ZIM aan de hand van diens ZIM-certificaat. Dit betekent dat: • de ZIM regelmatig een CRL moet ophalen van het UZI-register, de CA die alle UZIcertificaten uitgeeft, • alle aangesloten GBZ’en regelmatig een CRL moet ophalen van de CA die het ZIMcertificaat uitgeeft (momenteel DigiNotar). Daarnaast zal een GBZ in de volgende gevallen ook een CRL van het UZI-register moeten ophalen: • wanneer zorgverleners lokaal inloggen op een GBZ met hun UZI-pas, zoals onder meer nodig is voor het bijhouden van mandateringen. • {toekomst} wanneer GBZ'en buiten het LSP om berichten gaan uitwisselen, zoals nodig is voor de overdracht van grote bestanden. • {toekomst} wanneer GBZ'en straks elektronische handtekeningen gaan gebruiken voor ondertekenen van HL7v3-berichten. Tenslotte moet zowel de ZIM als een GBZ volgens PKIO ook de PKI-certificaten van die CA’s controleren op intrekking, door de CRL van hun CA op te halen. Dit gaat zo door voor alle bovenliggende CA’s tot aan de root van de Staat der Nederlanden, zie [UZI]. Al deze CA’s publiceren hun CRL op een locatie die bereikbaar is via het publieke internet. GBZ’en zijn echter via een privaat DCN van een ZSP gekoppeld aan de ZIM en andere GBZ’en. Dus zou iedere GBZ of iedere ZSP ook nog een eigen opening naar het publieke internet moeten maken. Dit vereist de nodige investeringen in de beveiliging: firewall, intrusion detection, etc. Om te voorkomen dat iedere GBZ of iedere ZSP op kosten wordt gejaagd, is het voorlopig beter dat de RouteerFunctie (RF) van het LSP een gemeenschappelijke, centrale opening biedt voor alle op de ZIM aangesloten GBZ’en. De ZIM heeft voor toegang tot de SBV-Z bovendien toch al een IP-koppeling via het publieke internet. Om te voorkomen dat GBZ’en de opening misbruiken voor willekeurige toegang tot het publieke internet, kan de RF het gebruik beperken tot de genoemde CA’s en het ophalen van een CRL.

56 van 150


Architectuurbeslissingen: CNV·b01

De RouteerFunctie (RF) moet alle op de ZIM aangesloten GBZ’en de mogelijkheid bieden om de bovengenoemde CA’s te bereiken voor het ophalen van een CRL.

Opdat een GBZ een LDAP-request naar het UZI-register resp. de CA van het ZIMcertificaat kan sturen, op basis van de URL in een UZI-certificaat resp. ZIM-certificaat, is het nodig dat de DNS-servers van de ZSP’s de URL’s van de CA’s vertalen naar een privaat IP-adres dat vervolgens door de RF door middel van NAT vertaald kan worden naar een IP-adres op het publieke internet. Tenslotte moet de RF bij die NAT-vertaling ervoor zorgen dat de LDAP-response weer netjes terugkomt bij de oorspronkelijke GBZ, zie de onderstaande figuur.

CA

CIBG

CA register

UZI register

SBV-Z

Publieke internet LSP ZIM RF

DNS NAT ZSP

ZSP DCN

DNS NAT

GBZ

GBZ

DCN NAT

NAT

NAT

GBZ

GBZ

GBZ

DNS

GBZ

Mocht op termijn blijken dat de capaciteit die de RF hiervoor kan bieden te klein is, dan kunnen ZSP’s wellicht in de toekomst aanvullende capaciteit bieden door ook een opening naar de CA’s via het publieke internet te bieden, voorzover zij dat niet reeds doen.


57 van 150

6.5

IP-koppeling tussen GBZ en SBV-Z

Veel zorgaanbieders zijn momenteel slechts aangesloten op een DCN en gebruiken daarbij een FQDN die niet is geregistreerd bij SIDN, omdat weinig of geen gebruik wordt gemaakt van het openbare internet. Echter, in het kader van de Wbsn-z moet iedere zorgaanbieder de SBV-Z kunnen benaderen om het BSN te kunnen gebruiken. Dat kan rechtstreeks via het openbare internet of via het LSP, behalve dat bestandsgewijze uitwisseling van gegevens niet via het LSP kan geschieden. Om de SBV-Z via het LSP te kunnen benaderen, moet de zorgaanbieder zijn systeem als GBZ aansluiten op het LSP. Dat vergt naast de GBZ-kwalificatie ook de aanvraag van UZI-passen en een UZI-servercertificaat om zich te kunnen authenticeren aan het LSP. De meeste zorgaanbieders zijn nog niet zo ver. Om de SBV-Z rechtstreeks via het openbare internet te kunnen benaderen, moet de zorgaanbieder zich tenminste kunnen authenticeren aan de SBV-Z met behulp van een UZI-servercertificaat. Daarvoor moet de zorgaanbieder een UZI-servercertificaat aanvragen bij het UZI-register, onder opgave van een FQDN die is geregistreerd bij SIDN als toebehorend aan de zorgaanbieder. Een zorgaanbieder die later alsnog wil aansluiten op het LSP, zou dan opnieuw een UZIservercertificaat moeten aanvragen bij het UZI-register, ditmaal onder opgave van een FQDN binnen het domein aorta-zorg.nl geregistreerd bij het LSP, zie paragraaf 6.1. Dit zou betekenen dat één GBZ dan twee UZI-servercertificaten moet hebben. Dezelfde problematiek geldt ook als een zorgaanbieder eerst aansluit op het LSP en later de SBV-Z rechtstreeks wil benaderen. Om ervoor te zorgen dat een zorgaanbieder kan volstaan met één UZI-servercertificaat voor zowel het benaderen van de SBV-Z als voor het aansluiten op het LSP, zijn onder meer de volgende oplossingsrichtingen overwogen door Nicitz, het UZI-register en de SBV-Z in overleg met zorgpartijen: • alle zorgaanbieders gebruik laten maken van UZI-passen in plaats van een UZIservercertificaat voor het benaderen van de SBV-Z. Deze oplossing is echter weinig realistisch gezien de enorme uitrol van UZI-passen die dan nodig is tijdens de invoering van het BSN in de zorg. • mogelijk maken dat het UZI-register een UZI-servercertificaat kan uitgeven met een FQDN niet onder aorta-zorg.nl, dat wordt geregistreerd bij het LSP. Deze oplossing is echter niet aanvaardbaar voor het UZI-register. • mogelijk maken dat de SBV-Z een UZI-servercertificaat accepteert met een FQDN binnen het domein aorta-zorg.nl geregistreerd bij het LSP. Deze oplossing is echter niet aanvaardbaar voor de SBV-Z. • mogelijk maken dat het LSP een UZI-servercertificaat accepteert met een FQDN geregistreerd bij SIDN. Nadeel van deze oplossing is dat het LSP bij de authenticatie van een GBZ dan niet redelijkerwijs kan controleren of het netwerkadres van het systeem waarmee het LSP communiceert klopt met de FQDN die bij het LSP bekend was voor dat GBZ.

58 van 150


Uiteindelijk is gekozen voor de laatste oplossingsrichting, waarbij het nadeel is ondervangen door de controle van het netwerkadres achterwege te laten. Dit is aanvaardbaar omdat bij de authenticatie van een GBZ voornamelijk moet worden geverifieerd dat het LSP communiceert met een systeem dat staat onder verantwoordelijkheid van de zorgaanbieder die die bij het LSP bekend was als verantwoordelijk voor dat GBZ. Het LSP kan dat verifiëren aan de hand van het UZIabonnee-nummer vermeld op het UZI-servercertificaat.

6.6

Koppeling tussen GBZ en webportaal

Al met al zijn er verschillende actoren rondom het beheer van GBZ-applicaties. Zo houdt de kwalificatiebeheerder bij welke XIS’en en GBZ’en gekwalificeerd zijn. De GBZbeheerder kan met zijn gekwalificeerde applicatie met geïmplementeerde berichten zelf GBZ-applicaties via het verturen van een bericht naar de ZIM aansluiten of (de)activeren. Hij zou deze beheeractiviteiten ook via een webportaal van het LSP of leverancier/ASP kunnen doen. Het is een keuzepallet dat geüniformeerd is richting het LSP op basis van de berichten. Hiervoor is wel authenticatie op basis van een UZI-servercertificaat of PKIoverheidcertificaat noodzakelijk. UZI-servercertificaat PKI-Overheidcertificaat

LSP VWI

ZIM

I&A

AUT

SCH

LOG

Appl. tabel

XIS kwal

GBZ kwal

aansluit/ (de)activatie web portaal bericht LSP Kwalificatie apl.beheer beheerder beheerder

Zorgaanbieder 3 Zorgaanbieder 1 GBZ1

aansluit/ (de)activatie berichten

GBZ3 browser

XIS zorg GBZ verlener beheerder

XIS

zorg GBZ verlener beheerder

ASP web portaal

Zorgaanbieder 2 GBZ2 zorg GBZ XIS verlener beheerder

browser

apl.beheer

XIS-leverancier web portaal apl.beheer

XIS ontwikkelaar

GBZ GBZ GBZ XIS

XIS XIS

ASP beheerder

In de figuur hierboven sluit zorgaanbieder 1 zijn GBZ-applicatie (XIS) eenmalig aan door middel van een bericht direct naar de ZIM en kan later ook zijn GBZ-applicatie (de)activeren met een bericht.


59 van 150

Zorgaanbieder 2 logt in op het webportaal van zijn XIS-leverancier om handmatig zijn GBZ-applicatie te beheren. Maar zou ook zijn XIS-leverancier dit voor hem laten kunnen doen. Zorgaanbieder 3 doet hetzelfde alleen dan via het applicatiebeheerportaal van het LSP. De ASP-leverancier (de ASP-beheerder is in feite de GBZ-beheerder) kan GBZ-applicaties via het UZI-servercertifaat beheren via berichtuitwisseling, via een eigen webportaal (met een PKI-overheidcertificaat) en natuurlijk ook nog via het LSP-webportaal.

60 van 150


7

Beveiliging (BVL)

7.1

Inleiding

Voor de beveiliging van de landelijke uitwisseling van patiëntgegevens zijn de volgende zaken van belang: • beveiliging tussen GBZ-gebruikers en GBZ-applicaties • beveiliging tussen GBZ-applicaties en de ZIM, • beveiliging tussen GBZ-gebruikers en de ZIM, • beveiliging tussen GBZ-dossiers/postbussen en de ZIM, • beveiliging tussen registers en de ZIM, • interne beveiliging GBZ, inclusief lokaal inloggen, • interne beveiliging ZIM. Voor de beveiliging van de communicatie tussen GBZ en ZIM is reeds een aantal keuzes gemaakt, zie [Architectuurvisie]: • als vertrouwensmiddel maken zorgverleners en hun systemen gebruik van UZI-passen respectievelijk UZI-servercertificaten. • De uitwisseling van patiëntgegevens tussen systemen wordt beveiligd op transportniveau met SSL/TLS en VPN en/of op berichtniveau met XML-encryption en XML-signature. • De toegang van personen tot patiëntgegevens wordt beveiligd op persoonlijk niveau met hard-tokens, uitgegeven volgens PKI. Zoals beschreven in [Bedrijfsarchitectuur] paragraaf 11.6, kunnen deze verschillende technieken worden geprojecteerd op de volgende vertrouwensniveaus, zoals vereist voor de landelijke uitwisseling van patiëntgegevens, afhankelijk van de instelling in het autorisatieprotocol, zie [Informatiesysteemarchitectuur] paragraaf 4.12: • {toekomst} voor vertrouwensniveau hoog: versleuteling en elektronische handtekening op berichtniveau via XML-encryption en XML-signature, met behulp van de sleutels van persoonlijke UZI-passen. • voor vertrouwensniveau midden: versleuteling op transportniveau via SSL/TLS en naar keuze: - authenticatie op transportniveau via dezelfde SSL/TLS, - authenticatie op berichtniveau via een token gemaakt met XML-signature met behulp van de sleutels van persoonlijke UZI-passen en/of UZI-servercertificaten. • voor vertrouwensniveau laag: versleuteling en authenticatie op netwerkniveau door aansluiting van het GBZ op een VPN met bijv. IPsec of SSL/TLS met behulp van de sleutels van UZI-servercertificaten of UZI-pas niet op naam. De [Bedrijfsarchitectuur] geeft in een bijlage A een overzicht van hoe deze technieken kunnen worden ingezet in de verschillende scenario’s op de verschillende vertrouwensniveaus.


61 van 150

7.1.1 Vertrouwensniveau laag Op vertrouwensniveau laag wordt de authenticatie van afzonderlijke zorgverleners en medewerkers overgelaten aan ieder GBZ. De rol van de ZIM beperkt zich dan tot de authenticatie van ieder GBZ, dus op instellingsniveau. De onderstaande figuur toont hoe dit vertrouwensniveau laag wordt gerealiseerd, bij het opvragen van het BSN uit de SBV-Z en bij het opvragen uit het zorgadresboek. De ZIM bewaakt hier slechts een deel van de keten. Dit is voldoende voor de volgende gebruiksscenario’s van een zorgverlener: • gebruiksscenario [SPA] identificeren patiënt/cliënt, • gebruiksscenario [SZA.s01] opzoeken zorgaanbieder in het zorgadresboek, • gebruiksscenario [SZA.s02] opvragen bereikbaarheidsgegevens uit de zorgadresboek. {toekomst} Dit speelt ook bij de volgende gebruiksscenario’s van een beheerder: • gebruiksscenario [ASL.s01] aangesloten applicatie op schakelpunt activeren, • gebruiksscenario [ASL.s03] aangesloten applicatie op schakelpunt deactiveren. In deze keten zijn de volgende verschillende schakels te herkennen, die afzonderlijk worden uitgewerkt in de volgende paragrafen: • beveiliging tussen GBZ-applicatie en ZIM, • beveiliging tussen registers en ZIM.

Zorg aanbieder

HL7verzoekbericht

applicatie

HL7verzoekbericht

ZIM-platform

GBZ-platform Zorg verlener

LSP

SSL-verbinding

UZI-cert

schakel punt

Register-platform SSL-verbinding

SSL-cert HL7antwoordbericht

Register beheerder

applicatie

SSL-cert

register

HL7antwoordbericht

Om de beveiligingsketen op vertrouwensniveau laag gesloten te houden, moet worden voorkomen dat een willekeurige persoon binnen de zorgaanbieder de registers benadert. Hoe dat wordt gerealiseerd, bijv. met lokaal inloggen met gebruikersnaam/wachtwoord, is de eigen verantwoordelijkheid van de zorgaanbieder.

7.1.2 Vertrouwensniveau midden Op vertrouwensniveau midden speelt de ZIM een centrale rol bij de authenticatie van zorgverleners, medewerkers en hun systemen. Immers, de ZIM authenticeert voor dit vertrouwensniveau zelfstandig alle aangesloten partijen op persoonlijk niveau, waardoor de aangesloten partijen elkaar onderling niet hoeven te authenticeren. Daarbij is het belangrijk dat de ZIM zichzelf kan authenticeren aan de aangesloten partijen, met een systeemgebonden vertrouwensmiddel uitgegeven door een CA conform de richtlijnen van PKI-Overheid. Dit komt neer op een servercertificaat, dat gezien de toepassing ook wel SSL/TLS-certificaat wordt genoemd.

62 van 150


De onderstaande figuren tonen hoe dit vertrouwensniveau midden wordt gerealiseerd bij het uitwisselen van patiëntgegevens, doordat de ZIM de gehele keten bewaakt van GBZgebruiker via de agerende GBZ-applicatie, via de ZIM naar de GBZ-applicatie die de dossiers en postbussen ontsluit. Dit is nodig voor de volgende gebruiksscenario’s van een zorgverlener: • gebruiksscenario [PUB] publiceren patiëntgegevens, • gebruiksscenario [OPV] opvragen patiëntgegevens, • gebruiksscenario [STU] versturen patiëntgegevens, • gebruiksscenario [OVD] overdragen patiëntgegevens, • gebruiksscenario [SZA.s03] bijwerken zorgadresboek. In deze keten zijn de volgende verschillende schakels te herkennen, die afzonderlijk worden uitgewerkt in de volgende paragrafen: • beveiliging tussen GBZ-gebruikers en GBZ-applicaties • beveiliging tussen GBZ-applicaties en ZIM • beveiliging tussen GBZ-gebruikers en ZIM, • beveiliging tussen GBZ-dossiers/postbussen en ZIM. Voor de realisatie van de eerste drie schakels in de beveiligingsketen is de keuze uit: • sessieauthenticatie; • tokenauthenticatie. Het toepassen van tokenauthenticatie is nieuw toegevoegd omdat: • sessieauthenticiatie moeilijk te implementeren bleek in een client/server-gebaseerde GBZ, • tokenauthenticatie noodzakelijk is indien het GBZ gastgebruik van UZI-passen wenst, (zie ook §3.4.). De volgende figuur toont in de situatie van sessieauthenticatie het uitwisselen van patiëntgegevens door de GBZ-gebruiker met de toepassing van: (lokale) authenticatie van de GBZ-gebruiker door de GBZ-applicatie met een UZI-pas. Hierbij stelt het GBZ vast dat de UZI-pas, waarvan de zorgaanbieder abonnee moet zijn, in het GBZ wordt toegelaten; (centrale) indirecte authenticatie van de GBZ-applicatie van de zorgaanbieder door de ZIM met een in de UZI-pas opgenomen netwerkadres; (centrale) authenticatie van zowel zorgaanbieder als GBZ-gebruiker door de ZIM met een UZI-pas.

Zorg aanbieder

HL7verzoekbericht

applicatie

UZIUZI-pas paslezer

HL7verzoekbericht

ZIM-platform

GBZ-platform Zorg verlener

LSP

SSL-sessie

schakel punt

GBZ-platform SSL-verbinding

SSL-cert HL7antwoordbericht

Zorg aanbieder

applicatie

UZI-cert

dossier `postbus

HL7antwoordbericht

De volgend figuur toont, in de situatie van tokenauthenticatie, het uitwisselen van patiëntgegevens door de GBZ-gebruiker met de toepassing van:


63 van 150

• (lokale) authenticatie van de GBZ-gebruiker door de GBZ-applicatie met een UZI-pas. Hierbij stelt het GBZ vast dat de UZI-pas, die mogelijk van een verschillende abonnee is, in het GBZ wordt toegelaten; • (centrale) authenticatie van de GBZ-applicatie van de zorgaanbieder door de ZIM met een UZI-servercertificaat; • (centrale) authenticatie van de zorgverlener/medewerker door de ZIM, met een, door middel van een UZI-pas getekend, token.

Zorg aanbieder

HL7Verzoekbericht

Zorg aanbieder

token

ZIM-platform

GBZ-platform Authen ticatie applicatie token

Zorg verlener

LSP

HL7verzoekbericht

GBZ-platform

schakel punt

applicatie

SSL-verbinding

SSL-verbinding

UZIUZI-paspaslezer

UZI-cert

HL7antwoordbericht

SSL-cert

UZI-cert

dossier `postbus

HL7antwoordbericht

Verschillende XIS-leveranciers kunnen ieder hun eigen keuze voor sessie- of tokenauthenticatie maken. Daarnaast kan een GBZ meerdere GBZ-applicaties van verschillende XIS-typen bevatten. Daarom moeten GBZ-applicaties binnen één GBZ verschillende wijzen van authenticatie kunnen toepassen. Architectuurbeslissing: BVL·b01

Voor iedere GBZ-applicatie moet worden ingesteld of met sessieauthenticatie danwel met tokenauthenticatie wordt geauthenticeerd. De ZIM bewaakt dat de GBZ-appicatie uitsluitend op de ingestelde wijze authenticeert.

Om de beveiligingsketen gesloten te houden op vertrouwensniveau midden, moet worden voorkomen dat patiëntgegevens die verkregen zijn door landelijk uitwisseling, vervolgens lokaal te gemakkelijk benaderd kunnen worden. Ook de toegang tot lokale tabellen die betrekking hebben op landelijke uitwisseling zijn gevoelig. {wens} Dit betekent dat zorgverleners/medewerkers voor de volgende gebruikscenario’s lokaal moeten inloggen met een UZI-pas: • gebruiksscenario [BIJ] bijhouden patiëntgegevens, • gebruiksscenario [STU.s02] ontvangen patiëntbericht, • gebruiksscenario [RLO] raadplegen toegangslog, • gebruiksscenario [BMD] bijhouden mandateringen. De onderstaande figuur toont het lokaal inloggen, dit wordt nader uitgewerkt in een volgende paragraaf.

64 van 150


Zorg aanbieder GBZ-platform Zorg verlener

applicatie applicatie applicatie

UZIUZI-pas paslezer

UZI-cert

dossier `postbus

In principe staat lokaal inloggen op een zorgapplicatie los van het inloggen (met toepassen van sessieauthenticatie) op de ZIM. Technisch gezien kunnen deze twee vormen van inloggen worden gecombineerd tot één gebruikershandeling. Maar dat is niet altijd verstandig wegens de korte time out op de gebruikerssessie met de ZIM, zie volgende paragraaf. Beter is het om een gebruiker eerst te laten inloggen op de zorgapplicatie voor zijn reguliere werkzaamheden. Daarbovenop kan hij nog eens inloggen op de ZIM voor de tijd dat dit nodig is. Een gebruiker hoeft dit niet te ervaren als inloggen, maar als een verzoek om zich opnieuw te authenticeren.

7.1.3 Combinatie van vertrouwensmiddelen in de beveiligingsketen Naar gelang de gebruikte combinatie van vertrouwensmiddelen wordt voor de beveiligingsketen het volgende vertrouwensniveau gerealiseerd: Vertrou wens niveau

Laag

Authenticatie van de GBZgebruiker door GBZapplicatie op basis van:

Authenticatie van de GBZ applicatie door ZIM op basis van:

Authenticatie van de GBZgebruiker door ZIM op basis van:

Gastgebruik mogelijkheid

Wachtwoord (zie 7.2.1)

UZI-server certificaat (zie 7.3.1)

Niet mogelijk (zie 7.4.1)

Niet van toepassing (zie 7.2.4)

UZI-pas niet op naam (zie 7.2.2)

UZI-server certificaat (zie 7.3.1)

Niet mogelijk (zie 7.4.1)

Nee (zie 7.2.4)

{toekomst} UZI-pas niet op naam (zie 7.2.2)

{toekomst} UZI-server certificaat (zie 7.3.1)

{toekomst} Tokenauthenti catie (zie 7.4.2)

{toekomst} Ja (zie 7.2.4)

UZI-pas niet op naam (zie 7.2.2) UZI-pas op naam

UZI-pas niet op naam (zie 7.3.3) UZI-server certificaat

Sessieauthent icatie (zie 7.4.3) Tokenauthenti catie

Nee (zie 7.2.4)


Ja (zie 7.2.4)

Vertrouwelijk heid uitwisseling GBZgebruiker met ZIM op basis van: UZIservercertifica at (zie 7.3.4) UZIservercertifica at (zie 7.3.4) {toekomst} UZIservercertifica at (zie 7.3.4) UZI-pas niet op naam (zie 7.3.4) UZIservercertifica

65 van 150

Midden

(zie 7.2.3)

(zie 7.3.1)

(zie 7.4.2)

UZI-pas op naam (zie 7.2.3)

UZI-pas op naam (zie 7.3.3)

Sessieauthent icatie (zie 7.4.3)

Nee (zie 7.2.4)

at (zie 7.3.4) UZI-pas op naam (zie 7.3.4)

Een gerealiseerd vertrouwensniveau midden volstaat tevens voor die gebruiksscenario’s waarvoor een vertrouwensniveau laag vereist is. Andere combinaties van vertrouwensmiddelen zijn niet toegestaan.

7.2 Beveiliging tussen GBZ-gebruikers en GBZapplicaties De volgende paragrafen gaan in op de authenticatie van de GBZ-gebruiker door de GBZapplicatie.

7.2.1 Authenticatie met wachtwoord De GBZ-applicatie kan een GBZ-gebruiker authenticeren door middel van een door de GBZ-gebruiker in te voeren wachtwoord. Een wachtwoord zal zijn uitgegeven onder verantwoordelijkheid van de zorginstellingverantwoordelijke, conform nader te bepalen richtlijnen. Het betreft een zwak authenticatiemiddel. Met dit vertrouwensmiddel wordt voor deze schakel in de keten vertrouwensniveau laag gerealiseerd.

7.2.2 Authenticatie met UZI-pas niet op naam De GBZ-applicatie kan een GBZ-gebruiker authenticeren door middel van een door de GBZ-gebruiker in te voeren UZI-pas niet op naam met PIN. Een UZI-pas niet op naam is een hardware-token met toegangscode (PIN), dat is uitgegeven door een TTP (het UZI-register), conform de richtlijnen van PKI-Overheid. Het betreft een sterk authenticatiemiddel wat wel de zorginstelling maar niet de persoon kan authenticeren. Met dit vertrouwensmiddel wordt voor deze schakel in de keten vertrouwensniveau laag gerealiseerd.

7.2.3 Authenticatie met UZI-pas op naam De GBZ-applicatie kan een GBZ-gebruiker authenticeren door middel van een door de GBZ-gebruiker in te voeren UZI-pas op naam met PIN. Een UZI-pas op naam is een hardware-token met toegangscode (PIN), dat is uitgegeven door een TTP (het UZI-register), conform de richtlijnen van PKI-Overheid. Het betreft

66 van 150


een sterk authenticatiemiddel wat zowel de zorginstelling en de persoon kan authenticeren. Met dit vertrouwensmiddel wordt voor deze schakel in de keten vertrouwensniveau midden gerealiseerd.

7.2.4 Authenticatie van gast-GBZ-gebruikers GBZ-gebruikers kunnen, indien zij beschikken over een UZI-pas waarvan de zorgaanbieder niet de abonnee is, door een GBZ-applicatie worden geauthenticeerd. Daarvoor moet zowel de zorgaanbieder als de abonnee door middel van tokenauthenticatie kunnen worden geauthenticeerd op basis van corresponderende vertrouwensmiddelen. Voor de zorgaanbieder betreft dat het UZI-servercertificaat. Voor de abonnee betreft dat de UZI-pas. Zie verder de beschrijving van gastgebruik in paragraaf 3.4.2.

7.3

Beveiliging tussen GBZ-applicaties en ZIM

De volgende paragrafen gaan in op de wederzijdse authenticatie van GBZ en ZIM en de vertrouwelijkheid van de gegevensuitwisseling van GBZ naar ZIM.

7.3.1 Authenticatie met het UZI-servercertificaat Deze paragraaf beschrijft de authenticatie van het GBZ (en daarmee diens applicaties) door middel van een UZI-servercertificaat. De ZIM authenticeert het GBZ op basis van een UZI-servercertificaat, op instellingsniveau. Het GBZ authenticeert de ZIM op basis van diens ZIM-server-certificaat. Na die tweezijdige authenticatie komt een SSL/TLS-sessie tot stand waarbinnen meerdere SSL/TLS-verbindingen kunnen worden opgezet. Voor iedere afzonderlijke GBZgebruiker kan vervolgens een aparte SSL/TLS-verbinding opgezet worden vanaf het GBZ naar de ZIM. De SSL/TLS-verbinding wordt vervolgens gebruikt om in een bericht de interactiegegevens naar/van de ZIM te versturen. Doordat een GBZ meerdere GBZ-applicaties kan omvatten die gebruik maken van het zelfde vertrouwensmiddel kan worden vastgesteld dat een GBZ-applicatie authentiek tot het GBZ behoort echter kan niet vastgesteld worden dat de GBZ-applicatie authentiek is. Met (enkel) het toepassen van dit vertrouwensmiddel wordt voor deze schakel in de keten vertrouwensniveau laag gerealiseerd. Dit is zonder aanvullende vertrouwensmiddelen voldoende voor het opvragen van het BSN of het raadplegen van het zorgadresboek. Immers, de SBV-Z volstaat ook met authenticatie op basis van een UZI-servercertificaat. De ZIM staat, voor interacties op vertrouwensniveau laag, toe, dat een GBZ-gebruiker zich niet aan de ZIM authenticeert (zie paragraaf 7.4.1). In dat geval is dus uitsluitend authenticatie op instellingsniveau aan de orde. Voordeel daarvan is het gebruiksgemak, want de gebruiker hoeft zich niet vooraf met een UZI-pas te authenticeren. Ander voordeel is bijv. dat ziekenhuizen voor hun baliepersoneel geen UZI-pas hoeven aan te vragen. Andere consequenties zijn:


67 van 150

• dat aanvullend door authenticatie van de GBZ-gebruiker door middel van een authenticatietoken (zie paragraaf 7.4.2) gastgebruik van UZI-passen mogelijk is. In dat geval worden immers zowel de authenticiteit van de instelling als de authentiiciteit van de GBZ-gebruiker door afzonderlijke vertrouwensmiddelen gewaarborgd. • dat iedere persoon binnen die zorgaanbieder het BSN mag opvragen en verifiëren, tenzij dit door de zorgaanbieder zelf is ingeperkt, • dat een GBZ ook automatisch BSN’s kan gaan opvragen of verifiëren, bijv. op basis van een behandelagenda of vlak voordat alle facturen uitgaan, • dat autorisatie en mandatering niet zinvol zijn om toe te passen door de ZIM op BSNopvraagberichten, • dat een patiënt uit de toegangslog van de ZIM alleen met zekerheid kan achterhalen vanuit welke zorgaanbieder zijn BSN is opgevraagd of geverifieerd, maar nooit met zekerheid welke persoon dat heeft gedaan. Ook in het geval van meerdere, gelijktijdige GBZ-gebruikers wordt één SSL/TLS-sessie opgezet vanaf het GBZ naar de ZIM op basis van het UZI-servercertificaat. Binnen die SSL/TLS-sessie kunnen vervolgens meerdere SSL/TLS-verbindingen worden gemaakt, één afzonderlijke verbinding voor iedere opvraag zie de onderstaande figuur.

GBZ

SSL/TLS-authenticatie SSL/TLS-verbinding

Client Zorgverlener/ medewerker

client applicatie

SSL/TLS-sessie opvraag antwoord Server

Client

Zorgverlener/ medewerker

client applicatie

LSP

opvraag antwoord

server applicatie

ZIM-platform HL7-opvrg-brcht HL7-antw-brcht HL7-opvrg-brcht HL7-antw-brcht HL7-opvrg-brcht HL7-antw-brcht

ZIM applicatie

Client

Zorgverlener/ medewerker

client applicatie

opvraag antwoord

UZI-cert

SSL-cert

Bijkomend voordeel van deze situatie boven die van paragraaf 7.4, is de snellere responstijd, want de tijdrovende authenticatie geschiedt alleen bij het opzetten van de SSL/TLS-sessie. Het maken van een SSL/TLS-verbinding gaat aanmerkelijk sneller. Als de server een pool van SSL/TLS-verbindingen in stand houdt, kan bij frequent BSN opvragen de gemiddelde responstijd nog sneller worden. Merk op dat het bestandsgewijs opvragen of verifiëren van BSN’s hier niet speelt, omdat de ZIM dat überhaupt niet ondersteunt. Interessant wordt het wel, als een GBZ berichtsgewijs via de ZIM de initiële koppeling gaat doen voor een groot aantal patiënten tegelijk. Dan ontstaat de situatie waarin voor één gebruiker alle HL7v3-opvraagberichten serieel over één SSL/TLS-verbinding of parallel over meerdere SSL/TLS-verbindingen verstuurd zullen worden. Dit speelt ook bij automatische opvragen op basis van een agenda of in het kader van facturering. Om te voorkomen dat één GBZ op deze wijze teveel SSL/TLS-poorten van het LSP in beslag neemt zal een maximum per GBZ moeten worden gedefinieerd.

68 van 150


Opmerkingen:

De boven beschreven wijze van authenticatie geldt slechts indien het GBZ de sessie initieert, en niet indien het LSP de sessie initieert. Afzonderlijke SSL/TLS-sessies dienen te worden opgezet voor een door een GBZapplicatie geïnitieerde communicatie en door het LSP geïnitieerde communicatie (met GBZ-postbussen/dossiers).

7.3.2 Authenticatie met de UZI-pas niet op naam Deze paragraaf beschrijft de authenticatie van het GBZ (en daarmee diens applicaties) door middel van een UZI-pas niet op naam. De ZIM authenticeert het GBZ (en daarmee diens applicaties), op basis van een UZI-pas niet op naam, wel op instellingsniveau maar niet op persoonsniveau. Het GBZ authenticeert de ZIM op basis van diens ZIM-server-certificaat. Na die tweezijdige authenticatie komt een SSL/TLS-sessie voor één GBZ-gebruiker tot stand waarbinnen meerdere SSL/TLS-verbindingen voor die GBZ-gebruiker kunnen worden opgezet. Een SSL/TLS-verbinding wordt gebruikt om in een bericht de interactiegegevens naar de ZIM te versturen. Met (enkel) het toepassen van dit vertrouwensmiddel wordt voor deze schakel in de keten vertrouwensniveau laag gerealiseerd. De authenticatie van de GBZ-applicatie (zoals in paragraaf 7.3.1) met de UZI-pas niet op naam is voldoende voor gebruikscenario’s waarvoor vertrouwensniveau laag vereist is zoals het opvragen van het BSN of het raadplegen van de zorgadresboek. De ZIM kan in dit geval dus niet de GBZ-gebruiker authenticeren. Een UZI-pas niet op naam is immers niet persoonsgebonden. Doordat de UZI-pas niet op naam (evenals de UZI-pas op naam) echter een middel betreft waarmee een token kan worden gegenereerd, biedt het in principe de mogelijkheid de abonnee van de UZI-pas afzonderlijk van de zorgaanbieder te authenticeren. In combinatie met tokenauthenticatie behoort dan het gastgebruik van een UZI-pas niet op naam tot de {toekomst} mogelijkheden, hoewel ook dan een laag vertrouwensniveau wordt gerealiseerd. Zie hiervoor paragraaf 7.4. Overige aspecten van het gebruik van de UZI-pas niet op naam voor de authenticatie van de GBZ-applicatie komen overeen met die van het gebruik van de UZI-pas op naam. Deze worden behandeld in de volgende paragraaf.

7.3.3 Authenticatie met de UZI-pas op naam Deze paragraaf beschrijft de authenticatie van het GBZ (en daarmee diens applicaties) door middel van een UZI-pas op naam.


69 van 150

De ZIM authenticeert het GBZ (en daarmee diens applicaties), op basis van een UZI-pas op naam, zowel op instellingsniveau als op persoonsniveau. Het GBZ authenticeert de ZIM op basis van diens ZIM-server-certificaat. Na die tweezijdige authenticatie komt een SSL/TLS-sessie voor één GBZ-gebruiker tot stand waarbinnen meerdere SSL/TLS-verbindingen voor die GBZ-gebruiker kunnen worden opgezet. Een SSL/TLS-verbinding wordt gebruikt om in een bericht de interactiegegevens naar de ZIM te versturen. Met (enkel) het toepassen van dit vertrouwensmiddel wordt voor deze schakel in de keten vertrouwensniveau midden gerealiseerd. Ook hier is authenticatie van de GBZ-applicatie (zoals in paragraaf 7.3.1) voldoende voor gebruikscenario’s waarvoor vertrouwensniveau laag vereist is zoals het opvragen van het BSN of het raadplegen van het zorgadresboek. Echter, doordat de UZI-pas op naam tevens de GBZ-gebruiker kan authenticeren aan de ZIM biedt dat tevens gebruiksmogelijkheden op vertrouwensniveau midden. Zie hiervoor paragraaf 7.4 . Het gebruik van de UZI-pas voor de authenticatie van de GBZ-applicatie biedt in vergelijk met authenticatie van de GBZ-applicatie door middel van het UZI-servercertificaat weinig voordeel en enkele belangrijke nadelen. Nadeel is het gebruiksgemak, een extra gebruikshandeling is vereist van de gebruiker waar dat met een UZI-servercertificaat niet zou hoeven. Bijv. ziekenhuizen zouden bij deze werkwijze voor hun baliepersoneel juist een UZI-pas moeten aanvragen. Andere consequenties zijn dat: • een zorgaanbieder door het toepassen van een UZI-pas het opvragen van het BSN kan beperken tot een specifieke groep GBZ-gebruikers; • een GBZ BSN’s niet automatisch kan opvragen of verifiëren; • autorisatie en mandatering kan worden toegepast door de ZIM op BSNopvraagberichten; • gegevens van iedere client GBZ-applicatie van het GBZ dienen te worden vastgelegd bij het LSP. In het geval van meerdere, gelijktijdige GBZ-gebruikers worden evenzovele SSL/TLSsessies opgezet (één SSL/TLS-sessie per UZI-pas) vanaf de desbetreffende client GBZapplicatie van het GBZ naar de ZIM. Binnen die SSL/TLS-sessie kunnen vervolgens meerdere SSL/TLS-verbindingen worden gemaakt, één afzonderlijke verbinding voor iedere opvraag zie de onderstaande figuur.

70 van 150


SSL-authenticatie

GBZ

SSL-verbinding

Client client Zorgverlener/ applicatie UZI-pas lezer medewerker

SSL-sessie verzoek antwoord

Server ZIM-platform HL7-verzk-brcht

Client client applicatie Zorgverlener/ UZI-pas lezer medewerker

verzoek antwoord


LSP

verzoek antwoord

HL7-antw-brcht server applicatie

HL7-vrzk-brcht HL7-antw-brcht

ZIM applicatie

HL7-vrzk-brcht HL7-antw-brcht SSL-cert

Bijkomend nadeel van deze situatie boven die van paragraaf 7.3.1, is de langere responstijd, want de tijdrovende authenticatie geschiedt telkens bij het opzetten van de SSL/TLS-sessie. Ook al gaat het maken van een SSL/TLS-verbinding aanmerkelijk sneller. Om te voorkomen dat één GBZ op deze wijze teveel SSL/TLS-poorten van het LSP in beslag neemt zal een maximum SSL/TLS-sessies per GBZ en per GBZ-applicatie moeten worden gedefinieerd ongeacht of de SSL/TLS-sessie door middel van UZI-passen of een UZI-servercertificaat wordt opgezet. Opmerkingen:

De boven beschreven wijze van authenticatie geldt slechts indien het GBZ de sessie initieert niet indien het LSP de sessie initieert. Voor door een GBZ-applicatie geïnitieerde communicatie en door het LSP geïnitieerde communicatie (met GBZ-postbussen/dossiers) dienen afzonderlijke SSL/TLS-sessies te worden opgezet.

7.3.4 Vertrouwelijkheid tussen GBZ-applicaties en ZIM De vertrouwelijkheid van de uitgewisselde informatie tussen GBZ-applicatie en ZIM wordt gewaarborgd op vertrouwensniveau midden door het toepassen van SSL/TLS-sessies die op basis van de vertrouwensmiddelen van zowel GBZ als ZIM tot stand komen. Deze beslissing is gerechtvaardigd, omdat het afluisteren van een SSL/TLS-sessie die is opgezet met behulp van een UZI-servercertificaat net zo moeilijk is als het afluisteren van een SSL/TLS-sessie die is opgezet met behulp van een UZI-pas (sessie authenticatie). Voor het afluisteren is het namelijk niet noodzakelijk (noch voldoende) om de private sleutel behorend bij het gebruikte certificaat te bemachtigen, maar is het noodzakelijk om de gebruikte sessiesleutel te bemachtigen. Die sessiesleutel bevindt zich


71 van 150

op de server die eindpunt van de versleutelde verbinding is, ongeacht of de verbinding is opgezet met behulp van het UZI-servercertificaat of met behulp van een UZI-pas. Voor iedere SSL/TLS-verbinding worden tijdelijke sleutels aangemaakt ten behoeve van vertrouwelijkheid en integriteit van de uitgewisselde berichten. De sleutels dienen een beperkte geldigheidsduur te hebben en regelmatig ververst te worden.

7.3.5 Architectuurbeslissingen Voor het authenticeren van GBZ en ZIM en de vertrouwelijkheid van hun gegevensuitwisseling gelden de volgende architectuurbeslissingen. Architectuurbeslissingen: BVL·b02

Voor het realiseren van een vertrouwensniveau midden ten aanzien van het aspect vertrouwelijkheid is het toepassen van SSL/TLS protocol voldoende.

BVL·b03

Wanneer een GBZ-applicatie een bericht wil sturen naar de ZIM dan past het GBZ een SSL/TLS-sessie toe met: tweezijdige authenticatie tussen GBZ-applicatie en ZIM op basis van ofwel UZI-servercertificaat danwel een UZI-pas en het ZIM-certificaat, meesturen van certificaten, toepassen van SSL v3.0 of TLS 1.0 RSA_WITH_RC4_128_MD5 of RSA_WITH_RC4_128_SHA, 128 bit tijdelijke sleutels die elke 5 minuten ververst worden, maximum sessieduur van 8 uur, maximum ongebruikte sessie van 1 kwartier, {toekomst} nader te bepalen maximum aantal verbindingen.

De bovenstaande tijdsparameters zijn instelbaar door de beheerders. Aldus wordt gedefinieerd: • applicatie-max-sleutel-duur is de maximum duur dat een tijdelijke SSL/TLS-sleutel gebruikt mag worden, waarna deze ververst moet worden. • applicatie-max-sessie-duur is de maximum duur van een SSL/TLS-sessie tussen GBZapplicatie en ZIM, voordat de sessie automatisch wordt beëindigd. • applicatie-max-sessie-onbruik is de maximum duur dat een SSL/TLS-sessie tussen GBZ-applicatie en ZIM niet gebruikt wordt, voordat de sessie automatisch wordt beëindigd. • {toekomst} applicatie-max-sessie-verbindingen is het maximum aantal SSL/TLSverbindingen dat een GBZ-applicatie gelijktijdig mag opzetten naar de ZIM. In theorie zijn er nog mogelijkheden om het aantal gelijktijdig openstaande SSL/TLSverbindingen te beperken tot 1 of 2. Deze oplossingen zijn echter ingewikkelder en worden pas interessant als blijkt dat de GBZ’en het met de bovenstaande oplossing niet redden qua responstijd en capaciteit.

72 van 150


7.4

Beveiliging tussen GBZ-gebruikers en ZIM

Zoals beschreven in [Informatiesysteemarchitectuur] paragraaf 4.2, moet een zorgverlener/medewerker, wil hij landelijk gegevens mogen uitwisselen, het authenticatiemiddel gebruiken dat minimaal het vertrouwensniveau heeft dat noodzakelijk is voor de gewenste gegevenssoort en interactie en hij wil uitvoeren (zie [Informatiesysteemarchitectuur] paragraaf 4.12). Daarvoor heeft een zorgverlener/medewerker een vertrouwensmiddel nodig, dat afhankelijk van de benodigde authenticatiesterkte tenminste aan de volgende eisen moet voldoen: • voor sterke authenticatie: een hardware-token met toegangscode (PIN), dat is uitgegeven door een TTP, conform de richtlijnen van PKI-Overheid. De persoonlijke UZI-passen die door het UZI-register worden uitgegeven voldoen hier aan. • voor normale authenticatie: een hardware-token dat is uitgegeven onder verantwoordelijkheid van de zorginstelling-verantwoordelijke, conform nader te bepalen richtlijnen. • voor zwakke authenticatie: een wachtwoord dat is uitgegeven onder verantwoordelijkheid van de zorginstelling-verantwoordelijke, conform nader te bepalen richtlijnen. De ZIM kan door de combinatie van vertrouwensmiddelen die in beveiligingsketen worden toegepast de GBZ-gebruiker (en zorgaanbieder) authenticeren op één van de volgende manieren: • Bij niet persoonsgebonden vertrouwensmiddelen is geen sprake van sterke authenticatie van de GBZ-gebruiker door de ZIM. De ZIM kan dan slechts het GBZ (en diens applicatie) authenticeren, dus op instellingsniveau. • Tokenauthenticatie van de GBZ-gebruiker. Het token is opgenomen in het verzoekbericht van een GBZ naar de ZIM. Hierbij verifieert de ZIM de authenticiteit: - van de GBZ-gebruiker aan de hand van een authenticatietoken dat is ondertekend door de UZI-pas van de GBZ-gebruiker. - van de zorgaanbieder aan de hand van het UZI-servercertificaat van het GBZ. • Sessieauthenticatie van de GBZ-gebruiker. Hierbij verifieert de ZIM de authenticiteit - van de GBZ-gebruiker aan de hand van diens persoonlijke UZI-pas die voor het opzetten van een SSL/TLS-sessie door het GBZ wordt gebruikt; - van de zorgaanbieder aan de hand van de abonnee van de UZI-pas die voor het opzetten van een SSL/TLS-sessie door de GBZ-gebruiker wordt gebruikt. Deze authenticatiemethoden worden in de volgende paragrafen behandeld.

7.4.1 Geen authenticatie van de GBZ-gebruiker Zonder het toepassen van een UZI-pas kan de ZIM een GBZ-gebruiker niet authenticeren. De ZIM kan slechts de zorgaanbieder, en het GBZ (en indirect diens applicatie) authenticeren, dus op instellingsniveau.


73 van 150

In dit geval mag de GBZ-gebruiker met de ZIM uitsluitend gebruikersinteracties uitvoeren waarvoor vertrouwensniveau laag voldoende is. Zie verder paragraaf 7.3.1.

7.4.2 Tokenauthenticatie van de GBZ-gebruiker Wanneer een zorgverlener/medewerker inlogt met een UZI-pas om landelijk patiëntgegevens te kunnen uitwisselen authenticeert hij zich daarmee bij een applicatie van het GBZ. Enige tijd daarna selecteert de zorgverlener/medewerker een patient waarvoor hij voor een gebruiksscenario in een gebruikersessie een gebruikersinteractie met het LSP wil uitvoeren. Daarbij wordt voor die interactie een authenticatietoken samengesteld dat bij bevestiging van de gebruikersinteractie door de private sleutel - opgenomen in het authenticatiecertificaat van de UZI-pas van de zorgverlener/medewerker - wordt ondertekend. Daarbij moet de UZI-pas ingevoerd zijn in de lezer. De zorgverlener/medewerker voert daarbij éénmalig per gebruikersessie zijn PIN-code in. Op enig moment daarna of daaraan voorafgaand zet het GBZ een SSL/TLS-sessie op met de ZIM en authenticeren een GBZ-applicatie en de ZIM zich aan elkaar met zijn UZIservercertificaat resp. ZIM-certificaat. De beveiliging tussen de GBZ-applicatie en de ZIM is vervolgens zoals beschreven in paragraaf 7.3. De ZIM moet kunnen beschikken over de publieke sleutel in het UZI-pas certificaat van de zorgverlener/medewerker waarmee het token is getekend en authenticeert eenzijdig door verificatie van het token onder meer de GBZ-gebruiker van dat bericht en de intentie die hij met het verzoekbericht heeft. De ZIM kan het UZI-pas certificaat: ophalen bij het UZI-register aan de hand van een referentie van het certificaat dat in het bericht is opgenomen. door de GBZ-applicatie meegestuurd krijgen in het bericht. Om te voorkomen dat in ieder verzoekbericht bij het token ook het certificaat van de UZI-pas moet worden meegestuurd en daardoor de gemiddelde berichtomvang en de netwerkbelasting toeneemt, legt de ZIM geldige certificaten vast die het bij het UZIregister betrekt. De onderstaande figuur toont dit verloop in het geval van bijvoorbeeld een client/servergebaseerde GBZ-applicatie. De figuur toont daarbij een applicatie met een client, waarbij de HL7v3-berichten op de server worden aangemaakt en aldaar een SSL/TLS-sessie wordt gestart.

74 van 150


tokenauthenticatie SSL-authenticatie SSL-verbinding SSL-sessie

GBZ

Client token client Zorgverlener/ applicatie medewerker UZI-pas lezer

LSP

verzoek ZIM-platform

Server antwoord token

HL7-vrzk-brcht HL7-antw-brcht

Client token client

Zorgverlener/ medewerker UZI-pas lezer

applicatie

verzoek antwoord

server applicatie

HL7-vrzk-brcht token HL7-antw-brcht

ZIM applicatie

HL7-vrzk-brcht token HL7-antw-brcht

antwoord Client client token applicatie

verzoek

UZI server cert.

SSL cert

Zorgverlener/ lezer UZI-pas medewerker

Uitsluitend een verzoekbericht van GBZ naar ZIM kan een token bevatten. Een dergelijk verzoekbericht mag slechts één token bevatten. Het dient te worden opgenomen in de SOAP header van het bericht. Het token bevat en signeert authenticatie- en berichtgegevens. De authenticatiegegevens omvat: een nonce waarmee het token uniek wordt gemaakt (gebaseerd op een unieke identificatie van het bericht en een unieke identificatie van de afzender) zodat het beveiligingsrisico van replay naar dezelfde bestemming kan worden verlaagd; de identificatie van de bestemming die geacht wordt de authenticiteit vast te stellen en het bericht te verwerken, zodat het token niet voor een ander bestemming kan worden misbruikt; Het moment waarop de geldigheid van het token begint, zodanig dat het geldig is voordat het corresponderende certificaat verloopt; Het moment waarop de geldigheid van het token eindigt, zodat het token een beperkte duur geldig is en zodanig dat het geldig is voordat het corresponderende certificaat verloopt. De berichtgegevens omvat gegevens waaruit de intentie van de zorgverlener/medewerker met de interactie blijkt en wordt geborgd: De identificatie van de patient (BSN) waar het bericht betrekking op heeft, indien dat voor de interactie van toepassing is; De identificatie van de interactie (in de vorm van het HL7v3 trigger_event_id) die de zorgverlener/medewerker wil uitvoeren. De ZIM verifieert de identiteit en de beroepstitel/specialisme van de auteur van het verzoekbericht aan de hand van het token. De identiteit en de beroepstitel/specialisme van de zorgverlener/medewerker blijkt uit het certificaat waarmee het token kan worden ontsleuteld. Ook de identiteit van de abonnee van de UZI-pas waarmee het token eerder is versleuteld blijkt uit het certificaat waarmee het token kan worden ontsleuteld.


75 van 150

De identiteit van het GBZ blijkt uit het UZI-server-certificaat waarmee de GBZ-applicatie zich heeft geauthenticeerd. Het GBZ hoeft niet de abonnee van de UZI-pas te zijn, er is dan sprake van gebruik van die UZI-pas door een zorgverlener/medewerker die bij dat GBZ te gast is. Zie hiervoor paragraaf 3.4.2 . Opmerking: • Optioneel mag een zorgaanbieder zijn GBZ geschikt maken voor het toelaten van UZIpassen waarvan de zorgaanbieder niet zelf de abonnee is. Zie hiervoor paragraaf 3.4 • Het LSP moet, indien de afzender door een token wordt geauthenticeerd, alvorens een opdracht door te sturen, controleren dat in het ontvangen bericht het zorgaanbieder-id van de gebruiker, de mandaterende, de afzender en de SSL/TLS-sessie waarover het bericht is ontvangen, aan elkaar gelijk zijn. En het bericht weigeren door te sturen in andere gevallen. Architectuur beslissingen: BVL·b04

Wanneer een GBZ-applicatie een bericht met toepassing van tokenauthenticatie wil sturen naar de ZIM dan past het een SSL/TLS-sessie toe met kenmerken zoals aangegeven in [BVL.b03] (zie paragraaf 7.3.5):

BVL·b05

Wanneer een GBZ-gebruiker een verzoekbericht met vertrouwensniveau midden met tokenauthenticatie wil versturen dan dient het GBZ een geldig authenticatietoken in het bericht op te nemen wat door de GBZ-gebruiker met zijn UZI-pas op naam is ondertekend.

BVL·b06

{toekomst} Wanneer een GBZ-gebruiker een verzoekbericht met vertrouwensniveau laag met tokenauthenticatie wil versturen dan dient het GBZ een geldig authenticatietoken in het bericht op te nemen wat door de GBZgebruiker met zijn UZI-pas niet op naam is ondertekend.

BVL·b07

De ZIM verzamelt een kopie van geldige certificaten die het bij het UZI-register ophaalt en regelmatig op geldigheid controleert.

De geldigheidsduur van een authenticatietoken is beperkt tot een door beheerders instelbaar maximum (Max-geldigheidsduur-token) van 90 minuten.

7.4.3 Sessieauthenticatie van de GBZ-gebruiker Wanneer een zorgverlener/medewerker inlogt met een UZI-pas op naam om landelijk patiëntgegevens te kunnen uitwisselen, kunnen de zorgverlener/medewerker en de ZIM elkaar authenticeren met behulp van SSL/TLS. Na die tweezijdige authenticatie begint een sessie waarbinnen meerdere SSL/TLS-verbindingen kunnen worden opgezet. Voor iedere afzonderlijke GBZ-gebruiker wordt een aparte SSL/TLS-sessie opgezet vanaf het GBZ naar de ZIM op basis van de persoonlijke UZI-pas, zoals de onderstaande figuur toont in geval van een client/server-gebaseerde GBZ-applicatie. De figuur toont daarbij een applicatie met een thin client, waarbij de HL7v3-berichten op de server worden aangemaakt en aldaar een SSL/TLS-sessie wordt gestart, waarbij de juiste UZI-pas op de client wordt aangesproken door middel van authentication forwarding.

76 van 150


Niet getoond in de figuur is dat binnen één SSL/TLS-sessie meerdere SSL/TLSverbindingen kunnen worden gemaakt, bijv. om parallel meerdere HL7v3-berichten naar de ZIM te sturen. Om te voorkomen dat één GBZ-gebruiker op deze wijze teveel SSL/TLS-poorten van het LSP in beslag neemt zal een maximum per GBZ-gebruiker moeten worden gedefinieerd.

sessieauthenticatie

GBZ

SSL-verbinding


SSL-sessie verzoek antwoord

HL7-verzk-brcht verzoek antwoord


ZIM-platform

Server

Client client applicatie Zorgverlener/ UZI-pas lezer medewerker

LSP

verzoek antwoord

server applicatie

HL7-antw-brcht HL7-vrzk-brcht HL7-antw-brcht

ZIM applicatie

HL7-vrzk-brcht HL7-antw-brcht SSL-cert

Om te voorkomen dat een ander dan de geauthenticeerde zorgverlener/medewerker zijn sessie kan overnemen, moet de sessie automatisch en definitief worden beëindigd in de volgende gevallen: • nadat de GBZ-gebruiker zijn UZI-pas heeft verwijderd, • wanneer de GBZ-gebruiker meer dan 8 uur gebruik maakt van de sessie, waarbij een eventueel lopende HL7v3-interactie eerst wordt voltooid, maar een opvraagsessie bestaande uit meerdere HL7v3-interacties kan dus worden afgebroken, • wanneer de GBZ-gebruiker gedurende 30 minuten geen gebruik heeft gemaakt van de sessie, • wanneer de GBZ-gebruiker gedurende 15 minuten geen gebruik heeft gemaakt van zijn applicatie. Omdat de UZI-pas tijdens een SSL/TLS-sessie niet gebruikt wordt, moet het GBZ dus frequent controleren of de kaart nog in de kaartlezer zit. Een tijdsinterval van 5 minuten maakt mogelijk dat een gebruiker zijn werkplek even kan verlaten en kan terugkeren (desnoods op een andere werkplek) om zijn sessie voort te zetten. Na afloop van de SSL/TLS-sessie moet het GBZ alle gebruikte geheimen zorgvuldig uitwissen: de master secret van de SSL/TLS-sessie en de tijdelijke sleutels. De PIN-code van de UZI-pas mag sowieso niet worden bewaard door het GBZ, maar moet na intoetsen door de gebruiker onmiddellijk worden uitgewist. Architectuurbeslissingen: BVL·b08

•

Voor sessieauthenticatie zet het GBZ bij inloggen van een GBZ-gebruiker op vertrouwensniveau midden een SSL/TLS-sessie op met de ZIM met: tweezijdige authenticatie tussen persoons-UZI-pas en ZIM-certificaat,


77 van 150

• • • • • • • •

meesturen van certificaten, toepassen van SSL v3.0 of TLS 1.0 128 bit tijdelijke sleutels die elke 5 minuten ververst worden, RSA_WITH_RC4_128_MD5 of RSA_WITH_RC4_128_SHA, maximum sessieduur van 8 uur, maximum ongebruikte sessie van 30 minuten, maximum ongebruikte applicatie van 15 minuten, {toekomst} nader te bepalen maximum aantal verbindingen.

De bovenstaande tijdsparameters zijn instelbaar door de beheerders. Aldus wordt gedefinieerd: • gebruiker-max-kaart-uit is de maximum duur dat een vertrouwensmiddel van de werkplek verwijderd mag zijn, voordat een SSL/TLS-sessie wordt beëindigd. • gebruiker-max-sleutel-duur is de maximum duur dat een tijdelijke SSL/TLS-sleutel gebruikt mag worden, waarna deze ververst moet worden. • gebruiker-max-sessie-duur is de maximum duur van een SSL/TLS-sessie tussen een gebruiker en de ZIM, voordat de sessie automatisch wordt beëindigd. • gebruiker-max-sessie-onbruik is de maximum duur dat een SSL/TLS-sessie tussen een gebruiker en de ZIM niet gebruikt wordt, voordat de sessie automatisch wordt beëindigd. • gebruiker-max-applicatie-onbruik is de maximum duur dat de applicatie door de gebruiker niet gebruikt wordt, voordat de sessie automatisch wordt beëindigd. • {toekomst} gebruiker-max-verbindingen is het maximum aantal SSL/TLS-verbindingen dat een GBZ-applicatie per gebruiker gelijktijdig mag opzetten naar de ZIM. Uit oogpunt van zekerheid moet de ZIM alle sessie-time-outs bewaken. De time-outs gebruiker-max-kaart-uit en gebruiker-max-applicatie-onbruik kunnen alleen door het GBZ worden bewaakt. Het gebruik van SSL/TLS voor de authenticatie van een zorgverlener met UZI-pas door de ZIM, garandeert nog niet dat de berichten die over de SSL/TLS-verbinding gaan, ook daadwerkelijk van die zorgverlener afkomstig zijn resp. bij de bestemde zorgverlener terechtkomen. Er zit immers altijd tenminste één applicatie tussen die berichten van de ZIM vertaalt naar schermuitvoer (resp. toetsenbord/muis-invoer in combinatie met gegevens uit een dossier of op het scherm vertaalt naar berichten voor de ZIM). Bij de GBZ-keuring is het daarom belangrijk vast te stellen of de applicaties binnen een GBZ alle berichten van/naar de ZIM exclusief koppelen aan invoer van/uitvoer naar de kaartlezer op zijn werkplek waarin de zorgverlener zijn UZI-pas heeft gestoken. Wanneer een zorgverlener patiëntgegevens uitwisselt met de ZIM, moet dat daarom altijd geschieden via een GBZ. Dit GBZ moet bovendien van zijn eigen zorgaanbieder zijn. Dit betekent dat de ZIM moet controleren dat de persoonlijke UZI-pas waarmee is ingelogd, dezelfde UZI-abonnee heeft als het UZI-servercertificaat behorende bij het GBZ. Het gastgebruik van een UZI-pas is in dit geval dus niet mogelijk. Deze restrictie moet voorkomen dat:

78 van 150


•

een zorgverlener/medewerker zonder UZI-pas zelfstandig een UZI-pas aanvraagt om onbedoeld vanaf het GBZ van de zorgaanbieder via het LSP patiëntgegevens uit te wisselen. Denk bijv. aan: een gesjeesde basisarts die als verpleegkundige werkt in een ziekenhuis maar toch een UZI-pas van een arts kan aanvragen om méér gegevens te kunnen opvragen dan hij op grond van zijn huidige functie mag inzien. een zorgverlener die na het behalen van een nieuwe beroepstitel daarvoor een nieuwe UZI-pas aanvraagt zonder dat de zorgaanbieder dat weet.

•

een zorgverlener zonder GBZ bij een andere zorgaanbieder binnenloopt om via hun GBZ onrechtmatig bepaalde patiëntgegevens via het LSP uit te wisselen. Denk bijv. aan: een verzekeringsarts die bij een ziekenhuis binnenloopt om de medische historie op te vragen van iemand die een klant van de verzekeraar aansprakelijk heeft gesteld voor letselschade. een werkloze arts of verpleegkundige die zelfstandig een UZI-pas aanvraagt en bij het voormalig werkgevende ziekenhuis binnenloopt om patiëntgegevens op te vragen van degene die hem ontslagen heeft.

Merk op dat het UZI-register een UZI-pas kan uitgeven aan iedereen die in het BIGregister staat, maar niet kan controleren of die persoon ook daadwerkelijk het beroep van zorgverlener uitoefent. Daarnaast geeft AORTA in principe toegang aan alle UZIpashouders. In geval van misbruik van AORTA zal niet alleen de zorgverlener, maar ook de zorgaanbieder-verantwoordelijke daarop zal worden aangesproken. Zonder de bovenstaande restrictie zou een zorgaanbieder-verantwoordelijke kunnen worden verrast door misbruik via zijn GBZ door iemand met een UZI-pas die nooit door hem is aangevraagd. Het is verleidelijk te denken dat de ZIM dan ook dat GBZ moet authenticeren aan de hand van het UZI-servercertificaat, omdat een zorgverlener binnen een zorginstelling niet de controle over het gehele GBZ kan hebben. Zo zou hij per ongeluk zijn UZI-pas in een onveilige werkplek kunnen steken, waardoor zijn UZI-pas wordt misbruikt door malafide programmatuur die ongemerkt namens deze zorgverlener allerlei HL7v3berichten met de ZIM gaat uitwisselen, zie ook paragraaf 7.7. Echter, deze zorgverlener is mede verantwoordelijk voor de correcte werking van het GBZ en kan deze verantwoordelijkheid niet zo maar afschuiven op de instelling. Bovendien wordt het UZIservercertificaat door de ZIM gebruikt voor de authenticatie van postbussen en dossiers en niet zozeer een GBZ als technisch systeem, zie paragraaf 7.5. Tenslotte hanteert het UZI-register enkele spelregels die consequenties hebben voor zorgaanbieders en hun GBZ: • Zorgverleners die voor een zorginstelling werken, kunnen ook zelfstandig een UZI-pas aanvragen. Ook maatschappen binnen een zorginstelling zouden eventueel UZI-passen kunnen aanvragen. Al deze UZI-passen zijn echter niet geschikt voor landelijke uitwisseling van patiëntgegevens via het GBZ van de zorginstelling, omdat deze passen niet aangeven namens welke zorgaanbieder wordt gewerkt. • Zorgverleners moeten ervoor tekenen dat zij hun UZI-pas strikt persoonlijk gebruiken. Dit betekent onder meer dat zij hun UZI-pas niet onbeheerd in een kaartlezer mogen laten zitten. In de praktijk zal het erg verleidelijk zijn dat toch te doen. De bovenstaande time-outs zijn bedoeld om dit te ontmoedigen.


79 van 150

80 van 150


7.5 Beveiliging tussen GBZ-dossiers/postbussen en ZIM Een dossier of postbus binnen een GBZ dat een HL7v3-verzoekbericht krijgt toegestuurd door de ZIM moet zich vooraf authenticeren aan de ZIM. Dit is bij een opvraagbericht belangrijk, omdat de ZIM zekerheid moet hebben dat het resulterende opleverbericht met patiëntgegevens daadwerkelijk afkomstig is het uit het dossier van de verantwoordelijke zorgaanbieder. Evenzo is dit belangrijk bij een opdrachtbericht, omdat de ZIM zekerheid moet hebben dat het opdrachtbericht met de patiëntgegevens daadwerkelijk terecht komen in de postbus van de bestemde zorgaanbieder. Zoals beschreven in [Informatiesysteemarchitectuur] paragraaf 4.16, moet ook een GBZ (-applicatie) met bijbehorend(e) dossiers en postbussen (dus een GBZ) verschillende vertrouwensniveaus kunnen halen, afhankelijk van wat vereist is voor de gegevenssoort (zie [Informatiesysteemarchitectuur] paragraaf 4.12). Daarvoor is een vertrouwensmiddel nodig, dat afhankelijk van de benodigde authenticatiesterkte tenminste aan de volgende eisen moet voldoen: • voor sterke authenticatie: een hardware-token of versleutelde software-token, dat is geplaatst in een GBZ onder goedkeuring van een TTP, conform de richtlijnen van PKIOverheid. De UZI-servercertificaten die door het UZI-register worden uitgegeven voldoen hier aan. • voor normale authenticatie: een software-token dat is geplaatst in een GBZ onder verantwoordelijkheid van de zorginstelling-verantwoordelijke, conform nader te bepalen richtlijnen. Zoals beschreven in [Bedrijfsarchitectuur] paragraaf 11.6, wordt een UZIservercertificaat gebruikt voor de authenticatie van postbussen en dossiers van een bepaalde zorgaanbieder en niet zozeer diens GBZ als technisch systeem. Dit onderscheid is vooral van belang in geval van een ASP die voor meerdere zorgaanbieders werkt, zie ook paragraaf 7.7. Wanneer (een applicatie binnen) een GBZ met een UZI-servercertificaat aansluit op de ZIM om dossiers en postbussen open te stellen voor landelijke uitwisseling van patiëntgegevens, kunnen (een applicatie binnen) het GBZ en de ZIM elkaar authenticeren met behulp van SSL/TLS. Na die tweezijdige authenticatie begint een sessie waarvoor per verbinding tijdelijke sleutels worden aangemaakt ten behoeve van de vertrouwelijkheid en integriteit van de uitgewisselde berichten. Het is echter de vraag of (een applicatie binnen) een GBZ continu een SSL/TLS-sessie moet openhouden met de ZIM, want het is onvoorspelbaar wanneer de ZIM komt met HL7v3-berichten voor het opvragen van patiëntgegevens uit de dossiers, dan wel het versturen van patiëntgegevens naar postbussen. Voor de ZIM zou het een enorm grote belasting zijn om voor alle aangesloten (applicaties binnen) GBZ’en een SSL/TLS-sessie continu open te houden. Het elke keer opnieuw opzetten van een SSL/TLS-sessie wanneer de ZIM een bericht wil sturen naar een GBZ, gaat daarentegen ten koste van de responstijd van met name een opvraag van patiëntgegevens. Als compromis kan de ZIM een opgezette SSL/TLS-sessie open houden zolang de ZIM nog meer berichten van of voor (die applicatie binnen) het GBZ verwacht, met een


81 van 150

maximum van bijvoorbeeld 8 uur. Deze maximumduur kan later op basis van ervaringscijfers worden geoptimaliseerd per (applicatie binnen een) GBZ. Tijdens deze sessie kunnen de tijdelijke sleutels met enige regelmaat worden ververst. Ook kunnen tijdens deze sessie meerdere SSL/TLS-verbindingen worden opgezet, zoals nodig is wanneer de ZIM meerdere HL7v3-interacties parallel wil afhandelen met éénzelfde (applicatie binnen een) GBZ. Zie de onderstaande figuur. Het is teveel gevraagd van een GBZ om rekening te houden met het maximum aantal SSL/TLS-verbindingen dat de ZIM ooit zou willen opzetten met één GBZ. Daarom wordt per GBZ-applicatie een maximum aangehouden.

SSL-authenticatie LSP

SSL-verbinding

ZIM-platform

GBZ

GBZ-platform HL7-verzoek-bericht

ZIM applicatie

HL7-antwoord-bericht HL7-verzoek-bericht

applicatie

HL7-antwoord-bericht HL7-verzoek-bericht

dossier `postbus

HL7-antwoord-bericht SSL-cert

UZI-cert

De eerste keer aansluiten van (een applicatie binnen) een GBZ op de ZIM geschiedt op initiatief van de eerste, omdat alleen de GBZ-beheerder precies weet wanneer (een applicatie binnen) het GBZ gereed is voor aansluiting, zie paragraaf 6.1. Navolgende, reguliere aansluitingen geschieden echter op initiatief van de ZIM, omdat alleen de ZIM weet wanneer er HL7v3-berichten klaarstaan voor het opvragen van patiëntgegevens uit de dossiers, dan wel het versturen van patiëntgegevens naar de postbussen. Architectuurbeslissingen: BVL·b09

• • • • • • • •

Wanneer de ZIM een bericht wil sturen naar (een applicatie binnen) een GBZ op vertrouwensniveau midden, zet de ZIM eerst een SSL/TLS-sessie op met: tweezijdige authenticatie tussen UZI-servercertificaat en certificaat van de ZIM, meesturen van certificaten, toepassen van SSL v3.0 of TLS 1.0 128 bit tijdelijke sleutels die elke 5 minuten ververst worden, RSA_WITH_RC4_128_MD5 of RSA_WITH_RC4_128_SHA, maximum sessieduur van 8 uur, maximum ongebruikte sessie van 1 kwartier, {toekomst} nader te bepalen maximum aantal verbindingen.

De bovenstaande tijdsparameters zijn instelbaar door de beheerders. Aldus wordt gedefinieerd: • systeem-max-sleutel-duur is de maximum duur dat een tijdelijke SSL/TLS-sleutel gebruikt mag worden, waarna deze ververst moet worden.

82 van 150


• systeem-max-sessie-duur is de maximum duur van een SSL/TLS-sessie tussen dossier/postbus en ZIM, voordat de sessie automatisch wordt beëindigd. • systeem-max-sessie-onbruik is de maximum duur dat een SSL/TLS-sessie tussen dossier/postbus en ZIM niet gebruikt wordt, voordat de sessie automatisch wordt beëindigd. • {toekomst} systeem-max-verbindingen is het maximum aantal SSL/TLS-verbindingen dat de ZIM gelijktijdig mag opzetten naar één GBZ-applicatie. Het gebruik van SSL/TLS voor de authenticatie van een GBZ met UZI-servercertificaat door de ZIM, garandeert nog niet dat de berichten die over de SSL/TLS-verbinding gaan, ook daadwerkelijk van de bevraagde zorgverlener afkomstig zijn respectievelijk bij de bestemde zorgverlener terechtkomen. Er zitten immers altijd tenminste één applicatie en één dossier dan wel een postbus tussen, die zijn opengesteld namens de verantwoordelijke zorgverlener, die niet altijd aanwezig is. Bij de GBZ-keuring is het daarom belangrijk vast te stellen of de applicaties binnen een GBZ alle berichten van/naar de ZIM exclusief koppelen aan de dossiers resp. postbussen van de zorgverlener, dan wel zorginstelling-afdeling. Tenslotte hanteert het UZI-register enkele spelregels die consequenties hebben voor zorgaanbieders en hun GBZ: • Een UZI-abonnee kan meerdere UZI-servercertificaten aanvragen, bijv. voor (de applicaties met bijbehorende dossiers en postbussen van) de verschillende afdelingen van een ziekenhuis. Het UZI-register kan voor UZI-passen en UZI-servercertificaten wel afdelingsgegevens (i.e. ‘Organisational Unit Name’) opnemen, maar kan die gegevens niet controleren (en dus niet de juistheid ervan garanderen). Dit betekent dat bij de keuring van een GBZ moet worden gecontroleerd of de UZIservercertificaten zijn gekoppeld aan de juiste applicaties, alvorens de bijbehorende applicatie-id’s worden vermeld in het zorgadresboek. • UZI-certificaten zijn 3 jaar geldig. Bij de uitgifte van een nieuwe persoonlijke UZI-pas kan het oorspronkelijke UZI-nummer behouden blijven. Bij de uitgifte van een nieuw UZI-servercertificaat kan dat niet. Dit betekent dat de systeembeheerder van het LSP moet worden ingelicht wanneer een reeds aangesloten GBZ een nieuw UZIservercertificaat krijgt.


83 van 150

7.6

Beveiliging tussen registers en ZIM

De ZIM wisselt identificerende gegevens van patiënten/cliënten uit met de SBV-Z. De beveiliging van die gegevensstroom valt onder verantwoordelijkheid van SBV-Z. De ZIM vraagt daarnaast certificaten en lijsten van ingetrokken certificaten (CRL) van zorgverleners en hun systemen op bij het UZI-register, via het publieke internet. De beveiliging van die gegevensstroom valt onder verantwoordelijkheid van het UZIregister. Voor het ophalen van een CRL gelden eisen van PKIO, zie ook [UZI]. Omdat het ophalen van de CRL zou kunnen mislukken, wegens problemen binnen het publieke internet of het UZI-register, is het nuttig dit te laten loggen door de ZIM. Architectuurbeslissingen: BVL·b10

De ZIM moet alle pogingen tot ophalen van de CRL bij het UZI-register en het resultaat daarvan te loggen.

Openstaande punten: • Voor de aansluiting van de ZIM op de SBV-Z wordt in principe ook SSL/TLS gebruikt, zie [BSN], maar gezien het intensieve berichtenverkeer zou een alternatief in de vorm van een VPN-verbinding zonder SSL/TLS te overwegen zijn.

7.7

Interne beveiliging GBZ

De interne beveiliging van een GBZ is hier van belang, voor zover het de landelijke uitwisseling van patiëntgegevens betreft. Het is moeilijk hieraan algemene eisen te stellen, omdat de situatie per zorgaanbieder enorm kan verschillen. Vanuit het vertrouwensmodel gezien is een GBZ idealiter een gesloten systeem dat slechts openingen biedt aan gebruikers met UZI-passen en aan de ZIM. Bij een zorgaanbieder met meerdere medewerkers is echter al gauw sprake van een gedistribueerd zorgsysteem met clients op de werkplek en servers in een aparte ruimte. In de praktijk zijn de clients vaak zodanig open, dat gemakkelijk nieuwe programmatuur kan worden geladen met een CD of via een USB-poort. Als een zorgverlener zijn UZI-pas invoert op zo’n client, bestaat het risico dat malafide programmatuur ongemerkt HL7v3berichten probeert te versturen naar de ZIM. Het is de verantwoordelijkheid van de zorgaanbieder om een GBZ zodanig gesloten te houden dat dit niet kan gebeuren. Dit betekent niet dat elke werkplek binnen de zorgaanbieder beveiligd moet worden, maar wel de werkplekken van waar patiëntgegevens landelijk worden uitgewisseld. Bij een grote zorgaanbieder kan verder spelen dat sommige afdelingen meedoen met landelijke uitwisseling via de ZIM, terwijl andere afdelingen daar voorlopig nog niet aan toe zijn. Daarom moet iedere zorgaanbieder met een GBZ zèlf bepalen hoe de grenzen van dat GBZ lopen door de eigen ICT-voorzieningen, zèlf analyseren wanneer patiëntgegevens die grenzen kunnen passeren en zèlf waarborgen dat dit om betrouwbare bestemmingen en bronnen gaat. Zo kunnen werkplekken voor zorgverleners

84 van 150


tot het GBZ worden gerekend, terwijl werkplekken voor administratief personeel daarbuiten vallen. Daarbij gaat het niet altijd alleen om ICT-voorzieningen binnen de zorgaanbieder. Wanneer een zorgaanbieder reeds patiëntgegevens uitwisselt met andere zorgaanbieders, bijv. via regionale voorzieningen, bestaat het risico dat patiëntgegevens die netjes via de ZIM zijn verkregen, onbedoeld bij andere zorgaanbieders terechtkomen. Daarom zal per zorgtoepassing ernaar gestreefd moeten worden alle uitwisseling van patiëntgegevens landelijk via de ZIM te laten verlopen. Alleen tijdens de migratie kan eventueel tijdelijk worden toegestaan daarnaast ook via regionale voorzieningen uit te wisselen. In geval van een ASP die meerdere zorgaanbieders bedient, zal het ASP-systeem logisch moeten worden opgedeeld in afzonderlijke domeinen per zorgaanbieder waarbinnen zijn postbus en dossiers met patiëntgegevens zich bevinden, zodanig dat andere zorgaanbieders daar niet zo maar bij kunnen. Voor zover de uitwisseling tussen verschillende zorgaanbieders niet via de ZIM verloopt, zal een lokaal autorisatieprotocol gehanteerd moeten worden. Ook in geval van een ASP moet iedere zorgaanbieder een eigen UZI-servercertificaat aanvragen. Door deze vervolgens te (laten) plaatsen in het ASP-systeem, geeft de zorgaanbieder dus te kennen dit ASP-systeem als beheerder van zijn postbus en dossiers met patiëntgegevens te beschouwen. Voor het overige is de interne beveiliging vooral een zaak voor de zorgaanbieder zelf. NEN 7510 zal naar verwachting algemeen verplicht zal worden, ongeacht of de zorgaanbieder deelneemt aan landelijke uitwisseling van patiëntgegevens. Zo verplicht de NEN 7510 een zorgaanbieder tot een risico-analyse op alle externe verbindingen en maatregelen voor alle risico’s. Op deze wijze kan voorkomen worden dat een GBZ voldoet aan de GBZ-eisen terwijl de veiligheid wordt ondermijnd door een aspect dat niet expliciet door de GBZ-eisen wordt afgedekt.

7.8

Interne beveiliging ZIM

De interne beveiliging van de ZIM is van groot belang omdat in principe alle landelijk uitgewisselde patiëntgegevens via de ZIM lopen. Echter, de ZIM is slechts een schakelpunt voor gegevensstromen. De ZIM kijkt in principe niet in de HL7v3 Payload met patiëntgegevens van de uitgewisselde HL7v3-berichten. De ZIM kijkt wel in de HL7v3 Transport Wrapper en de HL7v3 Control Act Wrapper, maar die bevatten geen patiëntgegevens. Daarmee is de interne beveiliging van de ZIM vooral een zaak van fysieke toegangscontrole, betrouwbare beheerprocedures, betrouwbaar personeel, etc.


85 van 150

8

Beschikbaarheid (BSK)

Zorgverleners moeten in principe 7 dagen per week en 24 uur per dag patiëntgegevens kunnen opvragen en versturen. Dit stelt hoge eisen aan de basisinfrastructuur, maar ook aan de aangesloten GBZ’en en hun DCN’en. Immers, als één GBZ patiëntgegevens opvraagt die verspreid liggen bij andere GBZ’en, moeten die andere GBZ’en ook beschikbaar en bereikbaar zijn.

8.1

Beschikbaarheid van een GBZ

Het is echter onvermijdelijk dat applicaties of hele GBZ’en uitvallen als gevolg van onvoorziene storingen. Ook moet het mogelijk zijn applicaties tijdelijk uit de lucht te halen voor onderhoud. Deze tijdintervallen van niet beschikbaar zijn, moeten uit oogpunt van de gebruikers zo kort mogelijk gehouden worden. Uit oogpunt van kosten moet echter voorkomen worden dat te strenge eisen worden gesteld. Een redelijk compromis tussen kosten en bruikbaarheid lijkt een gemiddelde storingstijd (MTTR) van maximaal 15 minuten. Immers, als een of meer applicaties uitvallen, bijv. door vastlopende programmatuur, is het meestal mogelijk deze applicaties binnen een kwartier weer op te starten. Een kwartier is ook een tijdsinterval dat kan worden uitgelegd aan een gebruiker: als het opvragen of versturen van patiëntgegevens mislukt doordat de ZIM of een GBZ uit de lucht is, kan men na een kwartier weer proberen met een redelijke waarschijnlijkheid dat het dan wel lukt. Niet uitgesloten kan worden dat een GBZ-platform zodanig defect raakt dat nieuwe onderdelen nodig zijn of dat het GBZ op een ander systeem moet worden overgezet. Dit vergt gauw een dag werk. Bovenstaande eisen aan een GBZ vergen wel professioneel beheer van het GBZ om binnen een kwartier een beheerder te kunnen waarschuwen en het GBZ weer op te starten. Behalve de beschikbaarheid van de functies, is ook de beschikbaarheid van de vastgelegde patiëntgegevens belangrijk. Het dagelijks maken van een back-up is onder professionele beheerders gebruikelijk. Back-ups moeten op een veilige plaats worden opgeborgen. Tenslotte moet gepland onderhoud kunnen plaatsvinden, bij voorkeur in de rustige uren. Indien tijdig aangekondigd, kunnen gebruikers en beheerders daarmee rekening houden. Architectuurbeslissingen: BSK·b01

Een GBZ vergt professioneel beheer om het GBZ continu te bewaken en om kleine storingen binnen 15 minuten en grote storingen binnen 1 dag te herstellen en dagelijks een back-up te maken.

86 van 150


8.2

Beschikbaarheid van de ZIM

Per operationele-ZIM locatie datacenter geldt een minimale beschikbaarheid van 99,982 procent onder niveau drie. De ZIM kan zodanig defect raken dat nieuwe onderdelen nodig zijn, maar bij een ZIM loont het om een fout-tolerant platform te kiezen met meervoudige hardware-onderdelen en 24 uur x 7 dagen per week bewaking door beheerders. Een bijzondere situatie is overmacht door externe bedreigingen, zoals overstroming, aardbeving, bomaanslag, etc. die de ZIM onherstelbaar kunnen beschadigen. Voor dergelijke gevallen is een failover voorziening met een tweede operationele ZIM nodig. Een continue synchronisatie van de tweede operationele ZIM met de gegevens in de eerstte operationele ZIM is derhalve vereist.

operat. ZIM locatie 1

operat. ZIM locatie 2

test/acc. ZIM

RF

RF

DCN

GBZ

GBZ

GBZ

GBZ

GBZ

Architectuurbeslissingen: BSK·b02

Er moet een tweede locatie met operationele ZIM zijn, om in geval van onherstelbare schade op locatie 1 transparant op locatie 2 te continueren.

BSK·b03

Er moet een testen acceptatievoorziening met test-ZIM zijn, om GBZ’en te kunnen testen en accepteren alvorens deze operationeel aan te sluiten.

Merk op dat een GBZ meerdere applicaties kan bevatten waarvan de ene reeds operationeel is en de andere nog wordt getest, zie GBZ2 in de onderstaande figuur. Dit maakt noodzakelijk dat een GBZ een IP-adres moet configureren voor zowel de operationele ZIMs, zie ook paragraaf 6.2.


87 van 150

Operat. ZIM loc. 1

test/acc. ZIM

Operat. ZIM loc 2

Sch.1

Sch.2

Sch.3

RF

RF

DCN

88 van 150

Appl.1 Appl.2

Appl.3 Appl.4

Appl.5

GBZ1

GBZ2

GBZ3


8.3

Beschikbaarheid van een DCN

Tenslotte is de beschikbaarheid van ieder DCN belangrijk. DCN’en kunnen behalve kortstondige storingen ook uitvallen als gevolg van defecte netwerkcomponenten. Klassieke defecten als kabels die door graafmachines worden geraakt vragen om redundante verbindingen binnen het netwerk. Kleine storingen kunnen op afstand worden verholpen. Grote storingen vergen vaak werkzaamheden op locatie, waardoor hersteltijden snel kunnen oplopen tot een werkdag. Een te vermijden single point of failure is de aansluiting van de ZIM op een DCN. Een uitvallende aansluiting van een GBZ raakt alleen de gebruikers van dat GBZ. Een uitvallende aansluiting van de operationele ZIM raakt alle gebruikers aangesloten via dat DCN. De meervoudige ZIM heeft aldus consequenties voor de wijze van aansluiten op een DCN. Ieder DCN moet aansluiten op de locaties van de operationele ZIM; dat vergt een actieve router, met daarnaast een redundant pad. Overschakelen van locatie 1 naar locatie 2 zal voor de DCN transparant en automatisch gebeuren zodat bij uitval dit voor de GBZ systemen ongemerkt gebeurt. Architectuurbeslissingen: BSK·b04

Ieder DCN vergt een redundante actieve aansluiting met de locaties van de operationele ZIM en een actieve aansluiting met de test-ZIM


89 van 150

8.4

Beschikbaarheidstoestanden

Zowel een ZIM als een daarop aangesloten GBZ zal op een bepaald moment vaststellen dat de ander onbeschikbaar wordt of is geworden. In geval van onderhoud wordt dit vooraf aangekondigd, in geval van storing wordt dit achteraf geconstateerd. In paragraaf 11 wordt beschreven hoe een incidentele fout wordt onderscheiden van een uitgevallen systeem. Daarnaast kan een systeem onbereikbaar worden, bijv. door het uitvallen van een DCN. De ZIM of het GBZ dat constateert dat de ander onbeschikbaar of onbereikbaar is geworden, zal zijn gebruikers daarover inlichten indien dat relevant is. Wanneer de ZIM of een GBZ weer beschikbaar wordt, zullen de betrokken gebruikers ook weer worden ingelicht, al dan niet via de beheerders. De onderstaande figuur toont in een UML statechart diagram de toestandsveranderingen van de ZIM en die van een schakelpunt binnen de ZIM, gezien vanuit een GBZ. De gestippelde pijlen tonen een toestandsovergang die handmatig moet plaatsvinden, zie [Informatiesysteemarchitectuur] paragraaf 4.18.

ZIM onbereik baar

ZIM bereikbaar Schakelpunt beschikbaar GBZ krijgt IP-contact met ZIM

gereed Schakelpunt stuurt toestandsbericht naar applicaties

GBZ verliest IP-contact met ZIM

actief

Schakelpunt onbeschikbaar ZIM-beheerder informeert GBZ-beheerders

onderhoud Schakelpunt stuurt toestandsbericht naar applicaties

Applicatie kan geen HL7-berichten meer uitwisselen, geen SSL-sessie met schakelpunt meer starten, maar GBZ heeft nog IP-contact met ZIM

storing

Een schakelpunt heeft dus de volgende beschikbaarheidstoestanden: • actiemodus: gereed, actief, onderhoud of storing, • beschikbaarheidsmodus: beschikbaar of onbeschikbaar. Een ZIM als geheel heeft de volgende beschikbaarheidstoestand: • bereikbaarheidsmodus: bereikbaar of onbereikbaar. De onderstaande figuur toont in een UML statechart diagram de toestandsveranderingen van een applicatie binnen een GBZ, gezien vanuit de ZIM. De gestippelde pijlen tonen een toestandsovergang die telefonisch of per e-mail moet plaatsvinden, zie [Informatiesysteemarchitectuur] paragraaf 4.16. De getoonde toestandsberichten zijn nog {toekomst} zodat die toestandsveranderingen voorlopig ook telefonisch of per e-mail moeten worden gemeld. Niet getoond is dat ook de ZIM-beheerder eigenhandig kan bepalen dat een applicatie zodanig veel fouten veroorzaakt, dat deze in de modus storing

90 van 150


moet worden gezet. Dit moet hij dan ook melden aan de GBZ-beheerder, want die heeft deze fouten misschien niet eens opgemerkt.

GBZ onbereik baar

GBZ bereikbaar

ZIM krijgt IP-contact met GBZ

Applicatie beschikbaar gereed Applicatie stuurt toestandsbericht naar schakelpunt

ZIM verliest IP-contact met GBZ

actief

GBZ-beheerder informeert ZIM-beheerder

Applicatie onbeschikbaar onderhoud Applicatie stuurt toestandsbericht naar schakelpunt

Schakelpunt kan geen HL7-berichten meer uitwisselen, geen SSL-sessie met applicatie meer starten, maar ZIM heeft nog IP-contact met GBZ

storing

Een applicatie heeft dus de volgende beschikbaarheidstoestanden: • actiemodus: gereed, actief, onderhoud of storing, • beschikbaarheidsmodus: beschikbaar of onbeschikbaar. Een GBZ als geheel heeft de volgende beschikbaarheidstoestand: • bereikbaarheidsmodus: bereikbaar of onbereikbaar. Openstaande punten: • het is nog de vraag of het LSP precies moet bijhouden voor elke GBZ hoelang deze onbeschikbaar is. Weliswaar heeft het LSP niet de taak om te controleren of ieder GBZ voldoet aan de beschikbaarheideisen. Maar ook zonder die taak, kan het nuttig zijn als het LSP de beschikbaarheid van iedere GBZ bijhoudt. Bijvoorbeeld om klachten van andere zorgaanbieders over de bereikbaarheid van andere GBZ’en goed te kunnen beantwoorden. Zo zou de ZIM de beschikbaarheid kunnen testen met heartbeats. Ook kan de verplichting bij een GBZ worden gelegd om gepland onderhoud en onverwacht lange storingen telefonisch of per e-mail te melden aan een LSP-beheerder. Dit moet echter nader onderzocht worden.


91 van 150

8.5

Samenvatting

De onderstaande tabel geeft de verdeling van beschikbaarheidscijfers voor afzonderlijke componenten resp. de gehele keten, te meten over een jaar. ZIM Kleine storingen: max. frequentie 12 / jaar max. duur 1 kwartier duur / jaar 3 uur

DCN > ZIM

DCN > GBZ

GBZ

6 / jaar 1 kwartier 1,5 uur

12 / jaar 1 kwartier 3 uur

12 / jaar 1 kwartier 3 uur

Grote storingen: max. frequentie 0 max. duur 0 duur / jaar 0

0 0 0

2 / jaar 12 uur 24 uur

2 / jaar 1 dag 48 uur

Onbeschikbaar / jaar % beschikbaar

1,5 uur 99,98

27 uur 99,7

51uur 99,4

3 uur 99,96

Voor één GBZ is de resulterende kans: • 99% dat het de ZIM kan bereiken om patiëntgegevens aan te melden, • 98% dat het aan een ander GBZ een patiëntbericht kan versturen, • 96% dat het van vier andere GBZ’en alle patiëntgegevens kan opvragen. De onbeschikbaarheid als gevolg van goed gepland en tijdig aangekondigd onderhoud wordt niet meegeteld in de bovengenoemde beschikbaarheidscijfers. Opmerkingen: • Of een GBZ of ZIM voldoet aan de gestelde beschikbaarheideisen, zal pas na lange tijd kunnen blijken. Omdat ook vóóraf bepaald moet worden of een GBZ resp. ZIM als zodanig mag functioneren, zullen specifieke preventieve maatregelen worden geëist, zoals een noodstroomvoorziening, back-up procedures, etc. • Wanneer behalve medicatiegegevens en huisartswaarneemgegevens ook andere toepassingen worden geimplementeerd, zou de beschikbaarheid van de gegevens nader kunnen worden gedifferentieerd naar de verschillende gegevensklassen (medische gegevens zijn immers veel belangrijker dan logistieke gegevens) of gegevenssoorten (medicatiegegevens zijn vaak urgenter dan röntgenfoto’s). Een dergelijke nuancering kan een zorgaanbieder veel kosten besparen.

92 van 150


9

Capaciteit en schaalbaarheid (CAP)

9.1

Inleiding

De benodigde capaciteit van de basisinfrastructuur hangt sterk af van het aantal berichten dat wordt uitgewisseld tussen de aangesloten GBZ’en onderling en met de registers. Dit aantal berichten hangt weer af van het aantal aangesloten GBZ’en en het aantal daadwerkelijke gebruikers dat patiëntgegevens opvraagt en verstuurt. Deze aantallen zijn zeer moeilijk te voorspellen, want dat hangt af van de mate van succes van de invoering van de zorgaanbiederapplicaties die gebruik maken van de basisinfrastructuur. Dit succes is echter mede afhankelijk van de responstijden. Daarbij komt nog dat veel zorgverleners vooral ’s ochtends hun spreekuur hebben en dan dus ook allerlei patiëntgegevens willen opvragen. Dit kan leiden tot enorme pieken in de systeembelasting en dus zeer lange wachttijden. Deze problematiek kan worden vergeleken met die van andere infrastructuren die dreigden te bezwijken onder hun succes, bijv. het Internet. Daaruit kan worden geleerd dat de oplossing ligt in schaalbaarheid en flexibiliteit. Schaalbaarheid houdt in dat de capaciteit in de tijd kan worden uitgebreid afhankelijk van de werkelijke behoefte. Flexibiliteit houdt in dat mogelijkheden worden opengehouden om de beschikbare capaciteit anders te benutten. Anderzijds blijkt vaak dat het feitelijke gebruik zich op termijn gaat voegen naar de gunstigere momenten. Ook blijkt vaak dat werkprocessen veranderen als gevolg van de nieuwe mogelijkheden. Uiteindelijk kan dit leiden tot een balans tussen vraag en aanbod. Voor de basisinfrastructuur in de zorg betekent dit, dat de capaciteit niet vanaf de invoering hoeft te zijn voorbereid op de uiteindelijke belasting, mits er voldoende mogelijkheden tot opschaling zijn. Hierbij is vooral de ZIM een cruciale factor, omdat deze een centrale schakel vormt in (vooralsnog) elke interactie tussen GBZ en andere systemen. Ook de DCN’en zijn hier belangrijk, maar het Internet heeft bewezen dat in principe deze voldoende schaalbaar kunnen zijn. Bovendien kunnen verschillende ZSP’s onderling concurreren op de beste responstijden. Voor de ZIM zijn er verschillende mogelijkheden tot opschaling. De ZIM kan worden opgebouwd uit verscheidene schakelpunten die ieder op een aparte hardware-processor of hardware-platform draaien. De systeembelasting kan zodanig worden verdeeld over de verschillende schakelpunten, dat groepen van applicaties die vooral binnen die groep berichten uitwisselen op hetzelfde schakelpunt worden aangesloten. Zo zullen medicatieberichten vooral tussen HIS’en, AIS’en en ZAIS’en worden uitgewisseld. Ook het feit dat de meeste uitwisseling van patiëntgegevens binnen de regio plaatsvindt, biedt mogelijkheden tot optimalisatie. De basisinfrastructuur zal bij aanvang van de exploitatie alleen de volgende toepassingen ondersteunen: e-medicatiedossier en e-waarneemdossier voor huisartsen. Aangenomen dat het enkele jaren kost dat alle huisartsen, apothekers en ziekenhuizen voor al hun medicatie en waarnemingen gebruik maken van de basisinfrastructuur, moeten de ZIM


93 van 150

en de verschillende DCN’en bij oplevering tenminste een zeker percentage van de uiteindelijk benodigde capaciteit leveren. Architectuurbeslissingen: CAP·b01

De basisinfrastructuur dient bij aanvang van de exploitatie een zeker percentage van de uiteindelijk benodigde capaciteit te kunnen leveren. Bij failover moet dit percentage ook minimaal beschikbaar zijn.

CAP·b02

De basisinfrastructuur moet schaalbaar zijn om de uiteindelijk benodigde capaciteit te kunnen leveren. Het wordt de verantwoordelijkheid van het LSP resp. de ZSP’s en zorgaanbieders om de capaciteit van de ZIM resp. de DCN’en en GBZ’en tijdig op te schalen om binnen de vereiste responstijden te blijven.

CAP·b03

De ZIM kan verscheidene schakelpunten omvatten om te kunnen opschalen en optimaliseren, bijv. per regio, per type applicatie (en dus berichtsoort), etc.

94 van 150


9.2

Capaciteitschatting

Naar huidig inzicht dient de basisinfrastructuur uiteindelijk de volgende capaciteit te leveren: • 20.000 aangesloten GBZ’en, • 50 aangesloten DCN’en, • 10.000 gelijktijdige gebruikerssessies, • 4.312.000.000 berichten per jaar, • gemiddeld 5 kByte per uitgewisseld bericht. Het aantal berichten is ingeschat op basis van een raming van de landelijke zorgtoepassingen huisartswaarneemgegevens en medicatiegegevens, zie de onderstaande tabel, en de aanname dat alle andere zorgtoepassingen tezamen nog eens zoveel berichten genereren. Landelijke toepassing

Aantal interacties

Aantal interacties tussen

gebruikersinteractie

tussen agerend

ZIM en reagerend GBZ

GBZ en ZIM

of register

Algemeen Opvragen PatiëntIdentificatie

32.000.000/jr

Opvragen Zorgadresboek Bijwerken Zorgadresboek aanmeldenGegevens afmeldenGegevens opvragenIndex

14.000.000/jr 300.000/jr 28.000.000/jr 14.000.000/jr 4.000.000/jr

32.000.000/jr 14.000.000/jr 0 0 0

Medicatiegegevens Versturen Medicatievoorschrift Versturen Medicatieverstrekking Opvragen Medicatievoorschriften Opvragen Medicatieverstrekkingen Opvragen Contra-indicaties

140.000.000/jr 14.000.000/jr 28.000.000/jr 280.000.000/jr 280.000.000/jr

140.000.000/jr 14.000.000/jr 28.000.000/jr 280.000.000/jr 560.000.000/jr

4.000.000/jr

4.000.000/jr

4.000.000/jr 4.000.000/jr

4.000.000/jr

846.300.000/jr 1.692.600.000/jr 3.385.200.000/jr 7.689.200.000/jr

1.076.000.000/jr 2.152.000.000/jr 4.304.000.000/jr

Huisartswaarneemgegevens Opvragen Professionele Samenvatting Versturen waarneemverslag Aansluiting en (de)activatie GBZapplicatie Totalen totaal aantal interacties totaal aantal HL7v3-berichten maal 2 voor andere toepassingen Totaal aantal berichten

Merk op dat iedere interactie tussen twee systemen leidt tot twee HL7v3-berichten. Gezien vanuit één systeem, is dat telkens één binnenkomend bericht en één uitgaand bericht.


95 van 150

Voor een onderbouwing van de raming voor medicatiegegevens en huisartswaarneemgegevens, zie [AO Medicatiegegevens] en [AO Huisartswaarneemgegevens].

96 van 150


9.3

Dempende maatregelen tbv ZIM

De ZIM vormt binnen de basisinfrastructuur in principe een bottleneck voor alle HL7v3berichtenverkeer. Zonder enige dempende maatregelen bij de aangesloten GBZ’en kan piekbelasting leiden tot overbelasting en uitval van de ZIM. Bijvoorbeeld, als vele zorgverleners om 9:00 uur beginnen met opvragen van patiëntgegevens, leidt dit tot een piekbelasting van de ZIM. Daardoor zullen de zorgverleners langer moeten wachten op antwoord. Als ongeduldige zorgverleners of hun applicatie daardoor opnieuw dezelfde opvraagberichten naar de ZIM gaan sturen, zal dit de situatie alleen maar verergeren. Het is daarom belangrijk dat GBZ’en zich beperken in hun capaciteitsvraag ter bescherming van de ZIM. Dit gaat niet alleen om het aantal HL7v3-verzoekberichten dat gelijktijdig kan uitstaan, maar ook om het aantal SSL/TLS-sessies dat gelijktijdig kan worden opgezet.

9.3.1 SSL/TLS-sessies Het opzetten van een SSL/TLS-sessie van GBZ-gebruiker ten behoeve van sessieauthenticatie naar de ZIM is erg bewerkelijk, wegens de SSL/TLS-handshake op basis van UZI-passen met lange PKI-sleutels. Als een SSL/TLS-sessie eenmaal is opgezet, zal voor ieder HL7v3-verzoekbericht een SSL/TLS-verbinding worden gemaakt, maar dat is véél minder bewerkelijk, omdat daarbij slechts korte symmetrische sleutels worden uitgewisseld. Binnen één SSL/TLS-sessie kunnen gelijktijdig vele SSLverbindingen worden gemaakt, zie paragraaf 7.4. In principe zal bij toepassing van sessieauthenticatie ieder GBZ per gebruiker één SSLsessie tegelijk met de ZIM opzetten om HL7v3-verzoekberichten naar de ZIM te sturen. Het opzetten van meerdere SSL-sessies is niet in het belang van het GBZ zelf of de GBZgebruiker, dus het is niet nodig hier een grens te stellen. Bij toepassing van tokenauthenticatie van GBZ-gebruikers volstaat één enkele SSL/TLSsessie voor het gehele GBZ. Voor alle SSL-verbindingen van alle GBZ-gebruikers waarover deze HL7v3-verzoekberichten met een token verstuurd worden kan de eenmaal opgezette SSL/TLS-sessie worden gebruikt. In het algemeen is, zowel voor GBZ als ZIM, de belasting gemoeid met het opzetten van SSL/TLS-sessies lager bij tokenauthenticatie dan bij sessieauthenticatie.

9.3.2 HL7v3-verzoekberichten Het aantal HL7v3-verzoekberichten dat een GBZ gelijktijdig bij de ZIM kan hebben uitstaan, is onder meer afhankelijk van: • het aantal gelijktijdig actieve gebruikers, • het aantal verzoekberichten dat een GBZ per gebruiker gelijktijdig stuurt. niet meer dan een maximum aantal opvraagberichten te Het is verleidelijk een beperking op te leggen dat een GBZ per gebruikerssessie gelijk naar de ZIM stuurt. Hiervoor is momenteel echter geen realistische grens te bedenken.


97 van 150

9.4

Dempende maatregelen tbv GBZ

Na aansluiting op de ZIM kan een GBZ een stroom HL7v3-verzoekberichten verwachten, waarvan de intensiteit gedurende de dag zal variëren, met de vermoedelijke pieken en dalen. Volgens architectuurbeslissing [CAPb02] is een zorgaanbieder en/of zijn XIS-leverancier zelf verantwoordelijk voor het opschalen van de capaciteit van het GBZ om aan de responstijden te kunnen blijven voldoen. De vereiste gemiddelde responstijden geven ruimte voor incidentele overschrijding als gevolg van piekbelasting, zie hoofdstuk 10. Toch is het belangrijk dat de ZIM enige beperkingen krijgt opgelegd ter bescherming van ieder GBZ. Dit gaat niet alleen om het aantal HL7v3-verzoekberichten dat gelijktijdig kan uitstaan, maar ook om het aantal SSL/TLS-sessies dat gelijktijdig kan worden opgezet.

9.4.1 SSL/TLS-sessies Het opzetten van een SSL/TLS-sessie van ZIM naar GBZ is erg bewerkelijk, wegens de SSL/TLS-handshake op basis van UZI-certificaten met lange PKI-sleutels. In geval van een grote SSL/TLS-belasting zou het noodzakelijk kunnen zijn binnen een GBZ speciale hardware (bijv. een SSL-offloader) te hebben. Dat kan de kosten onnodig opdrijven. Als een SSL/TLS-sessie eenmaal is opgezet, zal voor ieder HL7v3-verzoekbericht een SSL/TLS-verbinding worden gemaakt, maar dat is véél minder bewerkelijk, omdat daarbij slechts korte symmetrische sleutels worden uitgewisseld. Binnen één SSL/TLS-sessie kunnen gelijktijdig vele SSL-verbindingen worden gemaakt, zie paragraaf 7.5. In principe zal de huidige ZIM slechts één SSL/TLS-sessie tegelijk per GBZ opzetten om HL7v3-verzoekberichten naar een GBZ te sturen. Omdat een SSL/TLS-sessie een timeout heeft van 1 kwartier, kan hiervan doelmatig gebruik worden gemaakt, ongeacht de verschillende GBZ’en waar al die verzoekberichten vandaan komen, zie architectuurbeslissing [BVLb02]. Toch is niet uitgesloten dat het LSP ooit een vorm van load balancing gaat uitvoeren voor de eigen SSL-offloaders, waarbij het kan gebeuren dat incidenteel en kortstondig meerdere SSL/TLS-sessie tegelijk met dezelfde GBZ kunnen worden opgezet. Ook moet een GBZ rekening houden met het feit dat het LSP zowel een operationele ZIM als een test-ZIM heeft, zie paragraaf 8.2, laatste figuur. Aldus zal een operationele zorgtoepassing (bijv. huisartswaarneemgegevens) via de operationele ZIM verlopen en kan een test-zorgtoepassing (bijv. medicatiegegevens) tegelijkertijd via de test-ZIM verlopen. Daarmee worden meerdere SSL/TLS-sessie met de GBZ gerealiseerd. Verder moet een GBZ rekening houden met de mogelijkheid dat het LSP straks moet opschalen door meerdere operationele ZIM’s te installeren. Daarbij is het niet uitgesloten dat de ene zorgtoepassing (bijv. medicatiegegevens) via de ene ZIM verloopt en een andere zorgtoepassing (bijv. huisartswaarneemgegevens) via een andere ZIM verloopt. Dat zou ertoe leiden dat een GBZ structureel en langdurig meerdere SSL/TLS-sessies tegelijk moet verwachten.

98 van 150


Tenslotte moet een GBZ eventueel rekening houden met SSL/TLS-sessies die worden opgezet door andere systemen dan de ZIM, bijv. een GBZ dat röntgenfoto’s rechtstreeks ophaalt bij de bron, maar dat valt buiten AORTA is een zaak voor de zorgaanbieder en zijn XIS-leverancier. Architectuurbeslissingen: CAP·b04

een GBZ moet per aangesloten ZIM in principe één SSL/TLS-sessie, maar incidenteel meerdere SSL/TLS-sessies gelijktijdig kunnen onderhouden, met een maximum van ZIM-max-sessie-aantal = 3.

9.4.2 HL7v3-verzoekberichten Het aantal HL7v3-verzoekberichten dat de ZIM gelijktijdig bij één GBZ kan hebben uitstaan, is onder meer afhankelijk van: • welke zorgtoepassingen (medicatiegegevens, huisartswaarneemgegevens, etc.) operationeel zijn voor het GBZ, • het aantal patiënten waarvoor dit GBZ gegevens heeft aangemeld bij de VWI, • het aantal aangesloten GBZ’en dat dezelfde zorgtoepassingen operationeel heeft. Het is dus niet mogelijk om exact het maximum aantal gelijktijdige HL7v3verzoekberichten te definiëren dat een GBZ mag verwachten van de ZIM. Er is ook geen absolute grens waartegen een GBZ zal aanlopen als er teveel HL7v3-requests tegelijk binnenkomen. In plaats daarvan zal het GBZ gewoon trager (mogen) worden. Het lijkt dus ook niet erg zinvol om een GBZ bij overschrijding van een bepaalde limiet aan de ZIM een foutmelding “GBZ-overbelast” te geven. De kans is heel veel groter dat de ZIM tegen een time-out aanloopt. De ZIM zou dan eigenlijk geen retry moeten doen door een duplicaat-HL7v3-request te sturen, zoals voor de {toekomst} wordt overwogen, zie hoofdstuk 11. Een retry-mechanisme is alleen werkbaar als de ZIM daarbij de belasting terugregelt door de tussenliggende tijdsintervallen te vergroten volgens een exponential back-off scenario. Daarom anticipeert architectuurbeslissing [CAPb02] op de groei van berichtenverkeer doordat geleidelijk steeds meer GBZ’en aansluiten op de ZIM. Voordeel daarvan is dat voor een GBZ geen absolute capaciteitseis hoeft te worden geformuleerd. Nadeel daarvan is weer dat een kandidaat-GBZ bij de kwalificatie niet expliciet kan worden getest op dit punt. Daardoor kan het gebeuren dat pas tijdens operationeel gebruik zal blijken dat een GBZ eventueel te krap was gedimensioneerd om een incidentele piek op te vangen en daardoor onderuit gaat. Daarom zou moeten worden afgedwongen dat een GBZ bij dreigende overbelasting gewoon trager moet worden om onderuitgaan te voorkomen. Feitelijk komt dit neer op prioritering: beschikbaarheidseisen gaan boven responstijdeisen. Architectuurbeslissingen: CAP·b05

bij een piekbelasting van HL7v3-verzoekberichten door de ZIM, moet een GBZ de eisen inzake de beschikbaarheid laten prevaleren boven de eisen inzake de responstijden.


99 van 150

10

Responstijden (RPT)

10.1 Inleiding De responstijden genoemd in hoofdstuk 4 zijn gebruikerswensen en tellen vanaf het geven van het commando op het GBZ tot en met (het begin van) het tonen van het antwoord op het GBZ. De onderstaande tabel geeft de gemiddelde responstijden voor de verschillende gebruikersinteracties. Gebruiksscenario

Gemiddelde Interactiemechanisme met responstijd

ZIM

[INL] in/uitloggen gebruiker [INL.s01] inloggen [INL.s04] uitloggen

5 sec 2 sec

indirect opvragen -

[SPA] selecteren patient/cliënt [SPA.s02] nieuwe patiënt [SPA.s01] ingeschreven patiënt

5 sec 2 sec

indirect opvragen -

[SZA] selecteren zorgadresboek [SZA.s01] opzoeken zorgaanbieder [SZA.s02] opvragen bereikbaarheid [SZA.s03] bijwerkenZorgadresboek

2 sec 2 sec 2 sec

[BIJ] bijhouden patiëntgeg. [BIJ.s01] toevoegen gegevens [BIJ.s02] verwijderen gegevens

2 sec 2 sec

-

[PUB] publiceren patiëntgegevens [PUB.s01] vrijgeven gegevens [PUB.s02] afschermen gegevens [ABO] abonneren patiëntgegevens

2 sec 2 sec

direct versturen direct versturen

[ABO.s01] aanmelden abonnement [ABO.s02] afmelden abonnement

2 sec 2 sec

direct versturen direct versturen

[OPV] opvragen patiëntgegevens [OPV.s01] opvragen index [OPV.s02] opvragen gegevens [STU] versturen patiëntgegevens

2 sec 5 sec

direct opvragen indirect opvragen

[STU.s01] versturen opdracht [STU.s02] ontvangen opdracht [STU.s03] klaarzetten opdracht [STU.s04] ophalen opdracht [OVD] overdragen patiëntgegevens

3 2 2 5

sec sec sec sec

indirect versturen direct versturen indirect opvragen

[OVD.s01] verzoeken overdracht [OVD.s02] beantwoorden [OVD.s03] afronden [ASL] open-/dichtzetten applicatie [ASL.s01] openzetten [ASL.s02] synchroniseren

3 sec 3 sec 3 sec

indirect versturen indirect versturen indirect versturen

5 sec onbepaald

direct versturen

100 van 150


[ASL.s03] dichtzetten

2 sec

-

De genoemde tijden zijn gewenste gemiddelden, met uitschieters naar boven als gevolg van piektijden. 90% van de responstijden moeten blijven binnen het dubbele van de gewenste gemiddelde responstijden. De responstijden moeten worden gehaald bij de capaciteit gegeven in paragraaf 9. Zoals aangegeven in de bovenstaande tabel, leiden sommige gebruikersinteracties tot een keten van interacties plaats tussen GBZ, ZIM en andere GBZ’en, dan wel een register. De overige gebruikersinteracties worden geheel binnen het GBZ afgehandeld. De onderstaande tabel geeft voor de verschillende interactiemechanismen aan hoe de afzonderlijke systemen moeten bijdragen in de responstijden voor de verschillende gebruikers. Interactiemechanisme direct versturen versturen

Gem.

Aandeel

Aandeel

Aandeel

Aandeel

Aandeel

respons

GBZ

DCN

ZIM

DCN

ander

tijd 2 sec

bevestigen direct opvragen opvragen

0,1

1,2

0,3

0,1

0,3

0,1

0,3

0,1

0,3

0,1

0,5

0,1

0,3

0,1

0,5

0,1

0,3

0,1

1,0

0,1

0,3

0,1

1,0

0,1

1,2

3 sec

bevestigen indirect opvragen opvragen

0,3 2 sec

opleveren indirect versturen versturen

systeem

1

5 sec

opleveren

2

Merk op dat het om streefcijfers gaat, die zijn afgeleid van de voor gebruikers gewenste responstijden. De cijfers veronderstellen dat een SSL/TLS-sessie tussen GBZ en ZIM vooraf tot stand is gekomen als gevolg van vooraf inloggen door de gebruiker. De verschillende interactiemechanismen en hun doorlooptijden resp. vertragingstijden worden uitgewerkt in de navolgende paragrafen.


101 van 150

10.2 Indirect versturen De onderstaande figuur, afgeleid van die uit paragraaf 5.2, geeft aan welke schakels in de keten bijdragen aan de totale responstijd.

:opdracht gever

:GBZ1

:ZIM

: GBZ2

opdracht geven

1 2 3 4

opdracht opdracht

respons tijd

verwerken opdracht bevestiging

5 6 7 8 9

bevestiging presenteren terugmelding

De onderstaande tabel geeft aan welke doorlooptijden per schakel gelden: Nr. 1

Systeem GBZ

2 3

DCN ZIM

4 5

DCN GBZ

6 7

DCN ZIM

8 9

DCN GBZ Keten

Actie opdrachtbericht samenstellen opdrachtbericht versturen transporteren bericht opdrachtbericht uitlezen opdrachtbericht doorsturen naar bestemde GBZ transporteren bericht opdrachtbericht uitlezen patiëntbericht afleveren in postbus bevestiging terugsturen transporteren bericht bevestigingen uitlezen bevestigingen zonodig bundelen bevestigingen gedoseerd terugsturen transporteren bericht bevestiging uitlezen bevestiging presenteren op scherm Totale responstijd

Tijd 0,3 sec 0,1 sec 0,5 sec 0,1 sec 1 sec

0,1 sec 0,5 sec

0,1 sec 0,3 sec 3 sec

Voor direct versturen geldt eigenlijk hetzelfde, behalve dat de stappen 4, 5 en 6 vervallen en dat stap 3 en 7 worden samengevoegd tot één stap van 1,2 sec.

102 van 150


10.3 Indirect opvragen De onderstaande figuur, afgeleid van die uit paragraaf 5.3, geeft aan welke schakels in de keten bijdragen aan de totale responstijd.

:GBZ1

:opdracht gever

:ZIM

: GBZ2

opvragen

1 2 3 4

opvraag opvraag

respons tijd

5

opzoeken resultaten oplevering (resultaten)

6 7 8 9

oplevering (resultaten) presenteren resultaten

De onderstaande tabel geeft aan welke doorlooptijden per schakel gelden: Nr. 1

Systeem GBZ

2 3

DCN ZIM

4 5

DCN GBZ’en

6 7

DCN ZIM

8 9

DCN GBZ Keten

Actie opvraagbericht samenstellen opvraagbericht versturen transporteren bericht opvraagbericht uitlezen patiënt opzoeken in verwijsindex opvraagbericht divergeren naar relevante GBZ’en transporteren bericht opvraagbericht uitlezen patiëntstukken opzoeken in patiëntdossier opleverbericht samenstellen opleverbericht terugsturen transporteren bericht opleverberichten uitlezen opleverberichten zonodig bundelen opleverberichten gedoseerd terugsturen transporteren bericht eerste opleverbericht uitlezen inhoud presenteren op scherm Totale responstijd

Tijd 0,3 sec 0,1 sec 1 sec

0,1 sec 2 sec

0,1 sec 1 sec

0,1 sec 0,3 sec 5 sec

Voor direct opvragen geldt eigenlijk hetzelfde, behalve dat de stappen 4, 5 en 6 vervallen en dat stap 3 en 7 worden samengevoegd tot één stap van 1,2 sec.


103 van 150

11

Betrouwbaarheid (BTW)

11.1 Inleiding Betrouwbaarheid van een systeem wordt (conform IEC 61508) gedefinieerd als de kans dat het systeem functioneert zoals het is gespecificeerd. Hierbij kan het begrip systeem in de meest ruime betekenis worden opgevat. Omdat een betrouwbaarheid van 100% nooit gegarandeerd kan worden, wordt meestal geëist dat het systeem tenminste een aantal te verwachten uitzonderingscondities (foutconditiesmet fout in de meeste ruime betekenis van afwijking van de normale procesgang) detecteert, eventueel corrigeert en anders meldt aan de gebruikers en/of beheerders, zodanig dat die gebruikers en/of beheerders weten hoe ze met de conditie moeten omgaan. Binnen één systeem kunnen fouten optreden in de volgende categorieën: • momentaan, bijv. een tijdelijke overbelasting van het systeem, waardoor de gebruiker even geen respons krijgt. Voor dergelijke fouten geldt dat een gebruiker het over enkele minuten nog maar eens moet proberen. Als het systeem dergelijke fouten signaleert en de gebruiker een adequate foutmelding geeft, kan worden voorkomen dat de beheerder onnodig wordt opgeroepen. • systematisch, bijv. een programmatuurfout die zich in specifieke gevallen manifesteert, of een foutief ingestelde configuratieparameter, waardoor de gebruiker onverwachte respons krijgt. Dergelijke fouten vergen maatregelen van de beheerder of leverancier. Zij worden vaak opgeroepen nadat de gebruiker heeft geconstateerd dat de fout bij het systeem ligt. • voortdurend, bijv. vastlopende programmatuur of stroomuitval, waardoor het systeem onbeschikbaar wordt voor de gebruiker. Dergelijke fouten vergen snel ingrijpen van de beheerder. Die wordt ook vaak snel ingeroepen door de gebruikers, als de beheerder de fout niet reeds zelf herkend heeft. De basisinfrastructuur in de zorg omvat de ZIM met alle aangesloten registers en GBZ’en, inclusief de DCN’en en andere ondersteunende faciliteiten. Dit betekent dat fouten als onderdeel van een (keten van) interactie(s) tussen GBZ, ZIM, SBV, UZIregister, etc. door die afzonderlijke systemen moeten worden herkend en zonodig teruggemeld aan andere systemen. Tussen onderling communicerende systemen kunnen fouten optreden in de volgende categorieën: • momentaan, bijv. een zoekgeraakt bericht, waardoor het zendende systeem geen respons krijgt van het bestemde systeem. Voor dergelijke fouten geldt dat het zendende systeem het nog maar eens moet proberen. Zo kan worden voorkomen dat de gebruiker onnodig een foutmelding krijgt. • systematisch, bijv. foutieve berichtinhoud, waardoor het ontvangende systeem de gevraagde functie niet kan uitvoeren. Voor dergelijke fouten moet het ontvangende systeem een foutmelding retourneren naar het zendende systeem. Het systeem die de fout heeft veroorzaakt moet zijn beheerder of leverancier inlichten, al dan niet opgeroepen door de gebruiker, die onverwachte respons van zijn systeem heeft gekregen.

104 van 150


• voortdurend, bijv. uitgevallen netwerk of systeem, waardoor andere systemen daarmee geen verbinding kunnen krijgen. Dergelijke fouten vergen snel ingrijpen van de beheerder die verantwoordelijk is voor het uitgevallen netwerk of systeem. Die beheerder moet kunnen worden gewaarschuwd door andere beheerders, mochten de eigen gebruikers dat nog niet gedaan hebben. In • • • • •

de volgende paragrafen wordt uitgewerkt: detecteren van uitzonderingscondities, bundelen van uitzonderingscondities, melden van uitzonderingscondities, afhandelen van uitzonderingscondities, de wijze waarop time-outs moeten worden afgehandeld alvorens ze als foutconditie in de zin van doel of bron onbereikbaar mogen worden beschouwd, in aparte paragrafen voor de interactiemechanismen indirect versturen en indirect opvragen.

Merk op dat bij geen van deze gebruikersinteracties sprake is van transacties in de zin van samengestelde (inter)acties die als één geheel moeten worden uitgevoerd en zonodig geheel teruggedraaid. De ACID-eisen (atomic, consistent, isolated, durable) die meestal worden gesteld aan dergelijke transacties, zouden ook te zwaar zijn voor een stelsel van een ZIM met vele duizenden GBZ’en die allemaal onder verantwoordelijkheid van zelfstandige zorgaanbieders vallen. Merk op dat niet voor 100% kan worden gegarandeerd dat geanticipeerde fouten altijd worden gesignaleerd en gecorrigeerd. Dit betekent dat gebruikers en beheerders nooit blind mogen vertrouwen op het systeem en dus enigszins alert moeten blijven op onvoorziene fouten en in geval van twijfel de telefoon moeten pakken. In de navolgende paragrafen wordt gesproken over interacties en verbindingen met een GBZ en het uitvallen van een GBZ. In geval van een GBZ met meerdere applicaties die afzonderlijk communiceren met de ZIM, moet “GBZ-applicatie” worden gelezen in plaats van “GBZ”.


105 van 150

11.2 Uitzonderingen in de keten De meeste AORTA-interacties vinden als volgt plaats, zoals ook afgebeeld in de onderstaande figuur: • een GBZ-gebruiker doet een verzoek aan zijn GBZ • het GBZ stuurt een HL7-verzoekbericht naar de ZIM • de ZIM autoriseert het verzoekbericht • voor sommige interacties handelt de ZIM zelf het verzoek af, anders: o stuurt de ZIM het verzoekbericht door naar een Register of naar één of meer GBZ’en o handelt het Register resp. handelen de GBZ’en het verzoek af o stuurt het Register resp. sturen de reagerende GBZ’en een HL7antwoordbericht terug aan de ZIM • de ZIM bundelt zonodig de ontvangen HL7-antwoordberichten en stuurt één HL7antwoordbericht naar het agerende GBZ • het GBZ presenteert het antwoord aan de gebruiker. Een antwoord bevat vaak inhoudelijke resultaten, zoals na een opvraag, maar soms ook slechts een bevestiging, zoals na het versturen van een opdracht (bijv. labaanvraag) waarvan het resultaat later via een andere AORTA-interactie (bijv. labuitslag) wordt teruggestuurd. Merk op dat sommige verzoeken van gebruikers kunnen leiden tot meervoudige verzoekberichten vanuit hun GBZ. Bijvoorbeeld het opvragen van de verwijsindex kan ‘onder water’ leiden tot vele verzoekberichten om de zorgaanbieder-id’s te vertalen naar namen en locaties.

verzoek

1

verzoekbericht

2

GBZ GBZ gebruiker

antwoord met resultaat en/of melding

3

5

verzoekbericht

12

antwoordbericht met resultaat en/of melding

11

10

9

6

GBZx GBZx of GBZx 7 Register

ZIM 4 antwoordbericht met resultaat en/of melding

8

In elke schakel van die keten kan zich een omstandigheid voordoen, waardoor moet worden afgeweken van de normale afhandeling van het verzoek. We spreken hier over uitzonderingen. Het gaat bij AORTA-interacties niet alleen om fouten, maar ook om onverwachte antwoorden, zoals het geval dat er geen resultaten gevonden zijn. Een verklarende melding “geen resultaten gevonden” kan de gebruiker duidelijk maken dat er juist geen fouten zijn opgetreden. Elk systeem in de keten kan een uitzondering detecteren en een melding daarvan in het antwoordbericht terugsturen naar het vorige systeem in de keten, die het zonodig verder terugstuurt, zodat de GBZ-gebruiker uiteindelijk een melding op zijn scherm krijgt. Zo’n melding zal veelal in plaats van het verwachte resultaat komen, maar kan ook samen met een (onvolledig) resultaat komen. Bijvoorbeeld wanneer een opvraag van patiëntgegevens leidt tot een onvolledig antwoord, omdat een GBZ genoemd in de VWI niet bereikbaar was. De GBZ-gebruiker moet dan worden gemeld dat de gepresenteerde patiëntgegevens niet volledig zijn.

106 van 150


Omdat bij het opvragen van patiëntgegevens meerdere reagerende GBZ’en betrokken zijn, kan ieder GBZ een aparte melding terugsturen, die door de ZIM kunnen worden bewerkt tot zinvolle meldingen voor de GBZ-gebruiker. Zo wil de GBZ-gebruiker bij een onvolledig resultaat wellicht weten van welke zorgaanbieders de patiëntgegevens ontbreken. Het is echter ook mogelijk dat het agerende GBZ genoegen neemt met een onvolledig resultaat, waardoor de GBZ-gebruiker een antwoord zonder melding krijgt. Bijvoorbeeld de eerdergenoemde situatie van verwijsindex waarin enkele zorgaanbiederid’s niet zijn vertaald naar namen en plaatsen. De meeste uitzonderingen zullen ertoe leiden dat een verzoek van een GBZ-gebruiker niet leidt tot het gewenste resultaat. Hier spreken we van een fout. Meestal zal het detecterende systeem dan de afhandeling van het verzoek voortijdig moeten afbreken en zo mogelijk een foutmelding moeten terugsturen naar de GBZ-gebruiker.


107 van 150

11.3 Detecteren van uitzonderingen Bij de afhandeling van een AORTA-interactie kan een uitzonderingsconditie worden gedetecteerd door verschillende systemen op verschillende momenten, zoals afgebeeld in de onderstaande figuur:

verzoek

1

GBZ GBZ gebruiker

14

antwoord met resultaat en/of melding

melding

GBZ beheerder

verzoekbericht

2


3

4

6

ZIM 5 13 12

11

melding

LSP beheerder

verzoekbericht

8

7

10


GBZx GBZx of GBZx 9 Register

melding

GBZx of Register beheerder

Een uitzonderingsconditie kan worden gedetecteerd door: 1. agerende GBZ bij het versturen van een verzoekbericht: 2. agerende GBZ én de ZIM tijdens het transport van een verzoekbericht 3. ZIM bij het uitlezen van een verzoekbericht: 4. ZIM bij het authenticeren en autoriseren van een verzoek: 5. ZIM bij het afhandelen van een verzoek: 6. ZIM bij het doorsturen van een verzoekbericht: 7. ZIM én reagerende GBZ of Register tijdens het transport van een verzoekbericht 8. reagerende GBZ of Register bij het uitlezen van een verzoekbericht: 9. reagerende GBZ of Register bij het afhandelen van verzoek 10. reagerende GBZ of Register bij het versturen van een antwoordbericht 11. ZIM na het (niet) ontvangen van een antwoordbericht: 12. ZIM bij het eventuele bundelen van antwoorden 13. ZIM bij het doorsturen van een antwoordbericht 14. agerende GBZ na het (niet) ontvangen van een antwoordbericht. Tenslotte kan een agerende GBZ vele gebruikersfouten detecteren op het moment dat de gebruiker een verzoek invoert. Deze lokale foutafhandeling valt echter buiten het aandachtsgebied van AORTA. Welke uitzonderingen kunnen optreden bij het lokaal invoeren van een verzoek, hangt sterk af van de GBZ-applicatie. Daarbij hebben de zorgaanbieder en zijn XIS-leverancier primair hun eigen verantwoordelijkheid. Bij 1, 6, 10 en 13 gaat het veelal om DCN-fouten waardoor een verzoekbericht resp. een antwoordbericht überhaupt niet kon worden verstuurd. Deze uitzonderingen worden meestal gedetecteerd door de netwerk-apparatuur van het platform en vertaald naar de foutcodes van de desbetreffende protocol: SSL, TCP, IP.

108 van 150


Bij 2 en 7 gaat het veelal om GBZ- of ZIM-fouten waardoor een verzoekbericht resp. een antwoordbericht niet correct kon worden getransporteerd. Deze uitzonderingen worden deels gedetecteerd door de webserver van zowel GBZ als ZIM en dan vertaald naar HTTP- of SOAP-foutcodes. Anders worden deze gedetecteerd door de applicatie met behulp van XML-gereedschappen en vertaald naar een HL7-AcknowledgementDetailCode. Deze code wordt in latere instantie bij 3, 8 en 11 meegegeven in de HL7-transmission wrapper van het antwoordbericht. Bij 3, 8, 11 en 14 gaat het veelal om GBZ- of ZIM-fouten waardoor een verzoekbericht resp. een antwoordbericht niet kon worden geïnterpreteerd. Deze uitzonderingen worden deels gedetecteerd met behulp van XML-gereedschappen en vertaald naar een HL7AcknowledgementDetailCode. Bij 3, 8 en 11 wordt deze code meegegeven in de HL7transmission wrapper van het antwoordbericht. Bij 4, 5 en 9 gaat het veelal om gebruikersfouten waardoor een verzoek niet kon worden ingewilligd of om het feit dat er gewoon geen resultaten waren. Bij 12 gaat het om uitzonderingen die worden gebundeld en daardoor een nieuwe uitzondering kunnen opleveren. Al deze uitzonderingen worden meestal gedetecteerd door de applicatieprogrammatuur en vertaald naar een HL7-ActDetectedIssueCode. Deze code wordt teruggegeven in de HL7-controlact wrapper van het antwoordbericht. Bovenstaande indeling is overigens niet normatief voor een GBZ of de ZIM. Dat wil zeggen: een fout die door de ZIM uiterlijk bij 5 moet worden gedetecteerd, mag door de ZIM ook reeds bij 2 worden afgevangen. Denk bijvoorbeeld aan de fout “interactie wordt niet ondersteund”, die kan duiden op een denial of service attack. Evenzo: een fout die door de ZIM bij 2, 3, 4, 5 of 6 moet worden gedetecteerd, mag ook door een GBZ bij 1 al worden afgevangen. Denk bijvoorbeeld aan de fout “niet bevoegd op grond van autorisatieprotocol”, waarvan het voortijdig afvangen een verlichting is voor het DCN en de ZIM en misschien ook voor het GBZ zelf. Omgekeerd geldt dat aan een teruggekregen foutmelding nooit rechten ontleend kunnen worden. Bijvoorbeeld: als een XIS-applicatie op een HL7-bericht geen INVALXSDfoutmelding terugkrijgt van de ZIM, betekent dat niet noodzakelijkerwijze dat het HL7bericht correct valideert tegen de XSD. Immers, misschien had de ZIM geen XSDvalidatie gedaan.


109 van 150

11.4 Bundelen van uitzonderingen Bij het opvragen van patiëntgegevens zal de ZIM vaak meerdere GBZ-applicaties als bron van patiëntgegevens aantreffen in de verwijsindex en deze aldus bevragen. Voor elk van die GBZ-applicaties kunnen de foutcondities optreden genoemd onder 5, 7, 8, 9, en 11 in paragraaf 11.3. Het kan nuttig zijn meerdere foutcondities te signaleren aan de gebruiker. Maar het is verstandig daarbij de stapeling van foutmeldingen te beperken door de ZIM enige regels te laten toepassen: •

voor elke GBZ-applicatie die zoekresultaten oplevert, worden deze resultaten geconvergeerd naar het opvragende GBZ,

•

voor elke GBZ-applicatie die een foutconditie terugmeldt, wordt het hele foutbericht teruggemeld aan het opvragende GBZ, onder vermelding van de onbereikbare GBZapplicaties.

•

voor elke GBZ-applicatie die onbereikbaar of niet gekwalificeerd blijkt, maakt de ZIM een bericht aan waarin wordt teruggemeld aan het opvragende GBZ dat niet alle resultaten compleet zijn, onder vermelding van de onbereikbare GBZ-applicaties,

waarbij al deze berichten in willekeurige volgorde, gebundeld worden opgeleverd aan het opvragende GBZ. GBZ appl.11

6 doelapplicatie niet gekwalificeerd

GBZ appl.12

6 doelapplicatie niet bereikbaar

GBZ appl.13

8 syntaxfout

GBZ appl.14

8 doelapplicatie overbelast

Query Response 15,AE,??? QE,,,, PARAOB

GBZ appl.15

9 onjuiste parameter

Query Response 16,AR,??? AE,,,, ???

GBZ appl.16

Query Response 17,AA,??? NF, 0, 0, 0

GBZ appl.17

Query Response 18,AA,???

GBZ appl.18

Query Request Batch

VWI

1,AA Query Response 1,CE,NS200,11

appl.11 appl.12 appl.13 appl.14 appl.15 appl.16 appl.17 appl.18

Query Response 1,CR,RTEDST,12 Query Response 1,CE, SYNxxx,13 Query Response 1,CR,NOSTOR,14

GBZ appl 10

Query Response 1,AE,???,15 QE,,,, PARAOB Query Response 1,AR,???,16 AE,,,, ??? Query Response 1,AA,???,17 NF, 0, 0, 0 Query Response 1,AA,???,18 OK, 2, 2, 0

110 van 150

ZIM appl 1

Query Response 13,CE,SYNxxx

Query Response 14,CR,NOSTORE

9 gegevens afgeschermd of niet aanwezig

OK, 2, 2, 0


Het opvragende GBZ moet na ontvangst van het laatste bericht ervoor zorgen dat de opvragende gebruiker wordt ingelicht: •

dat niet alle zoekresultaten compleet zijn, mocht voor één van de GBZ’en een fout zijn gesignaleerd,

•

dat de gebruiker het later nog eens kan proberen, mocht voor één van de GBZ’en een momentane fout zijn gesignaleerd,

•

dat de gebruiker zonodig kan gaan bellen naar de beheerverantwoordelijke zorgaanbieder, mocht voor één van de GBZ’en een systematische fout zijn gesignaleerd,

Tenslotte moeten alle GBZ’en en de ZIM een structurele fout melden aan de GBZsysteembeheerders resp. ZIM-systeembeheerders.


111 van 150

11.5 Melden van uitzonderingen Als voor een AORTA-interactie ergens in de keten een uitzondering wordt gedetecteerd, zal behalve aan de initiërende GBZ-gebruiker vaak ook aan de beheerders van de betrokken systemen in die keten moeten worden gemeld. Opdat de gebruiker en beheerders van andere systemen de juiste melding krijgen, moet het detecterende systeem voor een bepaalde uitzondering een voorgeschreven meldingcode meegeven in het antwoordbericht. Opdat de meldingtekst voldoende details bevat om de juiste herstelacties te kunnen ondernemen, moet het detecterende systeem voor een bepaalde uitzondering ook de voorgeschreven details meegeven in het antwoordbericht. Merk op dat de meldingtekst voor de ZIM- en GBZ-beheerders bepaalde details kan bevatten die voor de GBZ-gebruiker niet interessant zijn. Zo zullen beheerders bijv. geïnteresseerd zijn in de applicatie-id van de reagerende GBZ-applicatie die een fout veroorzaakte, terwijl de GBZ-gebruiker hooguit wil weten van welke zorgaanbieder daardoor gegevens ontbreken. De exacte meldingtekst die de GBZ-gebruiker, GBZ-beheerder, etc. op zijn scherm krijgt, kunnen wij niet voorschrijven, de strekking ervan wel. Iedere XIS-leverancier kan dan zelf bepalen welke meldingtekst het beste te begrijpen is voor zijn doelgroep, het beste past bij de andere meldingen van zijn XIS-applicatie en hoe die tekst wordt toegesneden op de specifieke situatie. Daarbij heeft de XIS-leverancier de vrije keuze om in de meldingtekst een advies voor de gebruiker en/of beheerder op te nemen voor het eventueel herstellen van de uitzondering. Opdat de verschillende GBZ-beheerders eenduidig met de ZIM-beheerder kunnen communiceren, ondanks dat hun systemen voor eenzelfde uitzondering verschillende meldingteksten kunnen tonen, is het belangrijk dat behalve de vrije meldingtekst wel steeds een voorgeschreven meldingcode wordt getoond. Hierbij kunnen we ervoor kiezen om de eerdergenoemde protocolafhankelijke codes te tonen, of een AORTA-eigen identificatie van de uitzondering. De laatste optie heeft de volgende voordelen: • protocolonafhankelijk, dus geen wijzigingen als we ooit andere protocollen kiezen, • meer exacte identificatie van de opgetreden uitzondering, en de volgende nadelen: • de ZIM en alle GBZ’en moeten de protocolonafhankelijke foutcodes steeds vertalen naar AORTA-eigen codes, • meer onderhoud in geval van wijzigingen. Voorlopig wordt gekozen voor de eerste optie: protocolafhankelijke codes. Het voordeel van een code boven een meldingstekst is tenslotte dat deze automatisch verwerkt kan worden door een applicatie. bijv. om een bericht opnieuw te sturen als deze als gevolg van een tijdelijke conditie niet ontvangen kon worden. Op deze wijze hoeft een gebruiker niet onnodig lastig te worden gevallen met een foutmelding. Of dit mechanisme wenselijk is, moet per conditie worden afgewogen. Bij het kiezen van protocolafhankelijke meldingcodes zijn we natuurlijk gehouden aan de voorschriften die zijn gedefinieerd voor het desbetreffende protocol. Zo is het gebruik

112 van 150


van HTTP- en SOAP-meldingcodes gedefinieerd in de “WS-I Basic Profile” en nog eens aangehaald in de “Implementatiehandleiding Berichttransport” paragraaf 5.5. Ook HL7v3 heeft meldingcodes gedefinieerd, zie onder meer de “Implementatiehandleiding Berichtwrappers” paragraaf 4.2 en 5.1. Maar HL7v3 geeft de vrijheid om zelf ook een tabel met nieuwe HL7-meldingcodes te definiëren. Dat heeft de ZIM-leverancier dan ook gedaan voor de ZIM, omdat de oorspronkelijke HL7-meldingcodes niet toereiken. NICTIZ is gevraagd deze LSP-tabel te publiceren, opdat XIS-leveranciers deze meldingcodes kunnen interpreteren, zie “Implementatiehandleiding Berichtwrappers” paragraaf 6.1. Wanneer XIS-leveranciers de behoefte hebben om HL7-meldingcodes te definiëren en beschikbaar te maken voor andere XIS-leveranciers en de ZIM-leverancier, zou dezelfde tabel gebruikt kunnen worden. Dit zou dan een AORTA-tabel in plaats van LSP-tabel worden. HL7v3 staat ook toe om meerdere meldingcodes in een antwoordbericht te plaatsen. Dit geeft de XIS-leveranciers en de ZIM-ontwikkelaar de mogelijkheid een nieuwe, meer specifieke HL7-meldingcode toe te voegen aan een reeds gedefinieerde HL7meldingcode, zonder dat die nieuwe code al is (of ooit wordt) gepubliceerd. Het ontvangende XIS of ZIM kan onbekende meldingcodes negeren. In de bijlage [Technische architectuur BijlageC] zijn alle uitzonderingen op systematische wijze geïnventariseerd, door parallellen te trekken tussen de verschillende AORTAinteracties. Dit heeft geleid tot een tabel met, in essentie: • op iedere rij een generieke uitzonderingsconditie, • in iedere kolom een AORTA-interactie, • op ieder kruispunt een indicatie of de conditie zich kan voordoen voor die interactie. Daarnaast is voor iedere conditie aangegeven: • Type: indicatie of er sprake is van een fout, en zo ja, waar die ligt: bij de gebruiker, het GBZ of de ZIM. • Reactie: wat het detecterende systeem moet doen na detectie van deze uitzondering. • Code: de meldingcode die moet worden meegegeven in een antwoordbericht om de uitzondering te signaleren aan een ander systeem, dan wel moet worden gelogd. • Details: de details omtrent de gesignaleerde conditie die met de meldingcode moet worden meegegeven in een antwoordbericht, indien het protocol dat toelaat. • Meldingtekst: de strekking van de meldingtekst die aan de GBZ-gebruiker en de respectievelijke beheerders getoond moet worden na optreden van deze uitzondering. • Herstelacties: de acties die een gebruiker en/of beheerder kan of moet uitvoeren na de uitzondering. Let op: de tabel is niet bedoeld om te eisen dat een GBZ of ZIM al deze uitzonderingen moet signaleren (want dat moet in aparte GBZ-eisen en LSP-eisen terugkomen). De tabel is wel bedoeld te bepalen welke foutcodes gebruikt moeten worden, indien een bepaalde uitzondering wordt gesignaleerd.


113 van 150

11.6 Afhandelen van uitzonderingen Het is belangrijk dat een foutmelding aan de GBZ-gebruiker niet alleen vertelt dat zijn verzoek niet kon worden ingewilligd, maar ook vertelt welke actie hij eventueel kan of moet ondernemen om zijn werk met zijn GBZ te kunnen voortzetten. Hierbij wordt onderscheid gemaakt tussen: • gebruikersfouten die door de gebruikers zelf kunnen worden hersteld, • GBZ-fouten waarvoor de hulp van de GBZ-beheerder moet worden ingeroepen, • ZIM-fouten waarvoor de hulp van de ZIM-beheerder moet worden ingeroepen. • DCN-fouten waarvoor de hulp van de DCN-beheerder moet worden ingeroepen. De GBZ-gebruiker kan zonodig zelf zijn GBZ-beheerder inroepen, die zonodig de ZIMbeheerder en/of de DCN-beheerder inroept, etc. Zie verder [Bedrijfsarchitectuur]. Sommige foutmeldingen zullen de GBZ-gebruiker niet bereiken, bijv. als gevolg van een uitgevallen ZIM. Daarom moeten de beheerders voor GBZ- en ZIM-fouten sowieso ook van hun eigen systemen een foutmelding krijgen, bijv. via een alarmlog. Vooral de ZIMbeheerder moet hier alert zijn en zonodig de GBZ-beheerders aanspreken op fouten in hun GBZ. Zie de onderstaande figuur, waarbij de stippellijnen aanduiden dat de melding van een incident vermoedelijk telefonisch of per e-mail verloopt.

verzoek

GBZ gebruiker

GBZ 1

verzoekbericht

2

3 5 ZIM

verzoekbericht

4

alarmlog 12 antwoordbericht 11 alarmlog 10 9 antwoordbericht antwoord met resultaat met resultaat met resultaat en/of melding en/of melding en/of melding van uitzondering uitzondering uitzondering LSP

incident Zorgaanbieder

incident GBZ beheerder ZSP

GBZx of Register beheerder ZSP incident

incident DCN beheerder

uitzondering

incident LSP beheerder

incident

of 6GBZx GBZx GBZx 7 Register 8 alarmlog

DCN beheerder

Afhankelijk van de herstelbaarheid van een fout, kan de gebruiker het verzoek binnen korte of langere tijd opnieuw doen. Hierbij wordt onderscheid gemaakt tussen: • momentane condities, zoals kortstondige netwerkstoringen, waarvoor geen herstelactie nodig is, zodat de gebruiker het meteen opnieuw kan proberen, • herstelbare condities, zoals een structurele systeemfout, waarvoor de beheerder en eventueel ook de leverancier moet worden ingeschakeld, zodat de gebruiker moet wachten op het sein dat alles hersteld is, • onveranderlijke condities, zoals gebruikersfouten doordat een zorgverlener niet geautoriseerd is op grond van zijn functie.

114 van 150


De herstelbaarheid bepaalt ook in sterke mate of een optredende uitzondering moet worden gemeld aan een GBZ- of ZIM-beheerder. Zo is een beheerder veelal niet geïnteresseerd in gebruikersfouten en kortstondige storingen, tenzij die vaak optreden. In geval van (vermoede) kortstondige storingen kan ook het agerende GBZ of de ZIM eventueel automatisch opnieuw proberen een verzoekbericht te versturen, voordat de GBZ-gebruiker wordt lastiggevallen met een foutmelding. Het bovenstaande gaat uit van een bonafide GBZ-gebruiker, die dus moet worden geholpen aan voldoende informatie zodat hij verder kan met zijn GBZ. Een malafide GBZ-gebruiker moet daarentegen zo weinig mogelijk informatie krijgen, anders wordt hij bijv. geholpen bij het vinden van eventuele zwakke plekken in de beveiliging van AORTA. Dit geldt ook voor de hacker die met malafide programmatuur in het GBZ de UZI-pas van een bonafide GBZ-gebruiker misbruikt voor het versturen van malafide berichten naar het LSP. Het is daarom verstandig om voor elke foutconditie te bepalen of de fout kan voortkomen uit malafide gebruik. Zo ja, dan moet worden geprobeerd de in foutmelding voldoende informatie te geven voor de bonafide GBZ-gebruikers en onvoldoende voor de malafide GBZ-gebruikers. Dit geldt vooral voor GBZ-applicatiefouten. Die kunnen worden op SOAP-niveau worden afgevangen door de web server, zodat eventuele hackers niet zo maar tot de ZIMapplicatie kunnen doordringen. Aldus wordt voorgesteld om potentiële aanvalsfouten op SOAP-niveau proberen af te vangen met weinigzeggende foutmeldingen, maar ook op HL7-niveau te ondervangen met veelzeggende foutmeldingen. Mocht een XISontwikkelaar tijdens het testen hardnekkig stuiten op een weinigzeggende foutmelding, dan kan de beschermingsconstructie eventueel tijdelijk worden losgelaten opdat de ZIMapplicatie kan openbaren wat er precies fout gaat.


115 van 150

11.7 Indirect versturen Wanneer een zorgverlener vanaf zijn GBZ1 een opdracht verstuurt via de ZIM naar het GBZ2 van een bestemde zorgaanbieder, ontvangt hij gewoonlijk van GBZ2 spoedig een bevestiging, dan wel een foutmelding. Zolang antwoord uitblijft, is hij in onzekerheid: • is het verzoekbericht ergens zoekgeraakt en heeft GBZ2 de opdracht niet ontvangen en dus ook niet verwerkt? • of is alleen het antwoordbericht zoekgeraakt en heeft GBZ2 de opdracht netjes ontvangen en misschien ook al verwerkt? • is een systeem of netwerk momenteel hoogbelast en zijn de berichten nog onderweg? Om het laatste te kunnen uitsluiten is een bevestig-time-out nodig, zowel voor het opdrachtgevende GBZ als voor zijn gebruiker: • GBZ-bevestig-time-out is het tijdsinterval waarna een opdrachtgevende GBZ1 geen bevestiging meer van het opdrachtnemende GBZ2 hoeft te verwachten. • gebruiker-bevestig-time-out is het tijdsinterval waarna de gebruiker geen bevestiging meer van zijn opdrachtgevende GBZ1 hoeft te verwachten. De opdrachtgevende zorgverlener zou na definitief uitblijven van antwoord, dezelfde opdracht nog eens willen versturen. Eventueel kan zijn GBZ dat eerst zelf automatisch doen, voordat de opdrachtgever wordt ingelicht over de mislukte poging. Door de GBZ-bevestig-time-out korter te zetten dan de gebruiker-bevestig-time-out, komt er enige ruimte voor GBZ1 om automatisch enkele (verstuur-retry) herhaalde pogingen te doen. GBZ1 moet dat 1 of hooguit 2 keer opnieuw proberen, anders kan een incidentele drukte in de ZIM leiden tot een kettingreactie van vele hernieuwd verstuurde berichten die de ZIM vervolgens doen overstromen. Zie onderstaande figuur, afgeleid van die uit paragraaf 5.2.

116 van 150


:opdracht gever

:GBZ1

:ZIM

: GBZ2

opdracht geven originele opdracht originele opdracht opdracht uitvoeren

gebruiker bevestig time-out (10 sec)

GBZ bevestig time-out (5 sec)

bevestiging

dezelfde opdracht dezelfde opdracht duplicaat detecteren waarschuwing waarschuwing presenteren bevestiging

Herhaald sturen van dezelfde opdracht kan niet zomaar, want een opdracht is in principe geen idempotente interactie. Dus, als GBZ2 de opdracht al had verwerkt, moet GBZ2 dezelfde opdracht niet opnieuw verwerken. Ook moet GBZ2 in de bevestiging aan GBZ1 een waarschuwing opnemen dat de opdracht al was verwerkt. Daartoe moet de opdrachtnemende GBZ2 een opdracht kunnen herkennen als duplicaat van een eerder verwerkte opdracht. Dat kan in theorie op verschillende niveau’s plaatsvinden: • transport-niveau: door het bericht te herkennen aan de hand van de bericht-id, • applicatie-niveau: door het bijgesloten patiëntstuk te herkennen aan de hand van de patiëntstuk-id. Hier wordt gekozen voor duplicaat-detectie op applicatie-niveau, want: • een GBZ dat is gekoppeld aan zowel de ZIM als aan een ander, legacy schakelpunt, loopt het risico eenzelfde opdracht, bijv. een medicatievoorschrift, langs beide wegen te ontvangen. Ook dan moet een GBZ in staat zijn een duplicaat te herkennen. • duplicaat-detectie op transport-niveau is ingewikkeld en wordt idealiter ondervangen in een betrouwbaar transportprotocol, bijv. WS-RM. • als ooit wordt gekozen voor een betrouwbaar transportprotocol, bijv. WS-RM, bestaat nog steeds het risico dat er berichten zoekraken, bijv. door onjuiste aansturing vanuit de applicaties. Feitelijk is hiermee ervoor gekozen om opdrachten idempotent te implementeren in de applicaties, met behulp van unieke patiëntstuk-id’s, zie paragraaf 11.11. {toekomst} Mocht er ooit voor worden gekozen om niet-idempotente opdrachten te implementeren, dan zal duplicaat-detectie alsnog op transport-niveau moeten worden afgehandeld, zie paragraaf 11.10. Duplicaat-berichten kunnen dan als volgt worden geïmplementeerd:


117 van 150

• •

• • •

•

het zendende GBZ1 kan na de GBZ-bevestig-time-out een duplicaat van het opdrachtbericht naar de ZIM sturen, de ontvangende ZIM moet een duplicaat van een eerder ontvangen opdrachtbericht kunnen herkennen en deze beantwoorden met een duplicaat van het bijbehorende bevestigbericht. Daartoe moet GBZ2 alle bevestigberichten na verzending gedurende GBZ-bevestigbericht-bewaartijd (= gebruiker-bevestig-time-out) bewaren. als het opvragende GBZ0 voor de ontvangst vanhet bevestigbericht of na die bewaartijd nog met een duplicaat komt, moet de ZIM een foutmelding geven. de zendende ZIM kan reeds na de ZIM-bevestig-time-out een duplicaat van het opdrachtbericht naar GBZ2 sturen. het opdrachtnemende GBZ2 moet een duplicaat van een eerder ontvangen opdrachtbericht kunnen herkennen en deze beantwoorden met een duplicaat van het bijbehorende bevestigbericht. Daartoe moet GBZ2 alle bevestigberichten na verzending gedurende GBZ-bevestigrbericht-bewaartijd (= gebruiker-bevestig-timeout) bewaren. als de ZIM na die bewaartijd nog met een duplicaat komt, moet GBZ2 een foutmelding geven.

Merk op dat het opdrachtnemende GBZ1 een idempotente opdracht opnieuw mag versturen, maar dan wel in een nieuw bericht, dus met uniek bericht-id, anders bestaat het risico dat bij invoering van een betrouwbaar transportprotocol deze onbedoeld worden afgevangen. Merk op dat de ZIM niet in de berichtinhoud van een opdracht kijkt en dus ook geen duplicaat-detectie op applicatie-niveau kan doen. De ZIM zal dus in bovenstaande figuur bij uitblijven van een bevestiging niet eigenhandig een duplicaat sturen, maar dit aan het opdrachtgevende GBZ overlaten. Merk op dat de ZIM geen opdrachtberichten persistent maakt. In theorie had de ZIM het opdrachtbericht na ontvangst persistent kunnen maken, opdat de ZIM na eventuele uitval resp. herstart de verweesde opdrachtberichten alsnog zou kunnen afleveren op bestemming. Voor opdrachtberichten die onmiddellijk afgeleverd moeten worden, zie architectuurbeslissing [BUW01], heeft dit echter weinig toegevoegde waarde en past het ook niet binnen de gekozen gebruiker-bevestig-time-out. Merk op dat de opdrachtgever geen enkele zekerheid heeft of de opdrachtnemer zijn HL7v3-opdracht heeft ontvangen totdat zijn GBZ1 de HL7v3-ontvangstbevestiging presenteert. Daarom moet de opdrachtnemer of diens GBZ1 tot dat moment de HL7v3opdracht altijd opnieuw kunnen versturen. Zelfs al heeft de opdrachtgever de HL7v3opdracht allang verwerkt. De opdrachtgever en diens GBZ2 moeten er dus rekening mee houden dat zij duplicaten van HL7v3-opdrachten kunnen ontvangen, zie paragraaf 11.10. Merk op dat de opdrachtnemer nooit zekerheid heeft dat de opdrachtgever zijn HL7v3ontvangstbevestiging heeft ontvangen. Dit als gevolg van de beslissing om geen ontvangstbevestiging op ontvangstbevestiging te sturen.

118 van 150


11.8 Indirect opvragen Wanneer een zorgverlener vanaf zijn GBZ0 gegevens opvraagt via de ZIM bij allerlei andere GBZ’en of een register, krijgt hij gewoonlijk van de ZIM spoedig de resultaten opgeleverd, dan wel een foutmelding. Zolang antwoord uitblijft, is hij in onzekerheid: • is het verzoekbericht zoekgeraakt en hebben de ZIM of de opleverende systemen de opvraag niet ontvangen en dus ook niet beantwoord? • of is alleen het antwoordbericht zoekgeraakt en hebben de ZIM of de opleverende systemen de opvraag netjes ontvangen en beantwoord? • is een systeem of netwerk momenteel hoogbelast en zijn de berichten nog onderweg? Om het laatste te kunnen uitsluiten is een oplever-time-out nodig, zowel voor de gebruiker als voor het opvragende GBZ en de ZIM: • gebruiker-oplever-time-out is het tijdsinterval waarna de gebruiker geen oplevering meer van zijn opdrachtgevende GBZ1 hoeft te verwachten. • GBZ-oplever-time-out is het tijdsinterval waarna een opvragende GBZ1 geen oplevering meer van de ZIM hoeft te verwachten. • ZIM-oplever-time-out is het tijdsinterval waarna de ZIM geen oplevering meer van een opleverende GBZx hoeft te verwachten. De opvragende zorgverlener zou na definitief uitblijven van antwoord, dezelfde opvraag willen herhalen. Eventueel kan zijn GBZ0 dat eerst zelf automatisch doen, voordat de opdrachtgever wordt ingelicht over de mislukte poging.

De afhankelijkheden tussen de verschillende time-outs in bovenstaande figuur is te vinden in onderstaande tabel: Gebruiker_oplever_timeout (t)


Tijdsinterval in seconden van gebruiker waar binnen moet worden opgeleverd aan gebruiker

t ≥ GBZ_oplever-timeout

119 van 150

uiterste-oplevertijd_GBZ (t)

GBZ-oplever-time-out (t)

uiterste-oplevertijd_ZIM (t)

ZIM_oplever-time-out

Het tijdstip waarop het GBZ uiterlijk een antwoord verwacht op een opvraag (huidige tijd is actuele systeemtijd). tijdsinterval in seconden na HL7v3-opvraag van GBZ aan ZIM waarbinnen HL7v3-oplevering moet zijn ontvangen (huidige tijd is actuele systeemtijd). Het tijdstip waarop het ZIM uiterlijk een antwoord verwacht op een opvraag. tijdsinterval na HL7v3-opvraag van ZIM aan GBZ waarbinnen HL7v3-oplevering moet zijn ontvangen.

t=huidige tijd + GBZoplever-time-out verstekwaarde: huidige tijd + 60 seconden 5s < t < gebruikermaxsessie-onbruik

uiterste-oplevertijd_GBZ (t) – reponstijd. initële responstijd: 2 seconden Uiterste_oplevertijd_ZIM - huidige tijd

Door de GBZ- resp. ZIM-oplever-time-out korter te zetten dan de gebruiker-oplevertime-out, komt er enige ruimte voor GBZ1 resp. de ZIM om automatisch enkele (opvraag-retry) hernieuwde pogingen te doen. GBZ1 en ZIM moeten dat 1 of hooguit 2 keer opnieuw proberen, anders kan een incidentele drukte in de ZIM leiden tot een kettingreactie van vele hernieuwd verstuurde berichten die de ZIM vervolgens doen overstromen. Zie bovenstaande figuur, afgeleid van die uit paragraaf 5.3. Herhalen van een opvraag kan zonder problemen, want een opvraag is een idempotente interactie. Immers, een herhaalde opvraag levert dezelfde resultaten als de originele opvraag, tenzij het tijdsverschil zo groot is dat de opleverende dossiers inmiddels zijn gewijzigd of dat een dossier opeens niet meer bereikbaar blijkt. Herhalen van een vervolgopvraag kan niet zo maar, want een vervolgopvraag is geen idempotente interactie. Immers, binnen één opvraagsessie is iedere vervolgopvraag van nature identiek. De ZIM levert na ontvangst van een identieke vervolgopvraag steeds de volgende set resultaten uit de totale verzameling resultaten. Dit betekent dat de opvragende zorgverlener of zijn GBZ0 na uitblijven van antwoord op een vervolgopvraag de gehele opvraagsessie opnieuw moet beginnen. Zonodig kan een nog lopende opvraagsessie eerst worden afgebroken met een eindeopvraagbericht. Overigens mag de ZIM een lopende opvraagsessie ongevraagd afbreken na verstrijken van de ZIM-vervolgopvraag-time-out. {toekomst} Soms is een nieuwe opvraagsessie niet wenselijk. Als een opvragende GBZ0 veel resultaten verwacht van vele andere GBZ’en, kan het verstandig zijn om ongebundeld op te vragen. Bijv. ter voorkoming van al te grote opleverberichten waarin alle opleveringen van de verschillende GBZ’en zijn gebundeld. Het opvragende GBZ0 moet dan een vervolgopvraagbericht sturen voor iedere volgend opleverbericht. Bij uitblijven van het laatste opleverbericht zou de gehele sessie opnieuw worden gedaan, waarbij de ZIM ook alle opleverende GBZ’en opnieuw zou moeten bevragen. Dat kan worden voorkomen, door te kiezen voor een betrouwbaar transportprotocol, of het gebruik van duplicaat-berichten, zie paragraaf 11.10. Duplicaat-berichten kunnen hier als volgt worden geïmplementeerd:

120 van 150


•

het opvragende GBZ0 kan na uitblijven van een vervolgoplevering een duplicaat van het vervolgopvraagbericht sturen. • de ZIM moet een duplicaat van een eerder ontvangen vervolgopvraag kunnen herkennen en deze beantwoorden met een duplicaat van het bijbehorende opleverbericht. Daartoe moet de ZIM alle opleverberichten na verzending gedurende ZIM-opleverbericht-bewaartijd (= gebruiker-oplever-time-out) bewaren. • als het opvragende GBZ0 na die bewaartijd nog met een duplicaat komt, moet de ZIM een foutmelding geven. Zolang de ZIM dit ondersteunt, kan de keuze om duplicaat-berichten te gebruiken, vrij worden overgelaten aan ieder afzonderlijke opvragende GBZ0. {toekomst} De ZIM zal ooit rekening moeten houden met GBZ’en die ongevraagd toch gemaximeerd opleveren, bijv. omdat het GBZ teveel resultaten heeft om ze allemaal in één opleverbericht te verzenden. Dit betekent dat zowel de ZIM als zo’n GBZ moet kunnen omgaan met vervolgopvraagberichten. Omdat de time-outs wellicht niet toelaten dat na een zoekgeraakt bericht de opvraagsessie met dat GBZ opnieuw wordt begonnen. Dat kan weer worden voorkomen, door te kiezen voor een betrouwbaar transportprotocol, of het gebruik van duplicaat-berichten, zie paragraaf 11.10. Duplicaat-berichten kunnen hier als volgt worden geïmplementeerd: • de opvragende ZIM moet na uitblijven van een vervolgoplevering een duplicaat van het vervolgopvraagbericht sturen. • het gemaximeerd opleverende GBZx moet een duplicaat van een eerder ontvangen vervolgopvraag kunnen herkennen en beantwoorden met een duplicaat van het bijbehorende opleverbericht. Daartoe moet deze GBZx alle opleverberichten na verzending gedurende GBZ-opleverbericht-bewaartijd (= GBZ-oplever-time-out) bewaren. • als de ZIM na die bewaartijd nog met een duplicaat komt, moet het GBZx een foutmelding geven. Zolang de ZIM dit ondersteunt, kan de keuze om gemaximeerd op te leveren, vrij worden overgelaten aan ieder afzonderlijke opleverende GBZx. Ten behoeve van de betrouwbaarheid, in de zin van volledigheid van opgeleverde resultaten, is het verder belangrijk: • dat de ZIM na ontvangen van de HL7v3-opvraag: - goed bijhoudt welke GBZ’en antwoorden kunnen leveren en terugmeldt aan GBZ1 indien een GBZx niet bereikbaar lijkt, - per GBZx goed bijhoudt hoeveel antwoorden het GBZ kan opleveren en terugmeldt aan GBZ1 indien een GBZx niet alles heeft opgeleverd. • dat GBZ1 na het presenteren van alle antwoorden in een HL7v3-oplevering, de gegevensopvrager duidelijk informeert: - ofwel dat er nog meer antwoorden verwacht worden, - ofwel dat bepaalde GBZ’en geen antwoorden hebben opgeleverd, - ofwel dat alle verwachte antwoorden netjes zijn ontvangen. Let op: als een GBZx meerdere applicaties bevat, dan kan het een enkele applicatie binnen dat GBZ zijn, dat oplevert, uitvalt, onbereikbaar is, etc. in plaats van het gehele GBZ. In dat geval kan het GBZx eventueel expliciet terugmelden dat de applicatie uitgevallen is, in plaats van het laten aankomen op een ZIM-bevestig-time-out.


121 van 150

11.9 Beheeroverdracht Wanneer een zorgverlener vanaf zijn GBZ1 een overdrachtVerzoek, overdrachtAntwoord of intrekkingVerzoek verstuurt naar de ZIM, die het doorstuurt naar het GBZ2 van de bestemde zorgaanbieder, ontvangt hij gewoonlijk spoedig een bevestiging, dan wel een foutmelding. Zolang een reactie uitblijft, is hij in onzekerheid: • is het verzoekbericht ergens zoekgeraakt en heeft de ZIM of GBZ2 het verzoekbericht niet ontvangen? • of is alleen het bevestigbericht zoekgeraakt en hebben de ZIM en GBZ2 het verzoekbericht netjes ontvangen? • is zijn GBZ1, de ZIM, het andere GBZ2 of een DCN momenteel hoogbelast en zijn de berichten nog onderweg? Om het laatste te kunnen uitsluiten is een bevestig-time-out nodig, zowel voor de gebruiker als het agerende GBZ en de ZIM: • gebruiker-bevestig-time-out is het tijdsinterval waarna de gebruiker geen bevestiging meer van zijn agerende GBZ1 hoeft te verwachten. • GBZ-bevestig-time-out is het tijdsinterval waarna een agerende GBZ1 geen bevestiging meer van de ZIM hoeft te verwachten. • ZIM-bevestig-time-out is het tijdsinterval waarna de ZIM geen bevestiging meer van het reagerende GBZ2 hoeft te verwachten. De gebruiker zou na uitblijven van bevestiging, hetzelfde overdrachtVerzoek, overdrachtAntwoord of intrekkingVerzoek willen herhalen. Immers, berichten kunnen zoekraken als gevolg van een momentane storing in een GBZ, de ZIM of een DCN en slaagt een herhaalde poging misschien wel. Eventueel kan zijn GBZ1 dat eerst zelf automatisch doen, voordat de gebruiker wordt ingelicht over de mislukte poging. Ook de ZIM zou bij uitblijven van bevestiging van GBZ2 het overdrachtVerzoek, overdrachtAntwoord of intrekkingVerzoek kunnen herhalen, voordat het terugmeldt aan het agerende GBZ1 dat het reagerende GBZ2 niet bereikbaar is. Herhalen van een overdrachtVerzoek, overdrachtAntwoord of intrekkingVerzoek geeft het risico van dubbele ontvangst. Maar er is geen risico van dubbele verwerking, want: •

het ontvangende systeem (ZIM of GBZ2) zal een overdrachtVerzoek voor een bepaalde patiëntgegevens-id weigeren met de foutmelding “bestaat al” indien voor die patiëntgegevens-id reeds een overdrachtverzoek uitstaat. Dit betekent dat het zendende systeem (GBZ1 of ZIM) na een herhaald overdrachtverzoek de foutmelding “bestaat al” moet anticiperen.

•

het ontvangende systeem (ZIM of GBZ2) zal een overdrachtAntwoord of intrekkingVerzoek voor een bepaalde patiëntgegevens-id weigeren met de foutmelding “bestaat niet” indien voor die patiëntgegevens-id geen overdrachtVerzoek meer uitstaat. Dit betekent dat het zendende systeem (GBZ1 of ZIM) na een herhaald overdrachtAntwoord of intrekkingVerzoek de foutmelding “bestaat niet” moet anticiperen.

122 van 150



:GBZ1

:ZIM

: GBZ2

verzoeken overdracht origineel overdrachtVerzoek origineel overdrachtVerzoek ZIM bevestig time-out GBZ bevestig time-out

bevestiging

vastleggen verzoek

foutmelding “niet bereikbaar” OF herhaald overdrachtVerzoek

gebruiker bevestig time-out

foutmelding “bestaat al” bevestiging

presenteren foutmelding

herkennen reeds uitstaand verzoek

OF herhaald overdrachtVerzoek

foutmelding “bestaat al”

herkennen reeds uitstaand verzoek

presenteren OK

De bovenstaande figuur toont dat de ZIM de keuze heeft om, na uitblijven van de bevestiging van GBZ2, een foutmelding “niet bereikbaar” terug te sturen naar GBZ1 OF een herhaald overdrachtVerzoek naar GBZ2 te sturen. In het laatste geval moet de ZIM anticiperen dat GBZ2 het originele overdrachtVerzoek toch had ontvangen en nu dus een foutmelding “bestaat al” retourneert. De ZIM moet dan een bevestiging sturen naar GBZ1. Evenzo heeft GBZ1 de keuze om, na uitblijven van de bevestiging van de ZIM, een foutmelding “ander GBZ niet bereikbaar, probeer het later nog eens” aan de gebruiker te presenteren OF een herhaald overdrachtVerzoek naar de ZIM te sturen. In het laatste geval moet GBZ1 anticiperen dat de ZIM het originele overdrachtVerzoek toch had ontvangen en nu dus een foutmelding “bestaat al” retourneert. GBZ1 moet de gebruiker dan OK melden. Het is mogelijk dat GBZ1 reeds na de eerste poging een foutmelding “bestaat al” terugkrijgt. In dat geval gaat het vermoedelijk om een gebruiksfout, bijvoorbeeld dat een andere gebruiker voor dezelfde patiëntgegevens reeds een overdrachtVerzoek heeft uitstaan. Eventueel kan het ook gaan om een applicatiefout, bijvoorbeeld dat GBZ1 of de ZIM na een crash een oude back-up heeft teruggezet waarin voor de bewuste patiëntgegevens nog een oud overdrachtverzoek stond dat allang was afgewezen of ingetrokken. Als een zoekgeraakt bericht samenvalt met de gebruiksfout dat twee zorgverleners tegelijkertijd het beheer vragen van een dossier van een derde zorgverlener, kan het fout gaan. De onderstaande figuur toont de situatie waarin GBZ1 ten onrechte denkt dat zijn overdrachtVerzoek bij GBZ3 ligt. Dat is geen groot probleem, want als het overdracht-


123 van 150

Antwoord uitblijft, zal hij waarschijnlijk gaan bellen naar de zorgverlener. De figuur toont verder de situatie dat GBZ3 het overdrachtVerzoek van GBZ2 aanvaardt, maar geen bevestiging ontvangt en dus herhaald een aanvaarding stuurt. Maar omdat er inmiddels een geheel ander overdrachtVerzoek uitstaat van GBZ1, krijgt GBZ3 een foutmelding “andermans verzoek” omdat het uitstaande verzoek was gericht aan GBZ2. Dit betekent dat een GBZ na herhaling van een overdrachtAntwoord, ook de foutmelding “andermans verzoek” moet anticiperen.

:GBZ1

:GBZ2

:ZIM

: GBZ3

overdrachtVerzoek overdrachtVerzoek

overdrachtVerzoek

overdrachtVerzoek foutmelding “bestaat al” presenteren OK

bevestiging bevestiging

presenteren OK

overdrachtAntwoord (aanvaarding) overdrachtAntwoord (aanvaarding) bevestiging

bevestiging

overdrachtVerzoek

overdrachtAntwoord (aanvaarding) overdrachtVerzoek foutmelding “andermans verzoek” bevestiging bevestiging

In principe zouden de ZIM en ieder GBZ voor een ontvangen overdrachtVerzoek, overdrachtAntwoord of intrekkingVerzoek onderscheid kunnen maken tussen enerzijds een gebruiksfout, applicatiefout en anderzijds een herhaalde poging, want in het laatste geval zijn de gegevens in het overdrachtverzoek identiek aan die in het reeds vastgelegde verzoek. Aldus zouden de ZIM en GBZ2 een waarschuwing kunnen geven in plaats van een foutmelding. Besloten is om dat niet te doen, omdat dergelijke duplicaatdetectie in de toekomst zal worden opgelost met betrouwbaar transport op SOAP-niveau.

124 van 150



:GBZ1

:ZIM

: GBZ2


verzoeken overdracht overdrachtVerzoek

overdrachtVerzoek

ZIM bevestig time-out

bevestiging

presenteren verzoek

foutmelding “niet bereikbaar” aanvaarden verzoek overdrachtAntwoord (aanvaarding) foutmelding “bestaat niet” presenteren fout OF overdrachtAntwoord (afwijzing) foutmelding “bestaat niet”

afwijzen verzoek

presenteren OK

De bovenstaande figuur toont nog eens de situatie dat GBZ2 een overdrachtVerzoek heeft ontvangen, maar dat de ZIM geen bevestiging heeft gekregen en dus na de timeout het overdrachtVerzoek opruimt en GBZ1 een foutmelding geeft. Waarschijnlijk zal GBZ2 vroeg of laat alsnog een overdrachtAntwoord sturen, maar de ZIM kan die dan niet meer verwerken en zal dus een foutmelding “bestaat niet” terugsturen naar GBZ2. In geval van een aanvaarding, moet GBZ2 aan de gebruiker melden dat het overdrachtVerzoek al weer vervallen is. In geval van een afwijzing inhield, maakt het niet uit en mag GBZ2 gewoon doorgaan alsof er een bevestiging was ontvangen. Mocht de ZIM in bovenstaande geval het overdrachtAntwoord ontvangen binnen de time-out op het overdrachtVerzoek, dan mag de ZIM deze accepteren, als het daartoe in staat is.


125 van 150

11.10 {toekomst} Identificatie van berichten Zoals beschreven in de vorige paragrafen, kan een GBZ of de ZIM een verzonden HL7v3verzoekbericht opnieuw verzenden als binnen de time-out geen HL7v3-antwoordbericht is ontvangen. Bij deze herhaalde poging (retry) moet de verzender een duplicaat van het oorspronkelijke HL7v3-bericht verzenden, opdat de ontvanger kan herkennen dat het om een duplicaat gaat. Deze detectie van duplicaatberichten is belangrijk voor niet-idempotente interacties, bijv. wanneer de ontvanger het originele HL7v3-verzoekbericht wel had ontvangen, maar te laat een HL7v3-antwoordbericht had verzonden of het antwoordbericht was zoekgeraakt. De verzender mag bij lang uitblijven van het HL7v3-retourbericht veronderstellen dat het oorspronkelijke HL7v3-bericht is zoekgeraakt en opnieuw proberen. Ook zonder zoekraken van berichten kan het gebeuren dat het duplicaat-HL7v3-verzoekbericht wordt gekruist door het vertraagde HL7v3-antwoordbericht. Zowel een GBZ als de ZIM moet ontvangen duplicaat-HL7v3-berichten weggooien, met uitzondering van gedoseerde HL7v3-opvraagberichten, want die moeten worden beantwoord met een duplicaat HL7v3-opleverbericht. Om berichten te kunnen identificeren, moeten GBZ’en en de ZIM alle te versturen HL7v3berichten van een landelijk uniek bericht-id voorzien. Om duplicaat-berichten te kunnen versturen, moeten GBZ’en en de ZIM deze berichten na het versturen bewaren totdat daarop een retourbericht is ontvangen. Om duplicaat-berichten van anderen te kunnen herkennen, moeten GBZ’en en de ZIM minimaal de bericht-id’s en applicatie-id’s en zo mogelijk UZI-nummers van de afzenders van berichten gedurende 2 dagen onthouden en controleren. In theorie zouden zelfs alle attributen van een bericht moeten worden gecontroleerd, maar dat is bewerkelijk. Het bijhouden van alleen de laatste bericht-id is onvoldoende, want er mag niet worden aangenomen dat de verzender lineair oplopende bericht-id’s hanteert. Het bijhouden van alleen bericht-id’s is ook niet voldoende, want een GBZ dat onbedoeld dezelfde bericht-id’s gebruikt als een andere GBZ, zou dan de duplicaatberichten bestemd voor dat andere GBZ kunnen ophalen. Bovendien zou een malafide GBZ door middel van trial-and-error met gefingeerde bericht-id’s kunnen proberen duplicaatHL7v3-opleverberichten met privacygevoelige patiëntgegevens te kapen van de ZIM. De ontvanger mag er dus niet blind van uitgaan dat iedere applicatie netjes landelijk unieke bericht-id’s genereert. Tenslotte moet de ZIM de UZI-nummers van de GBZ-gebruikers controleren want ook binnen één GBZ zou een malafide gebruiker door middel van trial-and-error kunnen proberen duplicaat-HL7v3-opleverberichten te kapen van de ZIM die waren verzonden aan andere GBZ-gebruikers van hetzelfde GBZ. Voor een opleverend GBZ geldt iets dergelijks, want een malafide GBZ zou kunnen proberen rechtstreeks duplicaat-HL7v3-opleverberichten te kapen van een GBZ, dus HL7v3-berichten die zijn opgeleverd aan de ZIM. Dit is denkbaar wanneer er GBZ’en zijn die buiten de ZIM om met elkaar HL7v3-berichten uitwisselen, in kader van een zorgtoepassing die niet door de ZIM wordt ondersteund. In dit geval kan een opleverend GBZ geen UZI-nr van de GBZ-gebruiker controleren. In plaats daarvan geldt de ZIM als

126 van 150


opvrager. Aldus moeten GBZ’en de authenticiteit van HL7v3-berichten van de ZIM controleren.


127 van 150

11.11 Identificatie van patiëntstukken Wanneer een GBZ als onderdeel van een duplicaatbericht opnieuw dezelfde patiëntstukken verstuurt of oplevert, moeten ook die patiëntstukken herkenbaar zijn als kopie. Dit is belangrijk omdat bij landelijke uitwisseling van patiëntgegevens allerlei kopieën van patiëntstukken terecht zullen komen in andere dan de oorspronkelijke patiëntdossiers. AORTA beoogt dit kopiëren te beperken, maar kan het niet uitsluiten, omdat: •

sommige patiëntstukken idealiter worden opgenomen in de context van een ander patiëntstuk. Bijv. een labuitslag dat, opgenomen bij de diagnose in het dossier van een arts, meer betekenis heeft dan alleen in het dossier van het laboratorium.

•

opdrachtberichten met patiëntstukken kunnen opnieuw worden verstuurd na het zoekraken van bevestigberichten,

•

dezelfde patiëntstukken in verschillende aggregatieniveaus terecht kunnen komen in hetzelfde dossier. Bijv. een medicatievoorschrift kan ook voorkomen als onderdeel van een professionele samenvatting, zie [Bedrijfsarchitectuur] paragraaf 6.3.

Dit betekent dat ieder patiëntstuk een landelijk unieke identificatie moet hebben, dat bovendien persistent moet zijn, totdat dat patiëntstuk wordt weggegooid. Deze patiëntstuk-id kan ook worden gebruikt bij een atomaire aanmelding bij de verwijsindex, zie [Informatiesysteemarchitectuur] paragraaf 5.3. Deze eis is een uitdaging voor een GBZ wanneer men bedenkt welke wijzigingen op een GBZ kunnen afkomen tijdens de levensduur van patiëntstukken, bijv.: • twee GBZ’en worden samengevoegd wegens een fusie van zorgaanbieders, • de applicatie die het patiëntdossiers ontsluit wordt vervangen door een applicatie van een andere leverancier. HL7v3 verplicht het gebruik van de OID als bericht-id en patiëntstuk-id, zie [HL7v3 Infra]. Voor een GBZ wordt sterk aangeraden de URA van de zorgaanbieder die verantwoordelijk is voor het GBZ, te hanteren als root-OID voor een tak met alle berichtid’s en voor een tak met alle patiëntstuk-id’s. Let op dat bovenstaande niet geldt voor de applicatie-id’s, die worden namelijk uitgegeven door het LSP

128 van 150


Bijlage A - Bundelen, groeperen, doseren, etc. A.1 Inleiding Moet de ZIM de resultaten op queries van verschillende opleverende GBZ’en kunnen bundelen, groeperen, doseren en sorteren bij het terugsluizen van de resultaten naar het opvragende GBZ? HL7v3 biedt deze mogelijkheden bij de communicatie tussen twee zorgsystemen, maar in combinatie met een tussenliggende ZIM rijzen enkele vragen. Deze bijlage analyseert deze vragen en komt tot een aantal architectuurbeslissingen. Tenslotte geeft deze bijlage een uitwerking van de scenario’s die aldus worden ondersteund en waaruit een opvragende GBZ kan kiezen: • niet bundelen, niet doseren, • niet bundelen, wel doseren, • wel bundelen, niet doseren, • wel bundelen, wel doseren.

A.2 Achtergrond Wanneer de ZIM een opvraag ontvangt van een GBZ0, zal de ZIM deze opvraag divergeren naar alle GBZ’en waarvan in de verwijsindex is aangegeven dat ze antwoord hebben op deze opvraag. Daarbij kan sprake zijn van meerdere GBZ1, GBZ2, GBZ3, etc. die ieder vele resultaten opleveren, zie onderstaande figuur, waarbij iedere pijl een individueel resultaat voorstelt.

opvraag1 resultaat11 resultaat12

GBZ1

resultaat13

GBZ0 :Zorgverlener

opvraag resultaat11

ZIM

opvraag2 resultaat21

resultaat12

resultaat22

resultaat13

resultaat23

GBZ2

resultaat21 resultaat22 resultaat23

opvraag3

resultaat31

resultaat31

resultaat32

resultaat32

resultaat33

resultaat33

GBZ3

HL7v3 geeft een opleverend GBZ in principe de vrijheid om de resultaten individueel of gegroepeerd in berichten op te leveren. Anderzijds geeft HL7v3 een opvragend GBZ de mogelijkheid af te dwingen dat alle opleverberichten in één allesomvattend bericht


129 van 150

(batch) worden gebundeld. Daarnaast geeft HL7v3 de mogelijkheid van doseren en sorteren van de resultaten. Dit betekent dat de tussenliggende ZIM de berichtenstroom moet coördineren, rekening houdend met de wensen van het opvragende GBZ en de vrijheden van de opleverende GBZ’en. Echter, er moet worden voorkomen dat de ZIM overbelast raakt door teveel keuzevrijheid van de aangesloten GBZ’en.

A.3 Vraagstelling HL7v3 biedt een opleverend GBZ in principe de vrijheid om de resultaten te groeperen alvorens deze in berichten op te leveren: • groeperen betekent dat het opleverende GBZ meerdere of alle resultaten in één opleverbericht plaatst. Dit is zo doelmatig dat een GBZ dit eigenlijk altijd zou moeten doen, maar als de resultaten niet allemaal ineens kunnen worden opgeleverd, kan het nuttig zijn de resultaten te verdelen over meerdere opleverberichten. HL7v3 biedt het opvragende GBZ de mogelijkheid om in het opvraagbericht te vermelden dat de resultaten gebundeld, gedoseerd en/of gesorteerd moeten worden opgeleverd: • bundelen betekent dat het opvragende GBZ alle opleverberichten één allesomvattend bericht (batch) wil ontvangen. Dit kan nuttig zijn voor een applicatie omdat deze dan voor ieder opvraagbericht precies één opleverbericht ontvangt. • doseren betekent dat het opvragende GBZ kan aangeven hoeveel resultaten maximaal mogen worden opgeleverd. De overige resultaten kunnen met vervolgopvragen worden opgeleverd. Dit kan nuttig zijn als er zeer veel resultaten zijn, terwijl niet alle resultaten ineens verwerkt kunnen worden. • sorteren betekent dat het opvragende GBZ kan aangeven dat het alle resultaten in een bepaalde volgorde ontvangt. Dit kan nuttig zijn voor een applicatie die de resultaten op volgorde van een bepaald kenmerk wil presenteren. De vraag is of de ZIM deze mogelijkheden ook echt moet bieden, want dat kan in sommige combinaties betekenen dat de ZIM eerst alle resultaten van de opleverende GBZ’en moet verzamelen, met alle gevaar van overbelasting van de ZIM.

A.3.1 Groeperen Groeperen betekent dat het opleverende GBZ meerdere of alle resultaten in één opleverbericht plaatst, aangenomen dat er meerdere resultaten kunnen zijn. Groeperen is zo doelmatig dat een GBZ dit eigenlijk altijd zou moeten doen. Echter, soms kunnen de resultaten niet allemaal ineens worden opgeleverd, bijv. omdat een GBZ verschillende dossiers heeft die niet allemaal even snel kunnen opleveren. Of omdat een GBZ een maximum aantal resultaten per keer aanhoudt, ter voorkoming van het overstromen van buffers. In dergelijke gevallen kan het nuttig zijn de resultaten te verdelen over meerdere opleverberichten. Daarom biedt HL7v3 een opleverend GBZ in principe de keuze om de resultaten al of niet te groeperen, alvorens deze in berichten op te leveren. Niet groeperen heeft als

130 van 150


consequentie dat het opvragende GBZ na ontvangst van het eerste opleverbericht één of meer vervolgopvraagberichten moet uitsturen om alle resultaten te verzamelen. Aldus wordt het opvragende GBZ ongevraagd gedwongen tot gedoseerd opvragen. HL7v3 schrijft voor dat de resultaten als gegroepeerde payload binnen de ControlAct Wrapper van een opleverbericht wordt geplaatst, zie de onderstaande figuur.

Transmission Wrapper ControlAct Wrapper Payload: resultaat1 Payload: resultaat2 Payload: resultaat3

Een voorwaarde voor het groeperen is dat de resultaten allemaal van hetzelfde type zijn, dat wil zeggen, dat de opgeleverde patiëntstukken allemaal dezelfde gegevenssoort hebben. Als dat niet het geval is, moet het opleverende GBZ de resultaten per type groeperen in afzonderlijke opleverberichten. Wel kunnen die opleverberichten weer worden gebundeld in één allesomvattend opleverbericht, maar daar moet de opvragende partij dan wel om gevraagd hebben, zie onder Bundelen. Voor de ZIM zou het goed uitkomen als alle opleverende GBZ’en altijd alle resultaten in één opleverbericht zouden groeperen. Of dit afgedwongen kan worden, hangt echter mede af van de zorgapplicatie en de daarbij betrokken gegevenssoorten. Architectuurbeslissing: per zorgtoepassing en gegevenssoort moet worden bepaald of de opleverende GBZ’en alle resultaten moeten groeperen binnen de ControlAct Wrapper van één opleverbericht. Merk op dat de ZIM niet zelf kan groeperen ten behoeve van de opvragende GBZ, want daarvoor zou de ZIM de ControlAct Wrappers moeten uitpakken en daarmee zou belangrijke informatie verloren gaan. Bundelen van de verschillende, al dan niet gegroepeerde, opleverberichten is natuurlijk wel mogelijk.

A.3.2 Bundelen Bundelen betekent dat het opvragende GBZ alle opleverberichten één allesomvattend bericht (HL7v3: batch) wil ontvangen. Bundelen kan nuttig zijn voor een applicatie omdat deze dan voor ieder opvraagbericht precies één gebundeld opleverbericht ontvangt. Voor de belasting van het netwerk kan het voordelig zijn één gebundeld bericht te hebben in plaats van veel kleine opleverberichten, maar afhankelijk van de grootte van het antwoord en het aantal resultaten kan dit ook juist nadelig uitpakken. Het is aan de applicatie om al of niet gebruik te maken van bundelen. HL7v3 biedt de opvragende partij de mogelijkheid om de ControlAct Wrapper de responseModalityCode op Batch of RealTime te zetten. HL7v3 schrijft voor dat de opleverende partij de samen te voegen berichten met de Transmission Wrapper in een Batch Wrapper plaatst, zie de onderstaande figuur.


131 van 150

Batch Wrapper Transmission Wrapper ControlAct Wrapper Payload: resultaat11 Payload: resultaat12 Payload: resultaat13

Transmission Wrapper ControlAct Wrapper Payload: resultaat21 Payload: resultaat22 Payload: resultaat23

De ZIM is goed in staat om de opleverberichten van de verschillende GBZ’en te kunnen bundelen tot één allesomvattend opleverbericht. Dus kan een verzoek van een opvragende GBZ voor al of niet bundelen door de ZIM worden gehonoreerd. Paragraaf A.4.3 toont hoe dit bundelen uitpakt voor het berichtenverkeer. Paragraaf A.4.1 toont hoe het opvragende GBZ anders wordt gedwongen tot vervolgopvraagberichten. Architectuurbeslissing: de ZIM moet op verzoek van een opvragende GBZ de opgevraagde resultaten van de opleverende GBZ’en bundelen tot één allesomvattend opleverbericht aan het opvragende GBZ. De vraag is dan vervolgens: moet de ZIM aan ieder opleverend GBZ ook om een gebundeld opleverbericht vragen? Het antwoord is nee, omdat dit geen voordelen oplevert. Zelfs als een opleverende GBZ zou besluiten niet te groeperen, zou de ZIM alle afzonderlijke opleverberichten van dat GBZ kunnen verzamelen in het gebundelde opleverbericht. Architectuurbeslissing: de ZIM moet opleverende GBZ’en nooit om een gebundeld opleverbericht vragen.

A.3.3 Doseren Doseren betekent dat het opvragende GBZ kan aangeven hoeveel resultaten maximaal mogen worden opgeleverd. De overige resultaten kunnen dan met vervolgopvragen worden opgeleverd. Doseren is zinvol indien een opvraag kan leiden tot meer resultaten dan het opvragende GBZ, de ZIM of het datacom-netwerk ineens kan verwerken. Een opvragende GBZ heeft bij voorkeur zodanig ruime buffers dat doseren niet nodig is, maar die buffer heeft altijd een maximum omvang. Gedoseerd opvragen bij de ZIM heeft overigens weinig te maken met het eventueel gedoseerd presenteren van de resultaten aan de gebruiker. Voor de presentatielogica is het meestal nodig dat alle resultaten binnen zijn, bijv. om ze te kunnen sorteren op verschillende kenmerken.

132 van 150


HL7v3 biedt de mogelijkheid om in de ControlAct Wrapper van een opvraagbericht (Query Request) een maximum aantal resultaten (initialQuantity) te vermelden, waarmee de opvragende GBZ impliciet een sessie opent met de volgende opvraagcommando’s: • Query Spec: voor het starten van de sessie en de eerste opvraag, • Query Continuation: voor de tweede en volgende opvraag, • Query Cancel: voor het afsluiten van de opvraagsessie. De ControlAct Wrapper van het opleverbericht (Query Response) moet steeds vermelden: dit is resultaat X van een totaal Y en er zijn nog Z resultaten over, waarbij: X = resultCurrentQuantity Y = resultTotalQuantity Z = resultRemainingQuantity In de ControlAct Wrapper van een vervolgopvraag kan een maximum aantal resultaten (continuationQuantity) en een volgnummer van het eerstvolgende resultaat (startResultNumber) worden vermeld. Bij verstek geldt het maximum van het eerste opvraagbericht en het volgnummer van het eerstvolgende nog niet opgeleverde resultaat. Architectuurbeslissing: de ZIM moet opleveringen op verzoek van een opvragende GBZ kunnen doseren, omwille van een doelmatige afhandeling van de berichtenstroom. De vraag is dan vervolgens: moet de ZIM iedere gedoseerde opvraag ook gedoseerd doorzetten naar de opleverende GBZ’en? Het antwoord is JA, omdat de opleverende GBZ’en anders opleverberichten met teveel resultaten kunnen opleveren, die de ZIM dan zou moeten opsplitsen. Paragraaf A.4.2 toont hoe dit doseren uitpakt voor het berichtenverkeer. Architectuurbeslissing: de ZIM moet een gedoseerde opvraag ook gedoseerd doorzetten naar de opleverende GBZ’en, met dezelfde dosis, omwille van een doelmatige afhandeling van de berichtenstroom. Een opleverende GBZ heeft de vrijheid een maximum aan te houden voor aantal resultaten per opleverbericht. Daarmee kan de ZIM worden gedwongen vervolgopvragen te doen, ook als de ZIM niet om doseren had gevraagd. Architectuurbeslissing: de ZIM moet altijd rekening houden met een GBZ dat ongevraagd gedoseerd oplevert en zonodig vervolgopvraagberichten sturen. Als een opvragende GBZ in een vervolgopvraag een maximum aantal resultaten en/of een volgnummer zou mogen opgeven die afwijken van die in het eerste opvraagbericht, zou de ZIM de berichtenstroom niet goed kunnen optimaliseren, bijv. door opvraagberichten parallel te divergeren naar opleverende GBZ’en. Architectuurbeslissing: de ZIM mag een vervolgvraag van een opvragende GBZ weigeren indien deze een maximum aantal resultaten en/of een volgnummer bevat.


133 van 150

A.3.4 Sorteren Sorteren betekent dat het opvragende GBZ kan aangeven dat het alle resultaten in een bepaalde volgorde wil ontvangen. Sorteren kan zinvol zijn als een opvragend GBZ de resultaten gedoseerd én gesorteerd wil presenteren. Als de ZIM de opgevraagde resultaten niet gesorteerd zou kunnen opleveren, zou het opvragende GBZ alle resultaten moeten afwachten om de resultaten zelf te kunnen sorteren alvorens deze te presenteren. Daarmee zouden de voordelen van doseren vaak teniet worden gedaan. Echter, als de ZIM alle resultaten gesorteerd moet opleveren, zal de ZIM in principe eerst álle resultaten moeten opvragen bij de achterliggende GBZ’en, en deze vervolgens sorteren, voordat de ZIM de eerste resultaten kan opleveren aan het opvragende GBZ. Dat betekent feitelijk dat het sorteerprobleem van het GBZ naar de ZIM zou worden verplaatst. Het sorteren door de ZIM in plaats van door het GBZ, heeft bovendien enkele belangrijke nadelen: • Als het opvragende GBZ zelf ook resultaten heeft, zou de ZIM die resultaten eerst bij dit GBZ moeten opvragen, om ze na sorteren, samen met de resultaten van andere GBZ’en, weer terug te leveren aan het opvragende GBZ. • Sorteren kan heel veel geheugenruimte van de ZIM vergen, vooral als andere GBZ’en tegelijkertijd hetzelfde willen. Alleen als de opleverende GBZ’en in staat zijn gesorteerd op te leveren, zou de ZIM met parallel en zuinig gedoseerd opvragen van opleverende GBZ’en, dit eventueel kunnen voorkomen. Maar dan moeten de achterliggende GBZ’en ook gesorteerd kunnen opleveren; dat kunnen niet alle GBZ’en. • na het gesorteerd opleveren van resultaten aan een GBZ, zou een zorgverlener diezelfde resultaten nog eens op een andere wijze (oplopend versus aflopend, of op basis van ander kenmerk) willen sorteren. Dat betekent dat een GBZ alsnog moet sorteren. De waarde van het gesorteerd opleveren vanaf de ZIM is dus vaak beperkt. Architectuurbeslissing: de ZIM moet een verzoek van een opvragende GBZ voor het sorteren van resultaten weigeren.

134 van 150


A.4 Scenario’s van bundelen en doseren Deze paragraaf geeft een uitwerking van de verschillende combinaties van bundelen en doseren. De volgende combinaties zijn mogelijk en moeten door de ZIM worden ondersteund. Een opvragende GBZ kan kiezen welke combinatie voor een bepaalde zorgtoepassing het meest geschikt is: • GBZ vraagt om NIET bundelen en NIET doseren • GBZ vraagt om NIET bundelen en WEL doseren • GBZ vraagt om WEL bundelen en NIET doseren • GBZ vraagt om WEL bundelen en WEL doseren De opvragende GBZ geeft zijn keuze als volgt aan in de ControlAct Wrapper van het opvraagbericht: • responseModalityCode=B betekent WEL bundelen • responseModalityCode=R betekent NIET bundelen • initialQuantity= N betekent WEL doseren (eigenlijk maximeren, maar dat leidt dan tot vervolgopvragen, dus doseren) • geen initialQuantity betekent NIET doseren (maar als een opleverende GBZ of de ZIM zelf besluit tot maximeren, zijn alsnog vervolgopvragen nodig. Alle scenario’s gaan uit van een situatie waarbij: • GBZ1 heeft 2 zoekresultaten • GBZ2 heeft 5 zoekresultaten • GBZ3 heeft 13 zoekresultaten Voor elk scenario geldt dat de ZIM in ieder opleverbericht moet aangeven dat er nog meer resultaten zijn door het aanpassen van de resultRemainingQuantity in de ControlAct Wrapper. Dit is als volgt afgebeeld: “oplevering (X van Y rest Z)” vertegenwoordigt een ControlAct Wrapper met: X = resultCurrentQuantity Y = resultTotalQuantity Z = resultRemainingQuantity Een ? vertegenwoordigt nullFlavor=”NAV”, zie “Implementatiegids HL7v3 v3 Infrastructurele Domeinen” versie 2.3, paragraaf 2.5.3.


135 van 150

A.4.1 Niet bundelen, niet doseren In dit scenario stuurt de opvragende GBZ een opvraagbericht naar de ZIM waarin: • responseModalityCode=R, dus NIET bundelen • zonder initialQuantity, dus NIET doseren De ZIM stuurt het opvraagbericht door naar de GBZ’en genoemd in de VWI, waarin: • responseModalityCode=R, dus NIET bundelen • zonder initialQuantity, dus NIET doseren

GBZ0

ZIM

GBZ1

GBZ2

GBZ3

:Zorgverlener opvragen (alles)

opvraag (R, alles)

opvraag (R, alles) opvraag (R, alles) opvraag (R, alles) oplevering (2 van 2 rest 0)

oplevering (2 van ? rest ?)

presenteren (2)

oplevering (5 van 5 rest 0) oplevering (13 van 13 rest 0)

vervolgopvraag () oplevering (5 van 20 rest 13)

presenteren (5) vervolgopvraag () oplevering (13 van 20 rest 0)

presenteren (13)

Voordelen van dit scenario zijn: • de ZIM kan na de ontvangst van de eerste oplevering, deze onmiddellijk doorzetten naar de opvragende GBZ0. Dit kan nuttig zijn als het belangrijk is de gebruiker snel resultaten te tonen, zonder dat alle resultaten meteen compleet hoeven te zijn. Dit kan ook gunstig uitpakken voor zorgtoepassingen waarbij gewoonlijk maar één GBZ als bron optreedt. Nadelen van dit scenario zijn: • de opvragende GBZ0 moet voor elke opleverende GBZ de resultaten bij de ZIM ophalen. Over het geheel is dat minder doelmatig dan bij WEL bundelen. • doordat de ZIM begint met opleveren voordat alle resultaten binnen zijn, kan de ZIM nog niet meteen vertellen hoeveel resultaten er in totaal zijn. Opmerkingen: • de opvragende GBZ0 wilde alles ongedoseerd hebben, maar wordt toch gedwongen tot vervolgopvraagberichten. Dit is omdat de ZIM geen opleverberichten (met name de ControlAct Wrapper) mag uitpakken en dus niet alle resultaten van verschillende bronnen kan bundelen in één opleverbericht. Niet afgebeeld is dat een opleverende

136 van 150


GBZ ongevraagd een maximum kan aanhouden voor het aantal resultaten in een opleverbericht. De ZIM wordt dan ook gedwongen tot vervolgopvraagberichten.

A.4.2 Niet bundelen, wel doseren In dit scenario stuurt de opvragende GBZ een opvraagbericht naar de ZIM waarin: • responseModalityCode=R, dus NIET bundelen • initialQuantity=10, dus WEL doseren De ZIM stuurt het opvraagbericht door naar de GBZ’en genoemd in de VWI, waarin: • responseModalityCode=R, dus NIET bundelen • initialQuantity=10, dus WEL doseren

GBZ0

ZIM

GBZ1

GBZ2

GBZ3


opvraag (R, 10)

opvraag (R, 10) opvraag (R, 10) opvraag (R, 10) oplevering (2 van 2 rest 0)

oplevering (2 van ? rest ?)

oplevering (5 van 5 rest 0)

presenteren (2)


vervolgopvraag () oplevering (5 van 20 rest 13)

presenteren (5) vervolgopvraag () oplevering (10 van 20 rest 3)

presenteren (10) vervolgopvraag ()

opvraag (R, 3) oplevering (3 van 3 rest 0)


presenteren (3)

Voordelen en nadelen van dit scenario zijn dezelfde als voor NIET bundelen en NIET doseren, behalve dat de dosering dit scenario over het geheel genomen iets trager kan maken. Dat gebeurt echter alleen als er een opleverende GBZ is die meer resultaten heeft dan de gevraagde initialQuantity. Opmerkingen: • De enige zinvolle reden van een opvragende GBZ om te kiezen voor dosering, is het zichzelf beschermen tegen een overstroming van de buffer. Dan gaat het niet om een initialQuantity van 10, zoals in de figuur, maar om het echte maximum aantal resultaten dat de GBZ ineens kan verwerken. Overigens laat de omvang van een resultaat zich moeilijk schatten. Zo kan bijv. een medicatievoorschrift in omvang fors variëren. • Ten aanzien van de opleverende GBZ’en hanteert de ZIM dezelfde dosis als de opvragende GBZ hanteert. Dit garandeert dat de ZIM alle ontvangen opleverberichten


137 van 150

probleemloos kan doorschuiven naar de opvragende GBZ. Dit kan alleen misgaan als GBZ0 voor de vervolgvraag de dosis verlaagt, bijv. “vervolgopvraag (max 5)”. Dan kan de ZIM het klaarstaande opleverbericht met 10 resultaten niet kwijt aan GBZ0 en moet antwoorden met “oplevering (0 van 20 rest 18)”.

A.4.3 Wel bundelen, niet doseren In dit scenario stuurt de opvragende GBZ een opvraagbericht naar de ZIM waarin: • responseModalityCode=B, dus WEL bundelen • zonder initialQuantity, dus NIET doseren De ZIM stuurt het opvraagbericht door naar de GBZ’en genoemd in de VWI, waarin: • responseModalityCode=R, dus NIET bundelen • zonder initialQuantity, dus NIET doseren

GBZ0

ZIM

GBZ1

GBZ2

GBZ3

:Zorgverlener

opvragen (alles)

opvraag (B, alles)

opvraag (R, alles) opvraag (R, alles) opvraag (R, alles) oplevering (2 van 2 rest 0) oplevering (5 van 5 rest 0) oplevering (13 van 13 rest 0)

presenteren (20)

batch (oplevering (2 van 20 rest 18), oplevering (5 van 20 rest 13), oplevering (13 van 20 rest 0))

Voordelen van dit scenario zijn: • voor de opvragende GBZ is dit de meest eenvoudige interactie met de ZIM: één opvraag en één opleverbericht. • als de opvragende GBZ alle resultaten ontvangen moet hebben voordat die verwerkt of gepresenteerd kunnen worden, is dit het snelste scenario. Nadelen van dit scenario zijn: • als er veel resultaten zijn, kan de gebundelde oplevering erg groot uitpakken. De opvragende GBZ0 moet daarop voorbereid zijn. De ZIM ook, want die moet vele opvraagsessies tegelijk kunnen bedienen. • het kan even duren voordat de opvragende GBZ het opleverbericht ontvangt, omdat de ZIM moet wachten totdat alle opleveringen binnen zijn. Als sommige opleverende GBZ’en een eigen maximum hanteren bij het groeperen van resultaten, wordt de ZIM gedwongen tot een vervolgopvraag en kan het nog langer duren. Opmerkingen:

138 van 150


• uit de figuur blijkt dat het geen zin heeft voor de ZIM om van de opleverende GBZ’en een gebundeld opleverbericht te vragen. • niet afgebeeld is dat een opleverende GBZ ongevraagd een maximum kan aanhouden voor het aantal resultaten in een opleverbericht. De ZIM wordt dan alsnog gedwongen tot vervolgopvraagberichten.

A.4.4 Wel bundelen, wel doseren In dit scenario stuurt de opvragende GBZ een opvraagbericht naar de ZIM waarin: • responseModalityCode=B, dus WEL bundelen • initialQuantity=10, dus WEL doseren De ZIM stuurt het opvraagbericht door naar de GBZ’en genoemd in de VWI, waarin: • responseModalityCode=R, dus NIET bundelen • initialQuantity=10, dus WEL doseren

GBZ0

ZIM

GBZ1

GBZ2

GBZ3


opvraag (B, 10)

opvraag (R, 10) opvraag (R, 10) opvraag (R, 10) oplevering (2 van 2 rest 0) oplevering (5 van 5 rest 0) oplevering (10 van 13 rest 3)

presenteren (7)

batch (oplevering (2 van 20 rest 18), oplevering (5 van 5 rest 13) ) vervolgopvraag ()

presenteren (10)

batch (oplevering (10 van 13 rest 3) ) vervolgopvraag ()

opvraag (R, 10) oplevering (10 van 13 rest 0)

presenteren (3)

batch (oplevering (3 van 3 rest 0) )

Voordelen van dit scenario zijn: • zolang er geen opleverende GBZ is die meer resultaten heeft dan de gevraagde initialQuantity, kan dit doelmatig uitpakken, met een bescherming tegen overstroming van de buffers. Nadelen van dit scenario zijn: • voor de opvragende GBZ is dit de meest complexe berichtverwerking: gebundelde opleverberichten moeten worden uitgepakt en er moeten mogelijk vervolgopvraagberichten worden verzonden.


139 van 150

Opmerkingen: • hier gelden dezelfde opmerkingen als voor NIET bundelen en WEL doseren. • de ZIM moet in iedere gebundeld opleverbericht aangeven dat er nog meer gebundelde opleverberichten zijn door het aanpassen van de resultRemainingQuantity in de ControlAct Wrapper.

140 van 150


Bijlage B - Adresseren Deze bijlage is niet normatief en dient slechts voor een beter begrip van de samenhang tussen de verschillende mechanismen voor adresseren op de verschillende communicatieniveaus. Merk op dat het woord adresseren hier in de meest ruime zin wordt bedoeld.

B.1 Inleiding Bij het landelijk uitwisselen van patiëntgegevens tussen zorgaanbieders, worden deze patiëntgegevens verstuurd in een HL7v3-bericht, wordt dit ingepakt in een SOAPenvelop, voorzien van een HTTP-header, een TCP-header en een IP-header alvorens deze over het netwerk wordt gerouteerd, zie de onderstaande figuur.

A

B

zorgaanbieder

bron applicatie HL7 sender SOAP client HTTP client TCP handler IP handler

zorgaanbieder

HL7 payload HL7 controlact HL7 wrapper transmission wrapper

doel applicatie

SOAP envelope

SOAP server HTTP server

HTTP header TCP header IP header

HL7 receiver

TCP handler IP handler

UZI-nr, URA

Applicatie id

URL

IP-adres Poort-nr

Op al deze commmunicatieniveaus moet de juiste adressen worden gehanteerd om zeker te stellen dat de patiëntgegevens op de juiste plek worden afgeleverd. In de volgende paragrafen wordt het principe van adresseren voor ieder niveau behandeld: • Inhoud: HL7v3 Payload en ControlAct Wrapper • Envelop: HL7v3 Transmission Wrapper • Transport: HTTP/SOAP • Verbinding: TCP/IP Vervolgens worden de principes toegepast in de situatie dat een ZIM optreedt als intermediair tussen zorgaanbieders. Daarbij wordt apart behandeld: • het opvragen van patiëntgegevens, • het versturen van patiëntgegevens.


141 van 150

B.2 Inhoud: HL7v3 Payload en ControlAct Wrapper Deze paragraaf beschouwt de wijze waarop de HL7v3-berichtinhoud wordt gericht aan de juiste bestemming. De onderstaande figuur geeft een voorbeeld van hoe een opdrachtbericht (HL7v3: order) kan worden gericht aan een zorgaanbieder.

A

B

zorgaanbieder

zorgaanbieder

a1

a2

b1

b2

HL7v3 control act wrapper: zorgverlener

medewerker

zorg applicatie

HL7v3 payload: Author or Performer Responsible Party requested Performer

medewerker zorgverlener zorg applicatie

Author or Performer Overseer Informatiebron

Information Recipient Informatiedoel

In de HL7v3 Payload kan onder meer worden aangegeven, indien zinvol: • de requested Performer als beoogde uitvoerder van een verzoek. Dit kàn binnen een zorgapplicatie worden gebruikt om de berichtinhoud onder ogen van de beoogde uitvoerder te brengen. In de HL7v3 ControlAct Wrapper kàn als informatiedoel worden aangegeven, indien zinvol: • de Information Recipient als zorgaanbieder die de berichtinhoud onder ogen moet krijgen. De bovenstaande identificaties zijn alleen zinvol in geval van een opdrachtbericht en zelfs dan zijn ze niet altijd aanwezig, afhankelijk van de zorgtoepassing. In de HL7v3 ControlAct Wrapper moet als informatiebron worden aangegeven: • de AuthorOrPerformer als zorgverlener of gemandateerde medewerker die het bericht heeft verstuurd, • de Overseer als verantwoordelijke, eventueel mandaterende, zorgverlener. Als er geen sprake is van mandateren is de Author or Performer gelijk aan de Overseer. Zowel in de HL7v3 Payload als in de HL7v3 ControlAct Wrapper worden informatiebron en informatiedoel telkens aangeduid aan de hand van:

142 van 150


• het UZI-nummer, dit wordt gebruikt om een specifieke persoon te identificeren: zorgverlener of medewerker, • het UZI-abonneenummer (URA), dit wordt gebruikt om de omvattende organisatie te identificeren: de zorginstelling, de huisartspraktijk, de apotheek, etc. • de rolCode, dit kan worden gebruikt om de zorgverlenerfunctie van de zorgverlener aan te duiden, of anders de functiegroep binnen dezorgaanbieder als er geen specifieke zorgverlener was genoemd. Zo wordt een opdrachtbericht (bijv. medicatievoorschrift) meestal gericht aan een zorgaanbieder (bijv. apotheker) en niet aan een zorgverlener (bijv. apotheek). In geval van een grote zorgaanbieder (bijv. ziekenhuis met verschillende specialismen) kan een opdrachtbericht (bijv. verwijsbrief) worden gericht aan een specifieke zorgverlenerfunctie (bijv. orthopedie), waarbij de dienstdoende zorgverlener de verantwoordelijkheid voor de opdracht op zich neemt. Zie verder [HL7v3 Infra], [HL7v3 ZIM] en de implementatiehandleidingen van de specifieke zorgtoepassingen.


143 van 150

B.3 Envelop: HL7v3 Transmission Wrapper Deze paragraaf beschouwt de wijze waarop een HL7v3-envelop wordt geadresseerd aan de juiste bestemming.

zorg applicatie

zorg applicatie

HL7 poort applicatie applicatie zorg applicatie

HL7 sender

HL7v3 transmission wrapper: HL7v3 control act wrapper

HL7v3 payload

HL7 sender

HL7 poort applicatie applicatie HL7 receiver

zorg applicatie HL7 receiver

Sender: device.id applicatie-id organisation.id URA Receiver: device.id applicatie-id organisation.id URA

De bovenstaande figuur toont hoe op dit niveau applicaties als afzender en als ontvanger worden geadresseerd, telkens in de vorm van: • de applicatie-id van de zorgapplicatie die de HL7v3-berichtinhoud moet verwerken, vooral belangrijk als de zorgaanbieder meerdere zorgapplicaties heeft, • het UZI-abonneenummer (URA) van de verantwoordelijke organisatie: de zorginstelling, de huisartspraktijk, de apotheek, etc. Als ontvanger moet de identificatie worden aangegeven van de zorgapplicatie die ervoor zorgt dat de HL7v3-berichtinhoud onder ogen komt van de beoogde zorgaanbieder. Dit hoeft niet de applicatie te zijn bij wie het HL7v3-bericht wordt afgeleverd. Zo kan een poortapplicatie (bijv. als onderdeel van een communicatieserver) alle HL7v3-berichten van een zorginstelling ontvangen, waarna deze op basis van de applicatie-id kan besluiten dat het bericht voor een andere applicatie is. Als afzender moet de identificatie worden aangegeven van de applicatie die een eventueel retourbericht kan verwerken namens de zendende author or performer. Naar analogie van het bovenstaande hoeft dit weer niet de zorgapplicatie te zijn waar een zorgverlener of medewerker die de berichtinhoud heeft samengesteld. Poortapplicaties worden vaak gebruikt om de berichtinhoud vertalen naar een ander berichtformaat. Zo hoeft een zorgapplicatie zelf geen HL7v3-berichten te kunnen samenstellen en uitlezen. In dat geval kan de applicatie-id van de poortapplicatie worden gebruikt. Voor HL7v3-berichten die worden uitgewisseld via de ZIM mogen uitsluitend applicatieid’s worden gebruikt die zijn uitgegeven door het LSP. Zie verder [HL7v3 Infra].

144 van 150


B.4 Transport: HTTP-header/SOAP-envelop Deze paragraaf beschouwt de wijze waarop een HTTP-bericht en SOAP-envelop moet worden geadresseerd aan de juiste bestemming.

HTTP header: SOAP envelope applicatie applicatie applicatie

HL7v3 transmission wrapper applicatie

HL7v3 control act wrapper

applicatie

applicatie applicatie applicatie

HL7v3 payload HL7 sender

HL7 sender

SOAP client HTTP client

HL7 sender POST /webServiceName HTTP/1.1 SOAPAction: “urn:hl7-org:v3/naam” Host: www.gbz.nl ………

HL7 sender

SOAP client HTTP client

De bovenstaande figuur toont hoe op dit niveau webservers als afzender en als bestemming worden geadresseerd, alleen voor de bestemming, in de vorm van: • de hostnaam van de HTTP-server die de HTTP-berichtinhoud moet verwerken, • de webServiceName van de webservice die wordt aangesproken, in de vorm van een resource path, • de SOAPAction die aangeeft welke SOAP-server de SOAP-inhoud moet verwerken. Niet weergegeven is dat: • een zorgaanbieder meerdere HTTP-servers kan hebben, die afzonderlijk kunnen worden geadresseerd aan de hand van de resource path, • een zorgaanbieder meerdere SOAP-servers kan hebben, die afzonderlijk kunnen worden geadresseerd aan de hand van de SOAPAction. Merk op dat de SOAP-envelope geen adresgegevens bevat. De SOAPAction staat in de HTTP-header om op HTTP-niveau te kunnen routeren, dus zonder de XML te hoeven ontleden. Voor HL7v3-berichten die worden uitgewisseld via de ZIM mogen uitsluitend de vaste web service namen en SOAPAction namen worden gebruikt die zijn gedefinieerd in de WSDL’s per HL7v3-interaction-id. Zie verder [HL7v3 WSP].


145 van 150

B.5 Verbinding: TCP-header / IP-header Deze paragraaf beschouwt de wijze waarop een TCP-bericht in IP-pakketten moet worden geadresseerd aan de juiste bestemming.

A

B

zorgaanbieder

zorgaanbieder

Applicatie-id’s applicatie applicatie applicatie HL7 sender

GBZ URL

IP-adres

applicatie HL7 sender SOAP client HTTP client TCP handler IP handler

Applicatie-id’s HL7 payload HL7 control act wrapper HL7 transmission wrapper SOAP envelope HTTP header TCP header IP header

applicatie HL7 receiver SOAP server HTTP server TCP handler IP handler

applicatie applicatie applicatie HL7 receiver

GBZ URL

IP-adres

De bovenstaande figuur toont hoe op dit niveau GBZ’en als afzender en als bestemming worden geadresseerd, telkens in de vorm van: • het IP-adres van het GBZ, • de standaard TCP-poort voor HTTP over SSL/TLS: 443. Voor HL7v3-berichten die worden uitgewisseld via de ZIM mogen uitsluitend de hostnamen en IP-adressen worden gebruikt die zijn uitgegeven door de ZSP. De ZSP’s krijgen weer IP-adresreeksen toegewezen door het LSP. Binnen het GBZ mogen vele, willekeurige IP-adressen worden gebruikt, zolang het GBZ naar buiten zich manifesteert onder één IP-adres, zie hoofdstuk 6. Merk op dat de HTTP-server en SOAP-server vaak niet apart herkenbaar zijn. Meestal is er een webserver die deze functies omvat, tezamen met de TCP/IP-handlers. Opmerking:

De relatie tussen adressering op applicatie niveau (zie §B.6) en adressering op netwerk niveau ligt momenteel in de huidige implementatie vast in de configuratiegegevens van het GBZ bij het LSP. Alle gekwalificeerde applicaties van één GBZ hebben momenteel hetzelfde netwerkadres. Er zijn issues om deze beperking op te heffen. In het kader van de impact analyse van issue 1947 v0.9 is aangenomen dat dat niet in de najaarrelease 2008 zal wijzigen. Zolang het LSP routeert op applicatieniveau kan een GBZ volstaan met de aflevering aan de ZIM met

146 van 150


het applicatie-id in de bestemde GBZ. Mocht op enig moment in de toekomst een GBZ een ander GBZ willen adresseren op netwerk niveau dan dient het netwerkadres van de service van de bestemde GBZ opgenomen te worden in de attributen van de gekwalificeerde applicatie en daardoor desgewenst zichtbaar gemaakt worden in het zorgadresboek.


147 van 150

B.6 Versturen van patiëntgegevens Deze paragraaf beschouwt hoe de principes uit de vorige paragrafen worden toegepast wanneer een HL7v3-opdrachtbericht via de ZIM aan een bestemming wordt gericht.

1

2 ik wil iets versturen

zorgaanbieder

zorgaanbieder

Applicatie 1

UZI-nr URA-B rolCode

HL7 sender

Appl2-id URA2

SOAP client HTTP client TCP handler IP handler GBZ1

www.zim.nl

IP-adres ZIM

HL7 transceiver SOAP client/serv HTTP client/serv TCP handler IP handler ZIM

UZI-nr URA-B rolCode

Applicatie 2

Appl2-id URA2

HL7 receiver

www.gbz2.nl

IP-adres GBZ2

SOAP server HTTP server TCP handler IP handler GBZ2

De bovenstaande figuur toont in de berichten slechts de cruciale adresgegevens van de bestemming. Zorgaanbieder1 gebruikt applicatie1 om een opdracht m.b.t. een bepaalde patiënt/cliënt te sturen naar zorgaanbieder2 en zoekt daartoe diens UZI-nr, rolcode, URA op in een zorgadresboek of een lokaal adresbestand (niet afgebeeld). Applicatie1 heeft onder water tegelijk de applicatie-id van deze zorgaanbieder opgehaald uit het zorgadresboek of adresbestand. Applicatie1 zet diens UZI-nr, rolcode, URA in een HL7v3-bericht en vermeldt de applicatie-id en URA op de HL7v3-envelop. De web server van GBZ1 stuurt de HL7v3-envelop per HTTP/SOAP als transportmiddel naar de ZIM en gebruikt daarbij altijd de zelfde host name van de ZIM als bestemming. De web server van de ZIM kiest weer HTTP/SOAP als transportmiddel naar GBZ2, nadat de ZIM heeft opgezocht in zijn GBZ-configuratietabel dat applicatie met Appl2-id zich bevindt op GBZ2 en gebruikt de bijbehorende host name als bestemming. Merk op dat de ZIM hier als “bridge” fungeert, zie HL7v3 Abstract Transport Specification. Dit betekent dat de ZIM slechts HL7v3-berichten doorschuift zonder de HL7v3-envelop te openen. Zo worden HL7v3-opdrachten van GBZ1 door de ZIM afgeleverd bij GBZ2 alsof dat rechtstreeks ging.

148 van 150


B.7 Opvragen van patiëntgegevens Deze paragraaf beschouwt hoe de principes uit de vorige paragrafen worden toegepast wanneer een HL7v3-opvraagbericht via de ZIM aan een bestemming wordt gericht.

1

2 ik wil iets opvragen

zorgaanbieder

zorgaanbieder

Applicatie 1

(rolCode)

Schakel punt

(rolCode)

Applicatie 2

HL7 sender

ZIM-id LSP

HL7 transceiver

Appl2-id URA2

HL7 receiver

SOAP client HTTP client TCP handler IP handler GBZ1

www.zim.nl

IP-adres ZIM

SOAP client/serv HTTP client/serv TCP handler IP handler ZIM

www.gbz2.nl

IP-adres GBZ2

SOAP server HTTP server TCP handler IP handler GBZ GBZ2 GBZ

De bovenstaande figuur toont in de berichten slechts de cruciale adresgegevens van de bestemming. Zorgaanbieder1 gebruikt applicatie1 om een opvraag m.b.t. een bepaalde patiënt/cliënt te sturen naar de ZIM, want hij weet zelf niet welke andere zorgaanbieders allemaal patiëntgegevens hebben van deze patiënt/cliënt. Applicatie1 specificeert het BSN (niet afgebeeld) en de opvraagcriteria (waaronder eventueel een specifieke rolcode) in een HL7v3-bericht en vermeldt de ZIM-id en het LSP op de HL7v3-envelop. De web server van GBZ1 stuurt de HL7v3-envelop per HTTP/SOAP als transportmiddel naar de ZIM en gebruikt daarbij altijd dezelfde host name van de ZIM als bestemming. De ZIM-applicatie (schakelpunt) leest de HL7v3-berichtinhoud en kijkt op basis van het BSN en de opvraagcriteria in de verwijsindex (niet afgebeeld) om te bepalen welke applicaties allemaal patiëntgegevens hebben van deze patiënt/cliënt, en stuurt de ongewijzigde HL7v3-berichtinhoud in nieuwe HL7v3-enveloppen door naar die applicaties. De web server van de ZIM kiest weer HTTP/SOAP als transportmiddel naar de GBZ’en, nadat de ZIM heeft opgezocht in zijn GBZ-configuratietabel op welke GBZ’en de


149 van 150

verschillende bronapplicaties zich bevinden en gebruikt de bijbehorende host names als bestemming. Merk op dat de ZIM hier als “gateway” fungeert, zie HL7v3 Abstract Transport Specification. Dit betekent dat de ZIM als ontvanger van HL7v3-berichten optreedt en daarop gebaseerd andere HL7v3-berichten (met dezelfde inhoud) verstuurt naar andere zorgaanbieders. Merk op dat de opleverende GBZ’en niet aan de (door de ZIM gewijzigde) Transmission Wrapper, maar wel aan de (door de ZIM niet gewijzigde) ControlAct Wrapper kunnen zien waar de opvraag vandaan kwam.

150 van 150


Technische architectuur AORTA

Recommend Documents