Implementatiehandleiding. HL7v3 Infrastructurele Domeinen

Transcriptie

1 Implementatiehandleiding HL7v3 Wrappers, Vocabulaires, Identificatiemechanismen. - Versie Status : Definitief Datum : augustus 2006

2 Inhoudsopgave 1 Inleiding Doel van dit document Doelgroep Totstandkoming van dit document Opbouw van dit document Verschillen met vorige releases van dit document Normatieve status van dit document 6 2 Message Wrappers Inleiding Wrapper specialisaties HMDs en Message Types Transmission Wrapper beschrijving Transmission Wrapper R-MIM beschrijving (MCCI_RM000100) Accept Acknowledgement (MCCI_RM000200) Application Response/Acknowledgement (MCCI_RM000300) Batch Transmission Wrapper beschrijving Batch Wrapper D-MIM (MCCI_DM000000) Trigger Event Control Acts wrappers (TECA) Generieke D-MIM beschrijving (MCAI_DM000000) Trigger Event Control Act R-MIM (MCAI_RM700200) Application Acknowledgement (MCAI_RM700200) Master File/ Registry Act wrapper (MFMI_RM700700) Queries, Continuations en Responses (TECA) Query By Parameter Specification TECA (QUQI_RM021000) Query Continuation/Cancel Control Act (QUQI_RM000001) Query Response Trigger Event Control Act (QUQI_RM120000) Master File / Registry Query Response (MFMI_RM700710) Voorbeeld Message Transmission wrapper Voorbeeld Trigger Event Control Act Voorbeeld Accept Acknowledgement Voorbeeld Application Acknowledgement 45 3 Identificatiemechanismen en Vocabulaires Identificatiemechanisme Inleiding Object Identifiers Uitgiftemechanisme OIDs Identificatiemethode Identificatiesystemen OID Referentietabel Vocabulaire voor berichtspecificaties Inleiding HL7 Vocabulary Domain Values Vocabulaires OID-Referentietabel OID gerelateerde implementatie aspecten Gevolgen van OIDs voor GBZ applicaties Afgeleide root-ids 66 4 Verificatie-interacties Applicatie verificatie: HL7 Ping Dynamisch Model Bericht Model HL7 Ping Communicatie verificatie: HL7 Tick Dynamisch Model Bericht Model HL7 Tick 70 Implementatiehandleiding HL7v3-2

3 Implementatiehandleiding HL7v3-3

4 1 Inleiding 1.1 Doel van dit document De HL7 versie 3 standaard bevat een aantal algemene onderdelen (Infrastructurele Domeinen) die ter ondersteuning dienen van de gegevensuitwisseling. Voorbeelden daarvan zijn de definities van de in de standaard gebruikte transportenveloppen en de toe te passen tabelwaarden in attributen. Dit document heeft als doel de infrastructurele domeinen nader te verklaren en te specificeren voor toepassing in de Nederlandse zorgsector. Dit document dient gezamenlijk met de standaard documentatie van HL7 versie 3 te worden gelezen. Merk op dat de scope van dit document niet beperkt is tot datgene wat in het kader van AORTA toegepast wordt. Welke delen die van belang zijn voor AORTA wordt beschreven in de documentatie van NICTIZ. Voor XIS-leveranciers staat in het handboek een gedetailleerde fasering welke zaken op welk moment geïmplementeerd moeten zijn. 1.2 Doelgroep Dit document is vooral bedoeld voor softwareontwikkelaars van zorgapplicaties en zorginfrastructurele applicaties, die op grond de HL7 versie 3 communicatiestandaard en op grond van dit document hun berichtschema s en berichten willen definiëren. ` 1.3 Totstandkoming van dit document Dit document is opgesteld onder verantwoordelijkheid van NICTIZ. De inhoud is grotendeels gebaseerd op het document Implementatiehandleiding HL7 v3 versie 2.2 (september 2004) van HL7 Nederland. Het is afgestemd met de andere documenten van NICTIZ, met name met het document Specificatie van de basisinfrastructuur in de zorg versie Opbouw van dit document Dit document bestaat uit twee delen: Een beschrijving van de gebruikte transportenveloppen (wrappers). Een beschrijving van de te gebruiken tabelwaarden (vocabulaires) en identificatiemechanismen. De diverse wrappers worden aan de hand van de daarin aanwezige artefacts beschreven, waarbij uitsluitend die onderdelen worden beschreven die in de Nederlandse situatie van toepassing zijn. 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. Wrappers zijn als transportenveloppen onafhankelijk van de inhoud en daarom worden ze in dit document apart beschreven. Dit document bevat dus geen specificatie van berichten, maar van de verschillende enveloppen waarin de berichten getransporteerd moeten worden. Voor elk bericht in een bepaalde interactie zijn er Implementatiehandleiding HL7v3-4

5 wrappers nodig. In feite bepaalt de interactie welk type wrappers nodig zijn. In dit document worden de wrappers gespecificeerd ten behoeve van implementatie. HL7 artefacts worden in dit document aangeduid door hun officiële identificatie volgens de HL7 versie 3 ballot #7 van maart Deze artefacts worden in dit document niet in detail besproken, hiervoor wordt verwezen naar de HL7 versie 3 standaard zelf (zie Enkele van de in deze implementatiehandleiding beschreven HL7 artefacts bestaan (nog) niet in de genoemde ballotversie van de internationale HL7 standaard. Deze artefacts worden in dit document in detail beschreven, omdat zij in een latere ballotversie zijn beschreven, of als voor Nederland specifieke artifacts niet in het HL7 materiaal gedocumenteerd zijn. De voor Nederland specifieke artefacts zijn voorzien van een NL code. 1.5 Verschillen met vorige releases van dit document Sinds het verschijnen van de versie van dit document (april 2006) zijn een aantal wijzigingen aangebracht. De aangebrachte wijzigingen sinds versie zijn: Het corrigeren van verwijzingen naar niet meer aanwezige 4-nivo diepe paragraafnummers. Het versioncode attribuut in de Transmission Wrappers (Message en Batch) is nu verplicht, het was voorheen optioneel met een defaultwaarde. Het attribuut is eveneens verplicht gemaakt in de schema. Zie paragraaf en voor details. Het profileid attribuut in de Transmission Wrappers (Message en Batch) is nu verplicht, het was voorheen optioneel. Het attribuut is eveneens verplicht gemaakt in de schema. Zie paragraaf en voor details. Het anders verwoorden van het gebruik van acceptackcode in paragraaf Het gebruik van de acceptackcode NE in Immediate queries is nu verplicht (was aanbevolen ). Het nader documenteren van de manier om (meerdere) foutmeldingen te melden in de paragrafen 2.2.2, en Het toevoegen van een FAQ over het gebruik van het Acknowledgement.typeCode in antwoordbatches in paragraaf Het documenteren van het gebruik van het effectivetime attribuut in de TECA wrapper van antwoordberichten, zie paragraaf Het nader toelichten van de relatie tussen de UZI beroepstitel code en de HL7 berichten. Zie paragraaf voor details. De verplichting van een auteur tevens de URA en naam van de verantwoordelijke organisatie in de ControlAct Wrapper op te nemen geldt niet indien de auteur de ZIM of de SBV-Z BSN applicatie is. Zie paragraaf voor details. Het gebruik van de startresultnumber en continuationquantity attributen in vraagberichten is niet langer toegestaan, zie paragraaf Het gebruik van deze attributen kan de beantwoording van vraagberichten onnodig compliceren. Het verplicht zijn van het queryid attribuut in antwoordberichten is verduidelijkt in paragraaf Het toevoegen van voorbeelden van foutmeldingen in paragraaf 2.8 en de nieuwe paragraaf 2.9. Implementatiehandleiding HL7v3-5

6 Het opnemen van een grotere set foutcodes vanuit de HL7 standaard in dit document, evenals de OIDs van de foutcode vocabulaires. Zie de actdetectedissuecode en acknowledgementdetailcode vocabulaires in paragraaf Het uitvoeriger documenteren van het gebruik van identificatiemechanismen en OIDs in paragraaf 3.1. De implementatieconsequenties van OIDs zijn nader toegelicht in hoofdstuk 3 en dan met name in de nieuwe paragraaf 3.3. Het documenteren van een tweetal Verificatie-interacties (Ping en Tick) in hoofdstuk Normatieve status van dit document Dit document bevat een aantal Nederlandse aanwijzingen bij het toepassen van HL7 versie3. Dit document is gebaseerd op ballot 7 van de HL7 v3 standaard. Dit document dient als toevoeging op (en niet als vervanging van) de internationale HL7 versie 3 materialen. In geval van tegenstrijdigheden tussen de internationale standaard en dit document geldt hetgeen bepaald is in dit document. Implementatiehandleiding HL7v3-6

7 2 Message Wrappers 2.1 Inleiding De structuur van een samengesteld HL7 V3 bericht zoals dit verzonden wordt tussen 2 of meer applicaties bestaat uit de volgende onderdelen: een buitenste laag, de HL7 transmission wrapper, een tussenlaag bestaande uit een van de Trigger Event Control Acts, de detailgegevens, tevens bekend als de payload. Transmission Wrapper ControlAct Wrapper Payload Figuur 1: Structuur van een HL7 bericht De buitenste laag van een HL7 versie 3 bericht bestaat uit de transmission wrapper. De transmission wrapper kan worden vergeleken met het HL7 versie 2 MSH segment of met de Edifact MEDEUR segmenten UNH, NAD, COM, en ADR. De transmission wrapper bevat de Trigger Event Control Act en de bericht payload. De Trigger Event Control Act vormt tezamen met de payload de inhoud van het bericht. De Trigger Event Control Act kan worden vergeleken met een zeer uitgebreide versie van het HL7 versie 2 EVN segment. In formele zin is de Trigger Event Control Act (TECA) geen wrapper, de functionaliteit van de TECA komt echter wel grotendeels overeen met een wrapper. Om deze reden wordt in dit document de TECA veelal aangeduid met TECA wrapper. Deze beide termen duiden een en hetzelfde begrip aan. De payload bevat de details van de gebeurtenis, zoals de betrokken patiënt, de betrokken zorgverleners en relevante medische en administratieve gegevens Wrapper specialisaties Alle berichten bestaan tenminste uit een Transmission Wrapper. Van de Transmission Wrapper bestaan drie varianten: één voor Accept Acknowledgement berichten, één voor antwoordberichten, en één voor normale berichten. Een Accept Acknowledgement bericht bestaat uitsluitend uit de Transmission Wrapper, alle andere berichten bevatten tevens de Trigger Event Control Act. Van de Trigger Event Control Act (TECA) bestaan een groot aantal specialisaties, meestal afhankelijk van het soort bericht dat verstuurd wordt. Zo bestaat er een specialisatie voor Queries (en een voor bijbehorende antwoorden), en een specialisatie voor Master File/Registry berichten. De standaard TECA wordt gebruikt voor Notifications (mededeling zonder verdere activiteitsverplichting bij de ontvanger) en opdrachten. Opdrachten Implementatiehandleiding HL7v3-7

8 resulteren meestal in de verplichting voor de ontvanger te reageren met een application response/acknowledgement, waarvoor eveneens een TECA specialisatie bestaat HMDs en Message Types De wrapper specialisaties in dit document worden veelal beschreven aan de hand van een grafische weergave van hun model. Dit maakt het mogelijk de relaties tussen de diverse klassen weer te geven evenals de in de klassen aanwezige attributen; en het gebruik van de diverse modelleringselementen in de Nederlandse situatie toe te lichten. Deze modellen zijn ook op een andere manier in de HL7 materialen aanwezig, namelijk in de vorm van Hierarchical Message Description (HMDs), een tabellarische weergave. De HMDs bevatten 1 of meer Message Types (MT), berichtvarianten van het model. HL7 versie 3 berichten zijn gebaseerd op message typen (en niet op grafische modellen of HMDs). Om een bericht te kunnen verzenden volstaat het dus niet te weten welke wrapper of wrapper specialisatie toegepast moet worden, het is noodzakelijk te weten welk Message Type gebruikt moet worden. De grafische modellen bezitten een 1-op-1 relatie met een HMD. Een HMD definieert 1 of meer Message Typen. In die gevallen waar een HMD meerdere Message Typen definieert worden de Message Typen in dit document kort beschreven. 2.2 Transmission Wrapper beschrijving De buitenste laag van een HL7 versie 3 bericht bestaat uit de Transmission wrapper. Deze wrapper bevat gegevens over de zender en de ontvanger(s) van het bericht, en een identificatie van het berichttype. Het bevat eveneens gegevens die het gebruik van acknowledgements op applicatie niveau ondersteunen. De transmission wrapper bevat de Trigger Event Control Act (TECA) en de bericht payload. De transmission wrapper bevat de identificatie van de berichtzendende en de berichtontvangende applicatie. Het identificatiemechanisme van de ontvanger van een bericht is in HL7 gebaseerd op applicaties, bijvoorbeeld de communicatiemodule van het ZIS systeem X van ziekenhuis organisatie Y of het huisartssysteem van huisarts Z. In de transmission wrapper worden uitsluitend de zendende en ontvangende applicatie geïdentificeerd, eventuele routerende applicaties worden niet in de wrapper opgenomen. Eventuele routerende applicaties dragen zorg voor de aflevering van het bericht op een wijze die onzichtbaar is voor de zendende en ontvangende applicatie. Implementatiehandleiding HL7v3-8

9 2.2.1Transmission Wrapper R-MIM beschrijving (MCCI_RM000100) Figuur 2: Transmission Wrapper, HL7 R-MIM (Reference Message Information Model) De bovenstaande figuur bevat de voor Nederland van toepassing zijnde R-MIM-subset van de transmission wrapper. De weergave is niet volledig, die onderdelen die voor de Nederlandse situatie niet van toepassing zijn worden niet getoond. De volledige transmission wrapper kan worden gevonden in de HL7 versie 3 materialen. Zo is onder andere informatie aangaande acknowledgement berichten in deze paragraaf buiten beschouwing gelaten, deze worden apart beschreven in paragraaf Alle berichten hebben een zender en een ontvanger. In de context van HL7 bestaan de zender en ontvanger uit applicaties. In HL7 versie 3 worden deze applicaties weergegeven door objecten van het type Device. Alle berichten afkomstig van één en dezelfde zender bezitten dezelfde waarde in het Device.id attribuut. De relationele klasse Agent kan worden gebruikt om de verantwoordelijke organisaties voor deze applicaties te identificeren. De Device klassen zijn op hun beurt via de relationele klasse CommunicationFunction verbonden met de Message klasse. In de Nederlandse situatie dient de zendende applicatie te worden geïdentificeerd. Om deze reden dient de wrapper verplicht 1 Sender en 1 Device te bevatten. Het bericht heeft 1 ontvanger waarvan verplicht de ontvangende applicatie geïdentificeerd moet worden. Om deze reden dient de wrapper verplicht 1 Receiver en 1 Device te bevatten. De identificatie van de Device (applicatie) vindt plaats volgens een standaardmethode zoals beschreven in de sectie Identificatiemechanismen van dit document. Implementatiehandleiding HL7v3-9

10 FAQ: berichten binnen een ziekenhuisorganisatie dienen eveneens deze informatie te bevatten. Dit betekent wellicht dat een HL7 bericht eerst aan de communicatie server wordt verzonden (bijv. zender = ZIS, ontvanger = communicatie server), waarna deze de ontvanger in het bericht wijzigt in de uiteindelijke ontvangers van het bericht (bijv. zender = communicatieserver, ontvanger = Lab). Nadere details rondom het routeren en het verwerken door communicatieservers van HL7 berichten kunnen worden gevonden in de Abstract Transport Specification (opgenomen in de internationale HL7 versie 3 publicatie). De eigenlijke inhoud van het bericht is verpakt in de Trigger Event Control Act wrapper. De hoofdklasse in deze wrapper bestaat uit de ControlActProcess klasse. De ControlActProcess klasse (en de daaraan gerelateerde geneste klassen) bevat de klinische en administratieve gegevens. Normaal gesproken bevat de TransportWrapper één ControlActProcess klasse; in specifieke gevallen echter geen enkele ControlActProcess klasse. De rest van deze paragraaf bevat een beschrijving van de diverse objectklassen aanwezig in de bovenstaande Transmission Wrapper R-MIM. De root klasse van de Transmission Wrapper R-MIM wordt gevormd door de Message object klasse. De 'Message' klasse bevat gegevens over het bericht, en geen details over de inhoud van het bericht. De klasse Message bezit de volgende (verplicht te vullen) attributen: id: Een unieke identificatie van het bericht. Deze identificatie (bestaande uit een OID en een volgnummer) is uniek en kan nooit nogmaals worden uitgedeeld, noch door dezelfde applicatie, noch door een andere applicatie. Deze id wordt tevens gebruikt (in een ander attribuut) om in acknowledgement berichten aan te geven welk ontvangen bericht bevestigd wordt. De functionaliteit van dit attribuut kan worden vergeleken met de HL7 versie 2 ControlID. Noot: Een duplicaatbericht is een bericht dat ontvangen wordt, en waarvan de Message.id gelijk is aan een eerder ontvangen bericht. De ontvangende applicatie dient duplicaatberichten te detecteren. Een duplicaatbericht dient niet verwerkt te worden, tenzij er aan het bericht een antwoordverplichting hangt (een Accept Acknowledgement en/of een Application Acknowledgement). In dat geval dient een antwoordbericht verstuurd te worden, alsof het duplicaatbericht voor de eerste keer verwerkt wordt. Het antwoordbericht vormt daarbij (vanuit het gezichtspunt van het beantwoordende systeem) een duplicaatbericht van een eerder verstuurd antwoordbericht; het originele antwoordbericht en het duplicaat antwoordbericht dienen een gelijkluidende Message.id te bevatten. De detectie van duplicaten is alleen mogelijk indien de ontvanger de Message.ids bewaart gedurende een redelijke tijd. creationtime: Het tijdstip waarop het bericht is aangemaakt, dit is onafhankelijk van het tijdstip waarop een bepaalde klinische of administratieve gebeurtenis de noodzaak tot het versturen van het bericht deed ontstaan. versioncode: De HL7 versie van het bericht. De ontvanger gebruikt deze waarde om het bericht juist te kunnen interpreteren. Dit attribuut bevat standaard de waarde die de versie identificeert waarop de berichten gebaseerd zijn, bijvoorbeeld NICTIZEd2005-Okt (NICTIZ Editie Oktober 2005). Dit attribuut is vanaf de augustus2006-release verplicht, maar was in eerdere AORTA releases Implementatiehandleiding HL7v3-10

11 optioneel. Indien de waarde van dit attribuut leeg is dient het bericht geïnterpreteerd te worden als versie NICTIZEd2005-Okt. interactionid: Referentie naar de unieke (HL7 v3 HDF) Interaction Identifier van de interactie waar dit bericht deel van uitmaakt. De van toepassing zijnde interactie identifier (van het type AAAA_INnnnnnn ) is gedocumenteerd in de HL7 domeinen in de standaard. Indien het bericht een medicatieoverzicht is, bevat dit attribuut bijvoorbeeld de waarde PORX_IN De OID van de assigning authority van deze identificatie is de Interaction ID OID uitgegeven door de HL7 organisatie: Het door de ontvanger toe te passen XML-Schema is eveneens af te leiden uit de Interaction ID. profileid: identificeert één of meer berichtprofielen. De zender van het bericht kan hiermee aangeven dat een bericht aan deze berichtprofielen voldoet. De ontvanger van een bericht kan deze gegevens gebruiken bij het verwerken en valideren van het bericht. Binnen de context van AORTA komt dit attribuut tenminste één keer voor en identificeert het de AORTA publicatie release waaraan het bericht voldoet. Dit attribuut is vanaf de augustus2006-release verplicht, maar was in eerdere AORTA releases optioneel. Indien de waarde van dit attribuut leeg is dient het bericht geïnterpreteerd te worden alsof het voldoet aan de april2006-release. Indien de ontvanger constateert dat een bericht niet voldoet aan de eisen zoals vastgelegd in de opgegeven AORTA publicatie release dan dient een foutmelding aan de zender gestuurd te worden. Ter identificatie van de AORTA publicatie releases dienen de volgende OIDs gebruikt te worden: november2005-release: root extensie 511 april2006-release: root extensie 604 augustus2006-release: root extensie 608 FAQ: Wat wordt verstaan onder een AORTA publicatie release? Een AORTA publicatie release (zoals geïdentificeerd in het profileid attribuut) bevat alle, op één moment gezamenlijk gepubliceerde, functionele en HL7 versie 3 specifieke specificaties. processingcode: Geeft aan of het bericht te verwerken is als een productie-, training- of debugging-bericht. Bevat bijvoorbeeld P voor berichten in productieomgevingen en T voor testberichten. processingmodecode: Geeft aan of een bericht wordt verzonden als gevolg van current processing (normaal online productiebericht), initial load mode (zenden van een reeks berichten ter initiële vulling van een database), restore from archive mode (herzenden van reeksen historische berichten uit een archief), etc. Bevat normaliter T (online processing mode). acceptackcode: geeft aan onder welke omstandigheden de ontvanger van dit bericht een accept acknowledgement (syntax check gerelateerde ontvangstbevestiging) dient te versturen. In het kader van AORTA dienen de volgende waarden gebruikt te worden: AL (always) dient te worden gebruikt in alle berichten, behalve o NE (never) in accept-acknowledgement berichten. Zie paragraaf voor een beschrijving van accept acknowledgements. o NE (never) in antwoordberichten die horen bij een vraagbericht dat voorzien was van een I (Immediate) responseprioritycode. Zie paragraaf voor een beschrijving van QueryByParameter.responsePriorityCode. o NE (never) in berichten die een antwoord vormen op een bericht (van een type anders dan een vraagbericht) waarop een synchroon (Immediate) antwoord word verwacht. Implementatiehandleiding HL7v3-11

12 o NE in vraagberichten met een I (Immediate) responseprioritycode. Zie paragraaf voor een beschrijving van QueryByParameter. responseprioritycode. De Message klasse heeft tevens een aantal optionele attributen, o.a. op het gebied van het HL7 sequence number protocol. sequencenumber: In Nederland niet gebruiken. securitytext: in Nederland niet gebruiken. attachmenttext: in Nederland niet gebruiken. De klassen Sender(CommunicationFunction) en Receiver(CommunicationFunction) bezitten de volgende attributen: Telecom: bevat contactgegevens (meestal telefoonnummer) van de persoon of organisatie die verantwoordelijk is voor het beheer van de applicatie geïdentificeerd in de geassocieerde Device klasse. (optioneel) De klasse Device identificeert de zendende en ontvangende applicatie. Deze klasse bezit de volgende attributen: id: bevat de unieke identificatie(s) van de zendende/ontvangende applicatie. De identificatie van applicaties wordt nader omschreven in de sectie Identificatiemethoden van dit document. Zie paragraaf voor de identificatiemethode van applicaties binnen AORTA. (verplicht attribuut) De transmission wrapper bevat de gegevens aangaande de fysieke zenders en ontvangers, de Trigger Event Control Act (zie paragraaf 2.4), de logische zenders (afdelingen, personen) en logische ontvangers (afdelingen, personen). name: Een tekstuele identificatie van de zendende/ontvangende applicatie (optioneel). telecom: bevat 1 of meer URLs van de zendende/ontvangende applicatie, waaronder bijvoorbeeld de http of tcp/ip connectiegegevens. (optioneel) softwarename: een tekstuele beschrijving van de gebruikte software, bijvoorbeeld X-ZIS versie 7.2. (optioneel) overige attributen: niet te gebruiken. FAQ: Het attribuut Device.id vormt de kern in de identificatie (op transportniveau) van de zender en de ontvanger. Het attribuut telecom is ondersteunend. De klasse Organization identificeert de zendende en ontvangende organisaties. Deze klasse bezit de volgende attributen: id: bevat de unieke identificatie van de berichtzendende/ontvangende organisatie. Deze identificatie vindt normaliter plaats middels het UZI-Register- Abonneenummer (URA) nummer. Zie het document Identificatiemethoden (paragraaf 3.1.3) voor een nadere uitleg over de te gebruiken methoden ter identificatie van organisaties. (verplicht attribuut) Opmerking: In de Nederlandse situatie wordt met organisatie een organisatie(deel) bedoeld dat in juridische zin verantwoordelijk is voor het transport (de fysieke verzending) van een bericht of de ontvangst daarvan, bijvoorbeeld een apotheek of ziekenhuis. Voorbeelden: Indien de zender van een bericht een huisartssysteem is, dan bevat Device.id de identificatie van het huisartssysteem, en Organization.id de identificatie van de huisartsenpraktijk. De huisartsenpraktijk is de organisatie verantwoordelijk voor het transport van het bericht. Implementatiehandleiding HL7v3-12

13 Indien de zender van een bericht een laboratoriummodule binnen het ZIS is, dan bevat Device.id de identificatie van de laboratoriummodule. Indien het ZIS de communicatie (de transportverantwoordelijkheid) verricht namens de laboratoriummodule, bevat Organization.id de identificatie van het Ziekenhuis, zijnde de verantwoordelijke organisatie voor het ZIS. name: Een tekstuele identificatie van de berichtzendende/ontvangende organisatie (optioneel). telecom: bevat 1 of meer URLs van de zendende/ontvangende organisatie, waaronder bijvoorbeeld een telefoon- en faxnummer. (optioneel) Message Types: In de HMD geassocieerd met bovenstaande R-MIM is één message type gedefinieerd. De Transmission Wrapper R-MIM (MCCI_RM000100) heeft het volgende afgeleide Message Type: Send Message Payload MCCI_MT Accept Acknowledgement (MCCI_RM000200) HL7 kent meerdere typen acknowledgements, waaronder de accept acknowledgement en de application acknowledgement. Een accept acknowledgement bevestigt de syntactische verwerkbaarheid van het HL7 bericht. De ontvanger van een bericht (meestal de ontvangende communicatiesoftware) beoordeelt of het bericht op het eerste gezicht correct is. Dit houdt meestal de controle van een aantal velden in de Transmission Wrapper in, zoals de HL7 versie, de interactieid, de device.id van de ontvangende applicatie, en een controle wat betreft de basale structuur (bijvoorbeeld: voldoet het bericht aan het schema) van het ontvangen bericht. Indien het bericht niet verwerkt kan worden om syntactische redenen dan wordt dit teruggemeld aan de afzender in de vorm van een accept acknowledgement. De application acknowledgement bevestigt de inhoudelijke verwerkbaarheid van de in het bericht opgenomen gegevens. Zie paragraaf voor een beschrijving. FAQ: De applicatie die in de Transmission Wrapper is aangegeven als ontvanger dient een eventuele Accept Acknowledgement te versturen. Eventueel tussenliggende/ berichtrouterende systemen (zoals het Schakelpunt in de ZIM) mogen alleen een Acept Acknowledgement foutmelding sturen indien het bericht niet kan worden afgeleverd. FAQ: Wanneer dient een berichtontvanger een Accept Acknowledgement te versturen? Indien de zender in het Message.acceptAckCode attribuut een andere waarde dan NE (never) heeft opgegeven, dient het ontvangende systeem mogelijk een accept acknowledgement te versturen. Andere waarden voor het Message.acceptAckCode attribuut zijn: AL (Always): Verstuur altijd een Accept Acknowledgement, en ER (Error): Verstuur alleen een Accept Acknowledgement indien het bericht fouten bevat. De accept acknowledgement bestaat in HL7 uit een specialisatie van de Transmission Wrapper. Implementatiehandleiding HL7v3-13

14 Figuur 3: Accept Acknowledgement R-MIM De bovenstaande figuur bevat de voor Nederland van toepassing zijnde R-MIM-subset van de transmission wrapper die in accept acknowledgement berichten wordt toegepast. Zie voorgaande paragraaf voor een beschrijving van de Transmission Wrapper klassen Message, Sender/Receiver(CommunicationFunction), Device, Agent en Organization. Het Message.acceptAckCode attribuut in een accept acknowledgement moet NE (Never) bevatten om het cyclisch bevestigen van bevestigingen te voorkomen. Een accept acknowledgement bevat diverse klassen die specifiek gericht zijn op het afwikkelen van acknowledgements. De Acknowledgement klasse bevat de volgende attributen en associaties: typecode: (verplicht) Een code die aangeeft of een ontvangen bericht al dan niet bevestigd wordt. De waarden zijn afkomstig uit de HL7 vocabulaire AcknowledgementType. Bevat een van de Cx codes in het geval van een Accept Acknowledgement. De te gebruiken waarden zijn CA (accept, geen fouten), CE (error, één of meer fouten) of CR (reject, tijdelijk niet verwerkbaar). expectedsequencenumber, messagewaitingnumber, messagewaitingprioritycode: In Nederland niet gebruiken. De Acknowledgement klasse (verplicht) bevat de volgende associaties: TargetMessage: bevat de identificatie (verplicht) van het bericht waar dit acknowledgement bericht bij hoort. Implementatiehandleiding HL7v3-14

15 AcknowledgementDetail: Deze klasse (die meerdere keren voor kan komen) bevat attributen die het mogelijk maken een beschrijving van de opgetreden fout in het acknowledgement bericht te versturen. Deze klasse wordt gebruikt om fouten betreffende de communicatie van het bericht of de structuur van het bericht (bijvoorbeeld het ontbreken van een veld, het niet kunnen valideren van een veld tegen het bijbehorende XML-Schema) door te geven. Deze klasse mag niet worden gebruikt voor de terugmelding van berichtinhoudelijke (semantische, business-rule gerelateerde) problemen. De TargetMessage klasse (verplicht) bevat de volgende attributen: id: de identificatie van het bericht dat middels dit bericht bevestigd wordt. (verplicht attribuut) De AcknowledgementDetail klasse bevat de volgende attributen: typecode: (verplicht) Het type informatie waarover bericht wordt: E (Error, foutmelding), W (Warning, waarschuwing) of I (Information, ter informatie). code: Identificatiecode van de (fout-)omschrijving. Bevat naast de code de tekstuele omschrijving daarvan. De vocabulaire tabel AcknowledgementDetailCode bevat een aantal voorgedefinieerde foutcodes. Zie paragraaf voor een beschrijving van de tabelwaarden in de vocabulaire AcknowledgementDetailCode. text: Een nadere (multimedia/tekstuele) toelichting op de foutmelding. Deze toelichting kan de vorm hebben van een string, een XML bericht of een gedeeltelijke processlog. location: De identificatie van nul of meer locaties binnen het bericht waarop de foutmelding betrekking heeft. Het wordt aanbevolen de locaties middels hiërarchische naamgeving aan te duiden, bijvoorbeeld MedicationSupply.author.name. Message Types: In de HMD geassocieerd met bovenstaande R-MIM is één message type gedefinieerd. De Accept Acknowledgement R-MIM (MCCI_RM000200) heeft het volgende afgeleide Message Type: Accept Acknowledgement MCCI_MT Interactie: Accept Ack (MCCI_IN000002) Trigger Event Send Message Accept Acknowledgement MCCI_TE Transmission Accept Acknowledgement MCCI_MT Wrapper Control Act Wrapper n.v.t n.v.t. Message Type n.v.t. n.v.t Application Response/Acknowledgement (MCCI_RM000300) Een Application Response is het antwoordbericht op een eerder verstuurde interactie. Dit antwoordbericht bevat een inhoudelijke reactie op een eerder verstuurde interactie. Een application acknowledgement bevestigt de inhoudelijke verwerkbaarheid van de in een interactie opgenomen gegevens, het vormt één specifieke toepassing van een Application Response. Zie paragraaf voor een nadere beschrijving van de application acknowledgement. Implementatiehandleiding HL7v3-15

16 De Application Response maakt in HL7 gebruik van een specialisatie van de Transmission Wrapper. Figuur 3A: Application Acknowledgement R-MIM De bovenstaande figuur bevat de voor Nederland van toepassing zijnde R-MIM-subset van de transmission wrapper die in Application Response/Acknowledgement berichten wordt toegepast. De ControlActProcess klasse is verplicht in dit model en bevat de TECA Wrapper, met daarin de payload. De Acknowledgement klasse bevat de volgende attributen en associaties: typecode: (verplicht) Een code die aangeeft of een ontvangen bericht al dan niet bevestigd wordt. De waarden zijn afkomstig uit de HL7 vocabulaire AcknowledgementType. Bevat een van de Ax codes in geval van een Application Acknowledgement. De te gebruiken waarden zijn AA (application accept, geen fouten), AE (application error, één of meer fouten) of AR (application reject, tijdelijk niet verwerkbaar). FAQ: Wat is de waarde van typecode in het geval van een batchantwoord? In principe bevat typecode in een batchantwoord altijd AA, ook indien één of meer berichten in de antwoordbatch een foutcode AE bezitten. Typecode in een batchantwoord bevat alleen de waarde AE indien er op batchniveau een fout ontstaan is, bijvoorbeeld indien berichten niet in een batchwrapper verpakt konden worden. Implementatiehandleiding HL7v3-16

17 expectedsequencenumber, messagewaitingnumber, messagewaitingprioritycode: In Nederland niet gebruiken. De Acknowledgement klasse (verplicht) bevat de volgende associaties: TargetMessage: bevat de identificatie (verplicht) van het bericht waar dit acknowledgement bericht bij hoort. AcknowledgementDetail: Deze klasse (die meerdere keren voor kan komen) bevat attributen die het mogelijk maken een beschrijving van de opgetreden fout in het acknowledgement bericht te versturen. Deze klasse wordt gebruikt om fouten betreffende de communicatie van het bericht of de structuur van het bericht (bijvoorbeeld het ontbreken van een veld, het niet kunnen valideren van een veld tegen het bijbehorende XML-Schema) door te geven. Deze klasse mag niet worden gebruikt voor de terugmelding van berichtinhoudelijke problemen. Deze problemen (bijvoorbeeld: onbekende patiënt, ongeldig medicatievoorschrift gegeven de klinische situatie van de patiënt, de aangeleverde monsters zijn niet de juiste voor de aangevraagde test) dienen te worden opgenomen in de DetectedIssue klasse. Zie de sectie over Application Acknowledgements (paragraaf 2.4.3) voor een beschrijving van deze klasse. De TargetMessage klasse (verplicht) bevat de volgende attributen: id: (verplicht) de identificatie van het bericht dat middels dit bericht bevestigd wordt. Indien een laboratorium aanvraag-interactie de identificatie 5678 bezat, en resulteert in een orderbevestiging-interactie, dan bevat TargetMessage.id in het antwoordbericht de waarde 5678, en de TECA Wrapper de payload met een structuur zoals gedefinieerd voor de orderbevestiging-interactie. De AcknowledgementDetail klasse bevat de volgende attributen: typecode: (verplicht) Het type informatie waarover bericht wordt: E (Error, foutmelding), W (Warning, waarschuwing) of I (Information, ter informatie). code: Identificatiecode van de (fout-)omschrijving. Bevat naast de code de tekstuele omschrijving daarvan. De vocabulaire tabel AcknowledgementDetailCode bevat een aantal voorgedefinieerde foutcodes. Zie paragraaf voor een beschrijving van de tabelwaarden in de vocabulaire AcknowledgementDetailCode. text: Een nadere (multimedia/tekstuele) toelichting op de foutmelding. Deze toelichting kan de vorm hebben van een XML bericht of een gedeeltelijke processlog. location: De identificatie van nul of meer locaties binnen het bericht waarop de foutmelding betrekking heeft. Het wordt aanbevolen de locaties middels hiërarchische naamgeving aan te duiden, bijvoorbeeld MedicationSupply.author.name. Message Types: In de HMD geassocieerd met bovenstaande R-MIM is één message type gedefinieerd. De Application Response/Acknowledgement R-MIM (MCCI_RM000300) heeft het volgende afgeleide Message Type: Application Level Acknowledgement MCCI_MT Implementatiehandleiding HL7v3-17

18 2.3 Batch Transmission Wrapper beschrijving De buitenste laag van een HL7 versie 3 bericht bestaat niet altijd uit een transmission wrapper. Er zijn omstandigheden waarin het nuttig is meerdere individuele berichten (die elk een transmission wrapper bezitten) te bundelen tot één geheel ten bate van transportdoeleinden. Een typisch voorbeeld is een reeks financiële verrichtingsberichten die periodiek van een deelsysteem naar de facturerende applicatie worden verzonden. Voor AORTA wordt de batch wrapper toegepast om een reeks antwoordberichten te bundelen. Een batch bestaat meestal uit meerdere berichten van één en hetzelfde type, maar kan in principe berichten van verschillende typen bevatten. Een bericht (d.w.z. een niet in batch opgenomen bericht) mag nooit worden beantwoord met een batch tenzij expliciet door de zender van een bericht om het gebruik van de batchwrapper wordt gevraagd. Een vragende applicatie kan dit verzoeken door het QueryByParameter.responseModalityCode attribuut gelijk te maken aan B. Het verwerken van een batch vindt in twee fasen plaats: 1. Valideer de integriteit en syntactische correctheid van de batch; zend 1 accept acknowledgement batch. In een accept acknowledgement batch zijn alleen bericht accept acknowledgements opgenomen voor die berichten waarin een fout is geconstateerd. Bij deze optie kunnen lege batchberichten worden gebruikt, wat neerkomt op een impliciete accept acknowledgement van alle daarin opgenomen berichten. De acknowledgement batch bevat om deze reden nul of meer berichten. Alle berichten opgenomen in batches zijn voorzien van een message transmission wrapper. Zie paragraaf voor een beschrijving van Accept Acknowledgements. 2. Verwerk de in de batch opgenomen berichten en verstuur de antwoorden gerelateerd aan deze berichten (indien van toepassing). Implementatiehandleiding HL7v3-18

19 2.3.1Batch Wrapper D-MIM (MCCI_DM000000) De Batch Wrapper kan worden gebruikt in omstandigheden waarin het nuttig is meerdere individuele berichten (die elk een transmission wrapper bezitten) te bundelen tot één geheel ten bate van transportdoeleinden. Figuur 4: Batch WrapperDMIM De Transmission Infrastructure D-MIM heeft twee root klassen. De root klasse Message en de daaraan gerelateerde klassen zijn eerder in dit document beschreven. De attributen en associaties van de root klasse Batch zijn hieronder beschreven, voorzover zij niet reeds eerder in dit document beschreven zijn. De Batch klasse heeft de volgende attributen: id: (verplicht) Een unieke identificatie van de batch. Deze identificatie (bestaande uit een OID en een volgnummer) is uniek en kan nooit nogmaals worden uitgedeeld, noch door dezelfde applicatie, noch door een andere applicatie. Deze ID wordt tevens gebruikt om vanuit andere batches naar een specifieke batch te refereren (met behulp van het referencecontrolid attribuut). Noot: Een duplicaatbatch is een batch die ontvangen wordt, en waarvan de Batch.id gelijk is aan een eerder ontvangen batch. De ontvangende applicatie dient duplicaatbatches te detecteren. Een duplicaatbatch dient beantwoord te worden alsof het de eerste keer betrof dat de batch verwerkt wordt. De antwoordbatch vormt daarbij (vanuit het gezichtspunt van het beantwoordende systeem) een duplicaatbatch van een eerder verstuurde antwoordbatch; de originele antwoordbatch en de duplicaat antwoordbatch dienen een gelijkluidende Batch.id te bevatten. De detectie van duplicaten is alleen mogelijk indien de ontvanger de Batch.ids Implementatiehandleiding HL7v3-19

20 bewaart gedurende een redelijke tijd. creationtime: (verplicht) Het tijdstip waarop de batch is aangemaakt. securitytext: In Nederland niet gebruiken. versioncode: (verplicht) De HL7 versie van de batch. De ontvanger gebruikt deze waarde om het bericht juist te kunnen interpreteren. Bevat standaard de waarde die de versie identificeert waarop de batch gebaseerd is, bijvoorbeeld NICTIZEd2005-Okt (NICTIZ Editie 2005). Dit attribuut is verplicht, maar was initieel optioneel. Indien de waarde van dit attribuut leeg is dient het bericht geïnterpreteerd te worden als versie NICTIZEd2005-Okt. interactionid: (verplicht) Referentie naar de unieke (HL7 v3 HDF) Interaction Identifier van de interactie waar dit bericht deel van uitmaakt. Voor batch bertichten zijn twee vaste waarden van toepassing: MCCI_IN voor batches, en MCCI_IN voor antwoordbatches (bijvoorbeelde de antwoord batch op een query). De OID van de assigning authority van deze identificatie is de Interaction ID OID uitgegeven door de HL7 organisatie: Het door de ontvanger toe te passen XML-Schema is eveneens af te leiden uit de Interaction ID. profileid: (verplicht) identificeert één of meer berichtprofielen. De zender van het bericht kan hiermee aangeven dat een batch (als geheel) aan deze berichtprofielen voldoet. De ontvanger van een batch kan deze gegevens gebruiken bij het verwerken en valideren van het batch. Binnen de context van AORTA komt dit attribuut tenminste één keer voor en identificeert het de AORTA publicatie release waaraan het batch voldoet. Dit attribuut is vanaf de augustus2006-release verplicht, maar was in eerdere AORTA releases optioneel. Indien de waarde van dit attribuut leeg is dient de batch geïnterpreteerd te worden alsof het voldoet aan de april2006-release. Indien de ontvanger constateert dat een batch niet voldoet aan de eisen zoals vastgelegd in de opgegeven AORTA publicatie release dan dient een foutmelding aan de zender gestuurd te worden. Ter identificatie van de AORTA publicatie releases dienen de volgende OIDs gebruikt te worden: november2005-release: root extensie 511 april2006-release: root extensie 604 augustus2006-release: root extensie 608 FAQ: Wat wordt verstaan onder een AORTA publicatie release? Een AORTA publicatie release (zoals geïdentificeerd in het profileid attribuut) bevat alle, op één moment gezamenlijk gepubliceerde, functionele en HL7 versie 3 specifieke specificaties. referencecontrolid: Bevat in geval van de herzending van een batch een referentie naar de identificatie van een oorspronkelijk verzonden batch bericht. Dit attribuut is niet gevuld indien de batch voor de eerste keer verzonden wordt. (verplicht bij herzonden batches) name: (optioneel) Bevat een gecodeerde aanduiding van het type batch; de waarde kan door de ontvangende applicatie gebruikt worden ter verwerking van de batch. Voorbeeld van een alfanumerieke code: Verr - verrichtingen. batchcomment: Bevat extra informatie aangaande de batch. (optioneel) transmissionquantity: (verplicht) Bevat het aantal berichten opgenomen in deze batch. batchtotalnumber: (optioneel) Een of meer tellingen (proefsommen) gebaseerd op waarden zoals opgenomen in de berichten in de batch. De Implementatiehandleiding HL7v3-20

21 berekeningsmethode en de keuze van de totaliseren gegevens is applicatie afhankelijk, de HL7 standaard doet hier geen uitspraken over. De Batch klasse heeft de volgende associaties: message: een Batch is geassocieerd met nul of meer Messages. acknowledgement: deze klasse is verplicht in antwoordbatches. Interactie: Batch (MCCI_IN200100) Trigger Event Send batch MCCI_TE Batch Wrapper Batch MCCI_MT Interactie: Batch Response (MCCI_IN200101) Trigger Event Send batch Reponse MCCI_TE Batch Wrapper Batch Response MCCI_MT Trigger Event Control Acts wrappers (TECA) 2.4.1Generieke D-MIM beschrijving (MCAI_DM000000) De Trigger Event Control Act (TECA) vormt tezamen met de payload de inhoud van het bericht. De functionaliteit van de TECA komt grotendeels overeen met een wrapper. Om deze reden wordt in dit document de TECA veelal aangeduid met TECA wrapper. Deze beide termen duiden een en hetzelfde begrip aan. De TECA wrapper heeft een structuur die op hoofdlijnen voor alle HL7 berichten gelijk is. Het bevat gegevens over de reden waarom dit bericht verstuurd wordt, de verantwoordelijke persoon voor de inhoud van het bericht, de gebeurtenis die het bericht heeft doen ontstaan, het tijdstip waarop die gebeurtenis optrad, etc. De TECA wrapper speelt een belangrijke rol in de overdracht van gegevens. Daar waar de transmission wrapper het transport van het bericht ondersteund, specificeert de TECA wrapper het type gegeven of opdracht waarover gecommuniceerd wordt. Een voorbeeld: het ZIS systeem stuurt een opdracht tot het annuleren van een eerder verzonden laboratoriumaanvraag. De transmission wrapper bevat de identificatie van de zender en ontvanger (ZIS en Lab) en het berichttype (cancel lab order). De Trigger Event Control Act bevat het tijdstip waarop de aanvraag wordt geannuleerd, de reden van het verzoek tot annuleren, en de naam van de arts die de aanvraag annuleert. De payload bevat de gegevens van de aanvraag die te annuleren is, zoals de naam van de arts die de oorspronkelijke aanvraag gedaan heeft en de identificatie van de oorspronkelijk aangevraagde onderzoeken. De TECA wrapper bestaat in een aantal variaties (R-MIMs) op een basismodel (de D- MIM). Zo is bijvoorbeeld de TECA wrapper die voor query berichten gebruikt wordt iets anders gemodelleerd dan een TECA wrapper die voor master file berichten gebruikt wordt. Alle TECA wrappers zijn afgeleid van de D-MIM. Dit leidt tot een consistente modellering van alle TECA wrappers. De TECA D-MIM wordt in deze paragraaf besproken, de elementen van de gespecialiseerde R-MIMs worden beschreven in latere secties. Er is een zekere overlap tussen de gegevens in de TECA wrapper en de payload. Indien degene die de gebeurtenis veroorzaakt (de Author geassocieerd aan de ControlActProcess klasse) dezelfde is als de inhoudelijke verantwoordelijke (de Author Implementatiehandleiding HL7v3-21

22 geassocieerd met een object klasse in de payload) dan worden deze gegevens tweemaal in het bericht opgenomen. Figuur 5: Trigger Event Control Act D-MIM De inhoud van een transmission wrapper bestaat uit de controlactprocess klasse. Deze klasse bevat gegevens aangaande de gebeurtenis die ten grondslag ligt aan het bericht. De controlactprocess klasse bezit de volgende attributen: id: (optioneel) Een unieke identificatie van de gebeurtenis (event). Deze identificatie (bestaande uit een OID en een volgnummer) is uniek en mag nooit nogmaals worden uitgedeeld, noch door dezelfde applicatie, noch door een andere applicatie. Opmerking: over een specifieke gebeurtenis (met één specifieke identifier) kunnen meerdere berichten (die elk verschillende Message.id identifiers dienen te bezitten) worden verzonden, bijvoorbeeld bij het versturen van berichten over een gebeurtenis aan meerdere applicaties. Al deze berichten bevatten dezelfde waarde in het ControlActProcess.id attribuut. code: (optioneel) Bevat een code die het type van de gebeurtenis waarover bericht wordt, weergeeft. Bevat de identificatiecode van de trigger event (TE) van de HL7 interactie (van type AAA_TEnnnnnn ), bijvoorbeeld QURX_TE of COMT_TE Deze waarden zijn opgenomen bij de documentatie van de berichten en interacties. De te gebruiken OID is: effectivetime: (optioneel) Datum en tijdstip waarop de gebeurtenis die het bericht heeft doen ontstaan, plaatsvond. Dit tijdstip is mogelijkerwijs anders dan het tijdstip van het versturen van het bericht zoals opgenomen in de transmission wrapper. Opmerking ten aanzien van antwoordberichten: de ontvangst van een vraagbericht is aanleiding tot het versturen van een antwoordbericht. Het effectivetime attribuut van een antwoordbericht bevat om deze reden het verwerkingstijdstip van het ontvangen vraagbericht. prioritycode: (optioneel) Een code, of een reeks codes die prioriteit (mate van spoed) aangeven van de omstandigheden waarbinnen de gebeurtenis optrad, optreed, zal optreden, gepland is op te treden, of gevraagd wordt op te treden. Implementatiehandleiding HL7v3-22

23 Indien dit attribuut leeg is, wordt het bericht met prioriteit normaal ( R routine) verwerkt. reasoncode: (optioneel) Bevat de gecodeerde reden voor het versturen van het bericht. De te gebruiken codewaarden zijn beschreven in de vocabulaire ActReason. Voorbeelden: op verzoek van de patient/zorgverlener, op grond van foutcorrectieprocedure. Dit attribuut mag niet gebruikt worden om een fout te identificeren, deze dienen te worden opgenomen in de A_DetectedIssue CMET die met ControlActProcess geassocieerd is. De controlactprocess klasse bezit de volgende associaties: Author or Performer: (verplicht) Identificeert de partij die de controlactprocess klasse heeft aangemaakt. In feite is dit de verantwoordelijke partij voor de verzending van het bericht, d.w.z. degene die met behulp van zijn UZI-pas de gegevens verzendt. De gegevens van de persoon (auteur of performer) zijn opgenomen in de Assigned Person CMET. In Nederland is de identificatie van de auteur of performer (hieronder: auteur genoemd) met behulp van deze associatie verplicht. De AORTA infrastructuur vereist aanvullend hierop dat in alle berichten: o De auteur wordt geïdentificeerd door middel van het UZI nummer. In het merendeel van de berichten is een persoon de auteur van het bericht, en wordt het UZI nummer opgenomen in het AssignedPerson.id attribuut. De AORTA infrastructuur kent slechts enkele omstandigheden waarin een Device als auteur optreedt: De auteur van een antwoordbericht (op een Query) betreft een applicatie, de UZI (van het systeemcertificaat) dient verplicht te worden opgenomen in het AssignedDevice.id attribuut. Een device kan als auteur optreden in verificatieberichten (zie hoofdstuk 4). De UZI (van het systeemcertificaat) dient verplicht te worden opgenomen in het AssignedDevice.id attribuut. Een device kan als auteur optreden in vraagberichten aan de SBV-Z (BSN Query Interacties). De UZI (van het systeemcertificaat) dient verplicht te worden opgenomen in het AssignedDevice.id attribuut. NB: Een device (als auteur in de TECA wrapper) wordt altijd geidentificeerd door middel van een UZI nummer, met uitzondering van de ZIM (met root en extensie 1) en de SBV-Z BSN applicatie (met root en extensie 1). In toevoeging op het UZI nummer van het device kan tevens (optioneel) de Applicatie-ID van het device worden opgenomen. o Indien de auteur een persoon is dient de rol (Beroepstitel) van de persoon (een waarde afkomstig uit de RoleCodeNL tabel, opgenomen in het AssignedPerson.code attribuut) te worden meegegeven indien deze bekend is. Omdat in de Aorta-infrastructuur de rol is opgenomen op de UZI-pas moet de rolcode van een persoon in het bezit van een UZI-pas altijd worden opgenomen in HL7 v3 berichten. Merk op dat de op de pas aanwezige code staat voor rol zonder beroepstitel, deze waarde wordt niet in het HL7 bericht opgenomen. FAQ: Waarom dient de Rol te worden opgenomen in de HL7 berichten? Deze is toch af te leiden uit het UZI-nummer? Eén zorgverlener kan meerdere UZI-passen bezitten, per rol één pas. Al deze passen hebben één en het hetzelfde UZI nummer. Om deze reden moet de rol zoals vermeld op de pas mede worden opgenomen in de HL7 berichten. Implementatiehandleiding HL7v3-23

24 FAQ: Wat doe ik met de waarde als die op de UZI pas staat? Niets. Dit is de code die het CIBG gebruikt voor overige, onbekende rollen. Deze waarde wordt niet in het HL7 bericht opgenomen, ook niet als nullflavor. De waarde mag dus nooit in berichten voorkomen. Indien men uit een andere bron weet wat voor rol/functie de persoon heeft (bijv. Apothekers assistent, of Medisch secretaresse) dan kan men de code daarvoor (een niet van het CIBG afkomstige code uit de RoleCodeNL tabel) in het bericht gebruiken. o Het URA (UZI register Abonneenummer, de aanvrager van de UZI pas) dient verplicht te worden worden opgenomen in het bericht (in de E_Organization CMET, de scoping organization). Deze verplichting geldt niet indien de auteur de ZIM of de SBV-Z BSN applicatie is. o De naam behorende bij het URA (UZI register Abonneenummer, de aanvrager van de UZI pas) dient verplicht te worden worden opgenomen in het bericht (in de E_Organization CMET, de scoping organization). Deze verplichting geldt niet indien de auteur de ZIM of de SBV-Z BSN applicatie is. o Indien de auteur een medewerker is van een zorgverlener, dan dient de mandaterende zorgverlener (die onder de wet BIG valt) verplicht te worden opgenomen als Overseer (zie hieronder). Indien de auteur zelf een zorgverlener is, dan worden zijn of haar gegevens gedupliceerd in de Overseer. In SBV-Z berichten (BSN Query Interacties) zijn bovendien de volgende attributen verplicht voor auditing-doeleinden: o de naam van de vraagsteller (Person.name of Device.ManufacturerModelName). Overseer: (optioneel indien het bericht een antwoordbericht op een vraag is, of indien het bericht een BSN vraag is, of indien het bericht een verificatiebericht of een antwoord daarop is. Overseer is verplicht in alle andere gevallen). Een zorgverlener die de uiteindelijke (juridische) verantwoordelijkheid draagt voor het bericht, zonder noodzakelijkerwijs betrokken te zijn geweest bij het verzendproces of bij de activiteiten beschreven in het bericht. Veelal is de overseer gelijk aan de auteur of de performer. Een zorgverlener kan echter ook een medewerker mandateren om bepaalde beerichten namens de zorgverlener te versturen. De AORTA infrastructuur gebruikt de overseer voor autorisatie. Daarom is het vereist dat: o het bericht altijd een overseer bevat die de verantwoordelijke (mandaterende) zorgverlener identificeert. o de overseer wordt geïdentificeerd door middel van het UZI nummer (in het AssignedPerson.id attribuut). o de Rol van de zorgverlener wordt opgenomen in het bericht (in het AssignedPerson.code attribuut). o het URA (UZI register Abonneenummer, de aanvrager van de UZI pas) dient te worden worden opgenomen in het bericht (in de E_Organization CMET, de scoping organization). o de naam behorende bij het URA (UZI register Abonneenummer, de aanvrager van de UZI pas) dient te worden worden opgenomen in het bericht (in de E_Organization CMET, de scoping organization). Implementatiehandleiding HL7v3-24

25 dataenterer: (optioneel) Een of meer personen (en organisaties) die de in het bericht aanwezige gegevens hebben ingevoerd in een geautomatiseerd systeem. De invoer zal meestal onder toezicht van de auteur plaatsvinden; de auteur (of de overseer, indien aanwezig) is eindverantwoordelijke wat betreft de inhoud van de gegevens. Information Recipient: (optioneel) Een of meer personen of organisaties aan wie de inhoud van het bericht gericht is. De in dit attribuut geïdentificeerde geadresseerden van de berichtinhoud verschillen van de geadresseerde partij van het bericht zelf zoals opgenomen in de Transmission Wrapper (Organization klasse): de berichtinhoudelijke geadresseerden spelen geen rol in het transportproces van het bericht. Voorbeeld: indien een bericht is geadresseerd aan het St.Jozef Ziekenhuis, t.a.v. Dr. P.J. de Vries, of St.Jozef Ziekenhuis, t.a.v. Longartsen dan bevat de transmission wrapper St. Jozef (de ontvangende organisatie) en de TECA wrapper respectievelijk Dr.P.J. de Vries of Longartsen. De gegevens van de geadresseerde zijn opgenomen in de Assigned Person CMET. Opmerking: in vele gevallen zal niet een persoon, maar een organisatiedeel als geadresseerde optreden. In dergelijke gevallen wordt binnen de CMET alleen het gedeelte betreffende de organisatie ingevuld. Reason: (optioneel) Een of meer redenen (van een bepaald type) het bericht te versturen. De met deze associatie gerelateerde A_DetectedIssue CMET wordt vrijwel uitsluitend gebruikt in Application Acknowledgements. Zie de sectie over Application Acknowledgements (paragraaf 2.4.3) voor een gedetailleerde beschrijving van de klassen in deze CMET. Subject: (optioneel) Nul of meer payloads. Voorbeelden van payloads zijn een medicatie voorschrift, een laboratorium uitslag of een BSN-persoonsregistratie. In de meeste berichten bevat de TECA wrapper precies 1 payload. Een TECA wrapper kan in antwoordberichten nul payloads bevatten indien op de vraag geen zoekresultaten gevonden werden. Een antwoordbericht kan tevens vele payloads bevatten indien vele zoekresultaten gevonden werden. Naast deze associaties/relaties heeft de ControlActProcess klasse, afhankelijk van het exacte TECA wrapper type (specialisaties van de hierboven beschreven TECA), een of meer andere associaties/relaties. Deze worden per TECA wrapper specialisatie hieronder beschreven Trigger Event Control Act R-MIM (MCAI_RM700200) Dit is de standaard TECA wrapper voor alle Notification berichten. Notifications (unsollicited updates) zijn die categorie berichten waarin gegevens zitten die aan andere applicaties worden verstuurd, en waarop al dan niet een reactie van de ontvanger volgt. Deze categorie omvat bijvoorbeeld verzoeken/opdrachten (orders) waarop normaliter een reactie van de ontvanger volgt. De inhoud bestaat naast de generieke inhoud die alle TECA wrappers bezitten uit nul of meer associaties met Acts. Deze Acts vormen de payload van het totale bericht. Implementatiehandleiding HL7v3-25

26 Figuur 6: Trigger Event Control Act R-MIM Zie paragraaf voor een beschrijving van de diverse attributen en associaties van ControlActProcess. ControlActProcess bezit in deze specialisatie tevens de volgende associaties: Subject (Act): De ControlActProcess heeft een relatie met één of meer payload Acts. In vrijwel alle situaties wordt gebruik gemaakt van één payload act. De Subject associatie bevat een tweetal attributen: contextcontrolcode en contextconductionindicator. Het attribuut contextconductionindicator bevat altijd de waarde false wat aangeeft dat de diverse objecten die een associatie bezitten met de ControlActProcess klasse niet worden overgeërfd door de klassen in de payload. Message Types: In de HMD geassocieerd met bovenstaande R-MIM is één message type gedefinieerd. De Trigger Event Control Act R-MIM (MCAI_RM700200) heeft het volgende afgeleide Message Type: Trigger Event Control Act MCAI_MT Application Acknowledgement (MCAI_RM700200) Een application acknowledgement bevat een terugmelding over de verwerkingsstatus van de inhoud van het bericht. De ontvangende applicatie voert een aantal integriteitschecks uit die standaard uitgevoerd worden bij de import van gegevens die op welke wijze dan ook in de applicatie ingevoerd worden. FAQ: Wanneer dient een berichtontvanger een Application Acknowledgement te versturen? Indien aan de interactie (geïdentificeerd door de Message.interactionID) de Receiver Responsability tot het verzenden van een application acknowledgement verbonden is, dient de berichtontvanger een application acknowledgement te versturen. De eventuele verplichting tot het verzenden van een application acknowledgement is aan de interactie verbonden en beschreven in het van toepassing zijnde HL7 domein. De application acknowledgement moet expliciet in het interactie diagram in de documentatie opgenomen zijn. Het application acknowledgement bericht bestaat uit de Transmission Wrapper (zie de beschrijving in paragraaf 2.2.3, met name het Acknowledgement.typeCode attribuut), de TECA wrapper en de payload Act. De doorgevoerde application acknowledgement checks zijn tweeledig: 1. Inhoudelijke controle: het bericht wordt inhoudelijk gecontroleerd op syntax, codewaarden en datatypen. Eventuele problemen worden in de Implementatiehandleiding HL7v3-26

27 AcknowledgementDetail klasse in de Transmission Wrapper (zie paragraaf 2.2.3) teruggemeld. De op deze wijze teruggemelde problemen worden uitsluitend verwerkt door de cummunicatiemodule van de ontvangende applicatie, en niet door de applicatie zelf. 2. Business Rules controle: de inhoud van het bericht wordt bekeken op consistentie met reeds bij de ontvangende applicatie bekende informatie. Het gaat hierbij met name om problemen aangaande business rules. Voorbeelden zijn het voorschrijven van een medicatie die een contra-indicatie heeft met een al eerder voorgeschreven medicatie, het in rekening brengen van een dienst aan een patiënt waarvan de facturatie al afgesloten is, en het aanvragen van een laboratoriumtest die niet mogelijk is bij een patiënt gegeven het ziektebeeld. Deze problemen worden in de DetectedIssueEvent klasse (in de A_DetectedIssue CMET) in de TECA wrapper teruggemeld. Afhankelijk van het type probleem wordt de identificatie daarvan opgenomen in de AcknowledgementDetail klasse in de Transmission wrapper of in de DetectedIssueEvent klasse in de TECA wrapper, maar niet in beide klassen. Zie paragraaf 2.9 voor voorbeelden. Figuur 7: De application acknowledgement R-MIM (gedeeltelijk) De ControlActProcess klasse bevat de volgende (in deze context relevante) attributen: reasoncode: Bevat de gecodeerde reden voor het versturen van het bericht. De te gebruiken codewaarden zijn beschreven in de vocabulaire ActReason. Voorbeelden: op verzoek van de patient/zorgverlener, op grond van foutcorrectieprocedure. Dit attribuut mag niet gebruikt worden om een fout te identificeren, deze dienen te worden opgenomen in de A_DetectedIssue CMET die met ControlActProcess geassocieerd is. (optioneel attribuut) De ControlActProcess klasse bevat de volgende (in deze context relevante) associaties: subject: Act. In Application Acknowledgements bestaat de payload uit datgene waarover de Application Acknowledgement status (geaccepteerd / niet geaccepteerd) wordt teruggemeld (optioneel). reason: Een associatie met nul of meer A_DetectedIssue CMETs; deze bevatten de eventuele waarschuwingen of foutmeldingen ten aanzien van de Act. Implementatiehandleiding HL7v3-27

28 Figuur 7A: De A_DetectedIssue CMET De DetectedIssueEvent klasse kan worden gebruikt om waarschuwingen en fouten te identificeren die zijn gevonden gedurende het verwerken van het bericht. Het wordt gebruikt om de business rules te identificeren waarmee de subject Act strijdig is. De DetectedIssueEvent kan worden gevuld door: de ontvanger van de Act (en vervolgens gerapporteerd in een application acknowledgement). de zender van de Act, indien deze op de hoogte is van het probleem, maar tevens een beroep doet op omstandigheden om de Act toch te laten verwerken door de ontvanger. De reden van een verzoek om ondanks een bestaand probleem (zoals aangegeven in DetectedIssueEvent) het bericht toch te verwerken is opgenomen in de DetectedIssueManagement klasse. De waarden van het DetectedIssueManagement.code attribuut zijn vastgelegd in de vocabulaire ActCode:ActDetectedIssueManagementCode. De DetectedIssueEvent klasse bevat de volgende attributen: id: een unieke identificatie van het object (optioneel). code: een code die het type probleem identificeert (bijvoorbeeld medicatie contra-indicatie, onvoldoende autorisatie voor het beantwoorden van de query ). De waarden zijn afkomstig uit de vocabulaire ActCode:ActDetectedIssueCode. Zie paragraaf voor een beschrijving van Nederlandse uitbreidingen op de internationale vocabulaire. (verplicht attribuut) text: een tekstuele omschrijving van het probleem (optioneel). value: bevat een identificatie van het specifieke probleem (bijvoorbeeld medicatie X kan niet samen worden ingenomen met medicatie Y ). (optioneel) De DetectedIssueEvent klasse bezit de volgende associaties: targetof: nul of meer DetectedIssueManagement klassen. Een object van de DetectedIssueManagement klasse geeft aan hoe met het in DetectedIssueEvent aangegeven probleem omgegaan kan worden, of omgegaan dient te worden. De DetectedIssueManagement klasse bezit de volgende attributen: Implementatiehandleiding HL7v3-28

29 moodcode: bevat EVN indien de zender deze klasse gebruikt als verzoek om een bepaald probleem te negeren; bevat DEF indien de theoretisch mogelijke overridecodes behorend bij een probleem in een applicatie acknowledgement verstuurd worden. code: Typering van het verzoek een probleem te negeren (override type, vergelijkbaar met de velden OVR-1, ERR-10 in HL7 v2.x). text: De onderliggende reden, of commentaar bij, het verzoek een probleem te negeren (override reason, override comments, vergelijkbaar met de velden OVR- 2, ERR-11, OVR-3 in HL7 v2.x) Een voorbeeldscenario: 1) Piet Patiënt heeft bij zijn apotheek, naar aanleiding van een recept van zijn huisarts, medicatie afgehaald. Het gaat om een geneesmiddel in capsulevorm, in een verpakking die genoeg capsules bevat voor drie maanden. Door een misverstand is de medicatie twee weken na het afhalen in de prullenbak beland. Piet Patiënt meldt zich in paniek bij zijn huisarts. Deze stuurt een nieuw elektronisch recept naar de apotheek. 2) De apotheek stuurt een Application Acknowledgement met een afwijzing van het recept: de patiënt heeft volgens hun gegevens nog voldoende medicatie. In het Application Acknowledgement bericht bevat de DetectedIssueEvent klasse de identificatie van het gedetecteerde probleem: DUPTHPY (The proposed therapy appears to duplicate an existing therapy). De Application Acknowledgement bevat tevens in de DetectedIssueManagement klasse (in DEF mood) een aantal mogelijke redenen waar de huisarts wellicht een beroep op kan doen om ondanks het geconstateerde probleem het recept door de apotheek te laten uitvoeren. 3) De huisarts selecteert als reden COMPRFL (Compassionate Refill), en verstuurt nogmaals het recept bericht, zij het ditmaal voorzien van een DetectedIssueEvent klasse die de identificatie van het gedetecteerde probleem bevat: DUPTHPY (The proposed therapy appears to duplicate an existing therapy). De daarmee geassocieerde klasse DetectedIssueManagement klasse (nu in EVN mood) bevat de override-reden: COMPRFL (Compassionate Refill), met als commentaar Patiënt heeft medicatie per ongeluk weggegooid. FAQ: DetectedIssueManagement vormt tevens de basis van het Noodgeval opvraagscenario van gegevens uit de ZIM. Zie de Implementatiehandleiding HL7v3 Zorg Informatie Makelaar voor een gedetaileerde beschrijving Master File/ Registry Act wrapper (MFMI_RM700700) Deze wrapper is een specialisatie van de reeds hiervoor beschreven TECA wrapper D-MIM en wordt toegepast voor Master File en Registry berichten. De inhoud van de wrapper bestaat naast de generieke inhoud die alle TECA wrappers bezitten uit een aantal ondersteunende acts die master file registraties ondersteunen. Implementatiehandleiding HL7v3-29

30 Figuur 8: Registry Act Wrapper R-MIM De RegistrationProcess act klasse vormt de kern van de master file (registry) berichten. Het bevat gegevens over het toevoegen, wijzigen of verwijderen van een element in een registry. De RegistrationProcess klasse bezit de volgende attributen: classcode: "REG", Registered (verplicht) moodcode: De mood van de RegistrationProcess klasse. Bevat RQO in berichten waar een register om (een update van een) registratie verzocht wordt, bevat EVN in berichten waarin het register mededelingen over de geregistreerde gegevens verzendt. (verplicht) id: Een unieke identificatie van het registratieproces. Deze identificatie (bestaande uit een OID en een volgnummer) is uniek en kan nooit nogmaals worden uitgedeeld, noch door dezelfde applicatie, noch door een andere applicatie. De waarde van dit attribuut kan gelijk zijn met de identificatie van het te registreren object. (optioneel attribuut) code: Identificeert het type (of gegevenssoort) van het element dat geregistreerd wordt. (voor Nederland verplicht attribuut) Indien het geregistreerde element een Act is (zoals bij het gebruik van verwijsindexen) dan is het van toepassing zijnde vocabulaire domein ActRegistryCode:x_DataDomainCodeNL (DataDomainCode = gegevenssoort). Deze Nederlandspecifieke vocabulaire wordt in het vocabulaire-document nader omschreven. statuscode: De (nieuwe) status van de registratie. Deze status geeft aan of de registratie van een element geldig is of niet. Het gaat dus niet om de status van het geregistreerde element, maar om de status van de registratie zelf. Als waarden kunnen o.a. active (geldig, de default waarde) en nullified (vervallen) voorkomen. (verplicht attribuut) effectivetime: Geeft een datum/tijdsinterval aan waarbinnen de registratie de status 'active' (geldig) heeft (heeft gehad/zal hebben). Veelal zal alleen de startdatum van de geldigheidsperiode worden gevuld. Merk op dat dit de status van de registratie betreft, en niet de status van het geregistreerde element. (verplicht attribuut) Implementatiehandleiding HL7v3-30

31 De RegistrationProcess klasse heeft de volgende associaties/participaties: Subject1: Indien de te registreren elementen bestaan uit een Rol klasse (bijv. Patiënt of Zorgverlener) dan wordt deze middels Subject1 aan de RegistrationProcess klasse gekoppeld. De te registreren rollen vormen de eigenlijke payload van het bericht. Of Subject1, of Subject2 mag in een bericht gebruikt worden, maar niet beide. Subject2: Indien de te registreren elementen worden gevormd door een Act klasse (bijv. in het geval van de Verwijsindex) dan worden deze middels Subject2 aan de RegistrationProcess klasse gekoppeld. De te registreren acts vormen de eigenlijke payload van het bericht. Of Subject1, of Subject2 mag in een bericht gebruikt worden, maar niet beide. De controlactprocess klasse is geassocieerd met één of meer registrationprocess klassen. Elk van deze registrationprocess klassen kan een associatie hebben met nul of meer geregistreerde/te registreren elementen. In vrijwel alle gevallen wordt een registrationprocess klasse geassocieerd met precies één geregistreerd/te registreren element. Dit vanwege het feit dat de regsitratiegegevens (bijv. statuscode, effectivetime) van de geregistreerde/te registreren elementen onderling verschillen. Message Types: In de HMD geassocieerd met bovenstaande R-MIM zijn twee message types gedefinieerd. Het te gebruiken message type hangt af van het type register. In die gevallen waar het register gegevens bevat aangaande rollen (bijv. Patiënt, Zorgverlener), dient gebruik te worden gemaakt van MFMI_MT Indien het register Acts bevat (bijv. de verwijsindex), dient gebruik te worden gemaakt van MFMI_MT De Master File/ Registry Act wrapper (MFMI_RM700700) heeft de volgende afgeleide Message Types: Master File / Registry Control Act, Act Target MFMI_MT Master File / Registry Control Act, Role Subject MFMI_MT Queries, Continuations en Responses (TECA) De TECA wrapper vormt tezamen met de payload de inhoud van het bericht. De TECA wrapper heeft een structuur die op hoofdlijnen voor alle HL7 berichten gelijk is, en die gegevens bevat over de reden waarom dit bericht verstuurd wordt; de verantwoordelijke persoon voor de inhoud van het bericht, de gebeurtenis die het bericht heeft doen ontstaan, het tijdstip waarop die gebeurtenis optrad, etc. Deze paragraaf beschrijft een aantal Querygerelateerde specialisaties van de TECA wrapper. Bij de afhandeling van queries wordt een belangrijke rol gespeeld door een drietal querygerelateerde klassen: QueryByParameter, QueryAck en QueryContinuation. In dit hoofdstuk worden de volgende definities gehanteerd: Vraag (of: Query): het bericht waarin de vraagparameters zijn opgenomen. Antwoordbericht: het bericht dat naar aanleiding van een vraag (een gedeelte van) de gevonden informatie bevat; en dat aan het vragende systeem wordt verstuurd. Een antwoordbericht bevat nul of meer Zoekresultaten. Antwoordbatch: een batch (zie paragraaf 2.3) aangemaakt naar aanleiding van een Vraag. De Antwoordbatch bevat nul of meer Antwoordberichten. Zoekresultaat: een bij een vraag behorend elementair antwoord. Een antwoordbericht kan nul of meer Zoekresultaten bevatten. Implementatiehandleiding HL7v3-31

32 Vervolgvraag (of: Query Continuation): een bericht waarin om een vervolgset (nog niet eerder opgeleverde) zoekresultaten wordt gevraagd. Een voorbeeld: een vraagbericht over Röntgenverslagen bevat parameters die de patiënt Pietersen identificeren en de tijdsperiode vanaf 1 Januari Het ontvangende Radiologie systeem vindt vierentwintig verslagen gedurende de gevraagde periode. Ieder verslag is een zoekresultaat. Het Radiologiesysteem kan deze of samenvoegen in één antwoordbericht, of als (het theoretisch andere uiterste) vierentwintig berichten sturen met elk één zoekresultaat. Andere combinaties van antwoordberichten/ zoekresultaten zijn eveneens mogelijk, zoals vier berichten met elk acht zoekresultaten, of vijf berichten met respectievelijk tien, drie, zes, één, en vier zoekresultaten. Merk op dat de structuur van een antwoordbericht het samenvoegen van zoekresultaten in één bericht soms niet toestaat. In dat geval dienen alle zoekresultaten als losse antwoordberichten verstuurd te worden, mogelijk gezamenlijk verpakt in een Batch wrapper indien dit in de vraag aangegeven was. Figuur 9: Query/Response interacties, eenvoudig scenario In het bovenstaande, eenvoudige voorbeeld query scenario, zijn de volgende interacties opgenomen: Een query bericht. Het bericht is in een HL7 Domein gedefinieerd, en heeft een daar gedefinieerde interactie-identificatie. Het bericht maakt gebruik van de Query By Parameter Specification TECA wrapper (QUQI_RM020000, zie paragraaf 2.5.1). Het antwoord op deze query, bestaande uit één bericht. Het bericht is in een HL7 Domein gedefinieerd, en heeft tevens een daar gedefinieerde interactie identificatie. Het bericht maakt gebruik van de Query Response TECA wrapper (QUQI_RM120000, zie paragraaf ) of de Master File / Registry Query Response TECA wrapper (MFMI_RM700710, zie paragraaf 2.5.4). De gebruikte wrapper is afhankelijk van het feit of het al dan niet een vraag aan een Registry betreft. FAQ: Indien er geen zoekresultaten bij een vraag opgeleverd kunnen worden, omdat bijvoorbeeld de in de vraag geleverde parameters niet tot een zoekresultaat leiden, dan bevat het antwoordbericht nul opgeleverde antwoorden en het QueryAck.responseCode de waarde NF (Nothing Found, no errors). Het vinden van nul antwoorden is op zichzelf geen fout. FAQ: Zoals beschreven in paragraaf kan de zender van de vraag de syntactische verwerkbaarheid laten bevestigen door middel van een Accept Acknowledgement. Voor de Nederlandse infrastructuur is vastgelegd dat de waarde van het Message.acceptAckCode in het vraagbericht altijd NE (never) moet zijn. Dit houdt in dat ontvangende systeem geen accept Implementatiehandleiding HL7v3-32

33 acknowledgement mag versturen, ook niet als er sytactische fouten in het vraagbericht zitten. De syntactische fouten moeten om deze reden worden opgenomen (in de Transmission Wrapper) van het antwoordbericht. Figuur 10: Query/Response interacties, complex scenario In die situaties waarin mogelijk een groot aantal zoekresultaten op de vraag teruggeleverd kunnen worden, kan het bovenstaande scenario van toepassing zijn. In het scenario zijn de volgende interacties opgenomen: Een query bericht. Het bericht is in een HL7 Domein gedefinieerd, en heeft een daar gedefinieerde interactie-identificatie. Het bericht bevat een indicatie dat de vragensteller een bepaald maximum aan zoekresultaten wil ontvangen. Het bericht maakt gebruik van de Query By Parameter Specification TECA wrapper (QUQI_RM020000, zie paragraaf 2.5.1). Het eerste antwoord bericht op de query. De structuur van het antwoord bericht is in een HL7 Domein gedefinieerd, en heeft tevens een daar gedefinieerde interactie-identificatie. Het antwoord bericht bevat maximaal het aantal zoekresultaten zoals opgegeven in het query bericht. Indien er nog overige zoekresultaten op de query bestaan wordt de hoeveelheid nog beschikbare zoekresultaten (d.w.z. nog niet geleverde zoekresultaten) in het antwoord bericht meegestuurd. Het antwoord bericht maakt gebruik van de Query Response TECA wrapper (QUQI_RM120000, zie paragraaf 2.5.3) of de Master File / Registry Query Response TECA wrapper (MFMI_RM700710, zie paragraaf 2.5.4). De gebruikte Implementatiehandleiding HL7v3-33

34 wrapper is afhankelijk van het feit of het al dan niet een vraag aan een Registry betreft. De volgende twee interacties kunnen vervolgens paarsgewijs meerdere keren voorkomen, tot op het moment waarop het antwoord bericht aangeeft dat er geen verdere zoekresultaten zijn: Een query continuation bericht. Dit is een vervolgvraag op de oorspronkelijke query, ter verkrijging van een volgende set zoekresultaten. Dit bericht bestaat alleen uit een wrapper en wordt om deze reden niet in een HL7 domein gedefinieerd. De interactie-identificatie is QUQI_IN000003; zie paragraaf voor details. Het bericht bevat een verwijzing naar de unieke identificatie van de oorspronkelijk query. Een (vervolg) antwoord bericht op de query. De structuur en interactieidentificatie van dit antwoord bericht zijn gelijk aan die van het eerste antwoord bericht. Indien de aanvrager het bovenstaande iteratieve proces wenst af te breken, hoewel er op dat moment nog verdere zoekresultaten beschikbaar zijn, dan dient de verdere afhandeling van de query worden afgebroken door middel van de volgende interactie: Een query cancel bericht. Dit bericht bestaat alleen uit een wrapper en wordt om deze reden niet in een HL7 domein gedefinieerd. De interactie identificatie is QUQI_IN000003; zie paragraaf voor details. Het bericht bevat een verwijzing naar de unieke identificatie van de oorspronkelijk query Query By Parameter Specification TECA (QUQI_RM021000) Deze wrapper is een specialisatie van de reeds hiervoor beschreven TECA wrapper D-MIM en wordt toegepast om de parameters van een query van het QBP type van de vragende naar de beantwoordende applicatie te versturen. Figuur 11: Query by Parameter Trigger Event Control Act R-MIM Implementatiehandleiding HL7v3-34

35 Opmerking: de bovenstaande figuur is bewust onvolledig. De getoonde klassen maken deel uit van een specialisatie van de generieke TECA wrapper. Naast de hieronder beschreven artifacts zijn tevens de algemene TECA wrapper beschrijvingen in paragraaf van toepassing. QueryByParameter wordt gebruikt voor queryspecificaties. Onderstaand volgt een beschrijving en het gebruik van de attributen van de QueryByParameter klasse: queryid: de query-initiërende applicatie kan dit attribuut gebruiken om de query op unieke wijze te identificeren. De waarde van dit attribuut wordt in het antwoord teruggeleverd, zodat de antwoordberichten kunnen worden gerelateerd aan de vraag. Indien gebruik wordt gemaakt van herhaalde queries waarbij telkens een gedeelte van de antwoorden wordt opgeleverd, kan de queryinitiërende applicatie dezelfde waarde gebruiken als de vervolgqueries. Dit attribuut is in de Nederlandse situatie verplicht statuscode: Bevat de (nieuwe) status van de query. De te gebruiken waarden in dit attribuut zijn gedefinieerd in de QueryEventStatus vocabulaire. Als de initiële query wordt gestuurd, heeft de statuscode de waarde executing. (verplicht attribuut) modifycode: Geeft aan of de subscription (indien het query bericht als onderdeel van een publish/subscribe mechanisme gebruikt wordt) nieuw is ( N ) dan wel gewijzigd wordt ( M ). De waarden van dit attribuut zijn afkomstig uit de vocabulaire ModifyIndicator. responseelementgroupid: In Nederland niet gebruiken. responsemodalitycode: definieert de timing en groepering van de antwoordberichten. De te gebruiken waarden zijn gedefinieerd in de ResponseModality vocabulaire. De standaard te gebruiken waarde is R (Realtime): het antwoordbericht wordt als individueel bericht verstuurd op het eerst mogelijke moment nadat een zoekresultaat beschikbaar is. Een mogelijk andere waarde is B (Batch) waarbij de query-antwoordberichten worden verpakt in één enkele batch wrapper. De waarde T (Bolus) mag in Nederland niet worden toegepast. responseprioritycode: geeft het tijdsframe aan waarbinnen het antwoord wordt verwacht, zoals I (Immediate) voor directe beantwoording en D (Deferred) voor een antwoord op een later moment. De standaard waarde is I (Immediate). initialquantity: definieert de maximum omvang van het antwoord dat door de vragende applicatie kan worden geaccepteerd. Indien dit attribuut bijvoorbeeld de waarde twintig bevat dan zal of 1) het antwoordbericht maximaal twintig zoekresultaten bevatten, of 2) maximaal twintig antwoordberichten opleveren met elk één zoekresultaat, of 3) of een andere combinatie van antwoordberichten/ zoekresultaten opleveren die maximaal twintig zoekresultaten bevat. (optioneel attribuut). initialquantitycode: definieert de units die zijn geassocieerd met de omvang zoals gedefinieerd in initialquantity. Dit attribuut bevat MC (Matching Classes) voor een aantal zoekresultaten. De te gebruiken waarden zijn gedefinieerd in de QueryRequestLimit vocabulaire. (optioneel, echter verplicht indien initialquantity een waarde bevat). Een zoekresultaat wordt gekenmerkt door een bepaalde belangrijke klasse. In patiënt-georienteerde queries is dat de patiënt, in medicatieberichten een medicatie-gerelateerde act. De hoeveelheid zoekresultaten wordt door de aanwezigheid van deze klassen bepaald. executionanddeliverytime: specificeert het tijdstip waarop het antwoord moet worden afgeleverd; alleen te gebruiken indien responseprioritycode D -Deffered is (optioneel). Dit attribuut bevat meestal geen waarde, het wordt o.a. gebruikt Implementatiehandleiding HL7v3-35

36 om aan te geven dat men 4 uur s morgens een antwoord verwacht. De vraag wordt pas op dat tijdstip uitgevoerd, en het antwoord wordt daarna geleverd. De parameters die relevant zijn voor de inhoudelijke Query kunnen worden doorgegeven in de ParameterItem klasse. Voor alle gebruikte parameters worden dezelfde attributen gebruikt waarvan hieronder het gebruik wordt beschreven. value: bevat de waarde van de parameter waaraan de antwoorden in het query response bericht moeten voldoen. (verplicht attribuut) semanticstext: biedt een unieke tekstuele identificatie voor een element binnen een gespecificeerde query response structuur. Deze waarden zijn voorgedefinieerd in de berichtstructuur. (in Nederland verplicht) Het SortControl element (optioneel) bevat een specificatie van de gewenste sorteervolgorde van de zoekresultaten. Merk op dat de zoekresultaten alleen in de juiste volgorde bij de vraagsteller aankomen indien de volgordelijkheid van de antwoordberichten gegarandeerd is, bijvoorbeeld door het onderliggende transportprotocol. Onderstaand volgt een beschrijving en het gebruik van de attributen van de SortControl klasse. sequencenumber: specificeert het volgnummer van het sorteerelement in het geval dat gebruik wordt gemaakt van meerdere sorteringen (optioneel). elementname: identificeert een element uit de structuur van de query response (d.w.z. een klasse.attribuut identificatie uit de R-MIM van het response bericht) waarop gesorteerd moet gaan worden. Het bevat bijvoorbeeld SupplyEvent.activityTime als er gesorteerd moet worden op de verstrekkingsdatum van medicatie. (verplicht) directioncode: specificeert de volgorde van de sortering. De te gebruiken waarden zijn A (ascending) of D (descending) of N (None). (optioneel attribuut) Message Types: In de HMD geassocieerd met bovenstaande R-MIM is één message type gedefinieerd. De Query By Parameter TECA R-MIM (QUQI_RM021000) heeft het volgende afgeleide Message Type: Query Control Act Request : Query By Parameter QUQI_MT Query Continuation/Cancel Control Act (QUQI_RM000001) Deze wrapper is een specialisatie van de reeds hiervoor beschreven TECA wrapper D-MIM en wordt toegepast om vervolgvragen op een query van het QBP type te versturen. Implementatiehandleiding HL7v3-36

37 Figuur 12: Query Continuation/Cancel control act Opmerking: de bovenstaande figuur is bewust onvolledig. De getoonde klassen maken deel uit van een specialisatie van de generieke TECA wrapper. Naast de hieronder beschreven artifacts zijn tevens de algemene TECA wrapper beschrijvingen in paragraaf van toepassing. Het model voor Query Continuation/Cancel berichten kan worden toegepast in alle HL7 domeinen en als opvolging op alle query typen. De interactie is voorgedefinieerd in de HL7 standaard als QUQI_IN Deze interactie wordt gebruikt voor alle vervolgqueries, ongeacht de interactie ID van de initiele query. De QueryContinuation klasse heeftd e volgende attributen: queryid: (verplicht) identificeert de originele query bij het versturen van vervolg queries waarbij telkens een gedeelte van de antwoorden wordt opgeleverd. De waarde van dit attribuut wordt in het antwoord teruggeleverd, zodat de antwoordberichten kunnen worden gerelateerd aan de vraag. Dit attribuut is in de Nederlandse situatie verplicht. statuscode: Bevat de (nieuwe) status van de query. De te gebruiken waarden in dit attribuut zijn gedefinieerd in de QueryEventStatus vocabulaire. In vervolgvragen heeft de statuscode de waarde waitcontinuedqueryresponse, in vragen waarvan de vervolgvraagcyclus afgebroken wordt de waarde aborted. (verplicht attribuut) startresultnumber: (gebruik niet toegestaan). De ontvangende applicatie bepaalt de relevante offset binnen de volledige set zoekresultaten aan de hand van de queryid, en aan de hand van het aantal reeds opgeleverde zoekresultaten gerelateerd aan die queryid. continuationquantity: (gebruik niet toegestaan) Bevat de maximum omvang van het antwoord dat door de vragende applicatie kan worden geaccepteerd. Binnen de AORTA infrastructuur wordt de maximum waarde die in de initiële vraag is opgegeven gebruikt. Implementatiehandleiding HL7v3-37

38 FAQ: Indien een duplicaatvraag (een vraagbericht met een gelijkluidend Message.id als een voorafgaand vraagbericht) ontvangen wordt, dan dient de ontvanger dit te beantwoorden alsof de oorspronkelijke vraag nooit beantwoord was, en dit antwoordbericht van hetzelfde Message.id te voorzien als het eerder verstuurde antwoordbericht. Duplicaat Vraagberichten dienen te worden beantwoord met Duplicaat Antwoordberichten. Message Types: In de HMD geassocieerd met bovenstaande R-MIM is één message type gedefinieerd. De Query Continuation/Cancel Control Act R-MIM (QUQI_RM000001) heeft het volgende afgeleide Message Type: Query Control Act Request Continue / Cancel QUQI_MT Interactie: General Query Activate Query Continue (QUQI_IN000003) Trigger Event Query General Activate Query Continuation QUQI_TE Transmission Wrapper Send Message Payload MCCI_MT Control Act Wrapper Query Control Act Request Continue / QUQI_MT Cancel Message Type n.v.t. (geen payload) n.v.t Query Response Trigger Event Control Act (QUQI_RM120000) Deze wrapper is een specialisatie van de reeds hiervoor beschreven TECA wrapper en wordt toegepast in berichten die worden verstuurd als antwoord op een query. De payload bestaat zowel uit een generieke act (die het eigenlijke antwoord bevat) als uit gegevens waaruit blijkt of en hoe de query kon worden beantwoord. Implementatiehandleiding HL7v3-38

39 Figuur 13: Query Response/Acknowledgement Wrapper R-MIM Opmerking: de bovenstaande figuur is bewust onvolledig. De getoonde klassen maken deel uit van een specialisatie van de generieke TECA wrapper. Naast de hieronder beschreven artifacts zijn tevens de algemene TECA wrapper beschrijvingen in paragraaf van toepassing. QueryAck wordt gebruikt om gegevens aangaande het antwoord op de query aan de vragensteller te versturen. Onderstaand volgt een beschrijving en het gebruik van de attributen van de QueryAck klasse. queryid: (verplicht) de query-beantwoordende applicatie kan dit attribuut gebruiken om de query op unieke wijze te identificeren. De waarde van dit attribuut is gelijk aan de waarde van het corresponderende attribuut in de query. De aanvrager kan hierdoor de antwoordberichten relateren aan de vraag. queryresponsecode: bevat een statusmelding betreffende het antwoord. Waarden zijn onder andere OK (Data found), NF (No data found, No errors) en AE (Applicatie probleem, beantwoording afgebroken). De te gebruiken waarden zijn gedefinieerd in de QueryStatus vocabulaire. (verplicht attribuut) resulttotalquantity: Bevat de totale hoeveelheid zoekresultaten die geleverd (kunnen) worden als antwoord op de vraag. Indien in een reeks antwoordberichten de totale hoeveelheid zoekresultaten (nog) onbekend is, kan gebruik gemaakt worden van de null-waarde Not Available om aan te geven dat de waarde op dit moment- onbekend is. <resulttotalquantity nullflavor="nav"> Implementatiehandleiding HL7v3-39

40 resultcurrentquantity: Bevat de hoeveelheid antwoorden die opgenomen zijn in het huidige bericht. Een antwoordbericht kan meerdere antwoorden bevatten. (optioneel) resultremainingquantity: Bevat de hoeveelheid zoekresultaten die (nog) niet verstuurd zijn aan de aanvrager. (dit attribuut is in Nederland verplicht) Indien in een reeks antwoordberichten de hoeveelheid nog niet verstuurde zoekresultaten (nog) onbekend is, kan gebruik gemaakt worden van de nullwaarde Not Available om aan te geven dat de waarde op dit momentonbekend is. De null-waarde Not Available mag niet worden geïnterpreteerd als zijnde 0. <resultremainingquantity nullflavor="nav"> ControlActProcess bezit tevens de volgende associatie: Subject (Act): Associeert de controlactprocess klasse met één of meer klassen waarin de payload met het antwoord op de query opgenomen is. De Subject associatie bevat een tweetal attributen: contextcontrolcode en contextconductionindicator. Het attribuut contextconductionindicator bevat altijd de waarde false wat aangeeft dat de diverse objecten die een associatie bezitten met de ControlActProcess klasse niet worden overgeërfd door de klassen in de payload. Message Types: In de HMD geassocieerd met bovenstaande R-MIM is één message type gedefinieerd. De Query Response Trigger Event Control Act R-MIM (QUQI_RM120000) heeft het volgende afgeleide Message Type: Query Control Act Response / Acknowledgement QUQI_MT Master File / Registry Query Response (MFMI_RM700710) Deze wrapper is een specialisatie van de reeds hiervoor beschreven TECA wrapper D-MIM en wordt toegepast in berichten die worden verstuurd als antwoord op een Registry query (bijvoorbeeld antwoorden op vragen over registraties aan een MPIpersoonsregister, ZorgaanbiederGids, en Verwijsindex). De payload bestaat zowel uit een generieke act (die de eigenlijke zoekresultaten bevat) als uit gegevens waaruit blijkt of en hoe de query kon worden beantwoord. Implementatiehandleiding HL7v3-40

41 Figuur 14: Master File / Registry Query Response Wrapper R-MIM Opmerking: de bovenstaande figuur is bewust onvolledig. De getoonde klassen maken deel uit van een specialisatie van de generieke TECA wrapper. Naast de hieronder beschreven artifacts zijn tevens de algemene TECA wrapper beschrijvingen in paragraaf van toepassing. Deze wrapper bestaat uit een combinatie van de Master File / Registry Act TECA wrapper (zie paragraaf voor een gedetailleerde beschrijving van de daarin aanwezige klassen) en de QueryAck/QueryByParameter klassen (zie paragraaf voor een gedetailleerde beschrijving van deze klassen). Message Types: In de HMD geassocieerd met bovenstaande R-MIM zijn twee message types gedefinieerd. Het te gebruiken message type hangt af van het type register. In die gevallen waar het register gegevens bevat aangaande rollen (bijv. Patiënt, Zorgverlener), dient gebruik te worden gemaakt van MFMI_MT Indien het register Acts bevat (bijv. de verwijsindex), dient gebruik te worden gemaakt van MFMI_MT De Query Master File / Registry Query Response R-MIM (MFMI_RM700710) heeft het volgende afgeleide Message Types: Master File / Registry Query Response Control Act, Act Target MFMI_MT Master File / Registry Query Response Control Act, Role Subject MFMI_MT Implementatiehandleiding HL7v3-41

42 2.6 Voorbeeld Message Transmission wrapper In deze paragraaf wordt als illustratie van de theoretisch-georiënteerde beschrijving in een eerdere paragraaf een volledig uitgewerkte Message Transmission Wrapper weergegeven. De informatie in deze paragraaf is niet normatief en dient uitsluitend ter toelichting van het gebruik van de standaard. Voor informatie over het gebruik van OIDs als identificatiemechanisme, en het gebruik van UZI-nummers (unieke zorgverlener/zorgtoepassing identificatie) wordt verwezen naar paragraaf Het voorbeeldbericht betreft een medicatievoorschrift en wordt op 17 April 2004 verstuurd vanuit het ZIS systeem in het St. Jozef ziekenhuis naar de ZIM (Zorg Informatie Makelaar, bevat o.a. de verwijsindex). <?xml version="1.0" encoding="utf-8"?> <!-- example prescription interactie NL--> <PORX_IN932000NL xmlns="urn:hl7-org:v3" xmlns:xsi=" > <!-- Transport Wrapper --> <id extension="34234" root=" "/> <creationtime value=" "/> <versioncode code="nictized2005-okt"/> <interactionid extension="porx_in932000nl" root=" "/> <profileid root=" " extension="608"/> <processingcode code="p"/> <processingmodecode code="t"/> <acceptackcode code="al"/> <!-- Control Act Wrapper en payload worden hier niet getoond --> <receiver> <telecom use="wp" value="tel: "/> <device> <!-- receiving application, ID of receiving system --> <id extension="1" root=" "/> <name use="l"> <given>zim Applicatie</given> </name> <agencyfor classcode="agnt"> <representedorganization classcode="org" determinercode="instance"> <id extension="2" root=" "/> <name use="l"> <given>ministerie van VWS</given> </name> </representedorganization> </agencyfor> </device> </receiver> <sender> <telecom use="wp" value="tel: "/> <device> <!-- sending application, ID of sending system --> <id extension="922" root=" "/> <name use="l"> <given>abc-zis St.Josef Ziekenhuis</given> </name> <agencyfor classcode="agnt"> <representedorganization classcode="org" determinercode="instance"> Implementatiehandleiding HL7v3-42

43 <id extension=" " root=" "/> <name use="l"> <given>st.josef Ziekenhuis</given> </name> </representedorganization> </agencyfor> </device> </sender> </PORX_IN932000NL> 2.7 Voorbeeld Trigger Event Control Act In deze paragraaf wordt als illustratie van de theoretisch-georienteerde beschrijving in een eerdere paragraaf een voorbeeld getoond van een Trigger Event Control Act. De informatie in deze paragraaf is niet normatief en dient uitsluitend ter toelichting van het gebruik van de standaard. De getoonde Trigger Event Control Act is de standaard TECA wrapper gebruikt voor event-triggered berichten, MCAI_RM In het getoonde voorbeeld treedt een medewerker met UZI nummer op als verzender (author) van het bericht. De overseer bevat de identificatie van de verantwoordelijke (mandaterende) zorgverlener (UZI en Rolcode ). Van beide personen is tevens de URA opgenomen (URA ) als identificatie van de organisatie waarbinnen zij een rol spelen. <!-- Control Act Wrapper --> <controlactprocess moodcode="evn"> <id extension="746534" root=" "/> <code code="porx_te999999" codesystem=" "/> <effectivetime value=" "/> <authororperformer typecode="aut"> <participant> <AssignedPerson> <id extension=" " root=" " assigningauthorityname="uzi"/> <Organization> <id extension=" " root=" "/> </Organization> </AssignedPerson> </participant> </authororperformer> <overseer typecode="resp"> <participant> <AssignedPerson> <id extension=" " root=" " assigningauthorityname="uzi"/> <code code="17.000" codesystem=" " codesystemname="rolecode" displayname="apotheker"/> <Organization> <id extension=" " root=" "/> </Organization> </AssignedPerson> </participant> </overseer> <subject> <! de payload wordt hier niet getoond --> </subject> </controlactprocess> Implementatiehandleiding HL7v3-43

44 2.8 Voorbeeld Accept Acknowledgement In deze paragraaf worden als illustratie van de theoretisch-georienteerde beschrijving in paragraaf enkele voorbeelden getoond van een accept-level acknowledgement bericht. Het eerste voorbeeldbericht bevat de foutmelding NS200 (ontvangst van een niet ondersteunde interactie). <MCCI_IN xmlns="urn:hl7-org:v3" xmlns:xsi=" <!-- Transport Wrapper --> <id extension="34234" root=" "/> <creationtime value=" "/> <versioncode code="nictized2005-okt"/> <interactionid extension="mcci_in000002" root=" "/> <profileid root=" " extension="608"/> <processingcode code="p"/> <processingmodecode code="t"/> <!-- accept acks dienen zelf nooit ge-acked te worden --> <acceptackcode code="ne"/> <!-- CE = accept/commit-level error --> <acknowledgement typecode="ce"> <acknowledgementdetail typecode="e"> <!-- Zie codetabel in NL implementatiehandleiding infra domeinen --> <code code="ns200" displayname="unsupported InteractionID" codesystem=" "/> </acknowledgementdetail> <targetmessage> <!-- id van het bericht waar deze ACK bijhoort --> <id extension=" " root=" "/> </targetmessage> </acknowledgement> <receiver> <device> <id extension="956" root=" "/> </device> </receiver> <sender> <device> <!-- sending application, ID of sending system --> <id extension="1" root=" "/> </device> </sender> </MCCI_IN000002> Het volgende berichtfragment bevat twee foutmeldingen en een waarschuwing. <!-- CE = accept/commit-level error --> <acknowledgement typecode="ce"> <acknowledgementdetail type="e"> <code code="syn101" codesystem=" " displayname="required Attribute Missing"/> <location>message/creationtime</location> </acknowledgementdetail> <acknowledgementdetail type="e"> <code code="syn103" codesystem=" " displayname="value not in code system"/> <location>patient/person/administrativegender</location> </acknowledgementdetail> Implementatiehandleiding HL7v3-44

45 <acknowledgementdetail type="w"> <code code="syn101" codesystem=" " displayname="required Attribute Missing"/> <location>message/versioncode</location> </acknowledgementdetail> <targetmessage> <!-- id van het bericht waar deze ACK bijhoort --> <id extension=" " root=" "/> </targetmessage> </acknowledgement> Het volgende berichtfragment bevat geen opgaaf van de reden van de foutmelding. Het wordt overigens aangeraden altijd tenminste één reden te versturen. <!-- CE = accept/commit-level error --> <acknowledgement typecode="ce"> <targetmessage> <!-- id van het bericht waar deze ACK bijhoort --> <id extension=" " root=" "/> </targetmessage> </acknowledgement> Het laatste berichtfragment geeft aan dat er geen fouten gevonden zijn. <!-- CA = accept/commit-accept --> <acknowledgement typecode="ca"> <targetmessage> <!-- id van het bericht waar deze ACK bijhoort --> <id extension=" " root=" "/> </targetmessage> </acknowledgement> 2.9 Voorbeeld Application Acknowledgement In deze paragraaf worden als illustratie van de theoretisch-georienteerde beschrijving beschrijving in paragraaf enkele voorbeelden getoond van een applicatie-level acknowledgement bericht. Een Application Acknowledgement kan foutmeldingen bevatten over syntactische/communicatie issues (vergelijkbaar met de foutmeldingen zoals aanwezig in een Accept Acknowledgement, zie paragraaf 2.8) en/of foutmeldingen over businessrules. Het volgende berichtfragment bevat twee syntactische foutmeldingen. <!-- AE = applicatie -level error --> <acknowledgement typecode="ae"> <acknowledgementdetail type="e"> <code code="syn101" codesystem=" " displayname="required Attribute Missing"/> <location>message/creationtime</location> </acknowledgementdetail> <acknowledgementdetail type="e"> <code code="syn103" codesystem=" " displayname="value not in code system"/> <location>patient/person/administrativegender</location> </acknowledgementdetail> Implementatiehandleiding HL7v3-45

46 <targetmessage> <!-- id van het bericht waar deze ACK bijhoort --> <id extension=" " root=" "/> </targetmessage> </acknowledgement> Het volgende berichtfragment bevat één inhoudelijke foutmelding. <!-- AE = applicatie -level error --> <acknowledgement typecode="ae"> <targetmessage> <!-- id van het bericht waar deze ACK bijhoort --> <id extension=" " root=" "/> </targetmessage> </acknowledgement> <!- gedeelte van het bericht wordt niet getoond - - > <ControlActProcess moodcode="evn"> <!- gedeelte van het bericht wordt niet getoond - - > <reason> <justifyingdetectedissueevent> <code code="key204" codesystem=" " displayname="unknown Key Identifier"/> <text mediatype="text/plain">patient onbekend</text> </justifyingdetectedissueevent> </reason> Het volgende berichtfragment bevat één syntactische foutmelding, en één inhoudelijke foutmelding. <!-- AE = applicatie -level error --> <acknowledgement typecode="ae"> <acknowledgementdetail type="e"> <code code="syn103" codesystem=" " displayname="value not in code system"/> <location>patient/person/administrativegender</location> </acknowledgementdetail> <targetmessage> <!-- id van het bericht waar deze ACK bijhoort --> <id extension=" " root=" "/> </targetmessage> </acknowledgement> <!- gedeelte van het bericht wordt niet getoond - - > <ControlActProcess moodcode="evn"> <!- gedeelte van het bericht wordt niet getoond - - > <reason> <justifyingdetectedissueevent> <code code="key204" codesystem=" " displayname="unknown Key Identifier"/> <text mediatype="text/plain">patient onbekend</text> </justifyingdetectedissueevent> </reason> Het volgende berichtfragment bevat geen opgaaf van de reden van de foutmelding. Het wordt overigens aangeraden altijd tenminste één reden te versturen. <!-- AE = applicatie -level error --> <acknowledgement typecode="ae"> <targetmessage> <!-- id van het bericht waar deze ACK bijhoort --> <id extension=" " root=" "/> Implementatiehandleiding HL7v3-46

47 </targetmessage> </acknowledgement> Implementatiehandleiding HL7v3-47

48 3 Identificatiemechanismen en Vocabulaires 3.1 Identificatiemechanisme Standaardiseren van gegevensuitwisseling betekent enerzijds het afspreken van een berichtstructuur (grammatica), maar het betekent ook dat dezelfde aanduiding voor objecten en concepten gehanteerd moet worden. Het heeft immers weinig zin om precies af te spreken hoe (qua formaat en betekenis) een patiënt wordt aangeduid, als de identificatie van die patiënt vervolgens niet wordt begrepen door de ontvangende partij. Binnen een instelling is het meestal wel duidelijk welke stamtabel bedoeld wordt voor identificatie en codering. Als een opname binnen een ziekenhuis wordt uitgewisseld, dan weten alle ontvangers dat de opnamenummers degene zijn die zijn uitgegeven door het ZIS. Als een arts wordt geïdentificeerd, dan zal bekend zijn of dit gebeurd met lokale nummers óf eventueel met landelijke VEKTIS nummers. Van laboratoriumbepalingen zal bijv. bekend zijn dat de onderzoeken worden aangeduid met lokaal gedefinieerde codes. Dit geldt zeer waarschijnlijk niet in een transmuraal geïntegreerd zorgnetwerk, waar zender en ontvanger elkaars context niet per definitie kennen. In zo n setting kunnen er namelijk geen aannames meer gedaan worden over de aard van de gebruikte identificatie over codering. Die moet dus expliciet worden doorgegeven. Een tweetal voorbeelden: Regionale gegevensuitwisseling ziekenhuizen: Er worden kruistabellen bijgehouden van de nummers van een patiënt bij verschillende ziekenhuizen (MPI functie). Patiëntnummer wordt (bijv. bij onderlinge dienstverlening) verzonden van ziekenhuis A naar B. Bedoelt ziekenhuis A nu een eigen nummer of heeft het een nummer van ziekenhuis B gebruikt? Landelijke aanvraag van labonderzoeken: Een ziekenhuis stuurt een aanvraag voor onderzoek B345 naar een landelijk opererend laboratorium. Bedoelt de aanvrager nu een eigen code, een code uit de specifieke tabel van het laboratorium of een algemene code? Het eerste voorbeeld zal na invoering van het BSN niet (meer) spelen, omdat patiënten dan landelijk uniek identificeerbaar zijn. Maar hetzelfde probleem speelt ook bij de identificatie van bijvoorbeeld medicatieverstrekkingen of andere brongegevens in het (landelijk) EPD. Het blijft dus nodig om identifiers en codes uniek aan te duiden. Er is overigens vaak verwarring over het onderscheid tussen de termen identifier (ID) en code. De kreten worden soms door elkaar gebruikt, terwijl hun betekenis fundamenteel verschilt: Implementatiehandleiding HL7v3-48

49 Een ID (identifier) duidt een specifiek object aan: een bepaalde patiënt, een ziekenhuis, een arts, een labaanvraag, een röntgenfoto, een medicatieverstrekking. Kortom, iets of iemand waarvan er maar één is en waar je als het ware een volgnummer aan kunt hangen. Een code duidt een generiek concept aan: een soort patiënt, een type zorginstelling, een artstype, een soort labonderzoek, een medicatietype. Hier gaat het niet om één object, maar om een categorie objecten die bepaalde kenmerken met elkaar gemeen hebben. Merk op dat als men het dus heeft over de artscode van Dr. Jansen, dit feitelijk onjuist is. Het gaat dan immers om de identificatie van Dr. Jansen als object (oftewel individu) en het artsnummer zou dan ook de juiste benaming zijn Inleiding Object Identifiers Object IDentifiers (OIDs) is een concept dat wordt gebruikt door ISO (de wereldwijde standaardisatie-organisatie) om te komen tot unieke identificatie van een systeem waarbinnen zelf weer identifiers of codes worden uitgedeeld en beheerd. Het achterliggende idee daarbij is dat elke identificatie en elke code onderdeel is van een systeem waarbinnen deze gedefinieerd is, een identificatie- resp. coderingssysteem, bijv.: Patiëntnummers van ziekenhuis ABC Zorgverleneridentificatie o.b.v. AGB-Z Laboratoriumbepalingen volgens LOINC In alle drie deze voorbeelden is sprake van een identifier (eerste twee gevallen) resp. een code (laatste situatie) en van een systeem waarbinnen deze worden uitgedeeld en beheerd. In het eerste geval is het een ziekenhuis dat de nummers uitdeelt (of liever: een softwaresysteem dat door het ziekenhuis wordt gebruikt). In het tweede geval gaat het om een landelijke zorgverlenertabel (beheerd door VEKTIS) en in het derde geval zelfs om een internationaal beheerd systeem voor het coderen van laboratoriumbepalingen. De truc is nu om dat identificatie/coderingssysteem zelf een unieke identificatie te geven: deze identificatie is de OID van het identificatie- of coderingssysteem. Als de OID van het systeem globaal uniek is en de identificatie of code is uniek binnen dat systeem, dan is de combinatie van die twee dus een unieke aanduiding voor de identificatie/code. De achterliggende systematiek zorgt ervoor dat het identificatie- of coderingssysteem een OID heeft die gegarandeerd wereldwijd en eeuwig uniek is. Met andere woorden: een OID is niet alleen uniek, maar ook persistent. Er zal nergens ooit dezelfde OID worden toegewezen aan een andere identificatie- of coderingssysteem. Dit wordt later toegelicht. Een aardige analogie is die met nummertjesautomaten, waarin bonnetjes zitten die uniek zijn voor de betreffende automaat. Als ik nu een bonnetje trek uit twee verschillende automaten, dan zou het nummer daarop best gelijk kunnen zijn. Maar stel nu dat de automaat zelf een sticker met daarop een OID bevat. De OID is dan dus een unieke identificatie van de nummertjesautomaat zelf. De combinatie van de OID van de automaat met het nummer op het bonnetje is nu gegarandeerd wereldwijd en eeuwig uniek. Implementatiehandleiding HL7v3-49

50 In het geval van de identificatie van personen, organisaties of andere stoffelijke zaken wordt gebruik gemaakt van bestaande (HL7-externe) identificatiesysteem (zoals bijvoorbeeld Nederlands Rijbewijsnummer, SOFI-nummer, Ziekenhuisnummer binnen het St. Josef Ziekenhuis, UZI nummer van de zorgverlener). Ieder identificatiesysteem (Engels: identification scheme) wordt op zijn beurt uniek geïdentificeerd door een bepaalde OID. In het geval van vocabulaires/terminologieën heeft een bepaalde organisatie (zoals de WHO, HL7 zelf, Z-Index, Prismant, SNOMED) één of meer vocabulaires (coderingssystemen/ tabellen ) ontwikkeld. Iedere tabel wordt eenduidig geïdentificeerd door een bepaalde OID. Voorbeeld: Indien de OID is van het Nederlandse rijbewijsnummer identificatie systeem, en het Rijbewijsnummer van Jan Janssen is , dan wordt de persoon Jan Jansen eenduidig geïdentificeerd door de combinatie van a) de OID van het identificatie systeem ( ) en b) de extensie daarvan (Engels: extension), een identificatienummer binnen het identificatie systeem (hier , het Rijbewijsnummer). In een HL7 versie 3 bericht ziet dit er als volgt uit: <id root=" " extension=" " assigningauthorityname="nederlands Rijbewijs"/> Voorbeeld: Indien de OID is van de HL7-interne tabel geslacht codes, en binnen die tabel de waarde M voor mannelijk staat, dan wordt het concept Mannelijk eenduidig geïdentificeerd door de combinatie van a) de OID van de vocabulaire-tabel ( ) en b) de extensie daarvan (Engels: extension), een terminologie-code binnen de vocabulaire (M). In een HL7 versie 3 bericht ziet dit er als volgt uit: <cd code="m" codesystem=" " codesystemname="hl7-sexcode" displayname="male"/> 3.1.2Uitgiftemechanisme OIDs De opbouw van OID s is gebaseerd op het principe van gedelegeerde verantwoordelijkheid, d.w.z. dat de instantie die een OID beheert kan bepalen dat een andere organisatie zelf weer OID s mag uitdelen onder de OID die hen is toegewezen. Alle OID s worden uitgedeeld volgens een boomstructuur, met knopen (nodes) en takken, zodat een hierarchie ontstaat. Het allereerste niveau is ooit bepaald door ISO, dat daaronder nodes heeft toegewezen aan allerlei (categorieën van) organisaties. Nodes horen bij een assigning authority die een identificatie- of coderingssysteem beheert (bijv. HL7 zelf, VEKTIS of een specifieke zorginstelling). Deze assigning authority kent sub-oid s (oftewel nieuwe takken) toe onder de eigen root node. Bij elke nieuwe tak wordt een assigning authority geacht te controleren of er al een OID bestaat voor hetzelfde identificatie- of coderingssysteem. Op die manier wordt zoveel mogelijk voorkomen dat voor hetzelfde systeem (dezelfde nummertjesautomaat ) meer dan één OID gebruikt wordt. Dit aspect is echter niet 100% waterdicht, omdat er geen Implementatiehandleiding HL7v3-50

51 centrale registratie bestaat. Het gevolg daarvan is dat het zou kunnen dat er meerdere OID s voor één identificatie- of coderingssysteem bestaan. Het blijft echter zo dat een OID altijd een unieke aanduiding voor één specifiek systeem is (en dus als basis kan dienen voor identifiers of codes die binnen dat systeem worden uitgedeeld en beheerd). Een OID is altijd een unieke aanduiding voor één specifiek identificatie- of coderingssysteem. Een OID kan nadat zij is toegewezen nooit meer aan iets anders worden toegewezen. Een OID blijft ook geldig en bruikbaar als de assigning authority niet meer bestaat. Het gaat er immers om dat de OID persistent is, dus ook als een andere assigning authority het beheer overneemt, moet de OID voor alles onveranderd blijven. Teneinde het gebruik van OIDs in HL7 berichtimplementaties te vergemakkelijken hebben de internationale HL7 organisatie en HL7 Nederland elk een OID root bij ISO verkregen. Binnen deze OID roots kan HL7 op verzoek OIDs uitdelen. Figuur 15: OID boomstructuur Implementatiehandleiding HL7v3-51

52 Een OID bestaat uit een keten van nodes. De nodes zijn getallen met punten ertussen: n1.n2.n3.n4. Er is in principe geen beperking aan de lengte die een OID kan hebben (hoewel in de praktijk vaak een maximum van 100 posities wordt aangehouden). Een OID node mag geen voorloopnullen bevatten, hoewel een node wel gewoon uit het getal 0 mag bestaan. Dus is geen geldige OID, maar is dat wel. Een OID is slechts bedoeld om de uniciteit te borgen en de structuur van de OID heeft geen betekenis. OID s mogen dus niet geparsed worden, bijv. om te bepalen welke assigning authorities betrokken zijn bij het ontstaan van de keten van nodes. Elke tak onder een root in de boomstructuur correspondeert met een domein waarbinnen een assigning authority de uitgave van OIDs beheert. Indien een OID binnen deze tak wordt uitgegeven aan een andere organisatie, dan vormt die OID de OID root van de daaraan gerelateerde organisatie (die weer een assigning authority kan zijn). Voor meer informatie over OIDs zie de Franse ASN.1 website waar grote delen van de wereldwijde OID boomstructuur kunnen worden bekeken Identificatiemethode Binnen HL7 berichten is een identificatie systeem noodzakelijk waar het gaat om personen, systemen, instellingen en andere stoffelijke zaken. Daarbij wordt gebruik gemaakt van bestaande (HL7-externe) identificatiesystemen (zoals bijvoorbeeld Nederlands rijbewijsnummer, SOFI-nummer, Ziekenhuisnummer binnen het St. Josef Ziekenhuis, UZI nummer van de zorgverlener) die op zijn beurt uniek geïdentificeerd wordt door een bepaalde OID. Hieronder volgt per gegevenscategorie een tekstuele toelichting van de te gebruiken identificatiemethoden, alfabetisch gesorteerd op gegevenscategorie. Na deze lijst volgt een tabel met alle aangehaalde OIDs. Berichten: Een HL7 versie 3 bericht. Berichten dienen te worden voorzien van een uniek nummer door de zendende softwareapplicatie. Indien de OID van de zendende applicatie is (Zie softwareapplicatie in deze lijst), dan mag deze applicatie binnen de OID-tak zelf unieke nummers uitdelen. Als YYYY een oplopend nummer per bericht is, en de applicatie de OID tak 1 gebruikt om berichten verzonden door de applicatie te identificeren, dan vormt met extensie YYYY een unieke identificatie van het bericht. Voorbeeld: De applicatie met OID staat op het punt een nieuw bericht te verzenden. Het te verzenden bericht krijgt het unieke nummer (dit nummer mag slechts één keer worden gebruikt gedurende de levensduur van de zendende applicatie). De applicatie kan binnen haar eigen OID-tak zelf unieke nummers uitdelen. Als het te verzenden bericht aangeeft, en de organisatie er voor heeft gekozen OID tak 1 te gebruiken om berichten te identificeren, dan vormt met extensie een unieke identificatie van het bericht. <id root=" " extension=" " Implementatiehandleiding HL7v3-52

53 assigningauthorityname="applicatienaam"/> Softwareapplicatie: Met een softwareapplicatie wordt een applicatie bedoeld, die als fysieke zender of ontvanger van berichten optreedt, eventueel namens functionele applicatiemodules binnen de softwareapplicatie. Hieronder vallen de diverse XISsystemen. Zie tevens Appendix D Adresseren van dossiers en postbussen in het document Specificatie van de basisinfrastructuur in de zorg, versie 2.4 voor een beschrijving van het identificeren en adresseren van applicaties. Softwareapplicaties worden door middel van een door de verantwoordelijke organisatie uit te geven OID geïdentificeerd. Dit is mogelijk door of een OID af te leiden uit de OID van de organisatie die de applicatie beheert, of door het aanvragen van een aparte OID bij HL7 Nederland voor de applicaties binnen de eigen instelling. De identificatie heeft in principe geen enkele relatie met het UZI nummer van het systeemcertificaat van een GBZ; een relatie kan alleen aan de hand van een koppeltabel gelegd worden. Indien de applicatie een GBZ is (of een deel daarvan) dan wordt op moment van aansluiting van de GBZ een identificerende OID door de LSP uitgegeven en in de ZIM vastgelegd. Voorbeeld: indien de OID met extensie 22 een softwareapplicatie identificeert (zie hierboven voor een definitie van softwareapplicatie), dan mag deze softwareapplicatie binnen de OID zelf unieke nummers uitdelen. Als YYYY een oplopend nummer per softwaremodule binnen de softwareapplicatie is, en de OID-tak 56 wordt gebruikt ter identificatie van modules in de softwareapplicatie, dan vormt met extensie YYYY een unieke identificatie van de softwaremodule. FAQ: Gegeven dat elke softwareapplicatie een Systeempas met een certificaat voorzien van een uniek UZI nummer verkrijgt voor authenticatiedoeleinden, kan dat UZI nummer niet hergebruikt worden als unieke identificatie van de softwareapplicatie? Nee, systeemcertificaten dienen periodiek (elke drie jaar) te worden vernieuwd en verkrijgen dan een nieuw UZI nummer. Om deze reden wordt de identificatie van softwareapplicaties door middel van het UZI nummer van de Systeempas afgeraden. FAQ: De identificerende OID van een applicatie kan vrijelijk worden gedefinieerd. Een uitzondering wordt gevormd door een GBZ en applicaties binnen een GBZ die voor communicatiedoeleinden bekend zijn bij de verwijsindex. Deze verkrijgen, na aanmelding en registratie bij de LSP, een identificerende OID die verplicht is in alle communicatie met de landelijke infrastructuur. De root van de door de LSP uitgegeven identificaties is Patiënt/cliënt: Persoon die zorgservices afneemt van zorgverleners of zorgverlenende instellingen. Patiënten worden landelijk uniek geïdentificeerd door middel van het Burger Service Nummer (BSN). De OID van het BSN identificatie systeem is: Naast de BSN-identificatie (die indien deze bekend is in ieder geval verzonden moet worden) kan gebruik worden gemaakt van het identificatienummer zoals bekend binnen een zorgregio of de instelling zelf. Implementatiehandleiding HL7v3-53

54 Voorbeeld: Een patiënt heeft BSN en de locale (instellingsinterne) identificatie Er van uitgaande dat het HL7-bericht een identificerend data-element bevat wat herhalend voor mag komen, kan dit er in het bericht als onderstaand voorbeeld uitzien. Indien de OID de identificatie van de organisatie is, dan mag een applicatie binnen haar OID-tak zelf unieke nummers uitdelen. Als een organisatie-intern patiëntnummer is, en de organisatie er voor heeft gekozen OID tak 12 te gebruiken om patiënten te identificeren, dan vormt met extensie een unieke identificatie van de patiënt. <id root=" " extension=" " assigningauthorityname="bsn"/> <id root=" " extension="830760" assigningauthorityname="ons Ziekenhuis"/> Zorgverlenende Organisaties: Organisaties (of organisatiedelen) die op enigerlei manier bij het zorgproces of daaraan verwante processen betrokken zijn. Deze organisaties dienen binnen AORTA landelijk uniek geïdentificeerd te worden door middel van: 1. het CIBG UZI-Register-Abonneenummer (URA). Dit nummer is aanwezig op de UZI pas, het gebruik ervan binnen AORTA is feitelijk verplicht. 2. indien de organisatie geen (CIBG) URA bezit: de (Vektis) AGB-Z code. Indien van een organisatie meerdere identificaties worden verstuurd dient tenminste of de (CIBG) URA of de (Vektis) AGB-Z code aanwezig te zijn. Het begrip organisatie is in Nederland tevens van toepassing op zorgverleners die als zelfstandig ondernemer werkzaam zijn (ongeacht of zij bij de Kamer van Koophandel ingeschreven zijn). Voorbeeld: Huisartspraktijk Dr. T. de Vries wordt beschouwd als een organisatie, ongeacht of dit in de fomeel-juridische zin een organisatie is. De Vektis AGB-Z zorginstelling identificatie OID is: De UZI-Register-Abonneenummer (URA) Zorginstelling identificatie OID is: Naast het primaire identificatiesysteem kunnen tevens alternatieve identificaties gebruikt worden. De Prismant (SIG) Zorginstelling identificatie OID is: Zorgverleners: Personen die op enigerlei manier bij het zorgproces of daaraan verwante processen betrokken zijn. Deze personen worden landelijk uniek geïdentificeerd in het UZI-register. De OID ten bate van identificatie van personen door middel van een UZI is: Naast de UZI-identificatie (die indien zij bekend is in ieder geval verzonden moet worden) kan gebruik worden gemaakt van andere regionale identificatiesystemen. Veelal wordt het Vektis AGB-Z nummer van de zorgverlener gehanteerd. De Vektis AGB-Z Zorgverlener identificatie OID is: Voorbeeld: Een zorgverlener heeft UZI , Vektis AGB-Z nummer , en een locale (organisatie interne) code WEE. Er van uitgaande dat het HL7-bericht een identificerend data-element bevat wat herhalend voor mag komen kan dit er in het bericht als onderstaand voorbeeld uitzien. Indien het Vektis AGB-Z nummer van de organisatie is, dan mag deze organisatie binnen de OID zelf unieke nummers uitdelen. Als 160 een organisatie-interne zorgverlenercode is, en de organisatie heeft besloten OID tak 6 te gebruiken om zorgverleners binnen de organisatie Implementatiehandleiding HL7v3-54

55 te identificeren, dan vormt met extensie WEE een unieke identificatie van deze zorgverlener. <id root=" " extension=" " assigningauthorityname="uzi"/> <id root=" " extension=" " assigningauthorityname="vektis"/> <id root=" " extension="wee" assigningauthorityname="ons Ziekenhuis"/> 3.1.4Identificatiesystemen OID Referentietabel De volgende tabel bevat een overzicht met de in Nederland gebruikte OIDs voor gangbare identificatiesystemen. De getoonde tabel is niet volledig. Zie de website van HL7 Nederland voor een up-to-date en compleet overzicht van de uitgegeven OIDs. OID Identificatiesysteem Omschrijving VEKTIS AGB-Z Dient ter identificatie van zorgverleners en zorgverlenende organisaties Prismant/SIG code Dient ter identificatie van zorgverlenende organisaties Zorgverlener UZI Dient ter identificatie van zorgverleners (natuurlijke personen) in de Nederlandse zorgsector. Het UZI nummer wordt uitgegeven na opname in het ZorgaanbiederRegister (ZR). Formaat: 9N, met voorloopnullen indien korter dan 9 cijfers Systeem UZI Dient ter identificatie van systemen (applicatiesoftware) in de Nederlandse zorgsector. Formaat: 9N, met voorloopnullen indien korter dan 9 cijfers BSN(1) Landelijk Nederlands Burger Service Nummer, dient ter identificatie van patiënten of zorgcliënten. (1) Formaat: 9N, met voorloopnullen indien korter dan 9 cijfers UZOVI(2) Unieke identificatie van een zorgverzekeraar.(2) UZI-Register- Abonneenummer Dient ter identificatie van zorgorganisaties in de Nederlandse (URA) zorgsector. Het betreft zorgorganisaties (inclusief zelfstandigen) die tenminste één UZI pas bezitten. Formaat: 8N, met voorloopnullen indien korter dan 8 cijfers BIG-ID BIG-Register (ID van in BIG Register opgenomen entiteiten) Applicaties binnen de nationale infrastructuur Identificeert applicaties aangesloten op de landelijke infrastructuur, waaronder de ZIM en alle GBZ applicaties. Implementatiehandleiding HL7v3-55

56 Noot: 1. Deze OID mag in bepaalde pilotregio s worden toegepast voor het SOFI identificatiesysteem op basis van een Algemene Maatregel van Bestuur. Zodra de BSN wettelijk mag worden gebruikt in de zorgsector identificeert de OID het BSN identificatiesysteem. Het SOFI nummer en het BSN nummer zijn qua nummer gelijkluidend. 2. Deze OID duidde voor 15 September 2005 de Vektis ZV-tabel aan, en na die datum de UZOVI tabel. De identificatienummers in beide tabellen zijn gelijkluidend. Ministerie Identificaties Deze tabel bevat door HL7 Nederland uitgegeven identificaties voor Nederlandse Ministeriële Departementen (Ministeries). Deze identificaties worden gebruikt als organisatie identifiers. Het ministerie identificatie systeem zelf heeft de OID Deze tabel wordt nog nader aangevuld. Extensie Omschrijving 1 BZK Ministerie van Binnenlandse Zaken 2 VWS Ministerie van VWS 3.2 Vocabulaire voor berichtspecificaties Eenheid van taal c.q. standaardisatie van taal is een belangrijk terrein waarop zowel nationaal als internationaal veel werk dient te worden verzet. Binnen het brede begrip eenheid van taal is met name de standaardisatie van zorg- en behandelinhoudelijke taal en coderingen een der belangrijkste voorwaarden voor o.a. elektronische zorgdossiers en het uitwisselen van eenduidige zorg- en behandelinformatie tussen zorgprofessionals. Zowel internationaal als nationaal (Nictiz, NEN) is het belang onderkend om aandacht te besteden aan de relatie tussen taalstandaarden en HL7. De wetenschappelijke verenigingen spelen hierin een cruciale rol. Aangezien de HL7 standaard zich strikt genomen primair richt op het bieden van berichtenstructuren waarin informatie op een gestandaardiseerde wijze kan worden afgebeeld, behoren taalstandaarden zeker inhoudelijk niet tot het werkgebied van HL7. Taalstandaarden vormen vanuit de HL7 standaard externe content, vergelijkbaar met diverse andere externe coderingen en classificaties die inhoudelijk door derden worden ontwikkeld en beheerd. Met betrekking tot standaardisatie van taal houdt HL7 zich niet bezig met de inhoudelijke standaardisatie van taal, maar met het afbeelden en weergeven daarvan in de HL7 structuur. Dit document bevat beschrijvingen van de vocabulaire domeinen toegevoegd (of gewijzigd) voor gebruik in de Nederlandse situatie. Indien een vocabulaire in dit document niet genoemd wordt, zijn er geen specifieke Nederlandse richtlijnen van toepassing en wordt verwezen naar de vocabulaires zoals opgenomen in de internationale HL7 standaard Inleiding Aan alle HL7 attributen van een gecodeerd datatype is een Vocabulary Domain gekoppeld. Een vocabulaire domein (Vocabulary Domain) wordt beschreven door middel van een tabel met waarden, of een referentie naar een HL7-externe terminologie. Implementatiehandleiding HL7v3-56

57 In de HL7 versie 3 materialen wordt soms in de R-MIMs (<= MyVocabularyDomain), maar in ieder geval in de HMDs per attribuut de van toepassing zijnde vocabulaire aangehaald, bijvoorbeeld "MyVocabularyDomain" (CWE). Hierbij geeft CWE (Coded With Exceptions) aan dat er naast waarden uit het vocabualire domein ook andere waarden mogen worden gebruikt (zoals waarden uit Nederland-specifieke tabellen). Indien CNE (Coded, No Exceptions) is aangegeven, dient de gebruikte waarde uit de waarden van het vocabulaire domein te worden gekozen, er zijn dan geen uitzonderingen mogelijk. Structuur van een Vocabulairy Domain table MyVocabularyDomain This table contains values related to etc. Level Type, Domain name and/or Mnemonic code (2) Base OID / Externe terminologienaam (1) Mnemonic (2) Definition/ description Noten: 1. De externe terminologienaam wordt ter informatie gegeven indien de code afkomstig is uit een bestaande HL7-externe terminologie. 2. In het geval van een verwijzing naar een externe terminologie kunnen deze velden leeg zijn. In dat geval verwijst de tabel naar alle mogelijke waarden in de externe terminologie HL7 Vocabulary Domain Values Indien de waarden binnen een vocabulaire geen aanpassingen/inperkingen behoeven in de Nederlandse situatie wordt volstaan met een verwijzing naar de vocabulaire documentatie binnen de HL7 materialen (wel wordt de OID van de desbetreffende vocabulaire gedocumenteerd). HL7 Nederland streeft ernaar zo min mogelijk vocabulaires voor Nederland te definiëren. Indien mogelijk wordt gebruik gemaakt van in de internationale standaard opgenomen vocabulaire tabellen en (indien dat niet mogelijk is) van tabellen gedefinieerd door Nederlandse standaardisatie organisaties. ActRegistryCode: x_datadomainnl (Gegevenssoort) Deze tabel bevat de waarden die de gegevenssoort van de in de verwijsindex opgeslagen gegevens bepalen. In formele zin bevat deze tabel de definitie van een value set die deel uitmaakt van het reeds bestaande v3 vocabulary domein ActRegistryCode. Deze tabel wordt nog nader uitgewerkt. Level Type, Domain name and/or Mnemonic code S: Medicatie Base OID Mnemonic Definition/ description X X+1 L: (272353) Medicatieverstrekking Implementatiehandleiding HL7v3-57

58 X+1 L: (585626) Medicatietoediening X+1 L: (722933) Medicatie voorschrift X L: (460320) Care Provision X L: (117117) Organisatieidentificerende /demografische gegevens X L: (118118) Persoonidentificerende /demografische gegevens X L: (288432) Conditie (5) X+1 L: (800310) Intolerantie (3) (was: Allergie) X S: Observatie Observatie (4) X+1 L: (834295) Monster gerelateerd onderzoek (2) X+1 L: (188011) Beeldvormend onderzoek Noot: 1. De voor pilot-doeleinden gebruikte codes SUBSUP, SUBADM en PRESC dienen te worden vervangen door respectievelijk , , en (Monster gerelateerd onderzoek) omvat o.a. Lab en Pathologie onderzoek (Intolerantie) omvat o.a. allergie. 4. Observatie: Een activiteit die tot doel heeft een bepaalde resultaatwaarde te bepalen. Alle diagnostische medische activiteiten zijn observaties. Elke observatie heeft een auteur: de observator. Voorbeelden van observaties zijn laboratoriumbepalingen, radiologie-onderzoeken, etc., maar ook het bepalen van bijv. de lengte, het gewicht of de bloeddruk van een patiënt. 5. Conditie: Een kenmerk van de medische toestand van een patiënt. In alle gevallen betreft het een gegeven (binnen HL7 een Act) dat betrekking heeft op een ziekte, probleem of ander kenmerk van een specifieke patiënt, dat zich uitstrekt over een bepaalde periode in de tijd. Dit leent zich dus voor het weergeven van uiteenlopende verschijnselen, zoals: a. Een handicap, zoals blindheid. b. Een allergie of andere intolerantie. c. Een chronische aandoening, zoals diabetes. d. Een acute aandoening, zoals appendicitis of een beenbreuk. e. Een complicatie bij een achterliggend probleem, zoals koorts of slapeloosheid. f. Een ander aspect van de lichamelijke toestand, zoals zwangerschap of zelfs een kinderwens. g. Het ontkennen van het bestaan van één van bovenstaande aspecten (op basis van het attribuut negationind). RoleCodeNL (Rol Type) Deze tabel bevat waarden die het roltype van een entiteit bepalen. De onderstaande tabel is een uitbreiding op het v3 vocabulaire domein RoleCode. Deze tabel is specifiek voor Nederland en niet onderhevig aan harmonisatie met HL7. Implementatiehandleiding HL7v3-58

59 De onderstaande vocabulaire identificeert enerzijds de rol van zorgverleners binnen instellingen; de waarden in de A:PracticionerRoleNL hierarchie kunnen alleen worden toegepast op rollen gespeeld door Entiteiten van klasse PSN (mens). De waarden in de A:OrganisationRoleNL en A:PubOrgRoleNL kunnen alleen worden toegepast op rollen gespeeld door Entiteiten van klasse ORG (Organisatie) of PUB (Overheidsgerelateerde instantie). Deze vocabulaire heeft de OID Level Type, Domain name Mnemo Definition/ description and/or Mnemonic code nic 1 A: PractitionerRoleNL 2 S: Arts Arts (1) 3 L: (01.002) Internist-Allergoloog (1) 3 L: (01.003) Anesthesioloog (1) 3 L: (01.008) Arts arbeid gezond. / bedrijfsarts (1) 3 L: (01.010) Cardioloog (1) 3 L: (01.011) Cardiothoracaal chirurg (1) 3 L: (01.012) Dermatoloog (1) 3 L: (01.013) Gastro-enteroloog (1) 3 L: (01.014) Chirurg (1) 3 L: (01.015) Huisarts (1) 3 L: (01.016) Internist (1) 3 L: (01.018) Keel- neus- en oorarts (1) 3 L: (01.019) Kinderarts (1) 3 L: (01.020) Arts klinische chemie (1) 3 L: (01.021) Klinisch geneticus (1) 3 L: (01.022) Klinisch geriater (1) 3 L: (01.023) Longarts (1) 3 L: (01.024) Arts-microbioloog (1) 3 L: (01.025) Neurochirurg (1) 3 L: (01.026) Neuroloog (1) 3 L: (01.030) Nucleair geneeskundige (1) 3 L: (01.031) Oogarts (1) 3 L: (01.032) Orthopedisch chirurg (1) 3 L: (01.033) Patholoog (1) 3 L: (01.034) Plastisch chirurg (1) 3 L: (01.035) Psychiater (1) 3 L: (01.039) Radioloog (1) 3 L: (01.040) Radiotherapeut (1) 3 L: (01.041) Reumatoloog (1) 3 L: (01.042) Revalidatiearts (1) 3 L: (01.055) Arts maatschappij en gezondheid (1) 3 L: (01.045) Uroloog (1) 3 L: (01.046) Gynaecoloog (1) 3 L: (01.047) Verpleeghuisarts (1) 3 L: (01.048) Arts arbeid gezond. / verzekeringsarts (1) 3 L: (01.050) Zenuwarts (1) 3 L: (01.056) Arts verstandelijk gehandicapten (1) 2 S: (02.000) Tandarts (1) 3 L: (02.053) Orthodontist (1) 3 L: (02.054) Kaakchirurg (1) 2 S: (03.000) Verloskundige (1) 2 S: (04.000) Fysiotherapeut (1) 2 S: (16.000) Psychotherapeut (1) 2 S: (17.000) Apotheker (1) Implementatiehandleiding HL7v3-59

60 3 L: (17.060) Ziekenhuisapotheker (1) 2 S: (25.000) GZ-psycholoog (1) 2 S: (30.000) Verpleegkundige (1) 2 S: (87.000) Optometrist (1) 2 S: (88.000) Huidtherapeut (1) 2 S: (89.000) Diëtist (1) 2 S: (90.000) Ergotherapeut (1) 2 S: (91.000) Logopedist (1) 2 S: (92.000) Mondhygiënist (1) 2 S: (93.000) Oefentherapeut Mensendieck (1) 2 S: (94.000) Ofentherapeut Cesar (1) 2 S: (95.000) Orthoptist (1) 2 S: (96.000) Podotherapeut (1) 2 S: (97.000) Radiodiagnistisch laborant (1) 2 S: (98.000) Radiotherapeutisch laborant (1) 1 A: OrganisationRoleNL 2 L: (ZKH) ZKH Ziekenhuis 2 L: (PKLIN) PKLIN Kliniek (for profit) 2 L: (GGZ) GGZ GGZ Instelling 2 L: (APO) APO Apotheek 2 L: (HAP) HAP Huisartsenpraktijk (evt. Apotheek houdend) 1 A: PublicOrgRoleNL 2 L: (CON) CON Consultatie buro Noot: Deze tabel is nog in ontwikkeling. De codewaarden met (1) achter hun definition/description zijn met hun omschrijving zijn afkomstig uit de CPS van het UZI-register; de waarden zijn gebaseerd op de CIBG tabel Beroepstitels en Specialismen en is gebaseerd op de wet BIG. De waarde (geen beroepstitel) komt als waarde op de UZI pas voor, deze waarde wordt in HL7 niet gebruikt, ook niet als nullflavor. De voor testdoeleinden gebruikte codes 833 (Apotheker) en 638 (Huisarts) dienen te worden vervangen door resp. de codes en DrugEntity (Medicatiecode/Werkzame stof) Deze tabel identificeert de werkzame stof. Er wordt gebruik gemaakt van een externe tabel: de GPK tabel van de G-Standaard zoals beheerd door Z-Index. De medicatiecode is de typering voor het soort geneesmiddel dat bij de betreffende receptregel is voorgeschreven. In Nederland zijn meerdere coderingssystemen voor geneesmiddelen in gebruik, waarbij afhankelijk van de voorschrijver het recept o.b.v. één van de coderingen wordt opgesteld. Bij verwerking door de verstrekker kan deze vervolgens nog worden omgezet in een andere codering. De binnen de G-Standaard gedefinieerde coderingssystemen zijn in de volgende tabel weergegeven. Zuiver gesproken zijn zaken als sterkte, toedieningsvorm, toedieningsweg en verpakkingsvorm geen onderdeel van de typering van het soort geneesmiddel. In de toekomst zou een besluit kunnen vallen om de G-Standaard tabellen op te splitsen in feitelijke medicatiecode en aanvullende typeringen. Vooralsnog worden GPK, HPK en artikelcode echter alleen gebruikt om de werkzame stof te identificeren. Opmerking: In de G-Standaard kan men eigen codes gebruiken (codes en hoger). Deze codes zijn leverancier- of locatie- specifiek. Bij deze codes dient gebruik gemaakt te worden van een andere OID dan de G-Standaard OIDs. Implementatiehandleiding HL7v3-60

61 Coderingssysteem Omschrijving Voorbeeld GPK HPK Artikelcode Generieke Productcode merkloze aanduiding o.b.v. de werkzame stof, maar inclusief sterkte, farmaceutische vorm (doseervorm) en soms de toedieningsweg Handelsproductcode GPK incl. merkaanduiding specifieke fabrikant HPK incl. aanduiding specifieke verpakkingvorm Diazepam 5 mg/st, tablet, oraal Valium 5mg tablet, Stesolid 5mg tablet (als verschijningsvormen van Diazepam) Valium 5 mg tablet, 2 strip à 10 tablet, 1 verpakking à 50 EAV Een HL7 voorbeeld op het gebied van medicatiecodes, waarin zowel de GPK, de HPK als de artikelcode opgenomen zijn, volgt hieronder: <code code=" " codesystem=" " codesystemname="g-standaard artikelcode" displayname="valium 5 mg tablet, 2 strip à 10 tablet, 1 verpakking à 50 EAV"/> <code code=" " codesystem=" " codesystemname="g-standaard HPK" displayname="valium 5mg tablet, Stesolid 5mg tablet"/> <code code=" " codesystem=" " codesystemname="g-standaard GPK" displayname="diazepam 5 mg/st, tablet, oraal"/> Gebruiksvoorschrift Medicatie Deze tabel bevat gebruiksvoorschriften van een geneesmiddel. Er wordt gebruik gemaakt van een externe tabel: WCIA tabel 25. ActDetectedIssueCode De ActDetectedIssue vocabulaire (met OID ) bevat onder andere de onderstaande waarden. Zie de ActCode vocabulaire in de laatste HL7 versie 3 specificatie voor een volledige tabel. Value Description Comment INSPAR Insufficient detail in parameters to respond to query Onvoldoende gegevens in de vraag om deze eenduidig te kunnen beantwoorden. PARAOB Parameter out of bounds De parameter valt semantisch gezien buiten de mogelijke of geaccepteerde waarden. Business-rule boundaries exceeded, not a syntaxtic issue. Example: a date of birth which is in the future. A negative blood cell count. NAT Insufficient Authorization De zendende partij heeft niet de benodigde autorisatie om het bericht te versturen. KEY205 Duplicate key identifier De identificatie (primary key) van de patient, het recept etc. bestaat al. Gebruikt in antwoordberichten op toevoegings-/wijzigingsberichten (Admit, New Order, etc.). Implementatiehandleiding HL7v3-61

62 Value Description Comment KEY204 Unknown key identifier De identificatie (primary key) van de patient, het recept, etc. bestaat niet. Gebruikt in antwoordberichten op niet-toevoegingsberichten, bijvoorbeeld bij een verzoek van het verwijderen van een niet-bestaand recept. DRG Drug Interaction Alert Proposed therapy may interact with an existing or recent drug therapy COND Condition Alert Proposed therapy may be inappropriate or contraindicated due to an existing/recent patient condition or diagnosis DUPTHPY Duplicate Therapy Alert The proposed therapy appears to duplicate an existing therapy AcknowledgementDetailCode De AcknowledgementDetailCode vocabulaire (met OID ) bevat onder andere de volgende waarden: Value Description Comment SYN100 Required class missing Error: Required class missing in message; or the sequence of the classes is different than required by the standard or one of the conformance profiles identified in the message. SYN101 Required attribute missing Error: A required attribute is missing in a class SYN102 Data type error Error: The attribute contained data of the wrong data type, e.g. a numeric attribute contained "FOO". SYN103 Value not found in code system Error: An attribute value was compared against the corresponding code system, and no match was found. This error code is also used if a Realmspecific vocabulary has been selected by means of the RealmCode attribute. SYN104 Invalid code system in CNE An attribute value referenced a code system that is not valid for an attribute constrained to CNE. SYN110 Number of class repetitions exceeds limit Error: the number of repetitions of a (group of) class(es) exceeds the limits of the standard or one of the conformance profiles identified in the message. SYN112 Number of attribute repetitions exceeds limit Error: the number of repetitions of an attribute exceeds the limits of the standard or one of the conformance profiles identified in the message. NS200 Unsupported interaction Rejection: The interaction (or: this version of the interaction) is not supported. NS202 Unsupported processing id Rejection: The Processing ID is not supported. NS250 Unsupported processing Rejection: The processing mode is not supported Mode NS203 Unsupported version id Rejection: The Version ID is not supported. NS260 Unknown sender Rejection: the Device.id of the sender is unknown. NS261 Unrecognized attentionline Rejection: the receiver requires information in the attentionline classes for routing purposes. RTUDEST RTWDEST NOSTORE RTEDEST Message routing error, unknown destination. Message routing warning, destination unreachable. No storage space for message. Message routing error, destination unreachable The destination of this message is unknown to the receiving application. The receiving application in the message does not match the application which received the message. The message was neither routed, processed nor stored by the receiving application. Warning: The destination of this message is known to the receiving application. Message have been successfully routed to that destination in the past. The link to the destination application or a router application is (temporarily) unavailable. The receiving application will forward the message as soon as the destination can be reached again. Rejection: The message can t be stored by the receiver due to an unspecified internal application issue. The message was neither processed nor stored by the receiving application. Error: The destination of this message is known to the receiving application. Messages have been successfully routed to that destination in the past. The link to the destination application or an intermediate application is unavailable. Implementatiehandleiding HL7v3-62

63 3.2.3Vocabulaires OID-Referentietabel De volgende tabel bevat een overzicht met de in Nederland gebruikte OIDs voor de identificatie van vocabulaires (code tabellen), met in ieder geval de OIDs van een groot aantal Nederland-specifieke vocabulaires. De onderstaande tabel is niet volledig. Zie de website van HL7 Nederland voor een up-to-date en compleet overzicht van de uitgegeven OIDs. OID Identificatiemechanisme Omschrijving G-Standaard GPK Medicatie. Generieke productcode (GPK,GPC). Werkzame stof (inclusief sterkte), farmaceutische vorm (doseervorm) en de toedieningsweg. Voorbeeld: Diazepam 5 mg/st, tablet, oraal. (Zie noot 1) Medicatiedosering WCIA Tabel 25 Medicatiedosering (precoordinated), bestaande uit een reeks aanelkaargeplakte Tabel 25 codes Tijdseenheden - Toedieningstijdseenheden (numcode) WCIA Tabel Eenheden gebruiksadvies - WCIA Tabel 25 Eenheden (numcode) Tekstcategorieen- WCIA Tabel Aanvullende teksten - WCIA Tabel 25 Aanvullende teksten bij medicatiedosering (numcode) G-Standaard HPK Medicatie. Handelsproductcode (HPK, TPC). Als GPK, verbijzonderd met (onder andere) fabrikantnummer. Voorbeeld: Valium 5mg tablet, Stesolid 5mg tablet als verschijningsvormen van Diazepam. (Zie noot 1) G-Standaard Artikel Code Medicatie: Artikel Kode, Artikelnummer. Als HPK, verbijzonderd naar verpakking. Valium 5 mg tablet, 2 strip à 10 tablet, 1 verpakking à 50 EAV. (Zie noot 1) LOINC Observation identifier, identificeert een bepaald type (laboratorium)test ISO Landcodes lengte 2 2-karakter country codes volgens ISO Nederlandse Postcodes Lengte 6, zonder spatie Nederlandse uitbreidingen op versie 3 vocabulaires: HL7-NL Role Code Zorgverlener rol typen: Identificeert de diverse rollen die een zorgverlener binnen een organisatie vervult HL7-NL Act Code (Gegevenssoort) Gegevenssoorten, een hierarchische value set gebruikt door de verwijsindex. Noten: (1) Opmerking: In de G-Standaard kan men eigen codes gebruiken (codes en hoger). Deze codes zijn leverancier- of locatie- specifiek. Bij deze codes Implementatiehandleiding HL7v3-63

64 dient gebruik gemaakt te worden van een andere OID dan de G-Standaard OIDs. De G- Standaard OIDs mogen dus niet gebruikt worden in combinatie met eigen codes. 3.3 OID gerelateerde implementatie aspecten NICTIZ heeft gekozen voor HL7 versie 3 en gebruikt daarom OID s als onderdeel van identificaties en coderingen die voorkomen in diverse onderdelen van de HL7 berichten. Voorbeelden van identificaties die binnen een HL7 bericht in AORTA voorkomen: In de transmission wrapper: Berichten (message ID, identificatie van interacties tussen applicaties) Applicaties (device ID, als zender en ontvanger van de interactie) In de transmission wrapper gaat het altijd om de adressering van de interactie. In de control act wrapper: Zorginstellingen (altijd geïdentificeerd o.b.v. een URA nummer) Zorgverleners (altijd geïdentificeerd o.b.v. een UZI nummer) Zorgmedewerkers (ook geïdentificeerd o.b.v. een UZI nummer) Zorgsystemen (geïdentificeerd o.b.v. een UZI services certificaat) In de control act wrapper gaat het altijd om een auteur of verantwoordelijke. In de payload: Patiënten (altijd o.b.v. het BSN binnen de landelijke infrastructuur) Zorggegevens (medicatieverstrekkingen, laboratoriumuitslagen, etc.) Daarnaast worden ook in de payload zorgverleners/zorginstellingen aangeduid. Voor al deze identificaties geldt dat ze uniek en persistent moeten zijn. Dit betekent onder andere dat ze ook bestand moeten zijn tegen migraties en fusies van informatiesystemen. Het is onmogelijk om vanuit HL7 Nederland, of welke instantie dan ook, centraal bij te houden welke OID s gebruikt worden voor lokaal gegenereerde zorggegevens. Elke applicatie die een uniek nummer bepaalt per ingevoerde order of uitgevoerde activiteit zal daarvoor een eigen unieke en persistente OID moeten hanteren, om te zorgen dat bijv. elke medicatieverstrekking te onderscheiden is van elke andere medicatieverstrekking. Wat daarom nodig is, is een compromis met de volgende kenmerken: Forceer OID roots per applicatie, per zorginstelling of per softwareleverancier. Geef richtlijnen voor het uitdelen van nodes onder deze roots. Laat het beheer hiervan over aan de assigning authority (behorend bij de root). De volgende IDs kunnen in principe als root dienen in de zorg: De applicatie, o.b.v. de door het LSP uitgedeelde applicatie ID (dit zou handig zijn, maar er is dan geen vanzelfsprekende assigning authority). De zorginstelling, o.b.v. het UZI Register Abonnee (URA) nummer (probleem is dat nog niet zeker is of URA 1-op-1 bij zorginstelling zal horen). Het Goed Beheerd Zorgsysteem, o.b.v. de daaraan uitgedeelde GBZ ID (probleem is dat de juridische definitie van een GBZ nog niet 100% zeker is). De IT leverancier, o.b.v. een nog te bepalen identificatie van de organisatie (het lijkt niet zo handig om leverancier AA te maken, bijv. i.v.m. conversie). Implementatiehandleiding HL7v3-64

65 Implementatierichtlijnen zijn nodig om duidelijk te maken welke OID structuur gebruikt moet worden in HL7 versie 3 berichten binnen AORTA. Hierover is een beslissing genomen binnen NICTIZ, met deze richtlijn als uitkomst: Ten behoeve van de wereldwijde uniciteit en persistentie van gegevensidentificatie wordt de zorgaanbieder geadviseerd haar URA (UZI Register Abonneenummer) te gebruiken als basis voor de OID root van alle binnen de zorginstelling gegenereerde gegevens. Zorgaanbieders die reeds een bestaande OID hanteren, mogen deze wel blijven gebruiken. Complicatie hierbij is dat er nu reeds pilot- en andere implementaties zijn, terwijl er nog nauwelijks UZI passen (en dus ook geen bijbehorende URA nummers) zijn uitgedeeld. Oplossing is om in de tussenliggende periode hetzelfde principe te gebruiken o.b.v. Vektis AGB-Z nummers. Dit betekent dat een ziekenhuis met AGB-Z nummer de volgende OID root moet gebruiken: Als later een URA voor dit ziekenhuis beschikbaar komt, dan moet toch de node o.b.v. het AGB-Z nummer in gebruik blijven (de regel o.b.v. URA is alleen bedoeld voor nieuwe OID s). Merk op dat, ondanks deze richtlijn, het LSP of een daarop aangesloten applicatie nooit iets mag afleiden (o.b.v. parsing van de nodes) uit de opbouw van een ontvangen OID Gevolgen van OIDs voor GBZ applicaties De volledige ID (dus extensie én OID root) moet altijd reproduceerbaar zijn bij opslaan opgevraagde gegevens moet volledige identifier worden bewaard bij opnieuw opvragen van gegevens moet dezelfde identifier worden opgeleverd De volgende praktijksituaties moeten ondersteund worden: Gegevens wijzigen van bron Er vindt een migratie plaats van gegevens tussen softwareleveranciers, zorgverleners of locaties De ID (OID root en extensie) blijft gehandhaafd; er mag dus niet meer omgenummerd worden Gegeven wordt afgemeld voor oude bron en aangemeld als onderdeel van nieuwe bron Externe gegevens worden opgenomen in eigen dossier De ID (OID root en extensie) blijft gehandhaafd; er mag dus geen eigen nummer meer toegekend worden. Het feit dat het gegeven extern is moet ook bewaard blijven (dit is immers niet afleidbaar uit de structuur van de OID) Extern gegeven mag namelijk niet opnieuw als brongegeven worden aangemeld bij LSP Mag echter wel worden opgeleverd als onderdeel van bredere context (bijv. het huisartsdossier) Het fuseren of splitsen van: Zorginstellingen Softwareleveranciers Informatiesystemen Momenteel wordt in implementaties vaak nog getruukt met fixed values voor OIDs, maar juist gebruik vergt aanpassingen in minimaal de volgende applicatie-aspecten: databases (opslag root OIDs) configuratie (definitie lokale roots) Implementatiehandleiding HL7v3-65

66 implementatie (uitvoering conversies) 3.3.2Afgeleide root-ids Hieronder de opbouw van de binnen AORTA gebruikte OID voor applicatie ID s. Applicatie ID s zijn unieke nummers die door het LSP worden uitgedeeld aan alle applicaties die aansluiten op het LSP. Ze zijn de basis voor adressering binnen AORTA root OID van HL7.org HL7 international affiliates root OID van HL7 Nederland externe identificatiesystemen AORTA applicatie ID s Stel nu dat het LSP applicatie ID heeft uitgedeeld aan het apotheeksysteem (ZAIS) in ziekenhuis X. Deze applicatie ID heeft dus betrekking op de specifieke installatie van de applicatie van een bepaalde leverancier in deze instelling. In HL7 termen is de applicatie ID dus de extension, behorende bij de genoemde root OID. Dit betekent dat een vermelding in een HL7 v3 bericht (als device) er zo uit ziet: <device> <id extension= root= /> </device> Deze extension kan nu gebruikt worden als node bij het bepalen van OID s voor verdere identificaties binnen het ZAIS (zoals van unieke nummers voor verzonden berichten): root OID van dit ZAIS in zkh. X berichtnrs. binnen dit ZAIS Bij het gebruik van de applicatie ID als node worden de voorloopnullen verwijderd. Omdat de applicatie ID s uniek zijn binnen hun bijbehorende root, zal ook de resulterende OID uniek zijn voor deze applicatie. Strikt genomen moeten de applicatie ID s daarvoor wel allemaal dezelfde lengte hebben, anders zouden 0123 en dezelfde node opleveren, maar dit zal voor vrijwel elk identificatiesysteem gelden. Een vergelijkbaar afleidingsmechanisme kan worden toegepast om zorggegevens te identificeren. In dat geval (volgens de richtlijn beschreven in paragraaf 3.3) dient de root OID afgeleid te worden van de URA van de zorgverlener verantwoordelijk voor de zorggegevens. Implementatiehandleiding HL7v3-66

67 4 Verificatie-interacties Het transport protocol lijkt te werken, maar om een of andere reden worden mijn berichten door de ontvanger niet verwerkt. Iedereen die met het beheer van koppelingen te maken heeft herkent het bovenstaande scenario onmiddellijk. De koppeling lijkt te werken op het niveau van het transport protocollen, maar de status van de koppeling op applicatieniveau is onbekend. De interacties die in dit hoofdstuk beschreven zijn stellen het een systeem in staat te verifiëren in hoeverre de koppeling op applicatieniveau nog functioneert. De HL7 versie 3 standaard schrijft voor dat alle applicaties de verificatie-interacties moeten kunnen ontvangen en beantwoorden. Er bestaan twee typen verificatie-interacties: de HL7 Ping (formeel: de Verification Request) en de HL7 Tick (formeel: de Communication Verification Request) HL7 Ping: test of de ontvangende applicatie nog in staat is berichten inhoudelijk (semantisch) te verwerken en beantwoorden. Ping-Pong: een Ping wordt beantwoord met een Pong. HL7 Tick: test of de communicatiemodule van de ontvangende applicatie nog in staat is het bericht te ontvangen. Tick-Tock: een Tick wordt beantwoord met een Tock. Een succesvolle HL7 Ping impliceert een succesvolle HL7 Tick. Dit houdt tevens in dat het verzenden van een HL7 Tick na een succesvolle HL7 Ping geen enkele meerwaarde meer heeft. Een succesvolle HL7 Tick impliceert echter geen succesvolle HL7 Ping. Deze interacties spelen een belangrijke rol bij het oplossen van koppelingsproblemen. Voorbeeld Toepassingsscenario Stel de helpdesk van de automatiseringsafdeling in een ziekenhuis krijgt een telefoontje dat de HL7 koppeling tussen het ZIS en het Lab niet werkt. Om vast te stellen of dit het geval is, en zo ja, waar dan het probleem ligt, logt de medewerker van de helpdesk in het ZIS systeem in. 1. Vanuit de ZIS applicatie voert hij een HL7 Ping uit om vast te stellen of de ontvangende applicatie verzonden berichten nog inhoudelijk kan verwerken 2. Indien de HL7 Ping wordt beantwoord, dan werkt de koppeling en ligt het probleem (zo er een probleem is) waarschijnlijk aan de kant van de zendende applicatie. 3. Er vanuit gaande dat de HL7 Ping niet beantwoord wordt: Vanuit de ZIS applicatie voert hij een HL7 Tick uit om vast te stellen of de communicatiemodule van de ontvangende applicatie op transportniveau nog bereikbaar is en berichten verwerkt. 4. Indien de HL7 Tick wordt beantwoord (maar de HL7 Ping niet) dan blijven kennelijk de verzonden berichten hangen in de communicatiemodule van de ontvangende applicatie. Het probleem is dus niet primair communicatiegerelateerd, maar gerelateerd aan de verwerking van de berichtinhoud door de ontvangende applicatie. 5. Er vanuit gaande dat de HL7 Tick niet wordt beantwoord (en dus de HL7 Ping ook niet wordt beantwoord): Vanuit de de ZIS applicatie voert hij een transport- Implementatiehandleiding HL7v3-67

68 protocol check uit om vast te stellen of het Labsysteem bereikbaar is (bijvoorbeeld met behulp van een TCP/IP Ping in het geval dat TCP/IP gebruikt wordt als transportprotocol) 6. Indien het Labsysteem bereikbaar is op transportniveau (maar de HL7 Tick wordt niet beantwoord) dan hangt waarschijnlijk de ontvangende communicatiemodule. 7. Indien het Labsysteem niet bereikbaar is op transportniveau, dan ligt het probleem op transportniveau. Merk op dat het antwoord op een HL7 Ping of HL7 Tick foutmeldingen of waarschuwingen kan bevatten. Deze meldingen moeten worden betrokken bij de foutanalyse. 4.1 Applicatie verificatie: HL7 Ping De HL7 Ping interactie test of de ontvangende applicatie nog in staat is berichten inhoudelijk (semantisch) te verwerken en beantwoorden Dynamisch Model Figuur 16: verification request interactie diagram De Verification Request Placer stuurt de HL7 Ping interactie (formeel bekend als Verification Request, COMT_IN118118) naar de Verification Request Filler, een rol die door alle applicaties die HL7 versie 3 berichten kunnen verwerken gespeeld wordt. De Verification Request Filler beantwoord onmiddelijk (synchroon) het bericht met een Verification Response (COMT_IN229229) 4.1.2Bericht Model HL7 Ping De interactie en het bijbehorende antwoorden hebben een relatief eenvoudige structuur: ze bevatten geen payload en bestaan uitsluitend uit wrappers. De HL7 Ping bevat de waarde NE in het attribuut Message.acceptAckCode. Zie de beschrijving van de diverse wrappers voor details aangaande het gebruik van klassen en attributen. Implementatiehandleiding HL7v3-68

69 Het antwoord op een HL7 Ping kan foutmeldingen of waarschuwingen bevatten. Syntax en verbindingsproblemen worden aangegeven in de klassen Acknowledgement en AcknowledgementDetail (zie de paragrafen en 2.2.3). Eventuele inhoudelijke issues worden in de DetectedIssue klasse aangegeven (zie paragraaf 2.4.3), al is het gebruik daarvan gezien het karakter van de HL7 Ping onwaarschijnlijk. Interactie: Verification Request (COMT_IN118118) Trigger Event Send verification request COMT_MT Transmission Send Message Payload MCCI_MT Wrapper ControlAct Wrapper Trigger Event Control Act MCAI_MT Message Type n.v.t n.v.t Interactie: Verification Response (COMT_IN229229) Trigger Event Send verification response COMT_TE Transmission Application Level Acknowledgement MCCI_MT Wrapper ControlAct Wrapper Trigger Event Control Act MCAI_MT Message Type n.v.t n.v.t 4.2 Communicatie verificatie: HL7 Tick De HL7 Tick interactie test of de communicatiemodule van de ontvangende applicatie nog in staat is het bericht te ontvangen Dynamisch Model Figuur 17: communication verification request interactie diagram De Verification Request Placer stuurt de HL7 Tick interactie (formeel bekend als de Communication Verification Request, COMT_IN113113NL) naar de Verification Request Filler, een rol die door alle applicaties die HL7 versie 3 berichten kunnen verwerken gespeeld wordt. De Verification Request Filler beantwoord onmiddelijk (synchroon) het bericht met een Accept Acknowledgment (MCCI_IN000002, zie paragraaf voor details) Implementatiehandleiding HL7v3-69

70 4.2.2Bericht Model HL7 Tick De gebruikte interacties hebben een relatief eenvoudige structuur: ze bevatten geen payload en bestaan uitsluitend uit wrappers. De HL7 Tick bevat de waarde AL in het attribuut Message.acceptAckCode. Zie de beschrijving van de diverse wrappers voor details aangaande het gebruik van klassen en attributen. Het antwoord op een HL7 Tick kan foutmeldingen of waarschuwingen bevatten. Syntax en verbindingsproblemen worden aangegeven in de klassen Acknowledgement en AcknowledgmementDetail (zie paragraaf 2.2.2). Interactie: Communication Verification Request (COMT_IN113113NL) Trigger Event Send communication verification request COMT_MT Transmission Send Message Payload MCCI_MT Wrapper ControlAct Wrapper Trigger Event Control Act MCAI_MT Message Type n.v.t n.v.t Interactie: Accept Ack (MCCI_IN000002) Trigger Event Send Message Accept Acknowledgement MCCI_TE Transmission Accept Acknowledgement MCCI_MT Wrapper Control Act Wrapper n.v.t n.v.t. Message Type n.v.t. n.v.t. Implementatiehandleiding HL7v3-70