Technische architectuur AORTA

Transcriptie

1 Technische architectuur AORTA postadres: Postbus 19121, 2500 CC Den Haag bezoekadres: Oude Middenweg 55, 2491 AC Den Haag telefoon: (070) ; fax: (070) ; Versie : Datum : 31 oktober 2008

2

3 Inhoudsopgave 1 Inleiding Doel Doelgroep Versie, status en wijzigingshistorie Achtergrond Reikwijdte Structuur Samenhang met andere documenten Uitgangspunten Normatieve referenties Informatieve referenties Afkortingen Begrippen ICT-voorzieningen (ICT) Inleiding Sectorale BerichtenVoorziening UZI-register UZI-pas en UZI-servercertificaat Normaal gebruik van UZI-passen Gastgebruik van UZI-passen Zorgadresboek Zorg Informatie Makelaar RouteerFunctie DataCommunicatieNetwerken Goed Beheerd Zorgsysteem LSP-portaal {toekomst} XIS-leverancier/ASP-portaal Samenhang tussen ICT-voorzieningen Berichtuitwisseling (BUW) Overzicht van gebruikersinteracties Indirect versturen Indirect opvragen Beheeroverdracht Berichttransport (BTP) Inleiding Indirect versturen Indirect opvragen Beheeroverdracht Connectiviteit (CNV) IP-koppeling tussen GBZ en ZIM Aansluiting van applicatie op schakelpunt IP-koppeling tussen GBZ en IP-koppeling tussen GBZ en CA s IP-koppeling tussen GBZ en SBV-Z Koppeling tussen GBZ en webportaal Beveiliging (BVL) Inleiding...61 Technische architectuur AORTA

4 7.1.1 Vertrouwensniveau laag Vertrouwensniveau midden Combinatie van vertrouwensmiddelen in de beveiligingsketen Beveiliging tussen GBZ-gebruikers en GBZ-applicaties Authenticatie met wachtwoord Authenticatie met UZI-pas niet op naam Authenticatie met UZI-pas op naam Authenticatie van gast-gbz-gebruikers Beveiliging tussen GBZ-applicaties en ZIM Authenticatie met het UZI-servercertificaat Authenticatie met de UZI-pas niet op naam Authenticatie met de UZI-pas op naam Vertrouwelijkheid tussen GBZ-applicaties en ZIM Architectuurbeslissingen Beveiliging tussen GBZ-gebruikers en ZIM Geen authenticatie van de GBZ-gebruiker Tokenauthenticatie van de GBZ-gebruiker Sessieauthenticatie van de GBZ-gebruiker Beveiliging tussen GBZ-dossiers/postbussen en ZIM Beveiliging tussen registers en ZIM Interne beveiliging GBZ Interne beveiliging ZIM Beschikbaarheid (BSK) Beschikbaarheid van een GBZ Beschikbaarheid van de ZIM Beschikbaarheid van een DCN Beschikbaarheidstoestanden Samenvatting Capaciteit en schaalbaarheid (CAP) Inleiding Capaciteitschatting Dempende maatregelen tbv ZIM SSL/TLS-sessies HL7v3-verzoekberichten Dempende maatregelen tbv GBZ SSL/TLS-sessies HL7v3-verzoekberichten Responstijden (RPT) Inleiding Indirect versturen Indirect opvragen Betrouwbaarheid (BTW) Inleiding Uitzonderingen in de keten Detecteren van uitzonderingen Bundelen van uitzonderingen Melden van uitzonderingen Afhandelen van uitzonderingen Indirect versturen Indirect opvragen Beheeroverdracht van 150 Technische architectuur AORTA

5 11.10 {toekomst} Identificatie van berichten Identificatie van patiëntstukken Bijlage A - Bundelen, groeperen, doseren, etc A.1 Inleiding A.2 Achtergrond A.3 Vraagstelling A.3.1 Groeperen A.3.2 Bundelen A.3.3 Doseren A.3.4 Sorteren A.4 Scenario s van bundelen en doseren A.4.1 Niet bundelen, niet doseren A.4.2 Niet bundelen, wel doseren A.4.3 Wel bundelen, niet doseren A.4.4 Wel bundelen, wel doseren Bijlage B - Adresseren B.1 Inleiding B.2 Inhoud: HL7v3 Payload en ControlAct Wrapper B.3 Envelop: HL7v3 Transmission Wrapper B.4 Transport: HTTP-header/SOAP-envelop B.5 Verbinding: TCP-header / IP-header B.6 Versturen van patiëntgegevens B.7 Opvragen van patiëntgegevens Technische architectuur AORTA

6 1 Inleiding 1.1 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_IN NL en QUMT_IN020021NL aan gebruikersscenario tabel paragraaf : Wijziging van de manier waarop foutmeldingen terug gemeld worden. 1502: generieke foutafhandeling, zie paragraaf 11.1 tot en met : bundelen i.p.v. groeperen van foutmeldingen, zie paragraaf van 150 Technische architectuur AORTA

7 1586: kleine tekstuele wijziging. 1106, 1410, 1589 en 1598: Wijziging van de manier waarop de time-outs bij het indirect opvragen werken 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. Technische architectuur AORTA

8 CIBG UZIregister SBV-Z LSP VWI AUT ZIM SCH I&A LOG ZSP DCN DCN ZSP zorgaanbieder zorgaanbieder zorgaanbieder zorgaanbieder UZI UZI UZI UZI UZI UZI UZI UZI zorg verlener GBZ GBZ GBZ GBZ GBZ XIS XIS XIS XIS XIS XIS mede werker zorg verlener mede werker zorg verlener mede werker 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 Technische architectuur AORTA

9 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. Technische architectuur AORTA

10 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 Technische architectuur AORTA

11 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] [Technische architectuur BijlageC] Informatiesysteemarchitectuur AORTA Technische architectuur AORTA Bijlage C Nictiz Nictiz [HL7v3] HL7 Version 3 Standard [BSN] [SBV-Z] [UZI] een verzameling documenten m.b.t. het BSN-stelsel een verzameling documenten m.b.t. de SBV-Z een verzameling documenten m.b.t. het UZI-register [WBP] Wet Bescherming Persoonsgegevens CBP [WGBO] [NEN7510] Wet op de geneeskundige behandelingsovereenkomst Nederlandse norm NEN7510 (nl), Medische Informatica Informatiebeveiliging in de zorg - Algemeen bsn.nl onder Technische specificaties nl VWS NEN Versie Datum oktober oktober oktober oktober 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 oktober oktober 2008 Technische architectuur AORTA

12 Identificatie Titel Bron [PvE GBZ] [PvE LSP] ** [IH generieke berichten] [AO Medicatiegegevens] [AO Huisartswaarneemgegevens ] [AO Medicatiebewaking] Programma van eisen voor een goed beheerd zorgsysteem Programma van eisen aan het landelijk schakelpunt Implementatiehandleiding generieke berichten Architectuurontwerp Medicatiegegevens Architectuurontwerp Huisartswaarneemgegevens Architectuurontwerp Medicatiebewaking Nictiz Nictiz Nictiz Nictiz Nictiz Nictiz Versie Datum oktober oktober oktober oktober oktober 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 wet- en regelgeving gehanteerd worden. Onder identificatie wordt in dit document bijvoorbeeld iets anders verstaan dan onder de definitie binnen het wettelijk kader. 12 van 150 Technische architectuur AORTA

13 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 Nationaal UZI register SBV-Z LSP Nationaal ZAB ZIM RF Regionaal ZSP DCN DCN ZSP Lokaal ZA ZA ZA ZA ZA ZA GBZ GBZ GBZ GBZ GBZ 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. Technische architectuur AORTA

14 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 Technische architectuur AORTA

15 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 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 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 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 Van die passen moet het GBZ tevens de geldigheid van de passen Technische architectuur AORTA

16 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 Technische architectuur AORTA

17 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 APT I&A SVM APF SCH CFG ZIM LOG VWI GGS Technische architectuur AORTA

18 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-, test- en demo- ZIM 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 HL7v3- berichtsoorten 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 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 Technische architectuur AORTA

19 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. Technische architectuur AORTA

20 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 LOG GP SVM BRW Kaart PVM APB MDT APF GBZ PB ZA PD PI 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 Technische architectuur AORTA

21 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. Technische architectuur AORTA

22 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. APT ZAB I&A SVM LSP portaal APF LOG SCH CFG VWI ZIM GGS ABH 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 LOG GP SVM BRW ABH Kaart PVM APB PB ZA MDT PD APF PI GBZ TGT 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 Technische architectuur AORTA

23 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: SBV PR ZR UZI APT ZAB I&A SVM LSP portaal APF LOG SCH CFG VWI ZIM GGS ABH DCN Kaartlezer LOG GP SVM BRW ABH Kaart PVM APB PB ZA MDT PD APF PI GBZ TGT 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. Technische architectuur AORTA

24 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. ZIM GBZ GBZ HL7v3 {toekomst} multimediale bestandsoverdracht SBV-Z HL7v3 HL7v3, HTML, XML-bestandsoverdracht UZI-register LDAP LDAP, HTML LSP-portaal HL7v3 HTML {toekomst} XIS-leverancier/ASP portaal HL7v3 HTML 24 van 150 Technische architectuur AORTA

25 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 HL7v3- gebeurtenissen (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. Technische architectuur AORTA

26 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 Technische architectuur AORTA

27 Gebruiksscenario Gebruikersinteractie Berichtnaam interactie [INL] in/uitloggen gebruiker Inloggen gebruiker Geen Uitloggen gebruiker Geen HL7v3 payload HL7v3 controlact wrapper HL7v3 transmiss wrapper HL7v3 batch wrapper HL7v3- Ge- gevens- soort Mechanisme Toepassingsrol [SPA] selecteren patient/cliënt Opvragen PatiëntIdentificatie opvragenpatiëntidentificatie QUPA_IN opleverenpatiëntidentificatie QUPA_IN Opvragen Omloop status WID opvragenomloopstatuswid PRPA_IN NL opleverenomloopstatuswid PRPA_IN NL Opvragen PatiëntIdentificatie opvragenpersoonsgegevens QUPA_IN opleverenpersoonsgegevens QUPA_IN [SZA] Selecteren zorgaanbieder Opvragen Zorgadresboek opvragenzorgverlenerdetails PRPM_IN NL opleverenzorgverlenerdetails PRPM_IN NL opvragenzorgaanbiederdetails PRPM_IN QUPA_MT QUPA_MT QUPA_MT QUPA_MT QUPA_MT QUPA_MT QUPA_MT QUPA_MT PRPM_MT QUQI_MT MFMI_MT QUQI_MT MFMI_MT QUQI_MT MFMI_MT QUQI_MT MFMI_MT QUQI_MT MCCI_MT MCCI_MT MCCI_MT MCCI_MT MCCI_MT MCCI_MT MCCI_MT MCCI_MT MCCI_MT indirect opvragen indirect opvragen indirect opvragen alle alle alle alle alle alle Technische architectuur AORTA 27 van 150

28 nisme Gebruiksscenario HL7v3- HL7v3 HL7v3 Gebruikersinteractie interactie payload controlact Berichtnaam wrapper opleverenzorgaanbiederdetails PRPM_IN PRPM_MT MFMI_MT opvragenzorgaanbiederorganisatiedeeldetails Zie [IH Generieke berichten] opleverenzorgaanbiederorganisatiedeeldetails Zie [IH Generieke berichten] opvragenzorgaanbiederapplicatiede Zie [IH Generieke berichten] tails opleverenzorgaanbiederapplicatiede Zie [IH Generieke berichten] tails Bijwerken Zorgadresboek bijwerkenzorgaanbiederdetails Zie [IH Generieke berichten] bijwerkenzorgverlenerdetails Zie [IH Generieke berichten] bijwerkenzorgaanbiederorganisatie Zie [IH Generieke berichten] deeldetails bijwerkenzorgaanbiederapplicatiede Zie [IH Generieke berichten] tails [BIJ] bijhouden patiëntgegev. Geen [PUB] publiceren patiëntgegev. Publiceren MedicatieVoorschriften Publiceren MedicatieVerstrekkingen Publiceren EerstelijnsDossier aanmeldengegevens HL7v3 transmiss wrapper MCCI_MT HL7v3 batch wrapper Ge- gevens- soort Mecha- Toepassingsrol MFMT_IN MFMT_MT MFMI_MT MCCI_MT SBADM SPLY PCPR direct versturen medicatievoorschrij vend en - verstrekkend systeem Vaste huisarts systeem MFMT_IN MFMT_MT MFMI_MT MCCI_MT SBADM direct medicatievoorschrij 28 van 150 Technische architectuur AORTA

29 afmeldengegevens MFMT_IN MFMT_MT [ABO] abonneren patiëntgegev. Niet gede- finieerd [OPV] opvragen patiëntgegev. Opvragen Index opvragenindex QUMT_IN opleverenindex QUMT_IN opvragenindex (met QUMT_IN0 gegevensbeheerder) 20011NL QUMT_MT MFMT_MT QUMT_MT NL MFMI_MT QUQI_MT MFMI_MT QUQI_MT MCCI_MT MCCI_MT MCCI_MT MCCI_MT SBADM SPLY PCPR Gebruiksscenario HL7v3- HL7v3 HL7v3 HL7v3 HL7v3 Ge- Gebruikersinteractie interactie payload controlact transmiss batch gevens- soort Berichtnaam wrapper wrapper wrapper heraanmeldengegevens SPLY PCPR Mechanisme Toepassingsrol versturen vend en - verstrekkend systeem Vaste huisarts systeem direct versturen direct opvragen medicatievoorschrij vend en - verstrekkend systeem Vaste huisarts systeem alle opleverenindex (met gegevensbeheerder) Opvragen MedicatieVoorschriften QUMT_IN NL MFMT_MT NL MFMI_MT MCCI_MT opvragenmedicatievoorschriften QURX_IN QURX_MT QUQI_MT MCCI_MT SBADM indirect medicatievoorschrij (eerste) NL NL opvragen vend systeem opleverenmedicatievoorschriften QURX_IN PORX_MT QUQI_MT MCCI_MT MCCIMT medicatievoorschrij NL NL vend systeem opvragenmedicatievoorschriften QUQI_IN n.v.t. QUQI_MT MCCI_MT SBADM c Technische architectuur AORTA 29 van 150

30 opvragenmedicatieverstrekkingen (eerste) QURX_IN NL QURX_MT NL QUQI_MT MCCI_MT HL7v3 batch wrapper MCCIMT Gebruiksscenario HL7v3- HL7v3 HL7v3 HL7v3 Gebruikersinteractie interactie payload controlact transmiss Berichtnaam wrapper wrapper (vervolg) opleverenmedicatievoorschriften QURX_IN PORX_MT QUQI_MT MCCI_MT NL NL Opvragen MedicatieVerstrekkingen Gegevenssoort SPLY Mechanisme indirect opvragen Toepassingsrol medicatievoorschrij vend systeem medicatievoorschrij vend en - verstrekkend systeem opleverenmedicatieverstrekkingen QURX_IN NL opvragenmedicatieverstrekkingen QUQI_IN (vervolg) PORX_MT NL n.v.t. QUQI_MT QUQI_MT MCCI_MT MCCI_MT medicatieverstrekk end systeem SPLY medicatievoorschrij vend en - verstrekkend systeem opleverenmedicatieverstrekkingen QURX_IN NL Opvragen Samenvatting DWH opvragensamenvattingvoordwh QUPC_IN NL opleverensamenvattingvoordwh QUPC_IN NL Opvragen Contra-indicaties opvragencontra-indicaties REPC_IN NL opleverencontra-indicaties REPC_IN NL PORX_MT NL QUPC_MT NL REPC_MT NL -PS QUMT_MT NL REPC_MT NL QUQI_MT QUQI_MT QUQI_MT QUQI_MT QUOI_MT MCCI_MT MCCI_MT MCCI_MT MCCI_MT MCCI_MT MCCIMT MCCIMT PCPR indirect opvragen medicatieverstrekk end systeem Waarnemende huisarts systeem Vaste huisarts systeem 30 van 150 Technische architectuur AORTA

31 Gebruiksscenario Gebruikersinteractie Berichtnaam [STU] versturen patiëntgegev. Versturen MedicatieVoorschrift interactie versturenmedicatievoorschrift PORX_IN NL Versturen Medicatieverstrekking versturenmedicatieverstrekking PORX_IN NL Versturen Waarneemverslag WDH [BOV] beheeroverdracht. Verzoeken Overdracht versturenverslagwdh REPC_IN NL overdrachtverzoek COMT_IN Antwoorden Overdracht overdrachtantwoord (aanvaarding) COMT_IN overdrachtantwoord (afwijzing) COMT_IN Intrekken Overdracht HL7v3 payload PORX_MT NL PORX_MT NL REPC_MT NL _WR COMT_MT COMT_MT COMT_MT HL7v3 controlact wrapper MCAI_MT MCAI_MT MCAI_MT MCAI_MT MCAI_MT MCAI_MT HL7v3 transmiss wrapper MCCI_MT MCCI_MT MCCI_MT MCCI_MT MCCI_MT MCCI_MT intrekkingverzoek COMT_IN COMT_MT MCAI_MT MCCI_MT intrekkingantwoord (aanvaarding) COMT_IN COMT_MT MCAI_MT MCCI_MT intrekkingantwoord (afwijzing) COMT_IN COMT_MT MCAI_MT MCCI_MT intrekkingkennisgeving COMT_IN COMT_MT MCAI_MT MCCI_MT HL7v3 batch wrapper HL7v3- Ge- gevens- soort Mechanisme indirect versturen indirect versturen indirect versturen Toepassingsrol medicatieverstrekk end systeem medicatieverstrekk end systeem Waarnemende huisarts systeem Technische architectuur AORTA 31 van 150