HL7v3

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.

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