HL7v3

Uit informatiestandaarden
Versie door Wetering (overleg | bijdragen) op 27 jan 2021 om 14:41 (Nieuwe pagina aangemaakt met '=Algemene uitleg HL7v3= Deze pagina bevat algemene uitleg of implementatie-instructies over HL7v3. Het betreft onder andere zaken waar we vaker vragen over hebben b...')
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)
Naar navigatie springen Naar zoeken springen

Algemene uitleg HL7v3

Deze pagina bevat algemene uitleg of implementatie-instructies over HL7v3. Het betreft onder andere zaken waar we vaker vragen over hebben beantwoord.

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 scherma'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