Inhoudsopgave Inleiding ..................................................................................................... 4 1.1. Doel van dit document ............................................................................ 4 1.2. Doelgroep ............................................................................................. 4 1.3. Totstandkoming van dit document ............................................................ 4 1.4. Opbouw van dit document ....................................................................... 4 1.5. Verschillen met vorige releases................................................................. 5 2. Verwijsindex (VWI) ...................................................................................... 6 2.1. Inleiding................................................................................................ 6 2.1.1. Het aanmelden van patiëntgegevens.................................................... 7 2.1.2. Het opvragen van patiëntgegevens ...................................................... 8 2.1.3. Het opvragen van metagegevens ...................................................... 10 2.1.4. Het abonneren op metagegevens ...................................................... 11 2.2. Verwijsindex berichtbeschrijving ............................................................. 12 2.2.1. Datamodel van de verwijsindex......................................................... 13 2.2.2. Berichtmodel verwijsindex ................................................................ 13 2.2.3. Berichtmodel verwijsindex query ....................................................... 15 2.2.4. Inhoud verwijsindex ........................................................................ 17 2.3. Voorbeeldberichten ............................................................................... 18 2.3.1. Categoraal registreren van een groep Acts.......................................... 18 2.3.2. Atomair registreren van een Act ........................................................ 20 3. ZorgaanbiederGids (ZG).............................................................................. 23 3.1. Inleiding.............................................................................................. 23 3.2. Zorgverlener(persoon)register berichtbeschrijving ..................................... 23 3.3. Organisatieregister berichtbeschrijving .................................................... 24 3.3.1. Berichtmodel organisatieregister query............................................... 26 3.3.2. Berichtmodel organisatieregister antwoord ......................................... 27 3.4. Voorbeeldberichten ............................................................................... 28 3.4.1. Query parameter voorbeelden........................................................... 28 3.4.2. Query/antwoord voorbeeld ............................................................... 30 4. Patientenregister (PR) ................................................................................ 33 4.1. Inleiding.............................................................................................. 33 4.1.1. Het opvragen van persoonsgegevens ................................................. 33 4.2. Persoonsregister berichtbeschrijving........................................................ 34 4.2.1. Berichtmodel persoonsregister query ................................................. 35 4.2.2. Berichtmodel persoonsregister antwoord ............................................ 36 4.3. Voorbeeldberichten ............................................................................... 39 4.3.1. Query parameter voorbeelden........................................................... 39 4.3.2. Query/antwoord voorbeeld ............................................................... 41 5. Schakelpunt (SCH)..................................................................................... 45 5.1. Inleiding.............................................................................................. 45 5.1.1. Het routeren van berichten............................................................... 45 5.1.2. Het samenvoegen/routeren van antwoordberichten.............................. 46 5.1.3. Het adresseren van berichten ........................................................... 47 5.2. Voorbeeldberichten ............................................................................... 48 5.2.1. Voorbeeld Routeringsfoutmelding ...................................................... 48 5.2.2. Voorbeeld Batchgeoriënteerd antwoordberichten ................................. 49 6. Autorisatie ................................................................................................ 51 6.1. Inleiding.............................................................................................. 51 6.1.1. Noodgeval queries........................................................................... 52 6.2. Noodgeval queries berichtbeschrijving ..................................................... 52 6.3. Voorbeeldberichten ............................................................................... 53 6.3.1. Voorbeeld noodgeval query .............................................................. 53 1.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
-1–
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
-2–
Samenvatting De Zorg Informatie Makelaar (ZIM) is een centrale applicatie die in de Nederlandse gezondheidszorg een rol speelt. Een gedetailleerde beschrijving van de ZIM kan worden gevonden in het NICTIZ-document Specificatie van de basisinfrastructuur in de zorg versie 2.2. Patiëntgegevens (zorg- en administratieve gegevens) zijn opgeslagen in een veelheid aan systemen en applicaties bij meerdere zorgleveranciers. Indien deze gegevens toegankelijk kunnen worden gemaakt voor de diverse zorgverleners en de patiënt zelf, dan heeft dit een aantal significante voordelen. Om als centrale applicatie een rol te kunnen spelen bij het toegankelijk maken van de in de diverse applicaties opgeslagen gegevens zal de ZIM de volgende functionele gebieden moeten afdekken: Enterprise Directory (Identity Repository); dit bevat de identificatiegegevens van personen en organisaties betrokken bij zorgprocessen. In het basisinfrastructuurdocument is deze functionaliteit bekend als PatientRegister (PR) en ZorgaanbiederGids. Een van de functionele onderdelen van de ZorgaanbiederGids bestaat uit het ZorgaanbiederRegister (ZR). Authenticatie van personen (zorgverleners, patiënten) en systemen. Access Control; het beheren en handhaven van centrale autorisatieregels, gebaseerd op de identificatiegegevens van de betrokkene. Patiënt/zorgverlener/contact en gegevenssoort database; een repository met zorggerelateerde metagegevens die een zorgverlener in staat stellen te bepalen welke applicaties of zorgverleners nuttige gegevens bezitten. In het basisinfrastructuurdocument is deze functionaliteit bekend als de Verwijsindex (VWI), in Engelstalige HL7 documenten als Act Reference Registry (ARR). Berichtenrouter, op basis van gegevens in de verwijsindex. In het basisinfrastructuurdocument is deze functionaliteit bekend als Schakelpunt (SCH), in Engelstalige HL7 documenten als Gateway. In een optimale situatie zou de fysieke locatie van de gegevens niet meer van belang zijn voor de applicatie van een zorgverlener. De applicatie wisselt alleen nog gegevens uit met (of via) de ZIM. Ten opzichte van een zorgverlener vormt de ZIM een virtuele poort naar alle patiëntgegevens zoals aanwezig bij alle andere zorgverleners. Als voorbeeld van deze virtuele poortfunctie van de ZIM: indien een zorgverlener een overzicht wenst van alle medicatie die verstrekt is aan een bepaalde patiënt, dan richt hij zijn vraagbericht aan de ZIM. De ZIM levert de antwoorden op deze vraag. Het feit dat de ZIM intern deze vraag doorstuurt naar applicaties waarvan het weet dat daar detailgegevens te vinden zijn, is geheel onzichtbaar voor de aanvragende zorgverlener. De gegevensuitwisseling tussen zorgverleners en de diverse delen van de ZIM maken gebruik van de Health Level 7 (HL7) versie 3 standaard. Er is gekozen om een set berichten onder één standaard uit te brengen, omdat hiermee een consistente set van communicatieberichten uitgevaardigd kan worden. Dit document beschrijft hoe de communicatie standaarden zoals toegepast door de ZIM onderdelen Verwijsindex, Patientenregister, ZorgaanbiederGids en Schakelpunt toegepast dienen te worden.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
-3–
1. Inleiding 1.1. Doel van dit document Het document Specificatie van de basisinfrastructuur in de zorg versie 2.2 bevat een functionele beschrijving van de componenten van de ZIM (Zorg Informatie Makelaar) en de met deze applicatie uit te wisselen berichten. Het documenteert zowel het functionele ontwerp als de daaraan ten grondslag liggende ontwerpbeslissingen. Het doel van deze HL7v3 Implementatiehandleiding is te documenteren hoe de communicatie standaarden door de ZIM-onderdelen Verwijsindex, Patiëntenregister, ZorgaanbiederGids en Schakelpunt toegepast dienen te worden. Merk op dat de scope van dit document niet beperkt is tot die zaken die initieel tot de functionaliteit van de ZIM behoren. De exacte vereisten ten aanzien van de door de ZIM te ondersteunen interacties zijn beschreven in de LSP-documentatie.
1.2. Doelgroep Dit document is zowel bedoeld voor beleidsmakers als zorgverleners om hiermee een indruk verkrijgen over de wijze waarop gecommuniceerd zal worden. Het is ook bedoeld voor softwareontwikkelaars, die op grond van de HL7 versie 3 standaard en op grond van dit document hun berichtschema’s en berichten willen implementeren.
1.3. Totstandkoming van dit document Dit document is opgesteld door HL7-specialisten onder aanvoering van NICTIZ in het kader van het AORTA-programma van NICTIZ.
1.4. Opbouw van dit document Dit document bestaat uit de volgende onderdelen: • Verwijsindex-berichten (VWI), • ZorgaanbiederGids (ZG), • Patiëntenregister (PR), en • Schakelpunt-issues (SCH). In elk van deze delen wordt beschreven hoe de functionaliteit van de ZIM wordt ondersteund door middel van de uitwisseling van HL7 versie 3 berichten. Indien gebruik gemaakt wordt van standaard HL7 artefacts wordt veelal verwezen naar de HL7 versie 3 standaardmaterialen. Indien er specifieke aanwijzingen zijn hoe iets (wellicht in afwijking van de internationale standaard) in Nederland geïmplementeerd moet worden dan is dit in de tekst aangegeven. HL7 artefacts worden in dit document aangeduid volgens hun officiële identificatie volgens de HL7 versie 3 ballot #7 van april 2004. Deze artefacts worden in dit document niet in detail besproken, hiervoor wordt verwezen naar de HL7 versie 3 standaard zelf (zie http://www.hl7.org/v3ballot7/html/index.htm). Voor Nederland specifieke artefacts zijn in dit document voorzien van een “NL” code. Referenties naar de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3, dienen zolang dit document nog niet gepubliceerd is, begrepen te worden als een
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
-4–
referentie naar de uitleg van Datatypes en CMETs in de Implementatiehandleiding HL7v3 Medicatieberichten versie 2.3 en de Implementatiehandleiding HL7v3 Waarneming Huisartsen versie 3.1.
1.5. Verschillen met vorige releases Sinds het verschijnen van de vorige versie van dit document waarin de verwijsindexberichten beschreven werden (de Implementatiehandleiding HL7v3 Zorg Informatie Makelaar versie 2.2, september 2004) heeft dit document een aantal veranderingen ondergaan: • Interactiediagrammen en definities van interacties zijn in diverse paragrafen toegevoegd ter verduidelijking. • Naast het aanmelden van individuele Acts bij de Verwijsindex beschrijft paragraaf 2.2.1 hoe men categoraal een set Acts kan registreren. • Naast de structuur van de Verwijsindexberichten wordt tevens beschreven wat de minimale inhoud van de Verwijsindex is, gegeven zowel de functionele vereisten als de vereisten van de HL7 v3 berichten. Zie paragraaf 2.2.4 voor details. • Het toevoegen van Person.BirthPlace als parameter in de vraagberichten aan Persoonsregisters. Zie paragraaf 4.2.1 voor details. • Het toevoegen van 2 interacties ter opvraging van gegevens uit de zorgaanbiederGids: Find Provider Candidates Query (PRPM_IN306050NL) en Find Provider Candidates Query Response (PRPM_IN306051NL). Zie paragraaf 3.2 voor details. • Het corrigeren van een foutieve aanbeveling in paragraaf 3.3: niet PRPM_IN406010 en PRPM_IN406110, maar PRPM_IN405010 en PRPM_IN405110 zijn de toe te passen interacties voor vragen over organisatiegegevens. • Het toevoegen van de mogelijkheid de identificatie (het adres) van de preferente HL7 Applicatie van een zorgverlener op te nemen in het antwoordbericht van Persoons- en Organisatieregisters. Zie de paragrafen 3.3.2 en 4.2.2 voor details. • Het toevoegen van het gebruik van de klasse ObservationEvent aan antwoordberichten van Persoonsregisters. Zie paragraaf 4.2.2 voor details. • De batchvoorbeeldberichten in paragraaf 5.2.2 zijn aangepast aan de gewijzigde beschrijving van batch wrappers in de Implementatiegids HL7 v3 Infrastructurele Domeinen. • De QNAT detectedIssueCode is vervangen door de NAT detectedIssueCode.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
-5–
2. Verwijsindex (VWI) De volgende gebruiksscenario’s (beschreven in het document Specificatie van de basisinfrastructuur in de zorg versie 2.2) worden in dit hoofdstuk uitgewerkt: • Gebruiksscenario 1.2.1: vrijgeven patiëntgegevens bij de verwijsindex, • Gebruiksscenario 1.2.2: afschermen patiëntgegevens bij de verwijsindex, • Gebruiksscenario 2.1.1: opvragen index van beschikbare patiëntstukken, • Gebruiksscenario 2.1.2: opvragen inhoudelijke patiëntstukken, • Gebruiksscenario 1.3.1: aanmelden abonnement bij de verwijsindex, • Gebruiksscenario 1.3.2: afmelden abonnement bij de verwijsindex. Het begrip Verwijsindex wordt in het Engels aangeduid door Act Reference Registry.
2.1. Inleiding Iedere zorgverlener houdt de patiëntgegevens die onder zijn verantwoordelijkheid zijn gegenereerd, bij in zijn eigen zorgdossier. Samenwerking met andere zorgverleners leidt tot de behoefte om patiëntgegevens op te vragen, ongeacht in welke zorgapplicatie en ongeacht onder verantwoordelijkheid van welke zorgverlener die gegevens opgeslagen zijn. De verwijsindex bestaat uit een database met metagegevens aangaande patiëntgegevens die aanwezig zijn in de applicaties van diverse zorgverleners. Deze metagegevens hebben als doel op een later moment het vinden van relevante patiëntgegevens mogelijk te maken. Het biedt een overzicht van de gegevens zoals ze in de verwijsindex zijn aangemeld. Het zijn niet de gedetailleerde gegevens zelf (die worden door andere berichten opgevraagd), maar de ‘metagegevens’, ofwel het ‘overzicht’ ofwel de ‘index’. Een zorgverlener kan de patiëntgegevens van een specifieke patiënt opvragen bij elke willekeurige zorgverlenende instantie die relevante gegevens ter beschikking heeft. Dit document beschrijft generiek hoe zorggerelateerde metagegevens kunnen worden opgeslagen in de verwijsindex. Deze metagegevens hebben als doel op een later moment het vinden van relevante patiëntgegevens mogelijk te maken. Overwegingen aangaande de hoeveelheid gegevens (de dikte van de verwijsindex) en de frequentie van aanmelding van gegevens worden beschreven in het document Specificatie van de basisinfrastructuur in de zorg versie 2.2. Dit document beschrijft berichten waarmee de beschikbaarheid van een of meer gegevens van een bepaald type (vastgelegd door object klasse en gegevenssoort) bij een zorgverlener bij de verwijsindex kan worden aangemeld. De verzendende applicatie kan van alle in zijn applicatie bekende elementaire patiëntgegevens de bijbehorende metagegevens aanmelden bij de verwijsindex. De metagegevens bevatten onder andere de zorgverlener, het zorgverlenertype, de gegevenssoort, de datum van de activiteit, de status van de aangemelde gegevens (bijv. uitgevoerd, definitief rapport, gepland) en de patiënt identificatie. De werking van de verwijsindex wordt hieronder beschreven aan de hand van vier veel voorkomende scenario's: • Het aanmelden van patiëntgegevens bij de verwijsindex • Het opvragen van patiëntgegevens via de verwijsindex • Het opvragen van metagegevens bij de verwijsindex • Het abonneren op metagegevens bij de verwijsindex
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
-6–
Voor metagegevens-gerelateerde berichten kan gebruik gemaakt worden van de in het HL7 Shared Messages domein beschreven berichten aangaande Act Reference Registries. Zie het onderdeel Common Domains / Shared Messages / Act Reference Topic in de HL7 versie 3 standaard voor details.
2.1.1. Het aanmelden van patiëntgegevens Wanneer een zorgverlener allerlei patiëntgegevens invoert in zijn eigen zorgdossier, kan hij besluiten of deze patiëntgegevens beschikbaar komen voor opvraag door andere zorgverleners of niet. Ook in latere instantie kan hij besluiten bepaalde patiëntgegevens beschikbaar te stellen voor opvraag, of om deze niet meer ter beschikbaar te stellen. Wanneer een zorgverlener op verzoek van de patiënt diens gehele dossier verwijdert, of wanneer de verplichte bewaartermijn is verstreken, is opvragen niet langer mogelijk. In welke mate applicaties dit ondersteunen als een handmatig of als een automatisch proces, is afhankelijk van de specifieke storyboards waarin ook de juridische aspecten verwerkt zijn.
Figuur 1: Het aanmelden van patiëntgegevens Indien de zorgverlenende instantie zorggegevens aanmaakt of wijzigt, dan stuurt de zorgapplicatie de metagegevens daarvan (de Keys) naar de verwijsindex (de Act Registry). De metagegevens bestaan uit die gegevens die op een later moment het beantwoorden van vragen door/via de verwijsindex mogelijk maken. Het aanmelden van nieuwe of gewijzigde patiëntgegevens kan zowel direct plaatsvinden als op een later moment. Doorgaans zal de zorgverlener die zorggegevens aanmaakt (de gegevensauteur) deze ook zelf aanmelden bij de verwijsindex. Indien er organisatorisch geregeld is dat een zorggegeven eerst aan een andere zorgverlener wordt verstuurd (bijvoorbeeld na afloop van een huisartswaarneming) dan kan deze ontvangende zorgverlener, als gegevenshouder (en niet als gegevensauteur), het zorggegeven aanmelden bij de verwijsindex. Het gegeven is daarmee opvraagbaar bij de gegevenshouder. De gegevensauteur is dus niet per definitie de gegevenshouder. Daarmee is niet gezegd dat het zo moet verlopen, maar alleen dat er onderscheid is tussen het verwerken van een gegeven (door het in de context van het eigen dossier te plaatsen) en het overnemen van de verantwoordelijkheid van beheer en aanmelding van dat gegeven. Zo kan een huisarts het waarneemretourbericht verwerken, maar ook de registratie van het waarneemcontact overnemen (door bijvoorbeeld een overdrachtverzoek van de waarnemer te accepteren). In beide gevallen blijft de auteur van het waarneemcontact de waarnemer, maar bij overdracht wordt de bron (en daarmee de aanmelder) veranderd. Het registreren van metadata-keys is gebaseerd op de in de HL7 Shared Messages domein beschreven berichten, zie paragraaf 2.2.2 voor een toelichting.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
-7–
FAQ: In het aanmeldbericht dient het Burger Service Nummer (BSN) van de patiënt te worden opgenomen. Indien het BSN niet bekend is dient voorafgaand aan de aanmelding eerst een vraag gesteld te worden aan het Persoonsregister (PR) om het BSN te verkrijgen. Interactiediagram:
Interactie: Activate Act Trigger Event Transmission Wrapper Control Act Wrapper Message Type
2.1.2. Het opvragen van patiëntgegevens Wanneer een zorgverlener patiëntgegevens wil opvragen, stuurt hij een vraag naar de verwijsindex. De verwijsindex ondersteunt de beantwoording van de vraag door het
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
-8–
routeren van de vraag aan die zorgapplicaties (of andere verwijsindexen) die relevante patiëntgegevens bezitten. De vragende zorgverlener kan specificeren welke patiëntgegevens opgevraagd worden, aan de hand van onder andere de volgende selectiecriteria: • over welke patiënt de gegevens gaan, • welke verantwoordelijke zorgverlener deze gegevens in beheer heeft, • Welk zorgverlenertype (bijv. specialisme) deze gegevens aangemaakt heeft, • van welke gegevenssoort de gegevens zijn, • tot welke episode de gegevens behoren, • op welke tijdsperiode de gegevens slaan.
Figuur 2: Het opvraagproces van patiëntgegevens Het raadplegen van de verwijsindex kan worden geïllustreerd aan de hand van de volgende stappen: • Een zorgverlener oordeelt dat hij de patiëntgegevens van een patiënt moet raadplegen voordat hij de juiste behandeling kan doorvoeren. • De zorgverlener start een zoekfunctie op basis van de geselecteerde patiënt. • Met behulp van de zoekfunctie kan de zorgverlener bepaalde selectiecriteria meegeven (de Search Details). • Via de verwijsindex worden die zorgapplicaties benaderd waarvan bekend is dat zij relevante patiëntgegevens bezitten. • De zorgapplicaties verwerken het verzoek en genereren een antwoordbericht. Een antwoordbericht bevat nul of meer patiëntgegevens. • De antwoordberichten worden via de verwijsindex doorgestuurd naar de vragende zorgverlener. • De gegevens van de verschillende zorgapplicaties worden op het scherm van de zorgverlener getoond. Het opvragen van patiëntgegevens, en het opleveren daarvan, is gebaseerd op Query- en Response- berichten zoals gedefinieerd in het HL7 domein dat zich richt op de categorie gegevens die opgevraagd wordt. Zie bijvoorbeeld het HL7 v3 Laboratory domein voor een beschrijving van diverse Queries en bijbehorende antwoorden gerelateerd aan labuitslagen. FAQ: Betekent het feit dat de verwijsindex maar een beperkte hoeveelheid
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
-9–
metagegevens bevat ook dat een zoekfunctie tot die gegevens beperkt is? Nee, een zoekvraag gedefinieerd in een domein (zoals Laboratory) kan gebruik maken van domeinspecifieke zoekcriteria (bijvoorbeeld: een specifiek type onderzoek, of de uitslag van een onderzoek). De verwijsindex gebruikt zoveel mogelijk informatie uit de zoekvraag (maar niet noodzakelijkerwijs alle informatie) ten einde de vraag te kunnen routeren naar systemen die relevante patiëntgegevens bezitten. Deze systemen kunnen gebruik maken van alle informatie uit de zoekvraag. Interactiediagram:
2.1.3. Het opvragen van metagegevens Wanneer een zorgverlener van een bepaalde patiënt allerlei patiëntgegevens wil opvragen, dan wenst hij wellicht allereerst een overzicht van de beschikbare gegevens zoals deze zijn aangemeld bij de verwijsindex. Met behulp van dit overzicht kan worden doorgevraagd naar de gewenste patiëntgegevens. Als hij al precies weet wat hij zoekt, kan hij ook op basis van bepaalde selectieparameters rechtstreeks de gewenste patiëntgegevens opvragen, zoals beschreven in paragraaf 2.1.2.
Figuur 3: Het opvraagproces van metagegevens Naast het opvragen van de patiëntgegevens bestaat de mogelijkheid de verwijsindex te bevragen aangaande de aldaar aanwezige metagegevens. • De vragende zorgapplicatie stuurt een vraag voorzien van metagegevens, ofwel de selectiecriteria (de Searchkeys) aan de verwijsindex. • De verwijsindex beantwoordt de vraag met nul of meer metagegevens. • De vragende zorgapplicatie zal veelal een selectie maken uit deze metagegevens en de bijbehorende patiëntgegevens via de verwijsindex opvragen. Het opvragen van metadata-keys is gebaseerd op de in de HL7 Shared Messages domein beschreven berichten, zie paragraaf 2.2.2 voor een toelichting.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
2.1.4. Het abonneren op metagegevens Wanneer een zorgverlener op de hoogte wil worden gesteld indien van een bepaalde patiënt patiëntgegevens worden aangemeld bij de verwijsindex, dan kan hij zich abonneren op meldingen aangaande een bepaalde set gegevenssoorten van de patiënt.
Figuur 4: Het abonneren op metagegevens
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 11 –
Als een nieuw zorggegeven wordt aangemeld bij de verwijsindex, en deze voldoet aan de selectiecriteria van het opgegeven abonnement, dan wordt de aanmelding door de verwijsindex naar de geabonneerde zorgapplicatie verzonden. Indien de zorgverlener van een van de gemelde gegevenssoorten de details wenst te zien dan kunnen deze worden opgevraagd zoals beschreven in paragraaf 2.1.2. Het abonneren op metadata-keys is gebaseerd op de in het HL7 Shared Messages domein beschreven berichten, zie paragraaf 2.2.2 voor een toelichting. Interactiediagram:
2.2. Verwijsindex berichtbeschrijving Dit hoofdstuk bevat een beschrijving van de berichten die worden uitgewisseld in interacties waarbij de ontvangende rol een Verwijsindex (Act Reference Registry) is.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 12 –
2.2.1. Datamodel van de verwijsindex De use-cases van paragraaf 2.1 beschrijven het gebruik van de verwijsindex. De verwijsindex ondersteunt twee abstractieniveaus wanneer het gaat om registraties. Aanmelding van gegevens kan ook op deze twee niveaus gerealiseerd worden: • atomair: de registratie betreft een uittreksel van één specifieke Act (bijv. de metagegevens van een verslagbrief, een recept of een zorgdossier) • categoraal: de registratie betreft een groep Acts van één specifieke gegevenssoort, zonder dat de details van de individuele Acts opgeslagen worden (bijv. de metagegevens van een set laboratoriumresultaten).
Act Registry 0..n
0..n Category
0..n Entry (Act)
Figuur 5: Registratiemodel Verwijsindex De verwijsindex dient een niveau aan detail te bevatten dat nodig is om de door zorgverleners gestelde vragen optimaal te kunnen routeren/beantwoorden. Het detailniveau van aanmelding wordt mede bepaald door de relevantie daarvan bij latere vraagstellingen aan de verwijsindex. Een ontslagbrief zal bijvoorbeeld atomair aangemeld worden. Een set van honderd laboratoriumuitslagen die zijn aangemaakt tijdens een klinische ziekenhuisopname kunnen categoraal (als set, in één bericht) worden aangemeld, en/of atomair. De vaste apotheek van patiënt Jansen zou eenmalig categoraal kunnen aanmelden dat er van de gegevenssoort “verstrekking”, vanaf een bepaalde datum, één of meer verstrekkingen zijn gedaan. Indien Jansen op zijn vakantieadres eenmalig een verstrekking krijgt van een apotheek, dan kan die apotheek deze ene verstrekking atomair aanmelden. Indien de verwijsindex op een later moment een vraag over medicatievertrekkingen aan patiënt Jansen moet routeren, dan is alle benodigde informatie in de verwijsindex aanwezig. FAQ: Wanneer moeten gegevens atomair worden aangemeld? Dit is afhankelijk van de gegevenssoort. NICTIZ zal per gegevenssoort aangeven of atomaire aanmelding vereist is. FAQ: De versie 3 modellen in mijn domein (bijvoorbeeld Laboratorium aanvragen/uitslagen) bevatten meerdere Acts, evenals de uitgewisselde berichten. Welke acts moeten er worden aangemeld in het geval van atomair aanmelden? Men dient die acts aan te melden die de kern van de gegevens vormen, bijvoorbeeld de encounterAct uit een opnamebericht, of de voorschrift-Act in een voorschriftbericht. Alle daaraan gerelateerde (secundaire) acts hoeven niet te worden aangemeld. Het gaat in feite alleen om de act van de focal-class (waar het entry-point naar wijst).
2.2.2. Berichtmodel verwijsindex Verwijsberichten kunnen gebruikt worden om gegevens aan te melden of overzichten van aangemelde gegevens op te sturen. De payload van de Verwijsindex (VWI, Act Reference Registry) berichten bevat een aantal attributen die de VWI gebruikt om vast te leggen welke applicatie gegevens van een specifieke gegevenssoort bevat. Het onderliggende
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 13 –
model van de payload is weergegeven in onderstaande Act Reference R-MIM (MFMT_RM002000).
Figuur 6: Act Reference R-MIM De ActReference klasse bevat een “samenvatting” van één Act (atomair aanmelden) of van meerdere Acts (categoraal aanmelden). Doorgaans worden ActReferences opgeslagen in de verwijsindex, en is de oorspronkelijke act(s) te vinden in een andere applicatie. De ActReference klasse vormt de payload van de Registry Act Wrapper (MFMI_RM700700, of MFMI_RM700710 als het om een response op een query gaat). Zie het document Implementatiegids HL7 v3 Infrastructurele Domeinen versie 2.3 voor een beschrijving van deze Trigger Event Control Act wrapper. De ActReference klasse bevat de volgende attributen: Modelbeschrijving in het geval van atomaire aanmelding: • classCode: Het classCode attribuut is gelijk aan de classCode van de Act waar deze ActReference een uittreksel/referentie van is. (verplicht) • moodCode: Het moodCode attribuut is gelijk aan de moodCode van de Act waar deze ActReference een uittreksel/referentie van is. (verplicht) • id: De identificatie van de Act waar deze ActReference een uittreksel/referentie van is. De ActReference krijgt dus geen andere id dan de oorspronkelijke Act. (verplicht attribuut) • ‘Overige attributen’ (code, statusCode enz.): De overige attributen zijn gelijk aan de corresponderende attributen van de Act waar deze ActReference een uittreksel/referentie van is. Modelbeschrijving bij categorale aanmelding: • classCode: Bevat de waarde CATEGORY. (verplicht) • moodCode: Bevat de waarde EVN. (verplicht) • id: De identificatie van deze Act. (verplicht attribuut) Categoriën dienen verplicht te worden geïdentificeerd opdat zij op een later moment kunnen worden gewijzigd, of via een associatie gekoppeld kunnen worden aan atomair aangemelde acts. • effectiveTime: Het begin en/of eindtijdstip van de door deze category gerepresenteerde Acts. Het te gebruiken datatype is IVL. Door alleen gebruik te maken van het begintijdstip van het interval kan worden aangegeven dat gegevens van een bepaalde gegevenssoort die na een bepaalde datum zijn aangemaakt in het bronsysteem aanwezig zijn. Dit is een optioneel attribuut, het kan worden leeggelaten indien een waarde niet bekend is.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 14 –
FAQ: Mijn applicatie biedt geen ondersteuning voor unieke identificatie van Acts. De unieke identificatie (in het attribuut ActReference.id) is echter verplicht. Hoe is dit op te lossen ? De identificatie kan, indien de applicatiedatabase geen unieke sleutel aan bepaalde gegevens koppelt, worden opgebouwd uit een combinatie van andere gegevens, bijvoorbeeld het patiëntnummer, de gegevenssoort, de geboortedatum, de aanvraagdatum, het receptnummer, etc. Het is een vereiste dat de resulterende identificatie de Act eenduidig identificeert als daar op een later moment naar gerefereerd wordt (bijvoorbeeld in een query). De eenduidige identificatie is eveneens noodzakelijk indien men de Act op een later moment uit de Verwijsindex wil verwijderen. Indien het niet mogelijk is op deze wijze een identificatie te construeren kan men een willekeurig nummer gebruiken, zij het dat zeker gesteld moet worden dat eenzelfde nummer nooit twee keer wordt gebruikt. Indien deze methode wordt gehanteerd wordt het opvragen van de gegevens door andere zorgpartijen mogelijk ernstig bemoeilijkt. De ActReference klasse bevat de volgende associaties: • recordTarget: de patiënt gerelateerd aan de ActReference Act. De patiënt wordt geïdentificeerd door middel van de R_Patient CMET (COMT_RM050000). Van de gegevens in deze CMET is in ieder geval de ID van de patiënt verplicht. Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een beschrijving van de R_Patient CMET. • Author: Bevat de verantwoordelijke persoon of organisatie voor de ActReference Act. Dit betreft de verantwoordelijke partij van de Act(s) waar de ActReference de samenvatting van is, en dus niet de partij die verantwoordelijk is voor het aanmelden van de ActReference bij de verwijsindex. De verantwoordelijke partij wordt geïdentificeerd door middel van de R_AssignedEntity CMET (COMT_RM090000). De CMET dient voor alle zorginhoudelijke acts een persoon te identificeren, voor administratieve acts kan eventueel worden volstaan met het identificeren van een organisatie(deel). Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een beschrijving van de R_AssignedEntity CMET. Het time attribuut van de associatie bevat het tijdstip (of: de periode) waarop de auteur de Act heeft aangemaakt. FAQ: De gegevenssoort, het type geregistreerde gegevens, is opgenomen in een attribuut in de Master File / Registry Control Act Wrapper. Zie het document HL7 v3 Infrastructurele Domeinen. De mogelijke waarden van de gegevenssoort zijn eveneens in dit document beschreven. De gegevenssoort is veelal (maar niet per definitie) afleidbaar uit de classCode en moodCode van de geregistreerde gegevens. Message Types: In de HMD geassocieerd met bovenstaande R-MIM zijn twee message types gedefinieerd. De “Required Particpations” variant bevat verplicht de associaties Author en RecordTarget. De Act Reference R-MIM (MFMT_RM002000) heeft de volgende afgeleide Message Types: Act Reference Optional Participations MFMT_MT002001 Act Reference Required Participations MFMT_MT002002
2.2.3. Berichtmodel verwijsindex query De in deze paragraaf beschreven Query wordt gebruikt om informatie over de in de VWI (of ARR) aanwezige gegevens op te vragen. Het gaat hier alleen om het opvragen van de metagegevens zoals ze in de VWI geregistreerd zijn. Het onderliggende model van de payload is weergegeven in onderstaande Act Registry Find Acts Query R-MIM (QUMT_RM020020).
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 15 –
De payload van het bijbehorende antwoordbericht (of: berichten) bestaat uit de Act Reference Shared Message (MFMT_RM002000, zie paragraaf 2.2.2). Antwoordberichten maken gebruik van de Master File Query Response Trigger Event Control Act wrapper (MFMI_RM700710). Zie het document Implementatiegids HL7 v3 Infrastructurele Domeinen versie 2.3 voor een beschrijving van deze Trigger Event Control Act wrapper.
Figuur 7: De Act Registry Find Acts Query De QueryByParameterPayload en gerelateerde klassen van de verwijsindex query bevatten de details van de query aan de Act Reference Registry. Zie het document Implementatiegids HL7 v3 Infrastructurele Domeinen voor een algemene beschrijving van deze klassen. De volgende ParameterItem klassen zijn geassocieerd met QueryByParameterPayload: • PatientId: Identificeert de patiënt aan wie de gevraagde Acts gerelateerd dienen te zijn (het BSN; verplichte parameter). Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een beschrijving van het II datatype en voor XML voorbeelden. • RegistrationprocessActCode: Bevat de gegevenssoort van de gevraagde Acts. De waarde is afkomstig uit de ActRegistryCode: x_DataDomainNL vocabulaire; zie het document Implementatiegids HL7 v3 Infrastructurele Domeinen versie 2.3 voor een bespreking van gegevenssoorten. • EffectiveTime: Bevat een tijdsinterval. Het effectiveTime attribuut van de gevraagde Acts dient te liggen in het tijdsinterval. Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een beschrijving van het IVL (tijdsinterval) datatype en voor XML voorbeelden. • AuthorId: Identificeert 1 of meer auteurs aan de hand van hun Unieke Zorgverlener Identificatie (UZI). De auteur van de op te leveren Acts dient gelijk te zijn aan één van de vermelde auteurs.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 16 –
• •
•
StatusCode: Bevat één of meer Act statuscodes. De statuscode van de op te levern Acts dient gelijk te zijn aan één van de vermelde statuscodes. AuthorRoleCode: Identificeert de roleCode van de auteur van de gevraagde Act. Deze parameter kan worden toegepast indien de vraag gerelateerd is een bepaalde categorie auteurs (bijv. Apothekers) in plaats van een specifieke auteur (Apotheker X). Zie het document Implementatiegids HL7 v3 Infrastructurele Domeinen versie 2.3 voor een bespreking van de waarden in de roleCodeNL vocabulaire. ActId: De unieke ID van de Act zoals vastgelegd in de VWI. Deze identificatie zal meestal niet bekend zijn.
FAQ: Alle in deze paragraaf beschreven artefacts zijn tevens van toepassing bij het abonneren op gegevens. HL7 maakt geen onderscheid tussen een query (geldigheidsduur = nu) en een abonnement (geldigheidsduur = vanaf nu). Voor een nadere uitleg zie de beschrijving van de Query By Parameter Trigger Event Control Act wrapper.
Message Types: In de HMD geassocieerd met bovenstaande R-MIM is één message type gedefinieerd. De Act Registry Find Acts Query R-MIM (QUMT_RM020020) heeft het volgende afgeleide Message Type: Act Reference Registry Find Acts QUMT_MT020020
2.2.4. Inhoud verwijsindex Het document Specificatie van de basisinfrastructuur in de zorg versie 2.2 beschrijft de gegevens die de ZIM moet opslaan om haar rol optimaal te kunnen vervullen. Deze paragraaf beschrijft voor elk van de genoemde gegevens waar (en hoe) deze in de Verwijsindex (Act Reference Registry) berichten voorkomen. De volgende gegevenscategorieën zijn minimaal op te slaan door de Verwijsindex: • Identiteit Patiënt: Het BSN van de patiënt zoals opgenomen in de R_Patient CMET van de Verwijsindex berichten. • Applicatie ID van aanmeldende applicatie: De identificatie van de zendende applicatie van Verwijsindex aanmeldberichten. Deze waarde is aanwezig in de Device klasse van de Transmission Wrapper. Zie het document Implementatiegids HL7 v3 Infrastructurele Domeinen versie 2.3 voor een beschrijving van de Transmission Wrapper. • Identiteit zorgaanbieder: De UZI van de persoon die verantwoordelijk is voor de inhoud van de patiëntgegevens die bij de Verwijsindex aangemeld worden. Deze identificatie is opgenomen in het AssignedEntity.ID attribuut in de R_AssignedEntity CMET in de payload van de Verwijsindex berichten. Het gaat dus nadrukkelijk om de gegevensauteur en niet om de gegevensaanmelder. De gegevensaanmelder is overigens in de meeste situaties gelijk aan de gegevensauteur. • Functie zorgaanbieder: De functie (of: rol, beroepstitel) van de persoon die verantwoordelijk is voor de patiëntgegevens die bij de Verwijsindex aangemeld worden. De rol is opgenomen in het AssinedEntity.code attribuut in de R_AssignedEntity CMET in de payload van de Verwijsindex berichten. Het gaat dus nadrukkelijk om de gegevensauteur en niet om de gegevensaanmelder. De gegevensaanmelder is overigens in de meeste situaties gelijk aan de gegevensauteur. • Gegevenssoort: De identificatie van het type gegeven dat aangemeld word/is bij de verwijsindex. De gegevenssoort is opgenomen in RegistrationProcess.code attribuut in de Master File/ Registry ControlAct wrapper. Zie het document Implementatiegids HL7 v3 Infrastructurele Domeinen versie 2.3 voor een
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 17 –
•
beschrijving van deze wrapper en de van toepassing zijnde Gegevenssoort vocabulaire. Actualiteit: Het tijdstip (of: het tijdsinterval) waarop de aanmelding bij de Verwijsindex betrekking heeft. o ActReference.effectiveTime: De waarde van dit attribuut dient standaard als actualiteit te worden gezien. o Author.time: Indien Actreference.effectiveTime geen waarde bevat (wat bijvoorbeeld bij recepten het geval is), dan dient de waarde van Author.time als actualiteit te worden gezien.
Merk op dat de verwijsindex tevens alle als mandatory (verplichte) aangegeven attributen in de MFMT_RM002000 en MFMI_RM700710 berichtmodellen dient te bevatten om queries van het type “bieden van een overzicht/index” te kunnen beantwoorden.
2.3. Voorbeeldberichten 2.3.1. Categoraal registreren van een groep Acts Het voorbeeld is gebaseerd op het volgende scenario: patiënt Harry Venema is chronisch ziek en is pas geleden verhuisd naar een nieuwe regio. Harry ondergaat met enige regelmaat beeldvormende onderzoeken (CT, MRI) in het academische ziekenhuis in zijn nieuwe regio. De afdeling beeldvormend onderzoek (Radiologie) van het ziekenhuis registreert bij de verwijsindex dat gegevens van de gegevenssoort 188011 (de code voor diagnostische beelden) voor deze patiënt in het Radiologiesysteem aanwezig zijn, en het beelden betreft die gemaakt zijn op of na 28 April 2004. Interactiediagram:
Het onderstaande voorbeeldbericht is volgens de interactie MFMT_IN002101. <effectiveTime value="20040428161000"/> <subject> <statusCode code="active"/> <effectiveTime> <subject2 typeCode="SUBJ">
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 18 –
<statusCode code="active"/> <effectiveTime> <patient> <statusCode code=""/> <patientPerson> HarryVenema <providerOrganization> Op een later tijdstip kan het ziekenhuis deze verwijsindex registratie updaten om, desgewenst, het eindtijdstip van de aangemelde beeldvormende onderzoeken bij de verwijsindex bekend te maken. Dit mede om te voorkomen dat het ziekenhuis vragen via de verwijsindex krijgt die slaan op een tijdsperiode na het laatst gedane onderzoek. De mogelijk onderliggende reden van het “afsluiten” van een set acts (een category) is bijvoorbeeld:
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 19 –
• • •
de patiënt verhuist de klinische opname is afgelopen het zorgtraject is afgesloten
2.3.2. Atomair registreren van een Act Het voorbeeld is gebaseerd op het volgende scenario: een technicus heeft zojuist een CTscan uitgevoerd voor patiënt Harry Venema. De gegevens van dit onderzoek worden in dit scenario • met behulp van een POXX_IN900001 bericht (zoals gedefinieerd in het Radiology HL7 domein) aan het Ziekenhuis Informatie Systeem gemeld. • met behulp van een MFMT_IN002101 bericht bij de verwijsindex aangemeld. Het eerste bericht, wat dus niets te maken heeft met verwijsindexen, wordt ter informatie (gedeeltelijk) hieronder getoond. Het bericht is niet geschikt om gegevens bij een verwijsindex aan te melden, de inhoud heeft wel een sterke overeenkomst met het verwijsindex aanmeldbericht zoals dit (als tweede voorbeeldbericht) hieronder wordt getoond. <effectiveTime value="20040417"/> <subject> <statusCode code="active"/> <subject> <Patient> HarryVenema
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 20 –
De verwijsindex moet tevens op de hoogte worden gesteld van het feit dat een CTonderzoek uitgevoerd is; maar heeft daarvoor (mede op grond van privacy en autorisatie) niet alle details nodig, maar slechts die subset aan gegevens die het de verwijsindex mogelijk maken latere vragen zo optimaal mogelijk te kunnen routeren. De payload van het registratiebericht bij de verwijsindex wordt hieronder getoond. De Act Reference – Add vormt de payload binnen een Registry Act Wrapper (MFMI_RM700700) en de Transmission Wrapper. De gegevenssoort is opgenomen in de Registry Act Wrapper (in het RegistrationProcess.code attribuut, 188011 = Beeldvormend onderzoek) en komt in de payload niet voor. Het onderstaande voorbeeldbericht is volgens de interactie MFMT_IN002101. <effectiveTime value="20040417"/> <subject> <statusCode code="active"/> <effectiveTime> <subject2 typeCode="SUBJ"> <statusCode code="active"/> <patient> <statusCode code=""/> <patientPerson> HarryVenema <providerOrganization>
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 21 –
FAQ: Kan het verwijsindexbericht worden afgeleid uit het domeinbericht (bijvoorbeeld lab.uitslag, verstrekking, ontslagbrief) ? Ja, op de gegevenssoort na staan alle benodigde gegevens in het domeinbericht. De gegevenssoort is veelal afleidbaar uit de classCode en moodCode van de bij de verwijsindex te registreren Act. Indien gewenst kan het verwijsindex bericht met behulp van een XSLT door de zender op basis van het domeinbericht worden aangemaakt.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 22 –
3. ZorgaanbiederGids (ZG) 3.1. Inleiding Het document Specificatie van de basisinfrastructuur in de zorg versie 2.2 beschrijft de functionaliteit van de ZorgaanbiederGids. De volgende gebruiksscenario’s worden in dit hoofdstuk uitgewerkt: • (gebruiksscenario 0.4.1) opzoeken zorgaanbieder in de zorgaanbiedergids, • (gebruiksscenario 0.4.2) opvragen bereikbaarheidsgegevens uit de zorgaanbiedergids, • (gebruiksscenario 0.4.4) controleren zorgaanbieder in het zorgaanbiederregister. De ZorgaanbiederGids maakt gebruik van zowel eigen gegevens als gegevens afkomstig uit het ZorgaanbiederRegister (het CIBG UZI-register) bij het beantwoorden van bovenstaande berichten. Bij het opvragen van gegevens uit de zorgaanbiederGids maakt HL7 een onderscheid tussen personen en organisaties. • •
Indien de gegevens worden opgevraagd van een individuele zorgverlener (een rol van een persoon) dan noemt HL7 dit gedeelte van de zorgaanbiederGids een Provider Registry. Zie paragraaf 3.2 voor een beschrijving van de berichten. Indien het gaat om de gegevens van een organisatie of organisatiedeel dan noemt HL7 dit gedeelte van de zorgaanbiederGids een Organization Registry. Zie paragraaf 3.3 voor een beschrijving van de berichten.
FAQ: Hoe zit het met zorgverleners die als zelfstandig ondernemer fungeren (bijv. huisartsen) en die niet bij de Kamer van Koophandel zijn ingeschreven ? Deze zorgverleners zijn in juridische zin niet gerelateerd aan een organisatie. Gemakshalve wordt er van uit gegaan dat ook deze zorgverleners bij een organisatie horen: bijvoorbeeld “De huisartsenpraktijk P.E.B. Jansen” is gerelateerd aan de zorgverlener P.E.B. Jansen. Deze pseudo-organisaties worden tevens opgenomen in antwoorden op vragen aan het zorgaanbieder(Organisatie) register. Zorgverleners die onder de wet BIG vallen dienen via een UZI te worden geïdentificeerd, zorgorganisaties via het UZI-Register-Abonneenummer (URA) of de Vektis AGB-Z identificatie indien zij geen URA bezitten.
3.2. Zorgverlener(persoon)register berichtbeschrijving Deze paragraaf bevat een beschrijving van de berichten die worden uitgewisseld in interacties waarbij de ontvangende rol een Provider Registry (gids/register op het gebied van individuele zorgverleners) is. Bij het opvragen van zorgverlenergegevens zijn twee situaties te onderscheiden: • Een unieke identificatie (bijvoorbeeld UZI) van de zorgverlener is bekend, maar overige gegevens ontbreken (naam, adres, telefoonnummer, etc.) • De identificatie van de zorgverlener is niet bekend, het enige wat bekend is zijn niet-unieke attributen zoals naam, plaats, postcode of geboortedatum. De eerste situatie wordt vooralsnog niet ondersteund. In de tweede situatie moet gebruik worden gemaakt van de berichten Find Provider Candidates Query Zorgaanbiedergegevens (PRPM_IN306050NL) en Find Provider Candidates Response (PRPM_IN306051NL).
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 23 –
Interactiediagram:
Beide interacties bezitten een Nederland-specifieke interactiecode. De HL7 standaard bevat op het moment slechts een eerste ontwerpversie voor deze interacties (zie het Provider Topic gedeelte in het Personnel Management gedeelte van de standaard). Om deze reden wordt gebruik gemaakt van Nederlands-pecifieke interacties. De structuur en het gebruik van deze twee Nederlandse interacties is precies gelijk aan de persoonsregister gerelateerde interacties Find Candidates Query (QUPA_IN101103) en Find Candidates Response (QUPA_IN101104) zoals beschreven in paragraaf 4.2. Interactie: Find Provider Candidates Query (PRPM_IN306050NL) Trigger Event Provider Event Find Candidates Query Transmission Send Message Payload Wrapper Control Act Wrapper Query Control Act Request : Parameter List Message Type Person Event Query By Demographics Interactie: Find Provider Candidates Response (PRPM_IN306051NL) Trigger Event Provider Event Find Candidates Query Response Transmission Application Level Wrapper Response/Acknowledgement Control Act Wrapper Master File / Registry Query Response,Role Subject Message Type Person Event Find Candidates Query Response
3.3. Organisatieregister berichtbeschrijving Deze paragraaf bevat een beschrijving van de berichten die worden uitgewisseld in interacties waarbij de ontvangende rol een Organization Registry (gids/register op het gebied van zorgverlenerorganisaties) is.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 24 –
Bij het opvragen van organisatiegegevens zijn twee situaties te onderscheiden: • De identificatie van de organisatie is bekend, maar overige gegevens ontbreken (naam, adres, telefoonnummer, etc.) • De identificatie van de organisatie is niet bekend, het enige wat bekend is zijn niet-unieke attributen zoals naam, plaats of postcode. In de eerste situatie moet gebruik worden gemaakt van de in het Personnel Management domein beschreven berichten Organization Detail Query (PRPM_IN406010) en Organization Detail Response (PRPM_IN406110). In de tweede situatie moet gebruik worden gemaakt van de in het Personnel Management domein beschreven berichten Organization Candidate Query (PRPM_IN405010) en Organization Candidate Response (PRPM_IN405110). De structuur van deze berichten wordt beschreven in de paragrafen 3.3.1 en 3.3.2. Noot: Het gebruik van de eerstgenoemde twee interacties (PRPM_IN406010, PRPM_IN406110) wordt op dit moment in Nederland ontraden: de structuur van het antwoordbericht Organization Candidate Response is op dit moment bijna gelijk aan de structuur van het Organization Detail Response bericht. Interactiediagram:
Interactie: Organization Trigger Event Transmission Wrapper Control Act Wrapper Message Type Interactie: Organization Trigger Event Transmission Wrapper Control Act Wrapper Message Type
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 25 –
3.3.1. Berichtmodel organisatieregister query De in deze paragraaf beschreven Query wordt gebruikt om de unieke identificatie (URA, het UZI-Register-Abonneenummer) van een organisatie zoals aanwezig in het organisatieregister op te vragen, op basis van organisatienaam en adres. Het onderliggende model van de payload is weergegeven in onderstaande Organization Event Candidate Query R-MIM (PRPM_RM405000). FAQ: Welk alternatief dient men te gebruiken zolang het URA-identificatiemechanisme nog niet breed ingevoerd is ? Indien de URA van een organisatie niet bekend is (of nog niet uitgegeven is) dient als alternatief het Vektis AGB-Z nummer gebruikt te worden als identificatie van een organisatie. De payload van het bijbehorende antwoordbericht (of: berichten) bestaat uit de Organization Candidate Query Response Message (PRPM_RM405100, zie paragraaf 3.3.2).
Figuur 8: Organization Registry Query De QueryByParameterPayload en gerelateerde klassen bevatten de details van de query aan de Act Reference Registry. Zie het document Implementatiegids HL7 v3 Infrastructurele Domeinen versie 2.3 voor een algemene beschrijving van deze klassen. De volgende ParameterItem klassen zijn geassocieerd met QueryByParameterPayload: • Name: De (gedeeltelijke) naam van de gezochte organisatie. Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een beschrijving van het PN datatype en voor XML voorbeelden. • Address: Het (gedeeltelijke) adres van de gezochte organisatie. Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een beschrijving van het AD datatype en voor XML voorbeelden. Zie paragraaf 3.4.1 voor XML voorbeelden van de diverse query parameters.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 26 –
3.3.2. Berichtmodel organisatieregister antwoord Een antwoordbericht kan gegevens over meerdere organisaties bevatten, elk van deze deelantwoorden heeft onderstaande structuur. Het onderliggende model van de payload is weergegeven in onderstaande Organization Event Candidate Query Response R-MIM (PRPM_RM405100). Deze interactie maakt gebruik van de Master File Query Response Trigger Event Control Act wrapper (MFMI_RM700710NL). Zie het document Implementatiegids HL7 v3 Infrastructurele Domeinen versie 2.3 voor een beschrijving van deze Trigger Event Control Act wrapper.
Figuur 9: Organization Registry Response De AssignedEntity klasse bevat de volgende attributen: • id: de primaire identificaties van de rol van de organisatie. De organisatie die de primaire identificatie heeft uitgegeven, is geïdentificeerd in de geassocieerde E_Organization CMET. (verplicht attribuut) Meestal zal dit attribuut de URA van de organisatie bevatten, of indien dit niet bekend is de Vektis AGB-Z code. • code: geeft een typering van de soort rol die de organisatie vervult. De waarde is afkomstig uit de voor Nederland specifieke vocabulaire tabel RoleCodeNL. Dit attribuut is in Nederland verplicht voor organisaties. • addr: de adressen van de organisatie. • telecom: de bereikbaarheidsgegevens van de organisatie, zoals telefoonnummers en e-mail adressen. Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een nadere beschrijving van het TEL datatype. Naast telefoon- en
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 27 –
faxnummers, kan dit attribuut tevens de Applicatie Identificatie (een OID) bevatten van de applicatie waar de organisatie bereikbaar is.
De optioneel geassocieerde klasse PrincipalOrganization bevat het volgende attribuut: • name: de naam van de organisatie. Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een nadere beschrijving van het ON datatype. De optioneel geassocieerde klasse representedOrganization bestaat uit de volgende CMET: • E_Organization: bevat de identificatie en details van de Organisatie waar de AssignedEntity klasse een deel van uitmaakt. Indien de AssignedEntity geen zelfstandige entiteit is (bijvoorbeeld een ziekenhuisafdeling, of een ziekenhuislokatie) dan dient via deze CMET de verantwoordelijke organisatie te worden aangegeven (bijvoorbeeld het ziekenhuis).
3.4. Voorbeeldberichten 3.4.1. Query parameter voorbeelden In deze paragraaf is een aantal voorbeelden opgenomen van typische queryparameters zoals deze aan een organisatieregister worden gesteld. Een query bevat één of meer van deze parameters. Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een nadere beschrijving van de EN en AD adrestypen die ten grondslag liggen aan deze parameters. AZU <semanticsText>Organization.name Organisaties met de naam AZU. AZ* <semanticsText>Organization.name Organisaties met een naam die begint met “AZ”. <postalCode>1200 BR <semanticsText>Organization.addr Organisaties met een adres in het gebied aangeduid met postcode 1200 BR.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 28 –
22 <postalCode>1200 BR <semanticsText>Organization.addr Organisaties met een adres met huisnummer 22 in het gebied aangeduid met postcode 1200 BR.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 29 –
3.4.2. Query/antwoord voorbeeld Het volgende voorbeeld bevat een vraag naar organisatie-informatie op basis van twee gegevens: naam en postcode. De auteur van de vraag is geïdentificeerd door middel van zijn UZI-nummer. De query is uniek geïdentificeerd via de queryId 5551264. Merk op dat de Transmission Wrapper niet getoond wordt in onderstaand voorbeeld. Interactiediagram:
Het onderstaande voorbeeldbericht is volgens de interactie PRPM_IN405010. <effectiveTime value="20040719135956"/> <participant> <statusCode code="new"/> <postalCode>1200 BR <semanticsText>Organization.addr A* <semanticsText>Organization.name
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 30 –
De bovenstaande query levert bijvoorbeeld gegevens van twee organisaties op. Deze gegevens zijn opgenomen in het onderstaande voorbeeld. Merk op dat de Transmission Wrapper niet getoond wordt in onderstaand voorbeeld. Het onderstaande voorbeeldbericht is volgens de interactie PRPM_IN405110. <effectiveTime value="20040719140008"/> <participant> <subject> <statusCode code="active" codeSystem="2.16.840.1.113883.5.14"/> <effectiveTime nullFlavor="UNK"/> <subject1> <streetName>Vondellaan 22 <postalCode>1200 BR NijkerkAmphora Apotheek <subject> <statusCode code="active" codeSystem="2.16.840.1.113883.5.14"/> <effectiveTime nullFlavor="UNK"/> <subject1> <streetName>Vondellaan 31
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 32 –
4. Patientenregister (PR) 4.1. Inleiding Het document Specificatie van de basisinfrastructuur in de zorg versie 2.2 beschrijft de functionaliteit van het Patiëntenregister. Het volgende gebruiksscenario wordt in dit hoofdstuk uitgewerkt: • (gebruiksscenario 0.3.1) selecteren nieuwe patiënt. Bij het opvragen van gegevens van een persoon kan gebruik gemaakt worden van de in het HL7 domein Patient Administration beschreven berichten aangaande Person Registries. De in dit hoofdstuk uitgewerkte berichten vormen een raamwerk waarbinnen implementaties plaats moeten vinden. Zo zijn de berichten rondom het opvragen van het Burger Service Nummer (BSN) door het CIBG beschreven in het document SBV-Z Conformance Profiel BSN Opvraag/Verificatie versie 1.1. Dit document beschrijft de CIBG specifieke invulling van de in dit document beschreven berichten.
4.1.1. Het opvragen van persoonsgegevens Bij het opvragen van persoonsgegevens zijn twee situaties te onderscheiden: • Een unieke identificatie (bijvoorbeeld BSN) van de persoon is bekend, maar overige gegevens ontbreken (naam, adres, telefoonnummer, etc.) • De identificatie van de persoon is niet bekend, het enige wat bekend is zijn nietunieke attributen zoals naam, plaats, postcode of geboortedatum. In de eerste situatie moet gebruik worden gemaakt van de in het Patient Adminsitration beschreven domein beschreven berichten Get Person Demographics Query (QUPA_IN101101) en Get Person Demographics Response (QUPA_IN101102). In de tweede situatie moet gebruik worden gemaakt van de in het Patient Adminsitration beschreven domein beschreven berichten Find Candidates Query (QUPA_IN101103) en Find Candidates Response (QUPA_IN101104). Interactiediagram:
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 33 –
Interactie: Find Candidates Query (QUPA_IN101103 ) Trigger Event Person Event Find Candidates Query Transmission Send Message Payload Wrapper Control Act Wrapper Query Control Act Request : Parameter List Message Type Person Event Query By Demographics Interactie: Find Candidates Response (QUPA _IN101104 ) Trigger Event Person Event Find Candidates Query Response Transmission Application Level Wrapper Response/Acknowledgement Control Act Wrapper Master File / Registry Query Response,Role Subject Message Type Person Event Find Candidates Query Response
4.2. Persoonsregister berichtbeschrijving Het volgende hoofdstuk bevat een beschrijving van de berichten die worden uitgewisseld in interacties waarbij de ontvangende rol een Person Registry is. FAQ: De HL7 berichten staan (als technische specificaties) alle vraagtypen toe, inclusief het opvragen van alle gegevens van alle bekende personen. Het systeem dat de vragen beantwoordt legt in de praktijk beperkingen op ten aanzien van mogelijke vragen. Sommige parameters of parametercombinaties zijn dan wellicht verplicht. Dit is bijvoorbeeld het geval voor BSN-vraagberichten aan het CIBG SBV-Z Register. Indien er geen unieke patiënt gevonden wordt, zal het CIBG geen BSN als antwoord sturen. Ook zal het CIBG geen attributen verstrekken die al niet in de vraag waren ingevuld. Details staan beschreven in het CIBG document SBV-Z Conformance Profiel BSN Opvraag/Verificatie versie 1.1.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 34 –
4.2.1. Berichtmodel persoonsregister query De in deze paragraaf beschreven Query wordt gebruikt om informatie over personen zoals aanwezig in een personenregister op te vragen. Het onderliggende model van de payload is weergegeven in onderstaande Person Event Query by Demographics R-MIM (QUPA_RM101103).
Figuur 10: Person Registry Query De QueryByParameterPayload en gerelateerde klassen bevatten de details van de query aan de Act Reference Registry. Zie het document Implementatiegids HL7 v3 Infrastructurele Domeinen versie 2.3 voor een algemene beschrijving van deze klassen. Deze R-MIM wordt toegepast in meerdere Person Registry queries, zie paragraaf 4.1.1. De volgende ParameterItem klassen zijn geassocieerd met QueryByParameterPayload: • Person.name: bevat (gedeelten van) de persoonsnaam van de gezochte persoon. Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een beschrijving van het PN datatype. • Person.administrativeGender: bevat het geslacht van de gezochte persoon. De waarden zijn afkomstig uit de vocabulaire AdministrativeGender, en bevat normaliter of ‘F’ (vrouwelijk) of ‘M’ (mannelijk). • Person.birthTime: bevat een tijdsinterval waarbinnen de gezochte persoon geboren is. Beide tijdstippen kunnen of leeg zijn, of jaar, jaar-maand, jaarmaand-dag, of jaar-maand-dag-uur(-minuut) bevatten. Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een beschrijving van het IVL (tijdsinterval) datatype en voor XML voorbeelden. • Person.birthPlace: bevat (gedeelten van) het geboorteadres, zoals geboorteplaats of geboorteland. (NB: Deze parameter wordt niet in bovenstaande figuur getoond). Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een beschrijving van het AD datatype.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 35 –
• • •
• •
Person.addr: bevat (gedeelten van) het adres van de gezochte persoon. Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een beschrijving van het AD datatype. Person.telecom: bevat (gedeelten van) bereikbaarheidsgegevens van de patiënt, zoals telefoonnummer en e-mail adres. Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een beschrijving van het TEL datatype. Person.id: bevat een identificatie (inclusief de OID van de instantie die de identificatie heeft uitgegeven) van de gezochte persoon. Voorbeeld: Indien de gezochte persoon de identificatie 1234 heeft; en deze volgens het identificatiemechanisme met OID 2.16.435.655 is uitgegeven, dan wordt dit als volgt in het bericht weergegeven: Deze parameter kan tevens alleen de identificatie bevatten van een identificatiemechanisme. In dat geval dient door middel van het nullFlavor attribuut expliciet te worden aangegeven dat de persoonsidentificatie onbekend is. Het beantwoordende systeem zal alleen gegevens terugmelden van personen die een identificatie volgens het gevraagde identificatiemechanisme bezitten. MothersMaidenName: in Nederland niet gebruiken. Person.deceasedTime: bevat een tijdsinterval waarbinnen de gezochte persoon overleden is. Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een beschrijving van het IVL datatype.
Zie paragraaf 4.3 voor XML voorbeelden van de diverse parameterItem klassen.
4.2.2. Berichtmodel persoonsregister antwoord De structuur van de antwoorden op de verschillende queries aan de Person Registry is op hoofdlijnen gelijk. Deze paragraaf bevat de beschrijving van één van de mogelijke antwoorden: de Find Candidates Response R-MIM (QUPA_RM101104), het model wat ten grondslag ligt aan de interactie Find Candidates Response (QUPA_IN101104). Een antwoordbericht kan gegevens over meerdere personen bevatten, elk van deze zoekresultaten heeft onderstaande structuur. Deze interactie maakt gebruik van de Master File Query Response Trigger Event Control Act wrapper (MFMI_RM700710). Zie het document Implementatiegids HL7 v3 Infrastructurele Domeinen versie 2.3 voor een beschrijving van deze Trigger Event Control Act wrapper. FAQ: Indien er geen personen gevonden konden worden die passen bij de opgegeven parameters, bevat het antwoord bericht uitsluitend de Transmission wrapper en de TECA wrapper. Het QueryAck.responseCode attribuut in de TECA wrapper bevat in dat geval de waarde NF (Nothing Found, no errors). Het vinden van nul antwoorden is op zichzelf geen fout. FAQ: Indien op grond van beperkingen ten aanzien van ondersteunde vraagtypen (bijvoorbeeld om privacyredenen) een vraag niet kan worden beantwoord (de vraag bevat niet de vereiste combinatie van parameters), dan bevat het antwoordbericht uitsluitend de Transmission wrapper en de TECA wrapper. Het QueryAck.responseCode attribuut in de TECA wrapper bevat in dat geval de waarde QE (Query Parameter Error).
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 36 –
Figuur 11: Find Candidates Response (gedeeltelijk) De bovenstaande figuur bevat (een gedeelte van) de gegevens van een gevonden persoon. De getoonde modelleringelementen komen meerdere keren in het antwoordbericht voor indien er meerdere personen gevonden zijn. De kern wordt gevormd door de IdentifiedPerson en Person klassen. De klasse Person geeft de persoon weer, als onveranderbaar biologisch object in de werkelijkheid. Hiertoe behoren bijvoorbeeld attributen als geboortedatum en geboorteplaats. De klasse IdentifiedPerson geeft de rol van die persoon in zijn maatschappelijke context weer. Hiertoe behoren bijvoorbeeld attributen als adres en telefoonnummer. De IdentifiedPerson klasse bevat de volgende attributen: • id: de primaire identificatie van de persoon zoals deze binnen de Person Registry bekend is. Indien in een query gevraagd werd naar de identificatie van de persoon bij een bepaalde organisatie dan bevat dit attribuut de identificatie van de persoon zoals uitgegeven door die organisatie. Indien geen specifieke organisatie werd opgegeven dan bevat dit attribuut de BSN- of UZI- identificatie, voor zover deze bekend zijn.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 37 –
• •
• •
De organisatie die de primaire identificatie heeft uitgegeven, is geïdentificeerd in de (verplicht) geassocieerde E_Organization CMET. (verplicht attribuut) Identificaties uitgegeven door andere organisaties (secundaire identificaties) worden verstuurd in de attributen OtherIds.id en Citizen.id. addr: de adressen van de persoon. telecom: de bereikbaarheidsgegevens van de persoon, zoals telefoonnummers en e-mail adressen. Zie de Implementatiehandleiding HL7v3 Datatypes en CMETs versie 2.3 voor een nadere beschrijving van het TEL datatype. Naast telefoon- en faxnummers, kan dit attribuut voor zorgverleners tevens de Applicatie Identificatie (een OID) bevatten van de applicatie waar de zorgverlener bereikbaar is. statusCode: bevat de status van de gegevens. De waarden zijn afkomstig uit de RoleStatus vocabulaire. Het attribuut zal normaliter de waarde ‘active’ (geldig) bevatten, andere waarden zijn o.a. ‘suspended’, ‘nullified’ en ‘terminated’. effectiveTime: bevat het tijdsinterval waarbinnen de gegevens in deze klasse geldig zijn. Het begintijdstip van het interval komt veelal overeen met het tijdstip waarop de gegevens in de Person Registry de status ‘active’ hebben gekregen. Het eindtijdstip van het tijdsinterval komt overeen met het tijdstip waarop de gegevens de status ‘terminated’ hebben gekregen.
De Person klasse bevat onder andere de volgende attributen: • id: de identificatie van de persoon. Dit is een universele identificatie van het (biologische) persoonsobject, bijvoorbeeld door middel van biometrische identificaties zoals een vingerafdrukcode, een genetische code, of een irisscanidentificatie code. In de meeste situaties zal dit attribuut geen waarde bevatten. • name: de namen van de persoon. • administrativeGenderCode: bevat het geslacht van de gezochte persoon. De waarden zijn afkomstig uit de vocabulaire AdministrativeGender, en bevat normaliter of ‘F’ (vrouwelijk), ‘M’ (mannelijk) of ‘UN’ (anders). • birthTime: geboortedatum (en tijd) van de persoon. De OtherIds klasse bevat de volgende attributen: • id: alle secundaire identificaties van de persoon. Dit zijn alle persoonsidentificaties met uitzondering van de primaire identificatie zoals vermeld in het attribuut IdentifiedPerson.id. Elke OtherIds klasse is geassocieerd met een E_Organization CMET die de organisatie die de identificatie heeft uitgegeven nader identificeert. De Citizen klasse bevat de volgende attributen: • id: de identificaties van de persoon in zijn rol als staatsburger. Dit zijn die identificaties die direct aan het staatsburgerschap gerelateerd zijn, bijvoorbeeld het paspoortnummer. (optioneel attribuut) Elke Citizen klasse is (verplicht) geassocieerd met een E_Organization CMET die de organisatie (het land), die de identificatie heeft uitgegeven identificeert. Het is mogelijk het land te identificeren zonder dat een specifieke persoonsidentificatie bekend is, het Citizen.id attribuut is immers optioneel. • effectiveTime: bevat het tijdsinterval waarbinnen de gegevens in deze klasse geldig zijn. Het begintijdstip van het interval (indien gevuld) komt overeen met het tijdstip waarop het staatsburgerschap verkregen is; het eindtijdstip van het tijdsinterval (indien gevuld) komt overeen met het tijdstip waarop het staatsburgerschap vervallen of ontnomen is. De BirthPlace klasse bevat het volgende attribuut:
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 38 –
•
addr: het geboorteadres. Dit attribuut bevat tevens geboorteplaats en geboorteland. De geassocieerde E_Place CMET kan worden gebruikt om de geboorteplek nader te identificeren.
De klasse ObservationEvent (optioneel) wordt door het beantwoordende systeem gebruikt om opmerkingen over het gevonden resultaat aan het opvragende systeem te melden. De klasse bevat de volgende attributen: • id: Niet gebruikt. • code: Bevat de code die het type zoek- of matchingalgoritme identificeert. Dit is tevens een identificatie van de methode die gebruikt is om de waarde van het value attribuut te bepalen. (verplicht). • value: Bevat veelal een opgave van het percentage waarschijnlijkheid dat de gevonden persoon dezelfde is als degene waarover de vraag gegevens bevatte (verplicht). Het ANY datatype wordt in antwoordberichten veelal vervangen door een INT (percentage) of CD (code) datatype. De attributen in de LanguageCommunication klasse kunnen worden gebruikt om aan te geven of, en hoe goed, de persoon verschillende talen spreekt en/of schrijft.
4.3. Voorbeeldberichten 4.3.1. Query parameter voorbeelden In deze paragraaf zijn een aantal voorbeelden opgenomen van typische queryparameters zoals deze aan een persoonsregister worden gesteld. Een query bevat één of meer van deze parameters. Jansen <semanticsText>Person.name Voorbeeld voor opgave van een parameter met Jansen als achternaam, Jans* <semanticsText>Person.name Voorbeeld van opgave van een parameter met een achternaam die begint met “Jans”. <semanticsText>Person.administrativeGender Voorbeeld van opgave van een parameter voor het geslacht F (Female).
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 39 –
<semanticsText>Person.birthTime Voorbeeld van opgave van een parameter voor geboortedatum op 3 Januari 1975.
<semanticsText>Person.birthTime Voorbeeld van opgave van een parameter voor geboortejaar 2003.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 40 –
<semanticsText>Person.birthTime Voorbeeld van opgave van parameters van geboorte op of na 1 januari 1950 00:00 uur. <postalCode>1200 BR <semanticsText>Person.addr Voorbeeld van opgave van een parameter van een postcode 1200 BR. 22 <postalCode>1200 BR <semanticsText>Person.addr Voorbeeld van opgave van parameters van een huisnummer 22 en een postcode 1200 BR. <semanticsText>Person.id Voorbeeld van een opgave van een persoon die het identificatienummer 2003784 bezit; uitgegeven volgens het identificatiemechanisme dat de OID 2.16.840.1.113883.3.17.8 heeft.
4.3.2. Query/antwoord voorbeeld Het volgende voorbeeld bevat een vraag naar persoonsinformatie op basis van 2 gegevens: geboortedatum en postcode. De auteur van de vraag is geïdentificeerd door middel van zijn UZI-nummer. De query is uniek geïdentificeerd via de queryId 5553264. Merk op dat de Transmission Wrapper niet getoond wordt in onderstaand voorbeeld. Interactiediagram:
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 41 –
Het onderstaande voorbeeldbericht is volgens de interactie QUPA_IN101103. <effectiveTime value="20040719135956"/> <participant> <statusCode code="new"/> <postalCode>1200 BR <semanticsText>Person.addr
<semanticsText>Person.birthTime
De bovenstaande query levert bijvoorbeeld gegevens van 1 persoon op. Deze gegevens zijn opgenomen in het onderstaande voorbeeld. Merk op dat de Transmission Wrapper niet getoond wordt in onderstaand voorbeeld. Het onderstaande voorbeeldbericht is volgens de interactie QUPA_IN101104.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 43 –
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 44 –
5. Schakelpunt (SCH) 5.1. Inleiding De schakelpunt- (SCH) functionaliteit vormt een essentieel onderdeel van de ZIM. Het document Specificatie van de basisinfrastructuur in de zorg versie 2.2 beschrijft de functionaliteit van het schakelpunt. Zie tevens Appendix D “Adresseren van dossiers en postbussen“ in het document Specificatie van de basisinfrastructuur in de zorg. De volgende gebruiksscenario’s worden in dit hoofdstuk uitgewerkt: • Gebruiksscenario 2.2.1: sturen patiëntbericht naar een andere zorgverlener, • Gebruiksscenario 2.2.2: ontvangen patiëntbericht van een andere zorgverlener.
5.1.1. Het routeren van berichten De transmission wrapper bevat gegevens die de zendende en ontvangende applicatie identificeren. Een ontvangende applicatie dient altijd te controleren of een ontvangen bericht voor die applicatie bestemd was. Noot: Zie het Abstract Transport Specification, onderdeel van de HL7 versie 3 standaard voor een algemene beschrijving van architecturen die gebruik maken van applicaties zoals Bridges en Gateways. Indien de in de transmission wrapper een identificatie van een andere applicatie bevat dan de applicatie die het bericht ontvangt, dan dient de ontvangende applicatie het bericht (indien mogelijk) te routeren aan of de uiteindelijke ontvanger, of een andere routerende applicatie.
A
Router
B
Optional accept rejects
Execute reciever responsibilities
Figuur 12: Het routeren van berichten en accept acknowledgement NAKs Een voorbeeldscenario: Applicatie B ontvangt een bericht waarin als ontvanger de applicatie C is opgenomen. Een mogelijke reden is dat direct transport van A naar C om technische of andere redenen niet mogelijk of toegestaan is. Applicatie B detecteert dat het bericht voor C bedoeld is, en verwerkt de inhoud van het bericht niet zelf. Er zijn nu twee mogelijkheden: • B kan het bericht naar C routeren. In dit geval stuurt applicatie B het oorspronkelijke bericht naar C. Indien C het bericht ontvangt, detecteert het dat het bericht voor zichzelf bedoeld is, en verwerkt het bericht.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 45 –
•
B kent het systeem C niet; of kan het bericht niet naar C routeren. In dit geval stuurt applicatie B een accept acknowledgement (ERROR) naar A om aan te geven dat het bericht niet gerouteerd kon worden. Het accept acknowledgement bericht bevat de volgende attribuutwaarden: Acknowledgement.typeCode = ‘CE’ (Error), AcknowledgementDetail.typeCode = ‘E’ (Error), AcknowledgementDetail.code = ‘RTUDEST’ (Routing error, unknown routing destination).
Noot: In bovenstaand scenario zijn bijvoorbeeld de volgende foutmeldingen mogelijk: (1) B kent systeem C niet (2) B kan de berichtsyntax niet verwerken en de bestemming van het bericht niet bepalen, en (3) C kan het bericht syntactisch niet verwerken, of het bericht is van een niet ondersteund interactietype. Een accept acknowledgement dient altijd teruggerouteerd te worden naar de oorspronkelijke afzender van het bericht.
5.1.2. Het samenvoegen/routeren van antwoordberichten Indien aan de ZIM een vraag wordt gesteld, dan wordt deze vraag aan nul of meer systemen gerouteerd ter beantwoording. Antwoordberichten afkomstig van de diverse systemen worden verzonden naar de ZIM. Zie Appendix C “Samenvoegen, doseren en sorteren” van het document Specificatie van de basisinfrastructuur in de zorg versie 2.2 voor een functionele beschrijving. Het verwerken en doorzenden van HL7 antwoordenberichten is afhankelijk van het feit of in de vraag is aangegeven of een batchgeoriënteerd antwoord gewenst is. 1. Indien het QueryByParameter.responseModalityCode attribuut in de vraag de waarde B bevat, dan dient de ZIM de berichten te groeperen en als batch naar het vragende systeem te verzenden. Zie paragraaf 5.1.2.2 voor een beschrijving. 2. Indien het QueryByParameter.responseModalityCode attribuut in de vraag de waarde R bevat, dan dient de ZIM de berichten Realtime (als losse berichten) naar het vragende systeem te verzenden. Zie paragraaf 5.1.2.1 voor een beschrijving. Het generieke query beantwoordingsmechanisme is beschreven in paragraaf 2.5 van de Implementatiegids HL7 v3 Infrastructurele Domeinen versie 2.3. Dit document bevat een nadere toelichting op het gebruik van queries in combinatie met de ZIM.
5.1.2.1. Realtime antwoordberichten Indien in het Query bericht het QueryByParameter.responseModalityCode attribuut de waarde R bevat, dan dient de ZIM per (vervolg)vraag één antwoordbericht op te leveren, volgens het mechanisme zoals beschreven in paragraaf 2.5 van de Implementatiegids HL7 v3 Infrastructurele Domeinen versie 2.3.
5.1.2.2. Batchgeorienteerde antwoordberichten Indien in het Query bericht het QueryByParameter.responseModalityCode attribuut de waarde B bevat, dan dient de ZIM de antwoordberichten te groeperen en als batch naar het vragende systeem te verzenden. De batch bestaat uit een Batchwrapper, waarin
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 46 –
meerdere antwoordberichten zijn gegroepeerd. De Batch wrapper wordt besproken in de Implementatiegids HL7 v3 Infrastructurele Domeinen versie 2.3.
Figuur 13: Interactiediagram batchgeoriënteerde queries De diverse interacties kunnen als volgt worden beschreven: 1. De Query Placer stuurt de initiële query. Het QueryByParameter.responseModalityCode attribuut bevat de waarde B. Het QueryByParemeter.initialQuantity attribuut is of leeg, of bevat een waarde die het maximaal gewenste aantal antwoorden in de antwoordbatches aangeeft. 2. De Query Filler beantwoordt de query door middel van een Batch waarin één of meer antwoordberichten zijn verpakt. Merk op dat één antwoordbericht meerdere zoekresultaten kan bevatten; het aantal gevonden zoekresultaten bij een Query is niet per definitie gelijk aan het aantal antwoordberichten. Het aantal zoekresultaten is echter maximaal gelijk aan de in de initiële vraag opgegeven waarde QueryByParameter.initialQuantity (indien dat attribuut een waarde had). 3. Als het laatste antwoordbericht in de batch een QueryAck.resultRemainingQuantity bevat dat gelijk is aan de waarde “0”, dan is de query volledig beantwoord. Er worden geen verdere berichten uitgewisseld. Indien QueryAck.queryResponseCode van het laatste antwoordbericht in de batch de waarde “OK” bevat, dan is de beantwoording succesvol verlopen. Bevat het de waarde “AE” (Application Error) dan is verdere beantwoording van deze vraag niet mogelijk: een of meer bronsystemen waren niet bereikbaar, of een of meer bronsystemen hebben de query van de ZIM niet tijdig beantwoord. Zie paragraaf 5.2.2 voor voorbeeldberichten. 4. Als het laatste antwoordbericht in de batch een resultRemainingQuantity bevat dat ongelijk is aan de waarde “0” (d.w.z. een numerieke waarde > 0, of een nullFlavor) kan een vervolgvraag gesteld worden, er zijn nog één of meer zoekresultaten beschikbaar. 5. De Query Placer stuurt een vervolgvraag. Vervolgvragen maken (ongeacht het originele query interactie type) gebruik van de interactie MCCI_IN000003. 6. Zie stap 2.
5.1.3. Het adresseren van berichten Het zendende en ontvangende systeem worden in de Transmission Wrapper geïdentificeerd. Bij het routeren van berichten (Paragraaf 5.1.1) zijn de gegevens in de Transmission Wrapper onveranderlijk. Bij het doorsturen van aan de ZIM gerichte queries
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 47 –
en bij het doorzenden van bijbehorende antwoorden dient de identificatie van het zendende en het ontvangende systeem in de transmission wrapper te worden aangepast. Het adresseren van systemen wordt in detail besproken in Appendix D van het document Specificatie van de Basisinfrastructuur versie 2.2.
5.2. Voorbeeldberichten 5.2.1. Voorbeeld Routeringsfoutmelding Het volgende voorbeeldbericht is een accept-level NAK voor een bericht dat niet door het schakelpunt gerouteerd kan worden. De foutcode is RTUDEST. Onderstaand bericht maakt gebruik van interactie MCCI_IN000002. <MCCI_IN000002 xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <processingCode code="P"/> <processingModeCode code="T"/> <device> <sender> <device>
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 48 –
5.2.2. Voorbeeld Batchgeoriënteerd antwoordberichten Het volgende voorbeeldbericht is het batchgeoriënteerde antwoord op een vraag naar beschikbare Röntgenbeelden. Een batchgeoriënteerd antwoord heeft het vaste interactietype MCCI_IN200101. De batch bevat drie berichten van interactietype QUXX_IN090011 . Het eerste bericht bevat de details van één beeldvormend onderzoek, het tweede bericht drie, en het derde bericht twee. De resultRemainingQuantity in het derde (en laatste) bericht in de batch is gelijk aan nul, wat aangeeft dat alle beschikbare resultaten opgeleverd zijn. <MCCI_IN200101 xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> Query Antwoorden
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 49 –
<device> <sender> <device> Het volgende voorbeeldbericht is het batchgeoriënteerde antwoord op een vraag naar beschikbare Röntgenbeelden. Een batchgeoriënteerd antwoord heeft het vaste interactietype MCCI_IN200101. De batch bevat drie berichten van interactietype QUXX_IN090011 . Het eerste bericht bevat de details van twee beeldvormende onderzoeken, het tweede bericht acht, en het derde bericht nul. Het derde bericht is een “dummy bericht” aangemaakt door de ZIM. De QueryResponseCode in het laatste bericht is gelijk aan “AE” wat aangeeft dat er bij het beantwoorden van de vraag een applicatiefout is opgetreden. In de ZIM context houdt dit in dat één of meer systemen niet bereikbaar zijn of niet tijdig op de vraag geantwoord hebben. De resultRemainingQuantity in het derde bericht in de batch is gelijk aan nul, wat aangeeft dat alle beschikbare resultaten opgeleverd zijn. <MCCI_IN200101 xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> Query Antwoorden
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
6. Autorisatie 6.1. Inleiding De autorisatieregels rondom de inzage van gegevens door zorgverleners zijn gebaseerd op het UZI-nummer van de zorgverlener, en de rol van deze zorgverlener binnen zijn organisatie. De rol van de zorgverlener kan worden afgeleid uit de UZI; en is eveneens opvraagbaar bij de ZorgaanbiederGids.
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 51 –
De autorisatieregels worden in principe afgedwongen door de diverse bronsystemen. De ZIM dwingt namens de diverse bronsystemen eveneens autorisatieregels af.
6.1.1. Noodgeval queries Bij noodgevallen wil een zorgverlener alle beschikbare informatie van een patiënt inzien; en daarbij eventuele beperkende autorisatieregels tijdelijk buiten werking stellen. Overigens stelt de wet dat sommige patiëntgegevens zo privacygevoelig zijn, dat deze alleen met expliciete toestemming vrijgegeven kunnen worden. Het blijft de verantwoordelijkheid van het beantwoordende systeem welke gegevens zij (ook in een Noodgeval) oplevert.
6.2. Noodgeval queries berichtbeschrijving Om aan te geven dat een Query plaatsvindt in de context van een noodgeval dient de Trigger Event Control Act Wrapper een verzoek te bevatten om de autorisatieregels tijdelijk buiten beschouwing te laten, en aan te geven dat de reden van dit verzoek een noodgeval is. Deze gegevens dienen gecodeerd te worden opgenomen in de DetectedIssueEvent en DetectedIssueManagement klassen (in de A_DetectedIssue CMET). Zie de Implementatiegids HL7v3 Infrastructurele Domeinen versie 2.3 voor een detailbeschrijving van deze klassen.
Figuur 14: De application acknowledgement R-MIM (gedeeltelijk)
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 52 –
Figuur 15: De A_DetectedIssue CMET Om aan te geven dat het bericht een noodgeval betreft dienen de volgende attributen de volgende waarden te bevatten: • DetectedIssueEvent.code: NAT (insufficent authorization for –fully responding to- query) • DetectedIssueManagement.moodCode: EVN • DetectedIssueManagement.code: EMAUTH (emergency authorization override) Het gebruik van de overige attributen in de DetectedIssueEvent en DetectedIssueManagement klasse is niet verplicht. Zij kunnen worden gebruikt om de omstandigheden van het noodgeval nader aan te geven. FAQ: Zoals beschreven in het document Specificatie van de basisinfrastructuur in de zorg heeft het beroep doen op een noodgevalsituatie de nodige procedurele gevolgen: alle gegevens worden in een speciale auditfile opgenomen, de patiënt/cliënt wordt ingelicht, en de toezichthouder doorloopt een controleproces om zeker te stellen dat het een noodgeval betrof.
6.3. Voorbeeldberichten 6.3.1. Voorbeeld noodgeval query Het onderstaande XML voorbeeld bevat een Trigger Event Control Act Wrapper voorzien van DetectedIssueEvent en DetectedIssueManagement klassen. <effectiveTime value="20040417"/> <justifiedDetectedIssue> <source moodCode="EVN">
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
- 53 –
Implementatiehandleiding HL7v3 Zorg Informatie Makelaar (versie 2.3, juni 2005)
