Implementatiehandleiding HL7v3 Wrappers, Vocabulaires, Identificatiemechanismen. - Versie 2.5 - Status : Definitief Datum : augustus 2006
Inhoudsopgave 1 Inleiding 4 1.1 Doel van dit document 4 1.2 Doelgroep 4 1.3 Totstandkoming van dit document 4 1.4 Opbouw van dit document 4 1.5 Verschillen met vorige releases van dit document 5 1.6 Normatieve status van dit document 6 2 Message Wrappers 7 2.1 Inleiding 7 2.1.1 Wrapper specialisaties 7 2.1.2 HMDs en Message Types 8 2.2 Transmission Wrapper beschrijving 8 2.2.1 Transmission Wrapper R-MIM beschrijving (MCCI_RM000100) 9 2.2.2 Accept Acknowledgement (MCCI_RM000200) 13 2.2.3 Application Response/Acknowledgement (MCCI_RM000300) 15 2.3 Batch Transmission Wrapper beschrijving 18 2.3.1 Batch Wrapper D-MIM (MCCI_DM000000) 19 2.4 Trigger Event Control Acts wrappers (TECA) 21 2.4.1 Generieke D-MIM beschrijving (MCAI_DM000000) 21 2.4.2 Trigger Event Control Act R-MIM (MCAI_RM700200) 25 2.4.3 Application Acknowledgement (MCAI_RM700200) 26 2.4.4 Master File/ Registry Act wrapper (MFMI_RM700700) 29 2.5 Queries, Continuations en Responses (TECA) 31 2.5.1 Query By Parameter Specification TECA (QUQI_RM021000) 34 2.5.2 Query Continuation/Cancel Control Act (QUQI_RM000001) 36 2.5.3 Query Response Trigger Event Control Act (QUQI_RM120000) 38 2.5.4 Master File / Registry Query Response (MFMI_RM700710) 40 2.6 Voorbeeld Message Transmission wrapper 42 2.7 Voorbeeld Trigger Event Control Act 43 2.8 Voorbeeld Accept Acknowledgement 44 2.9 Voorbeeld Application Acknowledgement 45 3 Identificatiemechanismen en Vocabulaires 48 3.1 Identificatiemechanisme 48 3.1.1 Inleiding Object Identifiers 49 3.1.2 Uitgiftemechanisme OIDs 50 3.1.3 Identificatiemethode 52 3.1.4 Identificatiesystemen OID Referentietabel 55 3.2 Vocabulaire voor berichtspecificaties 56 3.2.1 Inleiding 56 3.2.2 HL7 Vocabulary Domain Values 57 3.2.3 Vocabulaires OID-Referentietabel 63 3.3 OID gerelateerde implementatie aspecten 64 3.3.1 Gevolgen van OIDs voor GBZ applicaties 65 3.3.2 Afgeleide root-ids 66 4 Verificatie-interacties 67 4.1 Applicatie verificatie: HL7 Ping 68 4.1.1 Dynamisch Model 68 4.1.2 Bericht Model HL7 Ping 68 4.2 Communicatie verificatie: HL7 Tick 69 4.2.1 Dynamisch Model 69 4.2.2 Bericht Model HL7 Tick 70 Implementatiehandleiding HL7v3-2
Implementatiehandleiding HL7v3-3
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 2.4. 1.4 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
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 2004. Deze artefacts worden in dit document niet in detail besproken, hiervoor wordt verwezen naar de HL7 versie 3 standaard zelf (zie http://www.hl7.org/v3ballot7/html/index.htm). 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 2.4.1 versie van dit document (april 2006) zijn een aantal wijzigingen aangebracht. De aangebrachte wijzigingen sinds versie 2.4.1 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 2.2.1 en 2.3.1 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 2.2.1 en 2.3.1 voor details. Het anders verwoorden van het gebruik van acceptackcode in paragraaf 2.2.1. 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, 2.2.3 en 2.4.3. Het toevoegen van een FAQ over het gebruik van het Acknowledgement.typeCode in antwoordbatches in paragraaf 2.2.3. Het documenteren van het gebruik van het effectivetime attribuut in de TECA wrapper van antwoordberichten, zie paragraaf 2.4.1. Het nader toelichten van de relatie tussen de UZI beroepstitel code 00.000 en de HL7 berichten. Zie paragraaf 2.4.1 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 2.4.1 voor details. Het gebruik van de startresultnumber en continuationquantity attributen in vraagberichten is niet langer toegestaan, zie paragraaf 2.5.2. 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 2.5.3. Het toevoegen van voorbeelden van foutmeldingen in paragraaf 2.8 en de nieuwe paragraaf 2.9. Implementatiehandleiding HL7v3-5
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 3.2.2. 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 4. 1.6 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
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. 2.1.1Wrapper 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
resulteren meestal in de verplichting voor de ontvanger te reageren met een application response/acknowledgement, waarvoor eveneens een TECA specialisatie bestaat. 2.1.2HMDs 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
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 2.2.2. 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
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
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_IN100002. De OID van de assigning authority van deze identificatie is de Interaction ID OID uitgegeven door de HL7 organisatie: 2.16.840.1.113883.1.6. 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 2.16.840.1.113883.2.4.3.11.1 extensie 511 april2006-release: root 2.16.840.1.113883.2.4.3.11.1 extensie 604 augustus2006-release: root 2.16.840.1.113883.2.4.3.11.1 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 2.2.2 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 2.5.1 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
o NE in vraagberichten met een I (Immediate) responseprioritycode. Zie paragraaf 2.5.1 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 3.1.3 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
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_MT000100 2.2.2Accept 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 2.4.3 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
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
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 3.2.2 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_MT000200 Interactie: Accept Ack (MCCI_IN000002) Trigger Event Send Message Accept Acknowledgement MCCI_TE000002 Transmission Accept Acknowledgement MCCI_MT000200 Wrapper Control Act Wrapper n.v.t n.v.t. Message Type n.v.t. n.v.t. 2.2.3Application 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 2.4.3 voor een nadere beschrijving van de application acknowledgement. Implementatiehandleiding HL7v3-15
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
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 3.2.2 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_MT000300 Implementatiehandleiding HL7v3-17
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 2.2.2 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
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
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_IN200100 voor batches, en MCCI_IN200101 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: 2.16.840.1.113883.1.6. 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 2.16.840.1.113883.2.4.3.11.1 extensie 511 april2006-release: root 2.16.840.1.113883.2.4.3.11.1 extensie 604 augustus2006-release: root 2.16.840.1.113883.2.4.3.11.1 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
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_TE200100 Batch Wrapper Batch MCCI_MT200100 Interactie: Batch Response (MCCI_IN200101) Trigger Event Send batch Reponse MCCI_TE200101 Batch Wrapper Batch Response MCCI_MT200101 2.4 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
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_TE100001 of COMT_TE200200. Deze waarden zijn opgenomen bij de documentatie van de berichten en interacties. De te gebruiken OID is: 2.16.840.1.113883.1.18. 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
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 2.16.840.1.113883.2.4.6.6 en extensie 1) en de SBV-Z BSN applicatie (met root 2.16.528.1.1007.4 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 00.000 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