HL7v3

1 Algemeen

HL7 versie 3 is een van leden van de standaardfamilies van de organisatie Health Level 7 vooral bekend als HL7. Andere zijn [[HL7v2|HL7 versie 2] (HL7v2) en HL7 FHIR (FHIR).

HL7 versie 3, vanaf hier HL7v3, is eerst een vooral een methodologie om tot standaarden te komen en bevat in mindere mate concrete implementatiehandleidingen. HL7v3 is dus niet graduele of backward compatibele versie met zijn voorganger HL7v2, zoals FHIR wat na HL7v3 is ontwikkeld niet zomaar een graduele of backward compatibele versie van HL7v3 is.

Op basis van HL7v3 methodologie zijn heel erg veel producten gemaakt. De bekende is Clinical Document Architecture (CDA). In Nederland gebruiken we in diverse andere informatiestandaarden naast CDA ook nog andere producten die met de methodologie zijn gebouwd. Al het nieuwe werk in informatiestandaarden gebeurt op basis van CDA.

Deze pagina bevat algemene uitleg of implementatie-instructies over HL7v3. Het betreft onder andere vaker gestelde vragen.

1.1 Templateversionering

HL7v3 waaronder CDA wordt gedefinieerd op basis van templates. Deze zijn opgesteld op basis van de HL7 standaard voor templatedefinities HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1.

Templates hebben een identificatie in de vorm van een OID en een versie in de vorm van een ISO 8601 tijdstempel zonder tijdzone (yyyy-mm-ddThh:mm:ss).

Templates zijn, tenzij expliciet anders gespecificeerd open. Dat wil zeggen dat alleen dingen worden gespecificeerd waarvoor specificatie nodig is binnen de bekende use case(s). Deze specificaties zijn in feite een inperking op het onderliggende model waarvan de structuur normalerwijs in een XML Schema is gespecificeerd. Een zender mag meer sturen, binnen de grenzen van het onderliggende model, en een ontvanger dient deze extra informatie minimaal te kunnen negeren maar mag deze uiteraard ook verwerken.

Principes voor versionering:

• Backward compatibele wijzigingen: nieuwe templateversie met behoud van het id, maar met een nieuwe versie (tijdstempel)
  • Waar relevant hebben templates een verplicht templateId element waarin attribuut root matcht met het id van de gebruikte template en optioneel een attribuut extension dat matcht met de versie van het template
  • Het element templateId kan meerdere keren voorkomen. De meeste specifieke template eerst Ieder templateId moet 'waar' zijn
    • Een zender moet instaan voor wat hij stuurt. Voor ieder templateId dat hij aangeeft moet gelden dat hij daarvoor de specificatie heeft gevolgd
    • Een ontvanger moet instaan voor de integriteit van zijn systeem bij verwerking van wat hij ontvangt. Hij mag op een of meerdere van templateId elementen valideren of die kloppen. Een ontvanger hoeft niet alle templateId elementen te kennen. Een ontvanger hoeft zichzelf ook niet afhankelijk te maken van aanwezigheid van templateId elementen om validatie doen. De context van ontvangst en/of context van een te valideren fragment kunnen ook aanleiding zijn om een of meerdere validatieregels uit te voeren alvorens het ontvangen bericht te verwerken.
• Niet-backward compatibele wijzigingen: nieuwe template met een nieuw id en een eigen tijdstempel
  • De nieuwe template kan middels een wat meer informeel relationship bijvoorbeeld van type "ADAPT" worden gekoppeld aan zijn voorganger

Voorbeeld:

<observation>
    <templateId root="1.2.3" extension="2021-01-01T00:00:00"/>
    <templateId root="1.2.3"/>
    <!-- ... -->
</observation>

In dit voorbeeld is er sprake van een observation die voldoet aan twee templatedefinities. Beide definities hebben id 1.2.3. De eerste zegt expliciet welke versie deze heeft. De tweede niet. De eerste is, naar verwachting, de meeste specifieke van de twee. Als de ontvanger de versie 2021-01-01T00:00:00 niet kent, dan valideert/verwerkt hij volgens de versie die hij wel kent. Vanwege de backward compatibile aard van versies, maakt het niet uit welke versie wordt gebruikt. De delen die de ontvanger niet kent, zal hij op die manier kunnen negeren. Dit principe garandeert een zekere mate van houdbaarheid van implementaties ten opzichte van een zekere mate van flexibiliteit in een veld waar niet alle communicatiepartners tegelijk updates doen.

1.2 XML Schema attributen realmCode, typeID en templateId

Gestelde vragen:

• In sommige XML Schema's staan attributen gedefinieerd die nergens worden beschreven. Wat is daarmee aan de hand?
• Ik kom in een instance dit tegen, mag dat?

    <ControlActProcess moodCode="EVN" templateId="" typeID="" realmCode="">
        <authorOrPerformer typeCode="AUT">

Antwoord:

Deze schema's zijn uit 2004 en ze zijn meestal van VZVZ (want vaak wrappers). In die tijd zat er een bug in de schemagenerator van HL7 Internationaal en/of is men later van gedachten veranderd. In elk geval bestaat templateId als attribuut vrij kort daarna alleen nog als element. Verder is behalve in CDA nergens in HL7v3 gebruik gemaakt van typeID en/of realmCode. Dat is ook de reden dat je voor geen van deze attributen een specificatie ergens binnen Nictiz en/of VZVZ zult zien, behalve bij het ClinicalDocument (CDA).

XSD: Optioneel attribuut. Het datatype van typeID en templateId is een list van oid. Een oid is gedefinieerd als niet-lege string (pattern '[0-2](\.(0|[1-9][0-9]*))*')

XSD: Optioneel attribuut. Het datatype van realmCode is een list van cs. Een cs is gedefinieerd als code uit een door HL7 voorgeschreven systeem waarbij volgens het XSD dit een potentieel lege string kan zijn maar in elk geval geen whitespace bevat (pattern '[^\s]*')

Als je deze dingen in het RIM uit 2004 opzoekt - zoals gezegd wij definiëren zelf doelbewust niets hierover - vind je:

1. realmCode SET<CS> Binding CNE Realm (leeg ConceptDomain, maar voor Realms gebruik je normaal ISO 3166-alpha 2 landcodes in hoofdletters of "UV" wat staat voor Universal Realm) Definition: When valued in an instance, this attribute signals the imposition of realm-specific constraints. The value of this attribute identifies the realm in question.
2. typeId SET<OID> Definition: When valued in an instance, this attribute signals the imposition of constraints defined in an HL7-specified message type. This might be a common type (also known as CMET in the messaging communication environment), or content included within a wrapper. The value of this attribute provides a unique identifier for the type in question.
3. templateId SET<OID> Definition: When valued in an instance, this attribute signals the imposition of a set of template-defined constraints. The value of this attribute provides a unique identifier for the templates in question.

Conclusie na dit alles:

1. Het XML Schema laat het technisch toe door zijn definitie op basis van xs:list dat je een "lege lijst" stuurt. Zodra je iets in een van deze drie attributen zet, dan geldt wel cs of oid.
2. De definitie in het RIM van deze attributen zegt logisch gezien dat als je in een instance deze attributen gebruikt, deze een bepaalde betekenis hebben. Door ze leeg door te geven, geven ze echter niet die beoogde betekenis.
3. Dus: technisch komt het erdoor. Logisch en functioneel biedt het geen meerwaarde en alleen maar afleiding.
4. De vraag of aanwezigheid van de attribuutnaam in een instance al gelijk staat aan "valued in an instance" vind ik een lastige, maar ik ga uit van wel: waarom zou je een element of attribuut in een instance opvoeren als je geen bedoeling daarmee hebt? Je dwingt een ontvanger er aandacht aan te besteden terwijl er geen meerwaarde uit te halen valt.
5. Gebruik deze attributen niet tenzij gespecificeerd