Implementatiehandleiding. HL7v3 Zorg Informatie Makelaar

Transcriptie

1 Implementatiehandleiding HL7v3 Zorg Informatie Makelaar Status : Definitief Versie : 2.3 Auteur : René Spronk, Ringholm GmbH Postbus 262, 2260 AG Leidschendam Datum : 6 juni 2005 Overgoo 11, 2266 JZ Leidschendam telefoon: (070) info@nictiz.nl /

2

3 Inhoudsopgave 1. Inleiding Doel van dit document Doelgroep Totstandkoming van dit document Opbouw van dit document Verschillen met vorige releases Verwijsindex (VWI) Inleiding Het aanmelden van patiëntgegevens Het opvragen van patiëntgegevens Het opvragen van metagegevens Het abonneren op metagegevens Verwijsindex berichtbeschrijving Datamodel van de verwijsindex Berichtmodel verwijsindex Berichtmodel verwijsindex query Inhoud verwijsindex Voorbeeldberichten Categoraal registreren van een groep Acts Atomair registreren van een Act ZorgaanbiederGids (ZG) Inleiding Zorgverlener(persoon)register berichtbeschrijving Organisatieregister berichtbeschrijving Berichtmodel organisatieregister query Berichtmodel organisatieregister antwoord Voorbeeldberichten Query parameter voorbeelden Query/antwoord voorbeeld Patientenregister (PR) Inleiding Het opvragen van persoonsgegevens Persoonsregister berichtbeschrijving Berichtmodel persoonsregister query Berichtmodel persoonsregister antwoord Voorbeeldberichten Query parameter voorbeelden Query/antwoord voorbeeld Schakelpunt (SCH) Inleiding Het routeren van berichten Het samenvoegen/routeren van antwoordberichten Het adresseren van berichten Voorbeeldberichten Voorbeeld Routeringsfoutmelding Voorbeeld Batchgeoriënteerd antwoordberichten Autorisatie Inleiding Noodgeval queries Noodgeval queries berichtbeschrijving Voorbeeldberichten Voorbeeld noodgeval query Implementatiehandleiding HL7v3-1

4 Implementatiehandleiding HL7v3-2

5 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-3

6 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 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 Totstandkoming van dit document Dit document is opgesteld door HL7-specialisten onder aanvoering van NICTIZ in het kader van het AORTA-programma van NICTIZ 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 Deze artefacts worden in dit document niet in detail besproken, hiervoor wordt verwezen naar de HL7 versie 3 standaard zelf (zie 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-4

7 referentie naar de uitleg van Datatypes en CMETs in de Implementatiehandleiding HL7v3 Medicatieberichten versie 2.3 en de Implementatiehandleiding HL7v3 Waarneming Huisartsen versie 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 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 voor details. Het toevoegen van Person.BirthPlace als parameter in de vraagberichten aan Persoonsregisters. Zie paragraaf 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_IN en PRPM_IN406110, maar PRPM_IN en PRPM_IN 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 en voor details. Het toevoegen van het gebruik van de klasse ObservationEvent aan antwoordberichten van Persoonsregisters. Zie paragraaf voor details. De batchvoorbeeldberichten in paragraaf 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-5

8 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 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-6

9 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 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 voor een toelichting. Implementatiehandleiding HL7v3-7

10 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 Reference, Request (MFMT_IN002101) Trigger Event Add Act Reference MFMT_TE Transmission Send Message Payload MCCI_MT Wrapper Control Act Wrapper Master File / Reg. Notif Control Act, Act MFMI_MT Subject Message Type Act Reference Required Participations MFMT_MT Interactie: Revise Act Reference, Request (MFMT_IN ) Trigger Event Revise Act Reference MFMT_TE Transmission Send Message Payload MCCI_MT Wrapper Control Act Wrapper Master File / Reg. Notif Control Act, Act MFMI_MT Subject Message Type Act Reference Optional Participations MFMT_MT Interactie: Nullify Act Reference, Request (MFMT_IN ) Trigger Event Nullify Act Reference MFMT_TE Transmission Send Message Payload MCCI_MT Wrapper Control Act Wrapper Master File / Reg. Notif Control Act, Act MFMI_MT Subject Message Type Act Reference Optional Participations MFMT_MT 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-8

11 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-9

12 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: 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 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 voor een toelichting. Implementatiehandleiding HL7v3-10

13 Interactiediagram: Interactie: Find Act Reference Registry Entries, Query (QUMT_IN020010) Trigger Event Find Act Reference Registry Entries, QUMT_TE Query Transmission Send Message Payload MCCI_MT Wrapper Control Act Wrapper Query Control Act Request : Query By QUQI_MT Parameter Message Type Act Reference Registry Find Acts QUMT_MT Interactie: Find Act Reference Registry Entries, Response (QUMT_IN020020) Trigger Event Find Act Reference Registry Entries, QUMT_TE Response Transmission Application Level MCCI_MT Wrapper Response/Acknowledgement Control Act Wrapper Master File / Registry Query Response, MFMI_MT Act Subject Message Type Act Reference Optional Participations MFMT_MT 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-11

14 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 Het abonneren op metadata-keys is gebaseerd op de in het HL7 Shared Messages domein beschreven berichten, zie paragraaf voor een toelichting. Interactiediagram: Interactie: Find Act Reference Registry Entries, Query (QUMT_IN020010) Trigger Event Find Act Reference Registry Entries, QUMT_TE Query Transmission Send Message Payload MCCI_MT Wrapper Control Act Wrapper Query Control Act Request : Query By QUQI_MT Parameter Message Type Act Reference Registry Find Acts QUMT_MT Interactie: Find Act Reference Registry Entries, Response (QUMT_IN020020) Trigger Event Find Act Reference Registry Entries, QUMT_TE Response Transmission Application Level MCCI_MT Wrapper Response/Acknowledgement Control Act Wrapper Master File / Registry Query Response, MFMI_MT Act Subject Message Type Act Reference Optional Participations MFMT_MT 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-12

15 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) 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-13

16 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_RM 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<TS>. 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-14

17 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_MT Act Reference Required Participations MFMT_MT 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-15

18 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<TS> (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-16

19 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_MT 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-17

20 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_RM en MFMI_RM berichtmodellen dient te bevatten om queries van het type bieden van een overzicht/index te kunnen beantwoorden Voorbeeldberichten 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 (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 Interactiediagram: Het onderstaande voorbeeldbericht is volgens de interactie MFMT_IN <ControlActProcess moodcode="evn"> <effectivetime value=" "/> <subject> <!-- payload --> <registrationprocess classcode="reg" moodcode="rqo"> <! Gegevenssoort = diagnostische beelden <code code="188011" codesystem=" " codesystemname="actregistrycodenl" displayname="beeldvormend onderzoek"/> <statuscode code="active"/> <!-- Geldigheidsduur van de registratie van de payload act --> <effectivetime> <low value=" "/> </effectivetime> <subject2 typecode="subj"> <ActReference classcode="category" moodcode="evn"> Implementatiehandleiding HL7v3-18

21 <id extension=" " root=" "/> <statuscode code="active"/> <!-- effectivetime van de middels category aangemelde beeldvormende onderzoeken --> <effectivetime> <low value=" "/> </effectivetime> <recordtarget> <patient> <id extension="197245" root=" "/> <statuscode code=""/> <patientperson> <name use="l"> <given>harry</given> <family>venema</family> </name> </patientperson> <providerorganization> <Organization> <id extension="123456" root=" "/> </Organization> </providerorganization> </patient> </recordtarget> <author> <time value=" "/> <assignedentity> <id extension="120450" root=" "/> <code code="01.039" codesystem=" " codesystemname="rolecode" displayname="radioloog"/> <assignedprincipalchoicelist> <assignedperson> <name/> </assignedperson> </assignedprincipalchoicelist> <Organization> <id extension="120450" root=" "/> </Organization> </assignedentity> </author> </ActReference> </subject2> </registrationprocess> </subject> </ControlActProcess> 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-19

22 de patiënt verhuist de klinische opname is afgelopen het zorgtraject is afgesloten 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_IN bericht (zoals gedefinieerd in het Radiology HL7 domein) aan het Ziekenhuis Informatie Systeem gemeld. met behulp van een MFMT_IN 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. <ControlActProcess moodcode="evn"> <code code="poxx_te900001" codesystem=" "/> <effectivetime value=" "/> <subject> <!-- payload --> <diagnosticimage classcode="dgimg" moodcode="evn"> <id extension=" " root=" "/> <statuscode code="active"/> <subject> <Patient> <id extension="197245" root=" "/> <Person> <name use="l"> <given>harry</given> <family>venema</family> </name> </Person> <Organization> <id extension="123456" root=" "/> </Organization> </Patient> </subject> <author> <time value=" "/> <AssignedPerson> <id extension="120450" root=" "/> <code code="01.039" codesystem=" " codesystemname="rolecode" displayname="radioloog"/> </AssignedPerson> </author> <! Details van payload worden niet getoond </Prescription> </subject> </ControlActProcess> Implementatiehandleiding HL7v3-20

23 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, = Beeldvormend onderzoek) en komt in de payload niet voor. Het onderstaande voorbeeldbericht is volgens de interactie MFMT_IN <ControlActProcess moodcode="evn"> <effectivetime value=" "/> <subject> <!-- payload --> <registrationprocess classcode="reg" moodcode="rqo"> <code code="188011" codesystem=" " codesystemname="actregistrycodenl" displayname="beeldvormend Onderzoek"/> <statuscode code="active"/> <effectivetime> <low value=" "/> </effectivetime> <subject2 typecode="subj"> <ActReference classcode="dgimg" moodcode="evn"> <id extension=" " root=" "/> <statuscode code="active"/> <recordtarget> <patient> <id extension="197245" root=" "/> <statuscode code=""/> <patientperson> <name use="l"> <given>harry</given> <family>venema</family> </name> </patientperson> <providerorganization> <Organization> <id extension="123456" root=" "/> </Organization> </providerorganization> </patient> </recordtarget> <author> <time value=" "/> <assignedentity> <id extension="120450" root=" "/> <code code="01.039" codesystem=" " codesystemname="rolecode" displayname="radioloog"/> <assignedprincipalchoicelist> <assignedperson> Implementatiehandleiding HL7v3-21

24 <name/> </assignedperson> </assignedprincipalchoicelist> <Organization> <id extension="120450" root=" "/> </Organization> </assignedentity> </author> </ActReference> </subject2> </registrationprocess> </subject> </ControlActProcess> 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-22

25 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 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-23

26 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 PRPM_TE306050NL Transmission Send Message Payload MCCI_MT Wrapper Control Act Wrapper Query Control Act Request : Parameter QUQI_MT List Message Type Person Event Query By Demographics QUPA_MT 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 PRPM_TE306051NL MCCI_MT MFMI_MT QUPA_MT 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-24