Inleiding

Doel

Op deze pagina worden vragen beantwoord die op kunnen komen tijdens het implementeren van de informatiestandaard Acute zorg. Deze pagina zal daarom regelmatig bijgewerkt worden als er nieuwe vragen voorbij komen die hier geadresseerd dienen te worden.

Wat is toegestaan om te gebruiken als <id> waarden?

In de berichten komen op een aantal plekken <id>'s voor die bedoeld zijn om de template-instantiaties uniek te kunnen identificeren. Uniek betekent niet alleen binnen het bericht geen 2 keer dezelfde, maar zelfs over alle berichten wereldwijd. Een id bestaat uit een root en een extension, waarbij de root gebruikt wordt als basis, en over het algemeen gebaseerd zal zijn op leverancier, zorgaanbieder of een combinatie daarvan. Deze heeft de vorm van een OID: zie https://www.hl7.nl/wiki/index.php/OIDs_en_FHIR_System_URIs en http://www.hl7.nl/wiki/index.php/Implementatiehandleiding_HL7v3_basiscomponenten#Identificatiemechanismen, en in het bijzonder daaronder http://www.hl7.nl/wiki/index.php/Implementatiehandleiding_HL7v3_basiscomponenten#OID_gerelateerde_implementatieaspecten.

Op basis van die informatie zou een leverancier kunnen kiezen voor:

• Op URA basis:

 2.16.528.1.1007.3.3. [OID van URA] 99999999. [Zorgaanbieder URA] 2222. [Leverancier nummer] 205 [ID type]

• Op leverancier OID basis:

 2.16.840.1.113883.2.4.3.11.999. [OID van leverancier] 1111. [Zorgaanbieder nummer] 205 [ID type]

• Op Applicatie ID basis:

 2.16.840.1.113883.2.4.6.6. [OID van Applicatie-ID] 70000003. [Applicatie-ID] 205 [ID type]

Hierin zijn de volgende variabele nummers gedefinieerd:

Zorgaanbieder URA - het UZI register abonneenummer (UZI = Unieke Zorgverlener Identificatie)
OID van leverancier - een OID aangevraagd door de leverancier bij HL7; uniek voor elke leverancier
Zorgaanbieder nummer - een door de leverancier zelf verzonnen nummer die uniek de zorgaanbieder identificeert
Applicatie ID - een door het LSP uitgegeven ID die uniek is voor het specifieke software pakket bij de specifieke zorgaanbieder
ID type - optioneel: een door de leverancier verzonnen nummering om de verschillende plekken in het bericht waar ID's gebruikt worden te onderscheiden

Het extensie attribuut van het <id> element is een vrij in te vullen string, die dus in combinatie met dezelfde root nooit een tweede keer gebruikt mag worden. Hiervoor kan bijvoorbeeld een automatisch gegenereerde GUID worden gebruikt.

Het is op zich toegestaan voor de root een andere constructie dan een van de drie bovenstaande opties te gebruiken, maar in dat geval zal bij de kwalificatie wel gevraagd worden aan te tonen dat de gekozen oplossing ook voldoet aan de eisen voor (wereldwijd) uniek en persistent.

Specifiek voor Meldkamer/Ambulance software is ook toegestaan:

een OID op basis van de AZN OID:

 2.16.840.1.113883.2.4.3.32. [OID onder beheer van AZN] 5. [door AZN hiervoor gereserveerd] 14. [regionummer RAV] 205 [ID type]

Wanneer mag ik hetzelfde <id> hergebruiken?

Let op: als het identieke bericht nogmaals verstuurd wordt, bijvoorbeeld vanwege een time-out bij de ontvanger, is het wel toegestaan hetzelfde id te gebruiken, maar zodra er iets aan de inhoud verandert wijzigt ook het id. Bij een bericht dat de opvolger is van een eerder bericht is dus het id anders, wordt het versionNumber opgehoogd, en blijft de setId gelijk.

Hoe zit het met de ID, setID en VersionNumber van berichten en bijlagen?

Zoals hierboven is toegelicht bij 'Wat is toegestaan om te gebruiken als <id> waarden?', is de ID de unieke identifier van het bericht / de bijlage, op basis waarvan een ontvangende partij kan beoordelen of die dit bericht / deze bijlage al eerder ontvangen heeft, en dus kan negeren. In sommige gevallen komt het voor dat er een update van een bericht / bijlage nodig is, bijvoorbeeld als de huisarts net de SEH verwijzing verstuurd heeft, en de patiënt nog iets belangrijks noemt. Dan zal de huisarts een update willen sturen van de net verzonden verwijzing. Voor de ontvangende partij betekent een update dat die in de plaats komt van de vorige, en die dus bijvoorbeeld als verouderd moet worden gemarkeerd, zodat een zorgverlener niet per ongeluk met verouderde informatie aan de slag gaat. Bij een bijlage is bijvoorbeeld een tweede ECG geen update, omdat de eerste daarmee niet mag vervallen. Alleen als het gaat om een tekst-gebaseerd bestand, zoals een PDF, waarbij een tweede versie een bijgewerkte/uitgebreide versie van het origineel is, gaat het om een update.

Voor updates biedt HL7 het setId/versionNumber mechanisme: het setId geeft aan dat verschillende berichten bij dezelfde set behoren, en aan de hand van het oplopende versionNumber kan de ontvanger zien welke de meest recente is. N.B. deze nummers moeten worden opgeslagen zodat als hetzelfde bericht / bijlage nogmaals verstuurd wordt, ze dezelfde ID's krijgen. Bij berichten die niet in zijn geheel worden opgeslagen, zijn de setId en versionNumber toch relevant als er een mogelijkheid is dat er een update verstuurd moet worden. Verzendende partijen vullen deze dus als volgt in:

een nieuw bericht / bijlage krijgt een nieuw ID, een nieuw setId, en versionNumber 1.
een update krijgt een nieuw ID, het setId van het originele bericht / bijlage, en een versionNumber 1 hoger dan de meest recent verstuurde met dat setId.

Waar staat de waarde bij een template die alleen een boolean waarde representeert?

Er zijn templates met bijvoorbeeld een <observation>, die als enige doel hebben een boolean waarde te kunnen bevatten, zoals 'No Reanimation Statement' (2.16.840.1.113883.2.4.3.11.60.55.10.1175), en 'Insurance Valid' (2.16.840.1.113883.2.4.3.11.60.55.10.9007). Deze observations bevatten alleen een <templateId> en een <code>, maar geen waarde - die lijkt dus te ontbreken. Maar hier wordt iets uit HL7v3 CDA gebruikt dat in eerste instantie bedrieglijk lijkt, maar waar de waarde wel degelijk aanwezig is: de waarde zit namelijk in het @negationInd attribuut van de <observation> zelf. <observation negationInd="true" classCode="OBS" moodCode="EVN">

In Art-Decor wordt bij de betreffende templates in de toelichting bij het attribuut beschreven hoe de 'true' en 'false' waarden geïnterpreteerd moeten worden. Omdat het attribuut negationInd heet, werken de waarden omgekeerd ten opzichte van wat de template naam beschrijft, dus bijvoorbeeld bij 'Insurance Valid?' staat in de toelichting: 'Indien @negationInd="true" dan is er geen verzekering.'

Waar vind ik ... ?

De plek waar alles over de publicaties te vinden is, is ART-DECOR. Vanuit de publicatie pagina (https://decor.nictiz.nl/pub/acutezorg/) kan je naar de HTML pagina's van ART-DECOR door de juiste deelpublicatie te selecteren, en de XML materialen downloaden.

Wijzigingen in de nieuwe publicatie	ART-DECOR - project
Specificatie van bericht-inhoud	Functioneel: ART-DECOR - scenario's Technisch: ART-DECOR - templates
XML Voorbeelden	Individueel element - ART-DECOR template definitie, bij de beschrijving van het element Individueel template - ART-DECOR template definitie, sectie 'Voorbeeld' uitklappen Compleet bericht - XML-materialen, in de xml-acutezorg folder
Bericht validatoren	XML-materialen - schemas en schematron folders. In de voorbeeldberichten kan ook gekeken worden welk schema en schematron gebruikt dienen te worden.

Kwalificatie scripts	Deze worden toegestuurd door het kwalificatieteam na aanmelding
Kwalificatie berichten	Deze zijn op de ART-DECOR kwalificatieserver op te vragen door de software; het benodigde account wordt geregeld bij aanmelding, en daar worden de juiste publicaties en kwalificaties aan gekoppeld.
Kwalificatie validatoren	Op de ART-DECOR kwalificatieserver kan op de tab 'Tests' het benodigde kwalificatie package opengeklapt worden, en het betreffende bericht aan gekoppeld worden. Dat wordt dan zowel op technische correctheid gecontroleerd (of het aan de ART-DECOR specificatie voldoet), als op de verwachte inhoud ten opzichte van het kwalificatie script. Bij verstuurde of handmatig geladen berichten kan ook alleen de technische correctheid gecontroleerd worden op de 'Validatie' tab.

Frequently Asked Questions - Acute Zorg

Inhoud