Implementatiehandleiding HL7v3 basiscomponenten v2.2 Part2

Implementatiehandleiding
HL7v3 Basiscomponenten deel 2

Inleiding

Naar inleidende hoofdstukken

Datatypes

 

Inleiding

Deze sectie beschrijft de belangrijkste datatypes, 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.

Alleen de binnen de modellen van deze handleiding gebruikte datatypes worden uitgelegd. Voor verdere informatie zie HL7v3 standaard/ballotmateriaal, met name de hoofdstukken "abstract data types" en "XML ITS data types".

 

Algemene toelichting op het gebruik van XML

Het uitwisselformaat voor HL7 versie 3 berichten is (op dit moment) de Extensible Markup Language (XML, zie [XML]). Het is niet de bedoeling van deze gids toelichting van XML in het algemeen te geven maar een paar kenmerken en vereisten worden hier wel genoemd.

 

Character Set

De encoding in de XML-proloog van een HL7 versie 3 bericht moet UTF-8 zijn.

<?xml version="1.0" encoding="utf-8"?>

of (als standaardwaarde)

<?xml version="1.0"?>

 

Speciale tekens

In XML zijn bepaalde tekens in gegevens te vervangen door combinaties van tekens (character entities) omdat ze in de XML-structuur een andere en speciale betekenis hebben. Een XML character entity is een "&" gevolgd door een aantal tekens en afsluitend een ";". De sequentie wordt door de XML-processor vervangen door het speciale teken.

De volgende tabel geeft een (niet volledige) overzicht over deze tekens. Voor verdere informatie zie de XML-specificatie ([XML]).

Speciale tekens in gegevens	Te vervangen door	Opmerkingen
&apm;	&
<	&lt;
>	&gt;
'	&apos;	Een ' is binnen gegevenswaarden niet toegestaan als deze waarden ook door dit teken worden begrensd en moet dan worden vervangen.
"	&quot;	Een " is binnen gegevenswaarden niet toegestaan als deze waarden ook door dit teken worden begrensd en moet dan worden vervangen.

XML-voorbeelden

<text>Waarden > 5 mg/l zijn pathologisch</text>

→ XML-processor levert: Waarden > 5 mg/l zijn pathologisch

<name>Wijkapotheek Leermans & zonen</name>

→ XML-processor levert: Wijkapotheek Leermans & zonen

<code ... displayName="'s-Gravenhage"/> of
<code ... displayName=''s-Gravenhage'/>

→ XML-processor levert: 's-Gravenhage

<code ... displayName="" 's-Gravenhage""/>

→ XML-processor levert: "'s-Gravenhage"

 

Algemene opbouw van een HL7 versie 3 bericht

HL7 versie 3 berichten hebben als root element altijd de naam van de bijhorende interactie. Zo begint een HL7 versie 3 bericht op basis van interactie "PORX_IN123456" met een XML-rootelement <PORX_IN123456>. De HL7v3 interactie schema's (voor toelichting W3C schema, zie [XMLSC]) hebben in het algemeen dezelfde naam als het root element.

<?xml version="1.0"? encoding="utf-8">
<PORX_IN123456 ...
   xmlns="urn:hl7-org:v3"
   xmlns:voc="urn:hl7-org:v3/voc"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
       ... HL7 versie 3 bericht  inclusief wrappers en payload
</PORX_IN123456>

Een schemaLocation kan de zender wel toevoegen, maar de ontvanger mag de informatie in schemaLocation niet gebruiken. Om te voorkomen dat schemareferenties verwerkt zouden worden, wordt het zenden ervan sterk ontraden.

In het geval van een gebundelde set HL7-interacties in een zogeheten batch heeft het root element de naam van de batch interactie en de verschillende interacties (deelberichten) zijn daarin opgenomen. Voor verdere informatie zie [NIWrappers].

 

Transport van de XML-berichten

In deze gids wordt niets over de feitelijke transport van de berichten gezegd, zie hiervoor de NICTIZ-gidsen ([NIInfraDom], [NIWebSvPrf]).

 

XML-representatie van modelklassen en -attributen

 

Klassen, attributen en datatypes

De attributen van klassen in de HL7-modellen worden op een bepaalde, vast voorgedefinieerde wijze omgezet naar de XML-representatie. [Merk overigens op dat de term 'attribuut' hier ongelukkig is, omdat verwarring kan ontstaan met XM-attributen. Vandaar dat buiten deze paragraaf zoveel mogelijk in XML-termen wordt gesproken.
Voorbeeld:

In de bijgaande klasse "Patient" zijn een aantal modelattributen opgenomen, waaronder de classCode (met als vaste waarde "PAT"), id, addr en telecom. Elk van de modelattributen heeft onder meer een naam, bijvoorbeeld id; een datatype, bijvoorbeeld AD; een cardinaliteit, bijvoorbeeld [0..*]

Met uitzondering van de structurele attributen (zie hieronder) worden de modelattributen weergeven als XML-elementen. De elementen dragen de naam zoals in het model aangegeven. Bijvoorbeeld als het attribuut id is, dan is de naam van het XML-element <id/>.

<id ... />
<addr ... />
<telecom ... />

In het XML-schema is de cardinaliteit van het modelattribuut meegenomen. In bovenstaand voorbeeld is <id> verplicht [1..1], <addr> [0..1] en <telecom> [0..*] optioneel.

Noot:

1. Let op: in de huidge XML-schemataal kan de cardinaliteit van een XML-element vastgelegd worden maar of de "inhoud", d.w.z. de gegevens volgens de datatype specificatie aanwezig zijn of niet of de juiste combinatie hebben, is niet valideerbar met een schema zoals ze nu uitgebracht zijn. Hier is echter een tweede validatestap nodig als gegarandeerd moet worden dat bijvoorbeeld een II datatype altijd met een root/extension attribuutpaar gevuld is of een nullFlavor attribuut bevat. Om dit niveau van validatie mogelijk te maken zijn verdere validatiestappen nodig met zogenaamde constraint talen (bijvoorbeeld OCL, Schematron).

De XML-elementen hebben XML-attributen (let op het andere gebruik van de term!), die door het datatype zelf worden bepaald. De hier gebruikte notatievorm is als volgt:

@naam attribuut

beschrijving / uitleg / betekenis (datatype / pattern)

N.B. een @ wordt hier als prefix voor XML-attributen gebruikt om het beter te kunnen onderscheiden van XML-elementnamen. Voor de datatypes zijn attributen gedefinieerd die de gegevens dragen. Zo heeft in het voorbeeld het id modelattribuut het datatype II (Instance Identifier). De bij dit datatype behorende attributen zijn bijvoorbeeld root en extension en worden als XML-attributen bij het element weergegeven. Zie hieronder:

<id root="" extension="" />

Verdere toelichtingen over datatypes en de bijbehorende XML-attributen zijn in de volgende hoofdstukken per datatype opgenomen.

 

Uitzonderingen met gegevens als element content

Voor de meeste datatypes komen de feitelijke gegevens in de XML-attributen terecht. Er bestaan echter een aantal uitzonderingen. Voor de datatypes Binary, Encapsulated Data, Entity Name, Person Name, Organization Name, Trivial Name, Address en Character String worden de gegevens als zogenaamde 'element content' weergegeven.
Voorbeeld: de componenten van een adres worden door subelementen van het <addr> element met de gegevens als 'element content' (in het voorbeeld in rood weergegeven).

<addr>
 <streetName>Purmersteenweg</streetName>
 <houseNumber>42</houseNumbe>
 <postalCode>1441 DM</postalCode>
 <city>Purmerend</city>
</addr>

 

Gecombineerde datatypes

Er bestaan een aantal gecombineerde datatypes. Zo wordt bijvoorbeeld een interval met een onder- en een bovengrens aangeduid en stelt een ratio een verhouding van twee waarden voor.
Bij gecombineerde datatypes is altijd de substructuur (bijvoorbeeld <low> en <high> bij een interval) weergegeven als subelementen van het desbetreffende datatype element.

<effectiveTime>
 <low value="20040507"/>
 <high value="20040909"/>
</effectiveTime>

Bij beschrijving van gecombineerde datatypes worden subelementen als volgt genoteerd:

<naam subelement>

beschrijving / uitleg / betekenis (datatype)

 

Structurele attributen

Er is een lijst van modelattributen die niet als aparte elementen worden gerepresenteerd maar als XML-attributen van het XML-element dat hoort bij de klasse als geheel. Dit zijn:

RIM klasse		Attribuut
	Act	moodCode
		classCode
		negationInd
		levelCode
	ActRelationship	typeCode
		inversionInd
		contextControlCode
		contextConductionInd
		negationInd
	Entity	classCode
		determinerCode
	Participation	typeCode
		contextControlCode
	Role	classCode
		negationInd
	RoleLink	typeCode

Voorbeeld: in de modelklasse Observation zijn twee modelattributen, classCode en moodCode, die structurele attributen zijn en dus niet als aparte XML-elementen verschijnen, maar als XML-attributen van het XML-element <Observation>, zoals hieronder:

<Observation classCode="OBS" moodCode="EVN"/>

 

Cardinaliteit, mandatory en conformance

In de HL7 versie 3 berichten kan bij de modelattributen gebruik gemaakt worden van verdere eigenschappen zoals de cardinaliteit van het betreffende modelattribuut. De volgende tabel geeft een overzicht van de betekenis van deze aanvullende eigenschappen.

Begrip	Verklaring / opmerkingen
Cardinaliteit	Specificeert het minimale en maximale aantal herhalingen van het betreffende modelonderdeel (d.w.z. modelattribuut of associatieve klasse) in de XML-instance. Bijvoorbeeld 1..* houdt in dat het XML-element minimaal 1 keer aanwezig moet zijn, en dat het XML-element een onbeperkt keer mag herhalen in de instance.
Mandatory	Een "mandatory" (vereist) modelonderdeel moet altijd aanwezig zijn in de XML-instance en er is geen nullFlavor toegestaan. Zonder dit onderdeel is de XML-instance ongeldig. Voor "mandatory" modelonderdelen (en bijbehorend XML-element) is het aantal herhalingen (cardinaliteit) per definitie minimaal 1 (één).
Conformance	Hier wordt onderscheid gemaakt tussen R (required, verplicht), NP (not permitted, niet toegestaan) en optional (optioneel). R = Required betekent dat zowel de zendende als de ontvangende applicatie dit modelonderdeel moeten ondersteunen. Als er gegevens beschikbaar zijn, dan moet dit onderdeel ook in de XML-instance aanwezig zijn. Als de minimale cardinaiteit 0 is en er geen gegevens beschikbaar zijn, mag het element ontbreken in de XML-instance en is het bericht toch geldig. Als de minimale cardinaliteit 1 is en er geen gegevens beschikbaar zijn, dient dit door een nullFlavor (zie de paragraaf "Ontbrekende gegevens: nullFlavors") aangeduid te worden. Als een zendende applicatie het optionele modelonderdeel altijd zou weglaten of als deze in het verplichte modelonderdeel altijd een nullFlavor zou zenden omdat deze het concept niet ondersteunt, dan is zo'n applicatie niet-conform. Als een ontvangende applicatie het modelonderdeel indien aanwezig nooit zou verwerken, dan is zo'n applicatie niet-conform. NP = not permitted (niet toegestaan) betekent dat het modelonderdeel niet in de instance mag voorkomen (en ook niet aanwezig is in het onderliggend schema). Optional (optioneel) betekent dat een modelonderdeel niet of wél aanwezig mag zijn en dat geen support door zendende en ontvangende applicaties verplicht is.
NullFlavor	Voor modelonderdelen met een minimale cardinaliteit van 1 dient een nullFlavor doorgegeven te worden als er geen gegevens voor dit element beschikbaar zijn in een zendende applicatie. Voorbeelden zijn "geen informatie" (NI – no information), "onbekend" (UNK – unknown) enz. Voor verdere toelichting zie de paragraaf "Ontbrekende gegevens: nullFlavors".

De onderstaande tabel vat de verschillende varianten samen (met ROOD voor verzenders en BLAUW voor ontvangers)

Conformance Cardinaliteit	Optioneel	Required	Mandatory
0..1	Invoer MAG mogelijk zijn Hoeveel waarden ingevoerd? 0 → GEEN XML-element 1 → 0 of 1 elementen N → 0 of 1 elementen	Invoer MOET mogelijk zijn Hoeveel waarden ingevoerd? 0 → GEEN XML-element 1 → 1 GEVULD element N → 1 GEVULD element
	Evt. verzonden waarde MAG verwerkt worden.	Evt. verzonden waarde MOET verwerkt worden.
0..*	Invoer MAG mogelijk zijn Hoeveel waarden ingevoerd? 0 → GEEN XML-element 1 → 0 of 1 elementen N → 0 tot N elementen	Invoer MOET mogelijk zijn Hoeveel waarden ingevoerd? 0 → GEEN XML-element 1 → 1 GEVULD element N → N GEVULDE elementen
	Evt. verzonden waarde(n) MOGEN (evt. deels) verwerkt worden.	Evt. verzonden waarde(n) MOETEN ALLEMAAL verwerkt worden.
1..1	Invoer MAG mogelijk zijn Hoeveel waarden ingevoerd? 0 → LEEG XML-element 1 → 1 element (evt. LEEG) N → 1 element (evt. LEEG)	Invoer MOET mogelijk zijn Hoeveel waarden ingevoerd? 0 → 1 XML-element (nullFlavor) 1 → 1 GEVULD element N → 1 GEVULD element	Invoer MOET VERPLICHT zijn Hoeveel waarden ingevoerd? 0 → NIET toegestaan 1 → 1 GEVULD element N → 1 GEVULD element
	Evt. verzonden waarde MAG verwerkt worden.	Evt. verzonden waarde MOET verwerkt worden.	Verzonden waarde MOET verwerkt worden.
1..*	Invoer MAG mogelijk zijn Hoeveel waarden ingevoerd? 0 → LEEG XML-element 1 → 1 element (evt. LEEG) N → 1 (evt. LEEG) tot N elementen	Invoer MOET mogelijk zijn Hoeveel waarden ingevoerd? 0 → 1 XML-element (nullFlavor) 1 → 1 GEVULD element N → N GEVULDE elementen	Invoer MOET VERPLICHT zijn Hoeveel waarden ingevoerd? 0 → NIET toegestaan 1 → 1 GEVULD element N → N GEVULDE elementen
	Evt. verzonden waarde(n) MOGEN (evt. deels) verwerkt worden.	Evt. verzonden waarde(n) MOETEN ALLEMAAL verwerkt worden.	Verzonden waarde(n) MOETEN ALLEMAAL verwerkt worden.

File:Info.png

INVOER betekent hier dat het gegeven betekenis heeft binnen de applicatie. Dat betekent meestal dat de gebruiker het invoert (terwijl die zich bewust is van de betekenis), maar kan in sommige gevallen ook betekenen dat de applicatie het automatisch vult (als de waarde duidelijk is uit de context van een bepaalde functie). Wat NIET is toegestaan, is het standaard versturen van betekenisloze dummy waarden (dus zon-der dat de betekenis geborgd is in de applicatie). VERWERKING betekent ook dat het gegeven betekenis heeft binnen de applicatie. Verwerken kan betekenen: opslaan, afwijzen van specifieke waarden binnen een concept, vertalen naar interne variant op het concept, tonen aan de gebruiker, etc. Het is niet per se noodzakelijk dat het gegeven reproduceerbaar wordt opgeslagen. Voorbeeld: een verloskundigensysteem dat geen geslacht (van wordende moeders) vastlegt omdat het altijd vrouwen zijn, maar dat wel ontvangen berichten over mannen uitfiltert en niet verder verwerkt, ondersteunt op deze manier het concept geslacht - want anders kan het systeem er ook niet op filteren. Een leeg XML-element heeft de vorm <element xsi:nil="true"/>. Een XML-element met een nullFlavor heeft de vorm <element nullFlavor="{type NullFlavor}"/>.

 

Ontbrekende gegevens: nullFlavors

Elk element in een HL7v3 XML-bericht heeft het optionele attribuut nullFlavor, dat gebruikt wordt om aan te geven dat de betreffende waarde in het geheel ontbreekt, inclusief mogelijk een reden voor het ontbreken.

Dit wordt gebruikt in die gevallen waar een gegeven verplicht aanwezig is in een HL7v3 instance (cardinaliteit 1..), maar waarvoor de zendende applicatie simpelweg geen waarde beschikbaar heeft. Dit betreft gegevens waarvan de conformance hoogstens required is, want bij mandatory conformance moet een niet-null waarde worden meegegeven.

File:Info.png

Het attribuut nullFlavor kan voorkomen bij alle XML-elementen, dus zowel degene die horen bij modelklassen (inclusief associatieve klassen) als bij de bijbehorende modelattributen. Binnen Nederland wordt een nullFlavor echter niet gebruikt voor 'lege modelklassen', maar slechts voor ontbrekende modelattributen en associatieve modelklassen.

Een NullFlavor kan de volgende waarden hebben:

Lvl	Type, Domain name and/or Mnemonic code	Print Name	Definition/ description
1	S: NoInformation (NI)	NoInformation	Uit het gebruik van deze nullFlavor mag geen enkele informatie worden afgeleid. Het betekent niet meer dan dat het betreffende gegeven ontbreekt, zonder reden daarvoor.
2	L: (NA)	not applicable	Er is geen waarde van toepassing binnen deze context (bijv. datum v/d laatste menstruatie bij een mannelijke patiënt).
2	S: Unknown (UNK)	Unknown	Er is wel een waarde van toepassing, maar deze is bij de verzender niet bekend (diverse specialisaties zijn mogelijk).
3	L: (NASK)	not asked	De informatie is niet 'gezocht' (bijv. als een bepaald gegeven niet aan de patiënt is gevraagd) en daardoor niet bekend.
3	S: AskedButUnknown (ASKU)	AskedButUnknown	De informatie is wel 'gezocht', maar niet 'gevonden' (bijv. als het wel aan de patiënt is gevraagd, maar deze het niet wist).
4	L: (NAV)	Temporarily unavailable	De informatie is momenteel nog niet vergaard, maar de verwachting is dat dit op een later moment alsnog gebeurd.
3	L: (TRC)	Trace	Er is sprake van een hoeveelheid die groter is dan 0, maar die te klein is om te worden gekwantificeerd. Deze nullFlavor wordt alleen gebruikt bij datatype PQ (Physical Quantity).
2	S: Other (OTH)	Other	Er is geen bruikbare waarde beschikbaar binnen het domein dat voor het betreffende gegeven van toepassing is (bijvoorbeeld verplicht een vocabulairedomein voor een code).
3	L: (PINF)	positive infinity	Een numerieke waarde die (positief) oneindig is.
3	L: (NINF)	negative infinity	Een numerieke waarde die (negatief) oneindig is.
2	L: (MSK)	Masked	Er is wel informatie over dit gegeven beschikbaar, maar de zender (of een gateway) heeft deze i.v.m. beveiliging, privacy of andere redenen afgeschermd. Er kan evt. een aanvullend mechanisme zijn om de informatie te verkrijgen.

XML-voorbeelden

Omdat geen enkel gegeven in een HL7v3 bericht feitelijk het datatype ANY kan hebben, wordt hier het gebruik van het attribuut nullFlavor toegelicht o.b.v. een aantal specifieke datatypes (die het attribuut nullFlavor dus overerven van ANY). Bij de beschrijvingen in het vervolg van deze implementatiegids wordt verder uitgegaan van niet-null waarden.

1. Het aanvraag/voorschrijftijdstip is verplicht aanwezig in een HL7v3 bericht, maar de zendende applicatie weet simpelweg niet wanneer de aanvraag of het voorschrift is uitgeschreven (ook al wordt het concept wel ondersteund, omdat het required is).
   

   <author>
   <time nullFlavor="UNK"/>
   	</author>

2. Een applicatie kent de mogelijkheid om gegevens te registreren voor patiënten waarvan (nog) geen burgerservicenummer bekend is, maar dit later alsnog aan de geregistreerde gegevens te koppelen. In dat geval kan de persoonsidentificatie (indien verplicht aanwezig in het betreffende HL7v3 bericht), als volgt zijn weergegeven:
   

   <patient>
   	...
   	<person>
   		<id nullFlavor="NAV"/>
   		...
   	</person>
    </patient>

3. Bij een bepaald gegeven is in de specificaties een vast vocabulairedomein aangegeven, zonder de mogelijkheid om extra waarden toe te voegen. De zendende applicatie kan echter geen van de waarden in het betreffende domein toepassen (een voorbeeld van deze situatie is het doorgeven van magistraal bereide medicatie).
   

   <medicationKind>
   	<code nullFlavor="OTH"/>
    </medicationKind>

   
   

   In een dergelijke situatie kan wel gebruik worden gemaakt van <originalText> bij het datatype CD (en daarvan afgeleide datatypes), zie de paragraaf "CD (Concept Descriptor - gecodeerde gegevens)". Dit is één van de weinige situaties waarbij nullFlavor kan voorkomen in combinatie met andere gegevens.
   

   <medicationKind>
   	<code nullFlavor="OTH">
   		<originalText>Mijn magistrale receptuur</originalText>
   	</code>
    </medicationKind>

4. Bij de specificatie van de ingrediënten van een bepaald medicijn moet worden aangegeven dat er sporen ijzer in zitten, hoewel de precieze hoeveelheid niet bekend is (en niet relevant i.v.m. de geringe hoeveelheid). In dat geval zou kunnen worden aangegeven dat sprake is van een TRC (trace) hoeveelheid van onbekende grootte.
   

   <ingredient>
   	<quantity nullFlavor="TRC"/>
   </ingredient>

5. Het privacy filter van een bepaalde applicatie (of een tussenliggende gateway) heeft besloten dat een bepaald gegeven niet doorgegeven mag worden. De betreffende waarde wordt vervangen door een nullFlavor van het type MSK (masked) om het af te schermen. Let op dat de ontvanger nog wel weet dat het gegeven beschikbaar was!
   

   <subject>
   	<patient>
   		...
   		<addr nullFlavor="MSK"/>
   		...
   	</patient>
    </subject>

File:Info.png

Let op dat het gebruik van het nullFlavor attribuut binnen een element in een HL7v3 bericht normaal gesproken betekent dat geen enkel ander attribuut of element onder het betreffende element aanwezig mag zijn. Een nullFlavor zal dus niet samen met inhoudelijke informatie voorkomen (de aanwezigheid van het nullFlavor attribuut geeft immers aan dat deze informatie juist ontbreekt in het element). Een uitzondering op deze regel vorm het gebruik van nullFlavor "OTH" in combinatie met het element <originalText> bij datatype CD (en afgeleide datatypen).

Er is helaas binnen HL7 nog steeds onduidelijkheid over hoe xsi:nil moet worden gebruikt. Op zich zijn nullFlavor="NI" en xsi:nil="true" semantisch equivalent. Sommige XML-processoren vereisen echter dat naast een nullFlavor ook expliciet xsi:nil="true" wordt aangegeven in het betreffende XML-element.

File:Info.png

Wanneer wordt een nullFlavor gebruikt en wanneer niet? De cardinaliteit van een berichtonderdeel is 0.. (d.w.z. het is optioneel aanwezig). als per definitie nooit een waarde beschikbaar is → niet meesturen als soms of altijd een waarde beschikbaar is: bepaal of het gegeven ondersteund wordt → zo ja, dan nullFlavor sturen als er geen waarde is → zo nee, dan niet meesturen De cardinaliteit van een berichtonderdeel is 1.. (d.w.z. het is verplicht aanwezig). als per definitie nooit een waarde beschikbaar is → leeg meesturen als soms of altijd een waarde beschikbaar is: bepaal of het gegeven ondersteund wordt → zo ja, dan nullFlavor sturen als er geen waarde is → zo nee, dan niet meesturen

 

ANY (het generieke datatype)

Dit abstracte datatype is de basis voor alle andere datatypes. Geen enkele waarde bin-nen een HL7v3 bericht heeft feitelijk het datatype ANY, maar elk datatype binnen HL7v3 is wel een specialisatie van ANY. Dat wil ook zeggen dat elk ander datatype de attributen van ANY door overerving overneemt (zie "Ontbrekende gegevens: nullFlavors").

Het ANY type komt af en toe voor in de HL7-modellen, meestal als het gaat om de waar-de van klinische bevindingen of bepalingen. Het ANY type komt echter in XML-berichten niet voor, ANY wordt altijd vervangen door een bepaald datatype in een bericht.

Een voorbeeld is de waarde van observaties (subelement value in een observation), omdat in het model nog niet bekend is welke type waarde er van toepassing is. Het datatype van de waarde is pas bij de totstandkoming (instantiatie) van de interactie bekend. In de interactie wordt op die plaats dan ook het betreffende datatype meegegeven met behulp van het structuurattribuut xsi:type. Op deze wijze beschikt de ontvanger over de benodigde informatie om de waarde te kunnen valideren en verwerken.

Attributen van een element met dit datatype zijn:

@nullFlavor

ontbrekende waarde (CS)

Hieronder worden een aantal voorbeelden aangegeven, echter geldt voor elke datatype dat er een nullFlavor kan worden aangegeven (tenzij het element mandatory is).

XML-voorbeelden

1. ANY geïnstantieerd als CE
   

   <value xsi:type="CE" code="N11.9" codeSystem="2.16.840.1.113883.6.3"/>

2. ANY geïnstantieerd als CD
   

   <value xsi:type="CD" code="C1" codeSystem="2.16.840.1.113883.2.4.99" displayName="Waarschuwing: de gevonden naamgegevens wijken af van de naamgegevens in de vraag."/>

3. ANY geïnstantieerd als PQ
   

   <value xsi:type="PQ" value="12" unit="ml"/>

4. ANY geïnstantieerd als ED
   

   <value xsi:type="ED">dit is een tekst met de reden</value>

 

BL (Boolean – true/false)

Het datatype BL (Boolean) heeft betrekking op zogenaamde twee-waarden logica. Een gegeven van dit type kan slechts de waarden "true" of "false" bevatten, of een nullFlavor indien de conformance dit toe staat (d.w.z. als het gegeven niet mandatory is).

Elke waarde (of tweetal waarden) van het type Boolean kent de volgende bewerkingen:

Tabel voor Booleaanse logica (een nullFlavor (NULL in de tabel) betekent dat de waarde ontbreekt)
NOT			AND	true	false	NULL		OR	true	false	NULL
true			true	true	false			true	true	true	true
false	true		false	false	false			false	true	false	NULL
NULL	NULL		NULL	NULL	false	NULL		NULL	true	NULL	NULL

Een element met datatype BL heeft (indien het niet-null is) het attribuut value. De moge-lijke waarden zijn "true" of "false", wat aangeeft of het gegeven waar of onwaar is

@value waarde (true|false)

XML-voorbeelden

1. Een persoon (of andere 'living subject') is overleden.
   

   <livingSubject> ... <deceasedInd value="true"/> </livingSubject>

2. Een associatie is non-conductive (d.w.z.: geeft geen context door).
   

   <support2 contextConductionInd="false"> ... </support2>

In de bovenstaande situatie is het datatype BL niet van toepassing op een XML-element, maar op een attribuut. In dat geval krijgt het betreffende attribuut direct de Booleaanse waarde (het neemt dus als het ware de rol over dat het attribuut value anders heeft).

 

BIN (Binary data - binaire gegevens)

BIN is het type voor multimedia data. Het BIN type komt niet zelfstandig in de berichten voor. Indien multimedia gegevens in een bericht moeten worden opgenomen, dient hiervoor het datatype Encapsulated Data (ED) gebruikt te worden.

 

ED (Encapsulated Data - ingekapselde gegevens)

Dit is een algemeen type voor allerlei multimediagegevens. Het zal in Nederland voor-alsnog gebruikt worden voor tekst, al dan niet voorzien van (eenvoudige) opmaak.

ED is een complex type: het bevat XML-elementen en attributen. De gegevens (tekst, beelden) bevinden zich binnen het ED element in de vorm die gespecificeerd is door het 'representation' attribuut.

Het ED type kent twee vormen van gebruik:

1. Inline data
   De volledige gegevens worden in het type verzonden. Deze vorm wordt voornamelijk gebruikt voor tekst.
2. By reference
   Een verkorte versie van de gegevens wordt gevat in een "thumbnail", daarnaast wordt voorzien in een "reference" naar de volledige gegevens. Deze vorm zal in Nederland vooralsnog niet gebruikt worden.

File:Info.png

Indien binnen een XML-element van datatype ED een 'embedded' XML-structuur voorkomt (afgezien van de elementen van het datatype zelf), dan dient hiervoor een aparte XML-namespace aangeduid te worden. Dit omdat de extra elementen, die een buiten HL7 bepaalde syntax hebben, strikt genomen dus niet binnen de HL7-namespace gedefinieerd zijn.

@representation

codering (CS)

Gebruik van dit attribuut is optioneel. Er zijn twee coderingen mogelijk.

Tabel: representation attribuutwaarden
Code	Definitie
TXT	Voor tekstuele gegevens. Dit is het standaardtype, als geen representation is aangegeven wordt uitgegaan van TXT.
B64	Base 64 codering wordt gebruikt voor alle andere multimediagegevens.

@mediaType

soort gegevens (CS)

Dit attribuut geeft het soort gegevens aan. In Nederland worden voorlopig alleen de volgende gegevenssoorten ondersteund, zoals in de volgende tabel weergegeven:

Tabel: mediaType attribuutwaarden
Code	Naam	Status	Definitie
text/plain	Plain Text	verplicht	Voor willekeurige tekst. Dit is het standaardtype. In deze vorm is het gelijk aan het ST type.
text/html	HTML Text	aanbevolen	Bedoeld voor opgemaakte tekst in HTML-structuur. HTML is voldoende voor de meeste toepassingen waarbij opmaak gewenst is. HTML is platformonafhankelijk en wordt breed gebruikt.
audio/basic	Basic Audio	verplicht	Enkelkanaals audioformaat voor spraak. Alhoewel ondersteuning van dit formaat verplicht is, zal het in Nederland nauwelijks gebruikt worden.
audio/mpeg	MPEG audio layer 3	verplicht	MPEG-1 Audio layer-3 (ook bekend als MP3) is op dit moment de standard voor gecomprimeerde audio.
image/png	PNG Image	verplicht	Portable Network Graphics (PNG) (http://www.cdrom.com/pub/png) is een verliesloze compressie voor beeldbestanden. Waar voorheen GIF werd gebruikt, dient nu PNG te worden ondersteund.
image/jpeg	JPEG Image	verplicht	Dit formaat wordt gebruikt voor hoge resolutie foto's en andere beeldbestanden. De compressie is niet zonder verliezen waardoor dit formaat niet altijd geschikt is voor diagnostische doeleinden. JPEG zal voornamelijk worden gebruikt voor 'thumbnails' van grote (DICOM) bestanden.
video/mpeg	MPEG Video	verplicht	MPEG is een internationale standaard voor video beelden. Het is wijd gebruikt en open-source implementaties zijn beschikbaar.
text/rtf	RFT Text	facultatief	Het Rich Text Format wordt breed gebruikt om tekstverwerkerdocumenten te delen. Echter, RTF heeft de nodige compatibiliteitsproblemen, aangezien het afhankelijk is van de tekstverwerker. Kan van belang zijn als uitgewisselde documenten te wijzigen moeten zijn door de ontvanger.
application/pdf	PDF	Aangeraden	Het Portable Document Format wordt aangeraden voor geschreven tekst die compleet is opgemaakt en alleen-lezen is. PDF is platformonafhankelijk, wijd gebruikt en open. Er zijn vrij verkrijgbare hulpmiddelen voor het maken en weergeven van bestanden.
application/dicom	DICOM	aangeraden	De Digital Imaging and Communication in Medicine standaard wordt gebruikt voor bijvoorbeeld röntgenbeelden. RFC 3240

Toegestane mediaTypes in een feitelijke implementatie kunnen verder ingeperkt worden.

File:Info.png

Er wordt nadrukkelijk geen begrenzing aangegeven voor de maximale grootte van de waarde in een element van dit datatype. Ook bij specifieke elementen van een HL7v3 bericht gebeurt dit meestal niet, omdat de maximale grootte in principe niet door de standaard wordt ingeperkt. Afspraken hierover zullen meestal op implementatieniveau worden gemaakt. Zonder specifieke afspraken moet de ontvanger in staat zijn om Encapsulated Data (bijv. plain text) van willekeurige grootte te verwerken.

<reference>

verwijzing (TEL)

Dit element wordt alleen in combinatie met het 'thumbnail' element gebruikt. Het bevat de verwijzing naar de volledige gegevens in de vorm van een TEL (telecom) type.

<thumbnail>

verkleinde of symbolische weergave (ED)

Dit element een verkleinde of symbolische weergave van de volledige informatie. Het 'thumbnail' element kan bijvoorbeeld gebruikt worden om een JPEG 'cover-picture' van DICOM videostreams door te geven.
Aangezien 'thumbnail' een ED type is kunnen hier alle, eerder genoemde, gegevenssoorten in geplaatst worden.

XML-voorbeelden

Simpele vrije tekst:

<text xsi:type="ED" mediaType="text/plain">De patiënt heeft een lastige thuissituatie doordat kinderen op grote afstand wonen.</text>

Voorbeeld van gebruik thumbnail en reference:

<value xsi:type="ED" mediaType="image/png" representation="B64">
 <reference value="http://radiology.iumc.edu/xrays/128s.png">
   <useablePeriod xsi:type="IVL_TS">
     <low value="200007200845" />
     <high value="200008200845" />
   </useablePeriod>
 </reference>
 <thumbnail mediaType="image/jpeg" representation="B64">
MNYD83jmMdomSJUEdmde9j44zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu83
6edjzMMIjdMDSsWdIJdksIJR3373jeu83MNYD83jmMdomSJUEdmde9j44zmMir
...
omSJUEdmde9j44zmMiromSJUEdmde9j44zmMirdMDSsWdIJdksIJR3373jeu83
4zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu83==
 </thumbnail>
</value>
 

 

ST (String of Characters - reeks tekens)

Dit type is bedoeld voor vrije tekst in de meest eenvoudige vorm. ST is een specialisatie van het ED type, het mediaType is vastgezet op 'text/plain' en de representation op 'TXT'. De andere attributen en elementen van ED mogen niet gebruikt worden bij het ST type.

Het ST type wordt voornamelijk gebruikt in andere datatypes zoals AD en PN. In het al-gemeen geldt dat voor tekst beter het ED type gebruikt kan worden aangezien dit toch gereduceerd kan worden tot een ST type door de attributen op de juiste manier te vullen.

XML-voorbeeld

Dit voorbeeld is nagenoeg gelijk aan het eerste voorbeeld bij ED, functioneel zijn ze identiek.

<text xsi:type="ST">De patiënt heeft een lastige thuissituatie doordat kinderen op grote afstand wonen.</text>
 

 

SC (String with Code - reeks tekens voorzien van code)

Dit type is een extensie van het ST type aangevuld met de attributen van het CV type. Hierdoor is het mogelijk tekst nader te specificeren door middel van een code. Op dit moment wordt het SC type nog niet gebruikt, in een volgende ballot zal het onderdeel gaan worden van het AD (adres) type. Het is dan mogelijk om bijvoorbeeld het land, naast vrije tekst, ook van een code te voorzien.

 

CD (Concept Descriptor - gecodeerde gegevens)

Dit datatype specificeert een concept door middel van een code en het bijbehorende co-deersysteem (met uitzondering van situaties waarin geen code beschikbaar is).

Van het generieke datatype CD bestaan de nodige specialisaties, die verschillen in de ei-genschappen (properties) van het datatype die al dan niet ondersteund worden:

Datatype Property	CD	CE	CV	CO	CS
code	X	X	X	X	X
codeSystem	X	X	X	X
codeSystemName	X	X	X	X
codeSystemVersion	X	X	X	X
displayName	X	X	X	X
originalText	X	X	X	X
translation	X	X
qualifier	X

Omdat de CE variant in de praktijk de meest gebruikte is, zal daar de algemene toelich-ting voor het gebruik van de meeste properties in Nederland worden gegeven. Het enige attribuut dat uniek is voor CD (qualifier) wordt hieronder kort toegelicht.

style="text-align:left" | <qualifier>

aanvulling op de code (LIST<CR>)

Het optionele qualifier bevat een nadere precisering van het concept zoals beschreven door het code attribuut. In deze versie van de implementatiegids wordt dit attribuut en het gebruikte CR datatype niet nader uitgewerkt. Er zijn op dit moment voor de Nederlandse situatie geen terminologieën bekend die dit attribuut gebruiken. Het gebruik van complexe terminologieën (bijv. SNOMED CT) is alleen mogelijk in combinatie met dit at-tribuut.

 

CE (Coded with Equivalents - gecodeerde gegevens, met equivalenten)

Dit datatype specificeert een concept door middel van een code en het bijbehorende codeersysteem (met uitzondering van situaties waarin geen code beschikbaar is). Optioneel bevat het één of meer equivalenten met behulp van andere codeersystemen.

Voorbeeld: Het concept "Mannelijk" wordt afhankelijk van het gebruikte codeersysteem geïdentificeerd door bijvoorbeeld de code "M" of de code "1". De ontvanger is alleen in staat een code eenduidig te interpreteren indien naast de code eveneens het gebruikte codeersysteem geïdentificeerd wordt. De combinaties ("M", HL7v3 Tabel AdministrativeGender) of de vertaling daarvan ("1", ABC-ZIS Systeem geslachtscodetabel) zijn eenduidig te interpreteren.

Attributen en elementen van dit datatype zijn:

@code

code (ST)

Verplicht. Bevat de code, een classificatie van het concept dat beschreven is in het in codeSystem aangegeven codeersysteem.

@codeSystem

codeersysteem (OID)

Verplicht. Bevat de identificatie van het codeersysteem (tabel, terminologie). Ter identificatie wordt gebruik gemaakt van een OID.

Een ISO Object Identifier (OID) is een wereldwijd unieke string die bestaat uit nummers en punten (bijvoorbeeld "2.16.840.1.113883.3.1"). Volgens de ISO definitie bestaan OID's uit paden volgens een boomstructuur, waarbij het meest linkse getal de root en het meest rechtse getal de leaf (een blad, eindpunt) representeert. Het nummer is gegarandeerd wereldwijd uniek omdat het is gebaseerd op een systeem van gedelegeerde verantwoordelijkheid. Elke tak onder een root in de boomstructuur correspondeert met een domein waarbinnen een organisatie de uitgave van OID's beheert. De Stichting HL7 Nederland publiceert een tabel met OID's. Informeer bij twijfel bij de Stichting HL7 Nederland welke (eventueel nieuw te registeren) OID gebruikt moet worden.
Zie het hoofdstuk "Vocabulaire voor berichtspecificaties" voor nadere informatie over codeersystemen en OID's.

@displayName

conceptbeschrijving (ST)

Optioneel. Een tekstuele omschrijving van het concept. Dit is de omschrijving van de code, zoals die in het zendende systeem aan de gebruikers wordt getoond. Aan de waarde van dit attribuut mag geen betekenis worden toegekend, anders dan het tonen ervan aan een gebruiker om de code te verduidelijken. Een displayName kan nooit voorkomen zonder bijbehorende code en moet qua betekenis bij de code aansluiten.

File:Info.png

Er mag nooit van de ontvanger verwacht worden dat deze de displayName controleert op consistentie met de bijbehorende code. De ontvanger mag zelf bepalen of de eigen omschrijving (indien aanwezig) of de displayName van de verzender gebruikt wordt voor weergave. Bij gebruik van een nullFlavor mag geen displayName maar wel het kindelement originalText gebruikt worden om een niet-gecodeerde omschrijving door te geven.

<originalText>

oorspronkelijke tekst (ST)

Optioneel. Een tekstuele omschrijving van het concept. Dit is de tekst op basis waarvan al dan niet een code werd toegewezen in het zendende systeem. Merk op dat dit dus andersom geredeneerd is als bij displayName, waar de omschrijving juist bepaald wordt door de code. Dit betekent dat originalText ook nadrukkelijk kan voorkomen in gevallen waarin geen code toegewezen kon worden. In dat geval is de originalText de manier om de tekst door te geven die blijkbaar niet te vatten was in het betreffende codeersysteem.

File:Info.png |style="background:yellow" | Merk op dat originalText niet als attribuut van een XML-element met type CE wordt doorgegeven, maar als subelement. Zie ook de XML-voorbeelden.

File:Info.png

Er mag nooit van de ontvanger verwacht worden dat deze de originalText controleert op consistentie met een eventueel afgeleide code. Bij gebruik van een nullFlavor in dit datatype kan de originalText uitgewisseld worden als alternatief voor een gecodeerde waarde (zie ook voorbeeld hieronder).

@codeSystemName

naam van het codeersysteem (ST)

Optioneel. Een tekstuele vorm van de naam van het codeersysteem dat de code bevat. Aan de waarde van dit attribuut mag geen betekenis worden toegekend, anders dan het tonen ervan aan een gebruiker om de achtergrond van een code te verduidelijken.

@codeSystemVersion

versie van het codeersysteem (ST)

Optioneel. Een tekstuele vorm van de versie van het codeersysteem dat de code bevat. Aan de waarde van dit attribuut mag geen betekenis worden toegekend, anders dan het tonen ervan aan een gebruiker om de achtergrond van een code te verduidelijken.

Verschillende versies van een codeersysteem worden geïdentificeerd door aparte OID's in het codeSystem attribuut. Het ontvangende systeem mag om deze reden nooit gebruik maken van de waarde van codeSystemVersion om de code te interpreteren.

<translation>

vertalingen van de code (SET<CD>)

Optioneel kindelement. Nul of meer vertalingen van het concept met behulp van alternatieve codeersystemen.

Alle vertalingen dienen één en hetzelfde concept aan te duiden. Hierbij is het toegestaan dat de vertalingen "minder genuanceerd/gedetailleerd" zijn dan het originele concept.

Voorbeeld: Het concept "Granny Smith" kan, indien een codeersysteem niet het juiste niveau aan detail bevat, vertaald worden in het concept "Appel". Het concept "Appel" mag echter nooit worden vertaald in het meer gedetailleerde concept "Granny Smith". Het concept "Appel" mag eveneens niet worden vertaald in het concept "Groen": dit zijn wellicht gerelateerde concepten, maar qua betekenis is het geen vertaling van het originele concept.

XML-voorbeelden

<administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>
<value xsi:type="CE" code="Z94.0" codeSystem="2.16.840.1.113883.6.3" displayName="Longontsteking" codeSystemName="ICD-10"/>
<code code="SF36" codeSystem="2.16.840.1.113883.2.4.4.13"/>
<code code="13715119" codeSystem="2.16.840.1.113883.2.4.4.8" codeSystemName="G-Standaard Artikel" displayName="ABSORIN ONDERLEGGER 60X90CM 120G FLUFF 60920">
   <translation code="753696" codeSystem="2.16.840.1.113883.2.4.4.7"/>
</code>
<code nullFlavor="OTH">
   <originalText>Een zelfgemaakt medicijn</originalText>
</code>

 

CV (Coded Value - gecodeerde waarde)

Dit datatype specificeert een concept door middel van een code en het bijbehorende codeersysteem (met uitzondering van situaties waarin geen code beschikbaar is).

Het enige verschil tussen het CV datatype en het CE datatype is het feit dat CE vertalingen van een concept kan bevatten. Zie de beschrijving van CE, met uitzondering van het element translation, voor het gebruik van het CV datatype in Nederland.

XML-voorbeelden

<administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>

<value xsi:type="CV" code="Z94.0" codeSystem="2.16.840.1.113883.6.3" displayName="Longontsteking" codeSystemName="ICD-10"/>

<code code="SF36" codeSystem="2.16.840.1.113883.2.4.4.13"/>

<code code="13715119" codeSystem="2.16.840.1.113883.2.4.4.8" codeSystemName="G-Standaard Artikel" displayName="ABSORIN ONDERLEGGER 60X90CM 120G FLUFF 60920"/>

<code nullFlavor="OTH">
   <originalText>Een zelfgemaakt medicijn</originalText>
</code>

 

CO (Coded Ordinal - sorteerbare gecodeerde waarde)

Dit datatype specificeert een concept door middel van een code en het codesysteem (de tabel) waar de code uit afkomstig is.

Het enige verschil tussen het CO datatype en het CV datatype is het feit de concepten opgenomen in het CO datatype een bepaalde volgordelijkheid bezitten, ze kunnen worden gesorteerd. Zie de beschrijving van CV, voor een beschrijving van het gebruik van het CO datatype in Nederland.

XML-voorbeeld

<value xsi:type="CO" code="2" codeSystem="2.16.840.1.113883.2.4.4.XX" codeSystemName="Barthel index"/>
 

 

CS (Coded Simple - eenvoudige code)

Dit datatype specificeert een concept door middel van een code uit een voorgedefinieerd codesysteem (de tabel) waar de code uit afkomstig is. Dit datatype wordt veelal toegepast daar waar het gaat om het gebruik van vaste, binnen HL7 gedefinieerde, tabellen.

@code

code (ST)

Verplicht. Bevat de code (mnemonic), een identificatie van het concept dat beschreven is in het voorgedefinieerde codeersysteem.

XML-voorbeelden

<Observation classCode="OBS" moodCode="EVN"/>

<statusCode code="active"/>

 

II (Instance Identifier - objectidentificatie)

Dit datatype specificeert de identificatie van objecten. Daarbij horen bijvoorbeeld identificaties voor organisaties of personen. Een element van het II datatype bevat een wereldwijde unieke identificatie van een object.

Attributen van een element met dit datatype zijn:

@root

identificatiesysteem (OID)

In Nederland is dit een verplicht attribuut. Bevat een unieke identifier (in Nederland: een OID) voor het identificatiesysteem waarbinnen de extension gegenereerd (en uniek) is. Een identificatiesysteem wordt gebruikt om personen, systemen, instellingen en andere stoffelijke zaken te kunnen identificeren. Voorbeelden zijn: 'Nederlands rijbewijsnummer', Burger Service Nummer (BSN), Ziekenhuisnummer binnen het St. Josef Ziekenhuis, Unieke Zorgverlener Identificatie (UZI), en het Vektis AGB-Z Organisatienummer.

Een ISO Object Identifier (OID) is een wereldwijd unieke string die bestaat uit nummers en punten (bijvoorbeeld "2.16.840.1.113883.3.1"). Volgens de ISO definitie bestaan OID's uit paden volgens een boomstructuur, waarbij het meest linkse getal de root en het meest rechtse getal de leaf (een blad, eindpunt) representeert. Het nummer is in principe wereldwijd uniek omdat het uitgiftesysteem gebaseerd is op een systeem van gedelegeerde verantwoordelijkheid. Elke tak onder een root in de boomstructuur correspondeert met een domein waarbinnen een organisatie de uitgave van OID's beheert. De Stichting HL7 Nederland publiceert een tabel met OID's. Informeer bij twijfel bij HL7 Nederland welke (eventueel nieuw te registeren) OID gebruikt moet worden. Zie het hoofdstuk Identificatiemechanismen voor nadere informatie over identificatiesystemen en OID's.

@extension

identificatie (ST)

Verplicht. Een unieke karakterreeks binnen de context van het identificatiesysteem dat wordt gedefinieerd in de root.
Een element van het datatype II dient in de Nederlandse situatie te bestaan uit een combinatie van root en extension (bijv. root="2.16.840.1.113883.2.4.6.1" met extensie "02054231"). Deze combinatie is verplicht voor de identificatie van alle objecten. De lengte van de extensie-string, en het gebruik van eventuele voorloopnullen in de extensie, en de hoeveelheid daarvan, wordt bepaald door de beheerder van het identificatiesysteem.

File:Info.png

Als de extension geen waarde is die uit de database van het verzendende systeem kan worden gehaald, maar er toch een unieke identifier nodig is, dan kan er eventueel ook een GUID worden aangemaakt. Een GUID is weliswaar niet gegarandeerd wereldwijd en eeuwig uniek, maar heeft wel andere voordelen boven het gebruik van een oplopende teller (bijv. de garantie dat geen dubbelen ontstaan bij terugezetten van de backup na een crash). Overigens doet dit niets af aan de noodzaak om een vaste, unieke root OID te hebben (die vanzelfsprekend geen GUID mag zijn) voor de II als geheel.

@assigningAuthorityName

naam van de uitgevende organisatie (ST)

Optioneel attribuut. Een tekstuele vorm van de zogenaamde 'assigning authority', de organisatie die de identificatie heeft bepaald (en meestal het bijbehorende identificatiesysteem beheert). Aan de waarde van dit attribuut mag geen betekenis worden toegekend, anders dan het tonen ervan aan een gebruiker om de achtergrond van de identificatie te verduidelijken. Voor de leesbaarheid van berichten wordt geadviseerd dat assigningAuthorityName wordt meegezonden.

XML-voorbeelden

<id extension="0004453645" root="2.16.528.1.1007.3.3.99999.12.1"/>

<id root="2.16.840.1.113883.2.4.15.3.427.1. 13234453645"/>

<id extension="100197231" root="2.16.840.1.113883.2.4.6.3" assigningAuthorityName="Ministerie van Binnenlandse Zaken"/>

<id extension="JANS2" root="2.16.528.1.1007.3.3.99999.14" assigningAuthorityName="Alfa Ziekenhuis"/>

 

URL (Universal Resource Locator)

Dit is een telecommunicatie adres gespecificeerd volgens de Internet standaard RFC 1738. De URL geeft een protocol en een contactpunt aan, die voor dit protocol gedefinieerd zijn. Bekende voorbeelden zijn telefoon- en faxnummers, een emailadres, hyperlinkreferenties, file transfer protocol (FTP) referenties enz.

URL's hebben een standaard representatievorm als strings in het formaat scheme:address; de meest bekende schemes zijn opgenomen in de volgende tabel. Het address gedeelte van een URL is een string waarvan het formaat bepaald is door de URL scheme.

Tabel: Domain URLScheme
Code	Naam	Definitie
tel	Telephone	Telefoonnummer (draft-antti-telephony-url-11.txt).
fax	Fax	Een nummer voor een fax toestel (draft-antti-telephony-url-11.txt).
mailto	Mailto	Electronic mail address (RFC 2368).
http	HTTP	Hypertext Transfer Protocol (RFC 2068).
ftp	FTP	File Transfer Protocol (FTP) (RFC 1738).
mllp	HL7 Minimal Lower Layer Protocol	Het traditionele HL7 Minimal Lower Layer Protocol. De URL heeft de vorm van een IP URL, bijvoorbeeld mllp://<host>:<port>/ met <host> als IP adres of DNS hostname en <port> als port nummer waar de MLLP dienst bereikbaar is.
file	File	computer specifieke locale bestandnamen (RCF 1738). Deze schemes werken alleen voor lokale bestanden. Wordt nauwelijks gebruikt omdat bij een zender / ontvanger scenario de ontvanger met een lokale bestandsnaam meestal niets kan.
nfs	NFS	Network File System Protocol [RFC 2224]. Wordt voor NFS servers gebruikt om bestanden te delen.
telnet	Telnet	Referentie naar een interactieve sessie (RFC 1738).
modem	Modem	Een telefoonnummer met een modem (draft-antti-telephony-url-11.txt).
x-hl7-applicatie	Applicatie Identificatie	OID die een HL7-berichtverzendende applicatie eenduidig identificeert. Binnen de basisinfrastructuur van NICTIZ worden hier de door het LSP uitgedeelde applicatie ID's voor gebruikt.

 

TEL (Telecommunication Address - telecommunicatiecontact)

Er bestaat geen apart datatype voor telefoonnummers. Dit zijn slechts URL's die betrekking hebben op telecommunicatiefaciliteiten.

Details over de definitie van telefoonnummers zijn gedefinieerd in de Internet "RFC 2806 URLs for Telephone Calls". Bijvoorbeeld is "tel:+31(299)675463" een telefoonnummer, "fax:+31(20)65714123" een faxnummer. De globale absolute telefoonnummers met een "+" and landcode aan te geven is de voorkeur. Scheidingstekens kunnen worden toegevoegd (voor de betere leesbaarheid) maar hebben geen betekenis voor de nummers. "tel:+31299675463" en "fax:+312065714123" zijn dus identiek aan de bovenstaande voorbeelden.

Elementen met dit datatype hebben als attributen:

@value

waarde (URL)

Het attribuut value komt verplicht voor en bevat een URL (zie bij dat datatype). Dit omvat dus zowel het scheme (bijv. tel:, fax:, mailto:) als het bijbehorende adres.

@use

gebruiksaanduiding (SET<CS>)

Met het optionele use attribuut kunnen één of meerdere codes worden aangegeven om een systeem of gebruiker een advies te geven welk telecommunicatiecontact hij kan gebruiken afhankelijk van de doeleinden.

Tabel: Domain TelecommunicationAddressUse attribuutwaarden
Code	Naam	Definitie
HP	primary contact (woon- / verblijfadres)	Het primaire telecommunicatiecontact, om een persoon te bereiken, kan hoogstens één keer voorkomen.
HV	vacation contact (vakantie telecommunicatiecontact)	Een vakantiehuis, om een persoon te bereiken tijdens de vakantie
WP	work place (werk)	Een telecommunicatiecontact op het werk. Eerste keus voor werkgerelateerde contacten. Is voor organisaties en zorgverleners het primaire telecommunicatiecontact.
AS	Antwoorddienst	Een persoon of dienst, om berichten achter te laten.
EC	Noodgevalcontact	Een telecommunicatiecontact in een noodgeval te gebruiken
PG	Pager	Een pager toestel, geschikt om te vragen om terug te bellen of een kort bericht achter te laten
MC	Mobielcontact	Een mobiele telefoon of toestel dat de eigenaar altijd met zich mee neemt, mag andere use codes bevatten

@useablePeriod

tijdsinterval (IVL<TS>)

Het is mogelijk om de geldigheidsduur vaan een telecommunicatie contact in te perken. Het element usablePeriod kan worden gebruikt om een tijdsinterval aan te duiden

XML-voorbeeld

<telecom value="tel:+31.10.4765342"/>

<telecom value="tel:+31.20.4637846" use="WP"/>

<telecom value="mailto:dialyse@centrum-rotterdam.nl"/>

<telecom value="x-hl7-applicatie:2.16.840.1.113883.2.4.6.6.75023"/>

 

AD (Postal Address - adres)

Elementen van dit datatype hebben een substructuur met verschillende elementen, die in een adres kunnen voorkomen.

Een adres wordt in HL7 versie 3 weergegeven als een serie van Address Name Parts, bijvoorbeeld straatnaam, stad enz. Het datatype voor alle Address Name Parts is coded string (SC. Op dit moment is country het enige element waar we codes toestaan.

Tabel: Domain AddressNamePartType elementnamen
Element	Definitie
delimiter	Begrenzers (delimiters) worden geprint zonder witte ruimte te vormen (framing). Wanneer er geen waardecomponent wordt geleverd, verschijnt de begrenzer als een regelonderbreking (line break).
country	Het land, bijvoorbeeld "Nederland". Het datatype van country is coded string (SC. Als het land gecodeerd wordt dienen de 2-karakter landcodes volgens ISO 3166-1 editie 2 (OID 1.0.3166.1.2.2) gebruikt te worden.
county	In Nederland wordt dit element gebruikt om de gemeente door te geven (in andere landen kan een ander type administratieve eenheid binnen een staat/provincie gebruikt worden). De gemeente kan, maar hoeft niet, overeen te komen met de stad. Sommige gemeenten, bijv. "Waterland", hebben een naam die geheel afwijkt van de steden die erin gelegen zijn. In het HL7-berichtenverkeer wordt de gemeente in Nederland alleen gebruikt in het kader van wettelijke identificatie van personen. Het datatype van county is coded string (SC. Als de gemeente gecodeerd wordt, dan dient GBA tabel 33 (OID 2.16.840.1.113883.2.4.6.14) gebruikt te worden.
city	De naam van een stad, dorp of ander woongebied of bezorgcentrum. Merk op: dit is de woonplaats, niet de eventuele gemeente waartoe de woonplaats behoort. Voorbeeld: Haren, gemeente Groningen.
postalCode	Een postcode, voor Nederlandse postcodes inclusief één spatie tussen numerieke code en twee letters, #### AA.
houseNumber	Het nummer van een gebouw, huis of perceel langs de straat. Ook wel "primary street number" genoemd. Dit nummert niet de straat, maar juist het gebouw, volledige huisnummer aanduiding waarop geadresseerd kan worden voor bezorging door de externe postbezorger. Een alfanumerieke toevoeging zoals bij "14a" wordt ook bij houseNumber meegezonden.
streetName	Straatnaam additionalLocator || Aanvullende locatieaanduiding bij het postadres. Dit kan bijv. een nummer van een appartement, suite of verdieping zijn. In de Nederlandse situatie wordt dit vaak gebruikt voor de verdieping, bijv. ´III´ als het gaat om een woning op 3 hoog. Dit kan ook een aanduiding zijn die de relatie met een ander adres aangeeft. Als een woonark bijv. tegenover nummer 14 ligt, dan wordt '14' in houseNumber gezet en 't.o.' (tegenover) in additionalLocator.

De codes voor postadres worden gedefinieerd door het HL7-domein PostalAddressUse, aangegeven in het "use" attribuut van het <addr> moeder element (zie voorbeelden).

Tabel: Domain PostalAddressUse attribuutwaarden
Code	Naam	Definitie
PHYS	visit address (woon- / verblijfadres)	Fysiek adres; in de eerste plaats gebruikt voor het bezoeken van de geadresseerde. Kan in Nederland gebruikt worden om een adres door te geven dat afwijkt van het officiële adres
PST	postal address (postadres, postbus)	Gebruikt om post naar te sturen
HP	primary home (officiële adres)	Het adres zoals vastgelegd in officiële registers, bijvoorbeeld GBA, kan hoogstens één keer voorkomen. Is voor personen het primaire adres.
HV	vacation home (vakantie huis)	Een vakantiehuis, om een persoon te bereiken tijdens de vakantie
WP	work place (werk)	Een adres op het werk. Eerste keus voor werkgerelateerde contacten. Voor organisaties en zorgverleners het primaire adres.

Voor adresgegevens van patiënten zijn de attribuutwaarden HP, WP, PST, PHYS toegestaan, voor Organisaties WP, PHYS, PST, voor artsen WP.

XML-voorbeelden

<streetName>Dorpstraat</streetName>

File:Info.png

In Nederland wordt tussen de cijfers en letters van een postcode altijd een spatie ingevoegd. Dit wijkt af van de NEN Norm 5825 (waar geen spatie is opgenomen), omdat het uitgangspunt van het datatype AD is dat alles zo wordt doorgegeven als het moet worden weergegeven.

<addr>
   <postalCode>5099 AK</postalCode>
</addr>

<addr use="HP">
   <streetName>Purmersteenweg</streetName>
   <houseNumber>42</houseNumber>
   <postalCode>1441 DM</postalCode>
   <city>Purmerend</city>
</addr>

<addr>
   <country>Nederland</country>
</addr>

<addr>
   <country code="NL" codeSystem="1.0.3166.1.2.2">Nederland</country>
</addr>

 

PN (Person Name - persoonsnaam)

Een naam van een persoon.

Attribuut:

@use

naamgebruikstype(n) (SET<CS>)

Elementen:

<validTime>		geldigheidsinterval (IVL<TS>)
<delimiter>		scheidingsteken(s) (ENXP)
<family>		familienaam (ENXP)
<given>		gegeven naam (ENXP)
<prefix>		voorvoegsel (ENXP)
<suffix>		achtervoegsel (ENXP)

Structuur: Het datatype PN is een extensie op het datatype EN (Entity Name) en bestaat dus uit een zogenaamde 'mixed content' inhoud, waar in principe vrije tekst kan worden gecombineerd met name parts. Voor Nederland is afgesproken om bij persoonsnamen beperkingen te stellen aan het gebruik van 'mixed content'. Toegestaan zijn:

• De volledige persoonsnaam is een vrije tekst (dus er zijn geen person name parts), uitsluitend te gebruiken in situaties waarbij het voor de verzender niet mogelijk is om onderdelen te benoemen.
• Alle onderdelen zijn als person name part benoemd. Er mag in dat geval dus geen tekst voorkomen die niet omgeven is door één van de hieronder beschreven tags.

File:Info.png

In Nederland geldt de richtlijn dat persoonsnamen zoveel als mogelijk moeten worden opgedeeld in de juiste naamdelen en worden getypeerd met de juiste qualifier. Dit is een verantwoordelijkheid van de verzender. Een ontvanger die niet alle onderdelen expliciet kan opslaan, heeft altijd de mogelijkheid om onderdelen samen te voegen, maar andersom kan niet.

File:Info.png

De volgorde van de person name parts is relevant! De richtlijn is dat deze moeten worden doorgegeven in de 'natuurlijke' volgorde bij het gebruik van de naam (zodat de ontvanger ze achter elkaar kan weergeven). De aangegeven volgorde is met name belangrijk in de volgende gevallen: Voorvoegsels (prefix) moeten altijd vóór de naam staan waar ze bijhoren. Achtervoegsels (suffix) moeten altijd ná de naam staan waar ze bijhoren. Voornamen (given) moeten altijd in de officiële volgorde staan. Achternamen (family) en een eventuele bijbehorende delimiter ('-') moeten in de volgorde staan waarin ze officieel gevoerd worden. Dit wordt nader toegelicht bij de verschillende person name parts.

File:Info.png

Het is niet toegestaan om lege naamdelen mee te geven. Om aan te geven dat een naamdeel leeg is dient het simpelweg niet te worden meegegeven in het bericht.

XML-voorbeelden

Persoonsnaam als vrije tekst

<name>
   Jan Jansen
</name> 

De naam wordt zonder interne structuur doorgegeven

Persoonsnaam met name parts.

<name>
   <given>Jan</given>
   <family>Jansen</family>
</name> 

De beide onderdelen van de naam worden benoemd en voorzien van een qualifier: "Jan" is een 'naam die bij de geboorte is gegeven', oftewel een voornaam (voluit), en "Jansen" is een 'familienaam zoals bekend bij de GBA', oftewel de eigen achternaam.

Ongeldige persoonsnaam.

<name>
    Jan <family>Jansen</family>
</name>

Dit is geen geldige persoonsnaam, omdat vrije tekst en name part gecombineerd zijn.

@use

naamgebruikstype(n) (SET<CS>)

In principe kan van elke Person Name worden aangegeven in welke situatie deze gebruikt kan worden. Voor Nederland is besloten dat de volgende naamgebruikstypen voor kunnen komen:

Tabel: Domain EntityNameUse attribuutwaarden
Code	Naam	Definitie
L	Reguliere naam	De naam zoals die door de persoon (entiteit) gevoerd wordt. De afkorting 'L' stond oorspronkelijk voor Legal (wettelijk), maar feit is dat hier ook componenten in voor mogen komen (zoals een roepnaam), die niet wettelijk zijn vastgelegd. Dit naamgebruikstype is de standaardwaarde als geen type wordt doorgegeven.
A	Pseudoniem	Een artiestennaam, 'schuilnaam' of tijdelijke naam voor een persoon (entiteit). Deze wijkt dus af van de regulier gevoerde naam en wordt bijv. gebruikt om iemands identiteit te maskeren (privacy) of als tijdelijke naam wanneer de echte niet bekend is ('John Doe').
OR	Wettelijk geregistreerde naam	De naam met de exacte componenten zoals deze voorkomen in het bevolkingsregister van het betreffende land. Voor Nederland is dit het GBA register of ARNI voor niet-ingezetenen. Dit is de naam zoals die wordt geretourneerd indien een BSN met succes wordt geverifieerd.

File:Info.png

Merk op dat een naam ook twee use attributen mag hebben. Dit kan bijv. voorkomen als de wettelijke geregistreerde naam ('OR') ook als de reguliere naam gevoerd wordt (zie het voorbeeld hieronder). Let echter op dat dan geen enkele component mag voorkomen (zoals roepnaam of een partnernaam) die geen onderdeel is van de wettelijk geregistreerde naam.

File:Info.png

De name use code 'OR' is nog geen onderdeel van de officiële HL7-standaard. Deze is echter alvast toegevoegd vooruitlopend op internationale harmonisatie.

XML-voorbeelden

De reguliere naam als standaardnaam, dus geen use attribuut

<name>
  <!-- Naam, onderverdeeld in componenten -->
</name> 

Een pseudoniem voor een patiënt:

<name use="A">
  <!-- Naam, onderverdeeld in componenten -->
</name>

De wettelijk geregistreerde naam, zoals geretourneerd door de SBV-Z:

<name use="OR">
  <!-- Naam, onderverdeeld in componenten -->
</name> 

De gevoerde naam is exact gelijk aan de wettelijk geregistreerde naam:

<name use="OR L">
  <!-- Naam, onderverdeeld in componenten -->
</name> 

<validTime>

geldigheidsinterval (IVL<TS>)

Dit is een optioneel XML-element binnen de Person Name en duidt de periode aan waarin deze naam 'in gebruik'/geldig was voor de betreffende persoon. De opties zijn:

• Er is geen validTime element: de betreffende naam is in principe onbeperkt geldig.
• Er is een onder- en een bovengrens: de naam was geldig in de aangeduide periode.
• Er is alleen een ondergrens: de naam is geldig sinds de aangeduide datum.
• Er is alleen een bovengrens: de naam was geldig t/m de aangeduide datum.

Dit element van Person Name kan worden gebruikt om aan te geven dat een persoon gedurende diens leven één of meer keer van naam veranderd is. Dit gebeurt o.a. bij:

• Adoptie van een baby, waarbij het de achternaam van de adoptieouders verkrijgt.
• Huwelijk, waarbij de partnernaam kan worden toegevoegd aan de eigen naam.
• Scheiding, waarbij een eerder aangenomen partnernaam juist weer vervalt.
• Personen die om andere redenen hun voor- of achternaam veranderen.

File:Info.png

In elke situatie waar één of meer Person Names worden doorgegeven, moet minimaal de naam worden aangeduid die op het moment van verzenden geldig/actueel is. Vervallen namen kunnen dus alleen worden doorgegeven als het betreffende berichtelement herhalend is (dus met cardinaliteit > 1).

• Merk op dat veel patiëntregistratiesystemen niet echt een historie (met ingangsdatum) bijhouden van de patiëntnaam. Wel wordt vaak een 'audit trail' (wijzigingshistorie) van de patiëntgegevens in het algemeen bijgehouden. Indien gewenst zou daaruit een historie van de persoonsnaam kunnen worden afgeleid, hoewel het natuurlijk ook mogelijk is om alleen de actuele naam door te geven (en dus geen validTime te gebruiken).

File:Info.png

In tegenstelling tot de situatie bij Organization Name is het niet toegestaan dat de ondergrens of de bovengrens van een validTime aanduiding bij Person Name in de toekomst ligt. Er kan dus geen 'geplande' nieuwe naam of het 'gepland vervallen' van de huidige naam worden doorgegeven voor persoonsnamen.

XML-voorbeelden

De actuele naam is geldig sinds 12 juli 2005

<name>
   <validTime>
      <low value="20050712"/>
   </validTime>
   <!-- Naam, onderverdeeld in componenten -->
</name>

Bovenstaande situatie kan zich bijv. voordoen bij een systeem dat alleen de actuele naam doorgeeft, maar wel de historie bijhoudt. Bovenstaande persoon kan bijv. op 12 juli getrouwd zijn en daarbij de achternaam van haar partner hebben aangenomen.

Oude namen plus actuele naam

<name>
   <validTime>
       <high value="19850412"/>
   </validTime>
   <!-- "Nicole de Vries" als naam van de baby voor adoptie -->
</name>
<name>
   <validTime>
       <low value="19850413"/>
       <high value="20050824"/>
   </validTime>
  <!-- "Nicolette Scheick" als naam na adoptie, maar voor huwelijk -->
</name>
<name>
   <validTime>
       <low value="20050825"/>
   </validTime>
   <!-- "Nicolette Scheick-Jansen" als naam na huwelijk -->
</name>

In bovenstaand voorbeeld wordt de baby Nicole de Vries geadopteerd door de familie Scheick, waarbij ze dus van achternaam verandert. Omdat de adoptieouders dit een leukere naam vinden, wordt haar voornaam (of in ieder geval haar roepnaam) ook veranderd in Nicolette. Na haar huwelijk neemt ze de achternaam van haar partner (Jansen) aan. Het verzendende systeem stuurt in dit geval de hele naamhistorie mee.

 

<delimiter>

scheidingsteken(s) (ENXP)

Een delimiter heeft geen speciale betekenis als onderdeel van een Person Name, anders dan het doorgeven van een (stukje) letterlijke tekst dat in de geschreven naam voorkomt.

Een delimiter moet altijd op de plaats in de Person Name staan waar de tekst ook geschreven zou worden. Er zijn geen impliciete spaties, dus als er normaal gesproken een spatie voor of achter geschreven wordt, dan moet deze expliciet worden meegegeven.

Voorbeelden van delimiters in Person Names zijn:

• Het streepje '-' tussen de eigen achternaam en de partnernaam (of andersom).
• De komma plus spatie ', ' die tussen de naam en bepaalde achtervoegsels komt.
• De tekst ', geb. ' of ', e.v. ' die soms gebruikt wordt bij eigen- resp. partnernaam.

Deze zouden als volgt gebruikt worden binnen een Person Name XML-berichtelement.

XML-voorbeelden

Scheider tussen partnernaam en geboortenaam

<name>
   <family qualifier="SP">Jansen</family>
   <delimiter>-</delimiter>
   <family qualifier="BR">Scheick</family>
</name>

Scheider tussen achternaam en academische titel

<name>
   <family qualifier="SP">Jansen</family>
   <delimiter>, </delimiter>
   <title qualifier="AC">RA</title>      <!-- registeraccountant -->
</name>

Zie verder de algemene voorbeelden achterin deze sectie van het document.

Een aantal voor de hand liggende vragen (en antwoorden) over delimiters:

File:Info.png

Q    Wordt een ontvangend systeem geacht een delimiter op te slaan? A    Een ontvangend systeem dat de afzonderlijke person name parts verwerkt, zal vrijwel nooit de delimiters opslaan in de eigen database. Q    Waarom zou een verzendend systeem dan ooit delimiters meesturen? A    Er kunnen ontvangende systemen zijn die géén of niet alle person name parts apart kunnen verwerken (bijv. omdat ze maar één veld voor de achternaam hebben). Deze kunnen d.m.v. de delimiters een volledig uitgeschreven naam overnemen. (Een voorbeeld van zo'n eenvoudige ontvanger is een web interface die binnenkomende HL7v3 berichten omzet naar HTML formaat voor directe weergave op het beeldscherm).

 

<family>

familienaam (ENXP)

Attribuut

@qualifier

naamsoort (SET<CS>)

Een person name part van het type family heeft betrekking op een deel van de naam dat door familiebanden is verkregen, meestal achternaam genoemd. Normaal gesproken heeft dit dus betrekking op de eigen achternaam (verkregen via de ouders) en eventueel op een aangenomen achternaam na een huwelijk ('overgenomen' van de partner).

Enkele regels voor person name parts van type family:/p>

• Ze moeten onderling altijd conform de officiële schrijfwijze geordend zijn (bijv. eerst eigen achternaam en dan achternaam van de partner of juist andersom).
• Er is altijd sprake van een impliciete spatie als tussenruimte met het erop volgende name part, behalve als dit een delimiter of een suffix is (zie aldaar).
• De aard van de familienaam kan verder worden aangeduid door het optionele attribuut qualifier te gebruiken. Zie de tabel voor daarbij toegestane waarden.
• Er mag maar één familienaam per type qualifier voorkomen in de naam!

Tabel: qualifiers bij person name family
Code	Definitie
BR	(birth) Geboortenaam. Een achternaam, zoals die is geregistreerd in de GBA (daarin aangeduid als 'geslachtsnaam'). Deze is meestal bij geboorte verkregen, maar kan ook op een later moment in het leven zijn aangenomen. Hierbij is uitgesloten de naam die wordt overgenomen van de partner in een huwelijk (deze krijgt qualifier "SP"). Normaal gesproken is dit de geboortenaam van één de (natuurlijke) ouders, maar in sommige culturen kan dit ook een combinatie van de geboortenamen van beide ouders of een afgeleide van de voornaam van één van de ouders zijn.
SP	(spouse) Partnernaam. Een achternaam die is 'overgenomen' van een partner in een huwelijksrelatie (meestal de geboortenaam van de partner). Er kan geen aanname worden gedaan over het geslacht van de drager, aangezien het overnemen van namen in Nederland volledig gelijkgesteld is tussen de beide partners. Ook kan geen conclusie worden getrokken over de huwelijkse staat als een partnernaam ontbreekt, aangezien iemand gehuwd kan zijn zonder de naam van de partner te voeren. Let op dat het bij het gebruik van een partnernaam niet alleen relevant is dat iemand getrouwd is, maar vooral of de betreffende persoon al dan niet met de naam van de partner wil worden aangesproken. Het toepassen van de partnernaam in de persoonsnaam staat los van het eventueel vastleggen van de partner als contactpersoon. In de huidige Nederlandse wetgeving kan na een huwelijk elke combinatie van eigennaam en/of partnernaam gevoerd worden door beide partners. Vanzelfsprekend is het geslacht van de beide partners daarbij niet relevant.

File:Info.png

Indien een person name part van type family zonder een qualifier wordt gebruikt, dan wordt het simpelweg geïnterpreteerd als achternaam. Als de ontvanger moet kiezen tussen opslag als een geboortenaam of als een partnernaam, dan moet in zo'n geval voor de geboortenaam gekozen worden.

File:Info.png

Er moet nog worden bepaald hoe moet worden omgegaan met een geboortenaam die iemand niet meer voert na een huwelijk (omdat alleen de partnernaam wordt gevoerd). De geboortenaam moet dan toch opgeslagen (en doorgegeven) worden, maar er zou daarbij kunnen worden aangegeven dat de naam 'onzichtbaar' moet zijn. Eén oplossing zou bestaan uit het implementeren van een attribuut invisible. Wat sowieso kan is om de naam twee keer door geven: één met use attribuut 'OR' (mét de geboortenaam) en één met 'L' (zonder).

File:Info.png

Er moet in internationaal verband nog worden uitgezocht hoe moet worden omgegaan met een achternaam die is overgenomen van de adoptieouders. Volgens de huidige definitie is de qualifier "BR" hier niet voor bedoeld, maar het is duidelijk dat de qualifiers "SP" en "CL" ook niet toereikend zijn. Vooralsnog is het advies om in dit geval (als überhaupt bekend is dat het om de adoptienaam gaat) geen qualifier mee te sturen. In de praktijk zal een dergelijke naam echter meestal als 'eigen achternaam' (en dus met qualifier "BR") worden gebruikt.

XML-voorbeelden

Jan Jansen

<name>
   <given>Jan</given>
   <family qualifier="BR">Jansen</family>
</name> 

Nicolette Jansen-Scheick

<name>
   <given>Nicolette</given>
   <family qualifier="SP">Jansen</family>
   <delimiter>-</delimiter>
   <family qualifier="BR">Scheick</family>
</name>

 

<given>

gegeven naam (ENXP)

Attribuut:

@qualifier

naamsoort (SET<CS>)

Een person name part van het type given heeft betrekking op een deel van de naam dat, meestal door de ouders en meestal bij de geboorte, wordt gegeven aan een persoon. In Nederland wordt het meestal voornaam genoemd, hoewel het niet in alle culturen vóór de familienaam wordt geschreven. Ook naamdelen die zijn afgeleid van de voornaam, nl. de initialen (voorletters) en de roepnaam (informele voornaam) hebben het type given.

Enkele regels voor person name parts van type given:

• Een persoon kan zondermeer meerdere voornamen of initialen hebben.
• Officiële voornamen en initialen moeten altijd in de juiste volgorde staan.
• Er is altijd sprake van een impliciete spatie als tussenruimte met het erop volgende name part, behalve als dit een delimiter of een suffix is (zie aldaar).
• De aard van de gegeven naam kan verder worden aangeduid door het optionele attribuut qualifier te gebruiken. Zie de tabel voor daarbij toegestane waarden.

Tabel: qualifiers bij person name given
Code	Definitie
BR	Officiële voornaam. Een voornaam die meestal bij de geboorte is gegeven (meestal door de ouders) en die officieel is vastgelegd. Deze dienen voluit en in de juiste volgorde te worden gebruikt. Als een persoon meerdere voornamen heeft, dan moet in ieder geval de eerste naam worden doorgegeven (alleen de eerste voornaam is dus toegestaan, maar alleen de tweede niet). Als er meerdere voornamen zijn, dan kunnen deze als aparte given elementen worden doorgegeven maar dit kan ook in één element (gescheiden door spaties). Ook komt het voor dat de eerste voornaam voluit wordt gebruikt in combinatie met de initialen.
CL	Roepnaam. Een voornaam waarmee de persoon informeel wordt aangesproken, meestal afgeleid van één van de officiële voornamen. In tegenstelling tot de officiële voornamen kan een roepnaam eenvoudig variëren tijdens iemands leven en kan een persoon zelfs meerdere roepnamen tegelijkertijd hanteren, afhankelijk van hoe mensen hem of haar kennen. In dat geval dient de meest toepasselijke roepnaam te worden verzonden.
IN	Initialen. Meestal een afkorting van een voornaam. Dit kan een enkele letter zijn of meer dan één (bijv. 'Th.' voor Theo). Een afsluitende punt moet expliciet worden vermeld. Initialen dienen in de juiste volgorde te worden gebruikt. Als er meerdere initialen zijn, dan kunnen deze als aparte given elementen worden doorgegeven maar dit kan ook in één element gebeuren (gescheiden door punten). Het voordeel van deze methode is dat er geen spaties tussen de afzonderlijke initialen in de naam worden geïmpliceerd.	_

File:Info.png

Indien een person name part van type given zonder een qualifier wordt gebruikt, dan wordt het simpelweg geïnterpreteerd als voornaam. Als de ontvanger moet kiezen tussen opslag als een officiële voornaam of als een roepnaam, dan moet in zo'n geval voor de officiële voornaam gekozen worden.

File:Info.png

De qualifiers "BR" en "CL" kunnen ook gezamenlijk voorkomen, om aan te geven dat een officiële voornaam ook als roepnaam fungeert. Op deze manier kan voorkomen worden dat dezelfde naam 2 keer moet worden meegegeven. Als de roepnaam echter verschilt van de officiële voornamen, dan kunnen ze beide worden doorgegeven: eerst de officiële voornamen, vervolgens de roepnaam.

File:Info.png

Als een combinatie van officiële voornaam en initialen wordt meegestuurd, dan is voor Nederland de afspraak dat deze niet mogen 'overlappen', d.w.z. dat de eerste voorletter (indien nodig) door het ontvangende systeem moet worden afgeleid uit de eerste letter(s) van de officiële voornaam (zie voorbeeld hierna).

File:Questionmark.png

Er moet in Nederland nog worden uitgezocht hoe moet worden omgegaan met een voornaam die is gegeven door adoptieouders. Volgens de huidige definitie is de qualifier "BR" hier niet voor bedoeld, maar het is niet duidelijk of de qualifier "CL" (roepnaam) wel toereikend is. De vraag is nl. of een dergelijke naam al dan niet een officieel karakter krijgt of alleen als roepnaam fungeert.

XML-voorbeelden

Hans Jansen, zonder qualifier

<name>
   <given>Hans</given>
   <family qualifier="BR">Jansen</family>
</name> 

Johannes Theodorus Cornelis Jansen, officiële voornamen

<name>
   <given qualifier="BR">Johannes Theodorus Cornelis</given>
   <family qualifier="BR">Jansen</family>
</name> 

Johannes Theodorus Cornelis Jansen, met roepnaam Hans

<name>
   <given qualifier="BR">Johannes Theodorus Cornelis</given>
   <given qualifier="CL">Hans</given>
   <family qualifier="BR">Jansen</family>
</name> 

Johannes Th.C. Jansen, zonder duplicering van voorletter 'J'

<name>
   <given qualifier="BR">Johannes</given>
   <given qualifier="IN">Th.C.</given>
   <family qualifier="BR">Jansen</family>
</name> 

Kai Uwe Heitmann, Kai is zowel officiële naam als roepnaam

<name>
   <given qualifier="BR CL">Kai</given>
   <given qualifier="BR">Uwe</given>
   <family qualifier="BR">Heitmann</family>
</name> 

Conclusie uit de voorbeelden is dat allerlei combinaties van officiële voornamen, roepnamen en initialen kunnen voorkomen, afhankelijk van de opslag- en communicatiemogelijkheden van het verzendende systeem. De betekenis van elk onderdeel moet echter duidelijk zijn.

 

<prefix>

voorvoegsel (ENXP)

Attributen:

@code		titelcode (CE), niet bij qualifier "VV"
@qualifier		naamsoort (SET<CS>)

Een person name part van het type prefix heeft betrekking op een deel van de naam dat hoort bij één of meer andere naamdelen en daar vóór wordt geschreven. In principe zijn er twee soorten voorvoegsels, nl. voorvoegsels bij de achternaam en titels (die als toevoeging in de schrijfnaam worden opgenomen). Het letterlijke woord 'voorvoegsel' is zelfs in de internationale HL7v3 materialen geslopen, als internationale term voor voorvoegsels bij de achternaam (al was family name prefix logischer geweest).

Enkele regels voor person name parts van type prefix:

• Een prefix moet altijd direct vóór de naamdelen worden geplaatst waar het betrekking op heeft (d.w.z. waar het normaal gesproken wordt geschreven).
• Er is geen impliciete spatie als tussenruimte met het erop volgende name part, d.w.z. een spatie na het voorvoegsel moet expliciet worden vermeld in de tekst!
• De aard van het voorvoegsel kan verder worden aangeduid door het optionele attribuut qualifier te gebruiken. Zie de tabel voor daarbij toegestane waarden.

In de eerstvolgende release van de datatypes van HL7v3 wordt het mogelijk om diverse elementen die nu een 'string' zijn, optioneel ook als code aan te duiden. Dit kan o.a. worden toegepast om titels gecodeerd te versturen, indien het verzendende systeem ze als code opslaat. Daarnaast moet echter ook altijd de tekst worden gezonden, zodat de ontvanger kan bepalen welke gebruikt wordt. Op het moment dat deze methode beschikbaar is, moet worden bepaald welke titelcodes binnen Nederland gehanteerd zullen worden (NEN/NUFFIC/NHG?).

Tabel: qualifiers bij person name prefix
Code	Definitie
VV	Voorvoegsel bij de achternaam. Dit gaat om de in Nederland veel voorkomende naamdelen als "van ", "de ", "ten " of "el ", maar ook combinaties als "van der " of "in 't ". Een voorvoegsel hoort altijd bij het person name part van type family dat er direct achter staat (zie de XML-voorbeelden). Een voorvoegsel kan als onderdeel van de achternaam worden opgenomen, maar het is gebruikelijk om het apart op te slaan (en te verzenden) indien sorteren (en dus ook terugzoeken) plaatsvindt op basis van de achternaam zonder het voorvoegsel. Dit is in Nederland absoluut gebruikelijk, maar in België bijvoorbeeld niet. Merk op dat er meerdere voorvoegsels kunnen voorkomen in één naam, nl. zowel bij de eigennaam als bij een eventuele partnernaam.
AC	Academische titel. Een titel (meestal in afgekorte vorm) die is verkregen door het voltooien van een studie of door het vervullen van een rol binnen een academische instelling. Als voorvoegsel kunnen bijv. fungeren: "Drs. ", "Ing. ", "Ir. ", "Mr. ", "Dr. ", "Prof. ", maar ook een combinatie als "Prof. Dr ".
NB	Adellijke titel. Een titel (meestal voluit geschreven) die is ontleend aan iemands aristocratische status. Voorbeelden zijn "Jonkheer ", "Graaf ", etc..
TITLE	Algemene aanhef. Dit wordt in principe gebruikt voor de aanhef bij een volledige naam (zoals gebruikt in correspondentie), bijv. "De Weledelgeleerde Heer" , "De Weledelhooggeboren Vrouwe ", maar ook simpelweg "Mevrouw ". De aard van zo'n aanhef hangt dus samen met het geslacht van de persoon en met eventuele academische en/of adellijke titels (o.b.v. afleidregels).

File:Info.png

Indien een person name part van type prefix zonder een qualifier wordt gebruikt, dan wordt het altijd geïnterpreteerd als titel. Dit omdat veel verzendende systemen wel titels ondersteunen, maar geen onderscheid maken tussen academische en adellijke titels. Voorvoegsels bij de achternaam en algemene aanhef ("VV" resp. "TITLE") moeten dus altijd expliciet worden doorgegeven.

File:Info.png

Indien van een titel niet bekend is of deze voor of achter de naam geplaatst moet worden, dan moet deze worden verzonden als prefix. Dit zal veel voorkomen bij systemen die geen plaats in de tekst bij een titel opslaan. In dat geval zullen titels dus altijd vóór de naam binnen het datatype Person Name staan.

File:Info.png

Er is geen regel voor het aantal voorvoegsels dat wordt gecombineerd in één element. D.w.z. dat "van " en "der " of "Mr. " en "Drs. " apart kunnen worden doorgegeven, maar ook gecombineerd als "van der " en "Mr. Drs. ".

XML-voorbeelden

Monique van Wijk

<name>
   <given>Monique</given>
   <prefix qualifier="VV">van </prefix>
   <family qualifier="BR">Wijk</family>
</name> 

Monique van Wijk-de Boer (voert ook de naam van haar partner)

<name>
   <given>Monique</given>
   <prefix qualifier="VV">van </prefix>
   <family qualifier="BR">Wijk</family>
   <delimiter>-</delimiter>
   <prefix qualifier="VV">de </prefix>
   <family qualifier="SP">Boer</family>
</name> 

Nu komen er twee <prefix> elementen voor, vóór beide delen van de achternaam.

Dr. Kai Heitmann

<name>
   <prefix qualifier="AC">Dr. </prefix>
   <given>Kai</given>
   <family qualifier="BR">Heitmann</family>
</name> 

In dit geval is de regel dus dat de titel ('Dr. ') voor de gehele naam wordt geplaatst, omdat dit de normale plaats is waar het in de geschreven vorm terecht zou komen.

Berend-Jan baron van Voorst tot Voorst

<name>
   <given>Berend-Jan</given>
   <prefix qualifier="NB">baron </prefix>
   <prefix qualifier="VV">van </prefix>
   <family qualifier="BR">Voorst tot Voorst</family>
</name> 

In dit (reële) voorbeeld staat de titel ('baron ') tussen de voornaam en de achternaam in, omdat dit de gebruikelijke schrijfwijze is. Daarnaast is er een 'gewoon' voorvoegsel bij de achternaam ('van '). Overigens zal veel software niet in staat zijn om een (apart opgeslagen) titel op de juiste plaats te zetten, waardoor 'baron' ook vooraan kan voorkomen.

De Weledelzeergeleerde Heer Dr. William Goossen

<name>
   <prefix qualifier="TITLE">De Weledelzeergeleerde Heer </prefix></span>
   <prefix qualifier="AC">Dr. </prefix>
   <given>William</given>
   <family qualifier="BR">Goossen</family>
</name> 

Dit is een voorbeeld waarbij het verzendende systeem de volledige titel blijkbaar heeft vastgelegd (of afleidt uit de titel) en doorgeeft als deel van de 'correspondentienaam'. Maar ook zonder titel kan het verzendende systeem een algemene aanhef meesturen (zie hieronder).

Mevr. A. Jansen

<name>
   <prefix qualifier="TITLE">Mevr. </prefix>
   <given>A.</given>
   <family qualifier="BR">Jansen</family>
</name> 

 

<suffix>

achtervoegsel (ENXP)

Attributen:

@code		titelcode (CE)
@qualifier		naamsoort (SET<CS>)

Een person name part van het type suffix heeft betrekking op een deel van de naam dat hoort bij één of meer andere naamdelen en daar achter wordt geschreven. In Nederland zijn als achtervoegsel alleen academische titels toegestaan.

Enkele regels voor person name parts van type suffix:

• Een suffix moet altijd direct achter de naamdelen worden geplaatst waar het betrekking op heeft (d.w.z. waar het normaal gesproken wordt geschreven).
• Er is geen impliciete spatie als tussenruimte met het eraan voorafgaande name part, d.w.z. een spatie voor het achtervoegsel moet expliciet worden vermeld!
• De aard van het achtervoegsel kan verder worden aangeduid door het optionele attribuut qualifier te gebruiken. Zie de tabel voor daarbij toegestane waarden.

In de eerstvolgende release van de datatypes van HL7v3 wordt het mogelijk om diverse elementen die nu een 'string' zijn, optioneel ook als code aan te duiden. Dit kan o.a. worden toegepast om titels gecodeerd te versturen, indien het verzendende systeem ze als code opslaat. Daarnaast moet echter ook altijd de tekst worden gezonden, zodat de ontvanger kan bepalen welke gebruikt wordt. Op het moment dat deze methode beschikbaar is, moet worden bepaald welke titelcodes binnen Nederland gehanteerd zullen worden (NEN/NUFFIC/NHG?).

Tabel: qualifiers bij person name part suffix
Code	Definitie
AC	Academische titel. Een titel (meestal in afgekorte vorm) die is verkregen door het voltooien van een studie of door het vervullen van een rol binnen een academische instelling. Bij achtervoegsels gaat het meestal om internationale gehanteerde aanduidingen als " MSc", " PhD" of " MD".

File:Info.png

Een person name part van type suffix dat zonder qualifier wordt gebruikt, moet worden beschouwd als een niet nader bepaald achtervoegsel. Ook het gebruik van (vaak Amerikaanse) termen als ', Jr.', ', Sr.' of ' III' valt in deze categorie.

File:Info.png

Er is geen regel voor het aantal achtervoegsels dat wordt gecombineerd in één element. D.w.z. dat " MSc" en " MD" apart kunnen worden doorgegeven, maar ook gecombineerd als " MSc MD".

XML-voorbeelden

Bert Kabbes, RI

<name>
   <given>Bert</given>
   <family qualifier="BR">Kabbes</family>
   <suffix qualifier="AC">, RI</suffix>
</name> 
 

 

ON (Organization Name - organisatienaam)

Definitie: Een naam van een organisatie.

Attribuut:

@use

gebruikstype(n) (SET<CS>), niet gebruiken in NL

Elementen:

<validTime>

geldigheidsinterval (IVL<TS>)

Structuur: Het datatype ON is een extensie op het datatype EN (Entity Name) en bestaat dus uit een zogenaamde 'mixed content' inhoud, waar in principe name parts in kunnen zijn aangeduid. Voor Nederland is vooralsnog afgesproken om geen gebruik te maken van organization name parts en de naam altijd uit te drukken als één tekst. Dit betekent dat ON in Nederland in feite gelijk wordt aan het datatype TN (Trivial Name).

XML-voorbeelden

minimaal

<name>De Naam van de Organisatie</name> 

Merk op dat de tekst van de naam zonder aanhalingstekens wordt doorgegeven.

@use

gebruikstype(n) (SET<CS>), niet gebruiken in NL

In principe kan van elke Organization Name worden aangegeven in welke situatie deze gebruikt kan worden. Voor Nederland is echter besloten dat het onderscheid (nog) niet relevant is, zodat het advies is om het attribuut use niet te gebruiken in de XML-tag.

<validTime>

geldigheidsinterval (IVL<TS>)

Dit is een optioneel XML-element binnen de Organization Name en duidt de periode aan waarin deze naam 'in gebruik'/geldig was voor de betreffende organisatie. De opties zijn:

• Er is geen validTime element: de betreffende naam is in principe universeel geldig.
• Er is een onder- en een bovengrens: de naam was geldig in de aangeduide periode.
• Er is alleen een ondergrens: de naam is geldig sinds de aangeduide datum.
• Er is alleen een bovengrens: de naam was geldig t/m de aangeduide datum.

XML-voorbeelden

Onder- en bovengrens

<name>
   <validTime>
      <low value='20030101'/>
      <high value='20041231'/>
   </validTime>
   De Oude Naam van de Organisatie
</name> 

De naam was geldig van 1-1-2003 t/m 31-12-2004.

Alleen ondergrens

<name>
   <validTime>
      <low value='20050101'/>
   </validTime>
   De Nieuwe Naam van de Organisatie
</name> 

De naam is geldig sinds 1-1-2005.

Alleen bovengrens

<name>
   <validTime>
      <high value='20051231'/>
   </validTime>
   De Oude Naam van de Organisatie
</name> 

De naam was geldig t/m 31-12-2005.

Zowel ondergrens als bovengrens van validTime kunnen ook in de toekomst liggen, om een geplande nieuwe naam of gepland vervallen van een bestaande naam aan te geven.

File:Info.png

In elke situatie waar één of meer Organization Names worden doorgegeven, moet minimaal de naam worden aangeduid die op het moment van verzenden geldig/actueel is. Vervallen namen kunnen dus alleen worden doorgegeven als het betreffende berichtelement herhalend is (dus met max. cardinaliteit > 1).

Herhalende naam

<name>
   <validTime> 
      <high value='20041231'/>
   </validTime>
   De Oude Naam van de Organisatie
</name>
<name>
   <validTime>
      <low value='20050101'/>
      <high value='20051231'/>
   </validTime>
   De Huidige Naam van de Organisatie
</name>
<name>
   <validTime>
      <low value='20060101'/>
   </validTime>
   De Nieuwe Naam van de Organisatie
</name> 
 

 

QTY (Quantity - hoeveelheid)

Hoeveelheid is een abstract datatype. Het wordt gebruikt om basiseigenschappen van afgeleidde types te definiëren. Deze abstractie is noodzakelijk om andere datatypes te kunnen definiëren zoals bijv. interval. Het kan dus niet als zodanig voorkomen in HL7-berichten.

 

INT (Integer Number - geheel getal)

Elementen van dit datatype hebben een attribuut value dat gehele getallen (integer) kan aannemen. Integers kunnen als zodanig in de berichten voorkomen. Voorbeelden zijn bijv. het aantal herhalingen van een voorschrift (repeatCount) en het sequenceNumber in een herhaalbare actRelationship. In het algemeen geldt dat integers gebruikt worden om te tellen, dan wel te ordenen.

@value

waarde (INT)

XML-voorbeeld

<number value="24"/>

 

REAL (Real Number - getal met decimalen)

Het datatype REAL kan een getal met decimalen als waarde aannemen. Decimale weergave via een punt „.". Het type REAL komt als zodanig niet voor in berichten. Een REAL is altijd onderdeel van een ander type, meestal Physical Quantity (PQ).

 

PQ (Physical Quantity - kwantitatieve weergave van fysieke grootheden)

Elementen van dit datatype zijn fysieke hoeveelheden, d.w.z. een hoeveelheid die een meetbare (of telbare) waarde uit de fysieke wereld weergeeft. Dit is dus iets anders dan alleen een 'aantal', aangezien ook sprake is van een (natuurlijke) eenheid waarin de bepaalde waarde wordt uitgedrukt.

Voorbeelden:

• Een hoeveelheid afgenomen bloed van 20 ml (monstergrootte)
• Een snijwond met een lengte van 10 cm (resultaat observatie)
• Een dosis van 200 milligram per toediening (doseerhoeveelheid)
• Aflevering van 60 stuks van een tablet (verstrekte hoeveelheid)

Elementen van dit datatype hebben de volgende structuur: het value attribuut geeft de hoeveelheid aan, uitgedrukt in de eenheid unit.

@value

grootte van de hoeveelheid (REAL

In unit staat de meeteenheid, uitgedrukt conform de Unified Code for Units of Measure (UCUM). Deze tabel bevat alle natuurlijke meeteenheden.

@unit

meeteenheid (CS)

Als value "niet telbaar", "meetbaar" is (bijv. uitgedrukt in milligram of liter) dan moet deze eenheid in dit attribuut worden opgenomen. Als value 'telbaar' is (bijv. tabletten) dan is dit attribuut niet aanwezig.

Voor een volledige beschrijving van de mogelijke eenheden, zie de Unified Code for Units of Measure (UCUM) specificatie die is opgenomen in [HL7v3]. UCUM is een verzameling van atomaire eenheden en prefixen en een bijhorende grammatica om geldige combinaties daarvan op te bouwen.

Als er een nullFlavor attribuut aanwezig is, mogen value en unit niet aanwezig zijn; als er geen nullFlavor attribuut is, dan moet een value aanwezig zijn. Een alternatieve representatie van dezelfde fysieke hoeveelheid, uitgedrukt in een andere eenheid, mogelijk uit een ander systeem dan UCUM en mogelijk met een andere bijbehorende waarde (value) kan in de translation worden weergegeven.

<translation>

alternatieve representatie (PQR)

Omdat de meetwaarden het meest in samenhang met een algemene observatie worden weergegeven (Observation) waarbij het datatype voor value ANY is, moet in ieder geval het datatype voor de instantiatie door middel van de xsi:type aanduiding worden aangegeven.

XML-voorbeelden

1. Meetwaarde met UCUM eenheid (165 cm)
   

   <value value="165" unit="cm"/>

2. Meetwaarde met UCUM eenheid (92,1 kg)
   

   <value value="92.1" unit="kg"/>

3. Meetwaarde met UCUM eenheid (bloeddruk 120 mmHG)
   

   <value value="120" unit="mm[Hg]"/>

Meetwaarde zonder eenheid (5)

<value value="5"/>

Meetwaarde met alternatieve representatie (1 (stuk), in HL7v3 altijd zonder eenheid, vertaald naar twee alternatieve eenheden (WCIA tabel 25 doseereenheid en G-Standaard Thesaurus 002 doseereenheid))

<doseQuantity>
   <center value="1">
      <translation value="1" code="245" codeSystem="2.16.840.1.113883.2.4.4.1.900.2" displayName="Stuk"/>
      <translation value="1" code="100" codeSystem="2.16.840.1.113883.2.4.4.1.361" displayName="tablet"/>
   </center>
</doseQuantity>

 

MO (Monetary Amount - hoeveelheid geld)

Elementen van dit datatype hebben twee attributen.

@value		waarde (REAL
@currency		valuta (CS)

Dit datatype wordt gebruikt om een hoeveelheid (value) geld aan te duiden in een bepaalde valuta (currency). MO vertoont veel overeenkomsten met het PQ type, er is echter een essentieel verschil: Valutakoersen zijn variabel, dit in tegenstelling tot de omrekening bij fysieke eenheden, vandaar dat geld niet in een PQ type kan worden uitgedrukt.

Valuta wordt gecodeerd volgens ISO 4217.

Tabel: codes voor het currency attribuut (belangrijkste codes)
Code	Naam	Land
EUR	Euro	Europese Unie
GBP	Britse Pond	Verenigd Koninkrijk
USD	Amerikaanse Dollar	Verenigde Staten

XML-voorbeeld

<value xsi:type="MO" currency="EUR" value="97.32"/>

 

TS (Time Stamp - tijdstip)

Elementen van dit datatype hebben een attribuut

@value

waarde (ST)

De 'waarde' van een tijdstip wordt vastgelegd m.b.v. de ISO 8601 notatie die gebruikelijk is binnen HL7. Een tijdstip dient volgens het volgende formaat te worden doorgegeven:

"YYYY[MM[DD[HH[MM[SS[.U[U[U[U]]]]]]]]][+|-ZZ[zz]]"

De betekenis van de componenten in deze syntax is als volgt:

YYYY	Het jaar volgens de Gregoriaanse kalender (waarden 0001-9999)
MM	De maand o.b.v. het volgnummer in het jaar (waarden 01-12)
DD	De dag o.b.v. het volgnummer in de maand (waarden 01-31)
HH	Het uur o.b.v. een 24-uurs notatie van de klok (waarden 00-23)
MM	De minuut binnen het uur (waarden 00-59)
SS	De seconde binnen de minuut (waarden 00-59)
UUUU	Fractie van een seconde (waarden 0-9999)
-	Aanduiding of de tijdzone voor of achter UTC is
ZZ	Het verschil in uren t.o.v. UTC (waarden 00-14)
zz	De bijkomende minuten verschil t.o.v. UTC (waarden 00, 30 of 45)

Noot: UTC staat voor Coordinated Universal Time. Voorheen werd dit wel aangeduid als Greenwich Mean Time (GMT). Het verschil is dat UTC niet afhangt van zomer/wintertijd, d.w.z. dat de UTC in de tijdzone van Greenwich "+01" wordt als het daar zomertijd is.

File:Info.png

Afgezien van bovenstaande ranges voor de waarden van de componenten, geldt dat de combinatie van de componenten jaar, maand en dag een geldige kalenderdatum moet vormen (dus bijv. geen 30 februari).

Als een systeem niet over voldoende informatie beschikt (bijvoorbeeld: alleen het jaar is bekend), kan van rechts naar links worden afgekapt. In principe geeft HL7 daarin volledige vrijheid, maar de interpretatie die binnen Nederland wordt gevolgd is dat het alleen toegestaan is per gehele component (bijv. dat niet alleen het eerste cijfer van de minuten mag worden genoemd, maar alleen géén minuten óf twee cijfers mogelijk is). Uitzondering op deze regel vormt de fractie van een seconde (UUUU component), die wel een willekeurig aantal cijfers mag hebben (met een maximum van 4 cijfers na de punt).

File:Info.png

Een informatiesysteem mag een Time Stamp alleen doorgeven met een precisie die kleiner of gelijk is aan de precisie die het zelf gebruikt binnen de software. Het is dus niet toegestaan om 0'en toe te voegen voor seconden of fracties ervan. Met andere woorden: een component moet alleen gebruikt worden als het ook echt een reële waarde kan krijgen.

File:Info.png

Merk op dat het zeker nuttig (of zelfs nodig) kan zijn om specifieke restricties voor het gebruik van TS aan te geven bij elementen in HL7-berichten. Zo zou bijv. bij de verzendtijd van een HL7-bericht (creationTime in de transmission wrapper) kunnen worden geëist dat minimaal seconden worden doorgegeven. Zie hiervoor de diverse implementatiehandleidingen.

File:Info.png

Bij het opstellen van conformance profiles door leveranciers of instellingen is het van belang om aan te geven welke precisie wordt gehanteerd voor specifieke time stamps. Zonder nadere aanduiding daarvan is de ontvanger nl. verplicht om de volledige precisie die de verzender hanteert te kunnen verwerken, opslaan en reproduceren. Dit is vergelijkbaar met het aanduiden van de maximum lengte van strings of het aantal decimalen van reals.

Met betrekking tot de tijdzone geldt dat deze optioneel kan worden aangeduid, indien de rest van de time stamp minimaal uren omvat. Als een tijdzone wordt aangeduid, geldt dat deze minimaal bestaat uit een + of –en 2 cijfers (de uren van het tijdverschil), met optioneel nog 2 cijfers (de minuten van het tijdverschil, met "00" als standaardwaarde).

File:Info.png

Als geen tijdzone wordt aangeduid is de aanname dat het tijdstip betrekking heeft op de tijdzone van het systeem dat de tijd heeft vastgelegd. Dit zal zelden een probleem zijn in een land als Nederland, maar kan van belang zijn i.v.m. toekomstige internationale uitwisseling.

XML-voorbeelden

<effectiveTime value="1967"/>                  <!--1967 (alleen jaar bekend)-->

<effectiveTime value="196703"/>                <!--maart 1967 (alleen maand)-->

<effectiveTime value="19670330"/>              <!--30 maart 1967 (datum)-->

<effectiveTime value="2007050316"/>            <!--3 mei 2007, van 16 tot 17 uur-->

<effectiveTime value="200705031606"/>          <!--3 mei 2007, om 16:06-->

<effectiveTime value="20070503160614"/>        <!--3 mei 2007, om 16:06:14-->

<effectiveTime value="20070503160614.0843"/>   <!--zelfde, met fractie-->

<effectiveTime value="2007050316+02"/>         <!--tijdzone A'dam in zomertijd-->

<effectiveTime value="200705031606+0530"/>     <!--tijdzone in Mumbai, India-->

<effectiveTime value="20070503160614-05"/>     <!--New York in wintertijd-->

 

BAG (Bag – verzameling met mogelijke dubbelen)

Sommige modelonderdelen dragen als datatype BAG<T> met T als een discreet of continue datatype. Dit betekent een ongesorteerde verzameling van waarden, waar waarden ook meer dan eenmaal kunnen voorkomen.

In de XML-representatie wordt een BAG<T> met een cardinaliteit van n..m omgezet naar een herhaalbaar XML-element met de cardinaliteit n..*.

 

SET (Set – verzameling zonder dubbelen)

Sommige modelonderdelen dragen als datatype SET<T> met T als een discreet of continue datatype. Dit betekent een ongesorteerde verzameling van waarden, waar waarden maximaal een keer kunnen voorkomen.

In de XML-representatie wordt een SET<T> met een cardinaliteit van n..m omgezet naar een herhaalbaar XML-element met de cardinaliteit n..*.

 

SXCM (Set Component – deelverzameling)

Er bestaat een generieke set component die een component representeert van een discreet of continue datatype en is bedoeld als onderdeel van een verzameling. Dit wordt in Nederland op dit moment alleen bij het datatype GTS gebruikt (zie GTS).

 

IVL (Interval)

In de Nederlandse situatie zijn tot nu toe de volgende intervaldefinities gebruikt. Intervallen zijn alleen gedefinieerd voor datatypes met een ordinaal of interval schaaltype. Er zijn verschillende mogelijkheden, een interval te bepalen (zie onderstaande figuur): er wordt bijvoorbeeld

• een ondergrens <low> en een bovengrens <high> (1),
• een ondergrens <low> en een breedte <width> (2)
• een bovengrens <high> en een breedte <width> (3)
• of het midden <center> van het interval en een breedte <width> (4)

aangegeven.

Er zijn vanzelfsprekend nog meer mogelijkheden. Ook hoeft een interval niet altijd volledig gespecificeerd te zijn (open intervallen). Zo kan bijvoorbeeld met alleen een bovengrens een maximale dosis worden aangeduid.

Om implementatieredenen worden in de Nederlandse situatie voor het aanduiden van een interval alleen de volgende combinaties toegestaan:

• een ondergrens <low> en een bovengrens <high>
• een ondergrens <low> en een breedte <width>
• alleen een ondergrens <low>
• alleen een bovengrens <high>
• alleen het midden van het interval <center>
• alleen de breedte van een interval <width>

Voor de volgende datatypes zijn intervalspecificaties gedefinieerd.

 

IVL<TS> (Interval of Time Stamps - tijdsinterval)

Elementen van dit datatype duiden tijdsintervallen aan. Daarbij wordt in de regel een boven- en een ondergrens als tijdstip aangeduid. Bij open tijdsintervallen (bijv. vanaf tijdstip X, of geldig tot tijdstip Y) wordt slechts één van de beide elementen aangegeven.

<low>

ondergrens (TS)

Bevat het begintijdstip van een tijdsinterval. In Nederland kan low op de volgende manieren worden toegepast: als enige element van IVL_TS (als het eindtijdstip niet bekend is) of in combinatie met high of width (als het eindtijdstip of de duur bekend is).

De waarde in low heeft als standaardinterpretatie "een begintijdstip later dan, of gelijk aan". Door expliciet op te geven dat inclusive="false" kan dit worden veranderd in "een begintijdstip later dan". Merk op dat de interpretatie mede afhangt van de nauwkeurigheid van het tijdstip: "na 2004" betekent "vanaf 1 Januari 2005", "na 20041201" betekent "vanaf 2 December 2004 00:00 uur", en "na 200412011200" betekent "vanaf 1 December 2004 12:01".

<high>

bovengrens (TS)

Bevat het eindtijdstip van een tijdsinterval. In Nederland kan high op de volgende manieren worden toegepast: als enige element van IVL_TS (als het begintijdstip niet bekend is) of in combinatie met low of width (als het begintijdstip of de duur bekend is).

De waarde in high heeft als standaardinterpretatie "een eindtijdstip voorafgaande aan, of gelijk aan". Door expliciet op te geven dat de bovengrens niet inclusief is kan dit worden veranderd in "een eindtijdstip voorafgaande aan". Dit wordt door het attribuut

@inclusive

"true|false" (BL)

aangeduid en kan zowel in een <low> en een <high> element worden gebruikt. Als het niet gespecificeerd is wordt als standaardwaarde "true" aangenomen.

Merk op dat de interpretatie mede afhangt van de nauwkeurigheid van het tijdstip: "voorafgaande aan 2008" betekent "voor 1 Januari 2008", "voorafgaande aan 20081201" betekent "voor 1 December 2008", en "voorafgaande aan 200412011200" betekent "voor 1 December 2004 12:00".

<center>

midden van het tijdsinterval (TS)

Bevat een tijdstip dat het midden vormt van het tijdsinterval. In Nederland wordt dit uitsluitend toegepast indien men (in een element van het datatype IVL<TS>) één specifiek tijdstip wil doorgeven in plaats van een tijdsinterval. center wordt in Nederland nooit gebruikt in combinatie met low, high, of width.

Merk op dat de interpretatie mede afhangt van de nauwkeurigheid van het tijdstip: "Op (in) 2005" betekent "in het jaar 2005", "op 20051201" betekent "op 1 December 2005", en "200512011200" betekent "op 1 December 2005 om 12:00 uur".

<width>

tijdsduur van het interval (PQ)

Bevat de tijdsduur van het interval. In Nederland wordt dit slechts in twee situaties toegepast: 1) als enige element van IVL_TS (in die gevallen waarin niets anders dan de duur van het interval bekend is) of 2) in combinatie met het low element, om aan te geven dat het interval een bepaalde duur heeft vanaf het beginmoment. Die laatste situatie is feitelijk synoniem met het gebruik van low in combinatie met high, maar is vaak handiger als de looptijd wordt aangeduid (en de einddatum daaruit afgeleid).

File:Info.png

Het <width> element is van datatype PQ (Physical Quantity). De waarde moet natuurlijk betrekking hebben op een tijdsduur. Het is daarbij verplicht om een tijdseenheid aan te duiden. Hierbij zijn de eenheden 'us' (microseconde), 'ms' (milliseconde), 's' (seconde), 'min' (minuut), 'h' (uur), 'd' (dag), 'wk' (week), 'mo' (maand) en 'a' (jaar) beschikbaar.

File:Info.png

Merk op dat ten aanzien van het gebruik van IVL_TS bij het doorgeven van doseerschema's in medicatievoorschriften (als onderdeel van het datatype GTS) aanvullende regels zijn vastgelegd binnen het NICTIZ EMD project.

XML-voorbeelden

1. vanaf 7 mei 2004 t/m 9 september 2004
   

   <effectiveTime>
      <low value="20040507"/>
      <high value="20040909"/>
   </effectiveTime>

2. vanaf 7 mei 2004
   

   <effectiveTime>
      <low value="20040507"/>
   </effectiveTime>

3. Op (gedurende) 3 januari 1975
   

   <value>
      <center value="19750103">
   </value>

4. In (gedurende) 2003
   

   <value>
      <center value="2003">
   </value>

5. vanaf 3 januari 1975, maar vóór 7 januari 1975
   

   <value>
      <low value="19750103">
      <high value="19750107" inclusive="false">
   </value>

6. gedurende 2 weken
   

   <value>
     <width value="2" unit="wk"/>
   </value>

7. gedurende 120 dagen, vanaf 1 januari 2008
   

   <value>
      <low value="20080101"/>
      <width value="120" unit="d"/>
   </value>

 

IVL<INT> (Interval of Integers – numeriek interval)

Elementen van dit datatype duiden intervallen van integer (gehele) getallen aan. Daarbij wordt in de regel een boven- en een ondergrens als getal aangeduid. Bij open intervallen (bijvoorbeeld bij een uitgifte van een herhaling "hooguit 3 keer herhalen") wordt slechts een van de beide elementen aangegeven.

<low>		ondergrens (INT)
<high>		bovengrens (INT)

XML-voorbeeld

1. Vanaf 3 t/m 5
   

   <repeatNumber>
      <low value="3"/>
      <high value="5"/>
   </repeatNumber>

2. hooguit 5
   

   <repeatNumber>
      <high value="5"/>
   </repeatNumber>

 

IVL<PQ> (Interval of Physical Quantities - hoeveelheidsinterval)

Elementen van dit datatype duiden intervallen van fysieke hoeveelheden aan. Daarbij wordt in de regel een boven- en een ondergrens als value-unit paar aangeduid. Ook is het mogelijk om in plaats van <low> en <high> gebruik te maken van <center>.

<low>

ondergrens (PQ)

Dit geeft de ondergrens van het interval aan (d.w.z. de minimale hoeveelheid).

<high>

bovengrens (PQ)

Dit geeft de bovengrens van het interval aan (d.w.z. de maximale hoeveelheid).

<center>

exacte waarde (PQ)

Dit element wordt gebruikt als geen sprake is van een interval, maar van een exacte waarde. Alternatief zou zijn om het datatype IVL_PQ in dat geval terug te brengen tot PQ, maar dit is bij verwerking van de XML lastiger, dus dit wordt in Nederland uitgesloten. Het element <center> mag niet in combinatie met <low> of <high> voorkomen.

XML-voorbeelden

Tussen 7,5 en 10 mmol/l.

<referenceRange>
   <low value="7.5" unit="mmol/l"/>
   <high value="10" unit="mmol/l"/>
</referenceRange>

Precies 9 stuks.

<doseQuantity>
   <center value="9" unit="1"/>
</doseQuantity>

 

RTO (Ratio - onderlinge verhouding tussen twee gegevens)

Elementen van dit datatype hebben twee subelementen, de teller (numerator) en de noemer (denominator) van een vergelijking (Ratio). Het QTY (Quantity) datatype is een abstract datatype en wordt in berichten vervangen door een specifiek dataype, veelal PQ of TS. De relevante structuurelementen zijn:

<numerator>

teller (QTY)

De hoeveelheid die gedeeld wordt in de ratio. De standaardwaarde is de integer 1.

<denominator>

noemer (QTY)

De hoeveelheid waardoor de numerator gedeeld wordt in de ratio. De standaardwaarde is de integer 1. De denominator mag niet de waarde 0 hebben. De denominator is veelal een tijdseenheid.

XML-voorbeelden

6 (keer/stuk) per (één) dag

<maxDoseQuantity>
   <numerator xsi:type="PQ" value="6"/>
   <denominator xsi:type="PQ" value="1" unit="d"/>
</maxDoseQuantity>

400 milligram per (één) dag

<maxDoseQuantity>
   <numerator xsi:type="PQ" value='400' unit='mg'/>
   <denominator xsi:type="PQ" value='1' unit='d'/>
</maxDoseQuantity>

5 per (één) uur

<maxDoseQuantity>
   <numerator xsi:type="PQ" value="5"/>
   <denominator xsi:type="PQ" value="1" unit="h"/>
</maxDoseQuantity>

1:10000 bijvoorbeeld bij epidemiologische gegevens of bij lab resultaten

<value xsi:type="RTO_QTY_QTY">
   <numerator xsi:type="INT" value="1"/>
   <denominator xsi:type="INT" value="10000"/>
</value>

 

GTS (General Timing Specification - generieke tijdspecificatie)

Het volgende beschrijft het GTS (Generic Timing Specification, generieke tijdsopgave) datatype, waarbij uitsluitend die onderdelen worden beschreven die in de Nederlandse situatie van toepassing zijn. Indien er specifieke aanwijzingen zijn hoe iets in Nederland geïmplementeerd moet worden dan is dit in de tekst aangegeven.

Het datatype GTS biedt een zeer rijke (maar ook complexe) structuur voor het aanduiden van tijdstippen, tijdsintervallen en tijdsschema's met een vrijwel onbeperkt complexe opbouw. De studie van GTS is een onderwerp op zich, maar gelukkig zijn de meeste toepassingen uit te drukken met een beperkte set GTS functies, zoals TS en IVL<TS>.

Vereenvoudigd is een GTS een SET<TS>. Deze kunnen worden gecombineerd tot sets van periodes en door set operaties is het mogelijk op deze manier ook complexe tijdsaanduidingen te specificeren. Het volgende plaatje schetst als voorbeeld een tijdsaanduiding van bijvoorbeeld een instructie voor medicatietoediening "op even dagen (begin met dag 0, de eerste dag dat de medicatie wordt toegediend) door de week ma t/m vr" als een set van dagen. Het set van weekdagen (eerste rij) wordt met een set van de dagen ma t/m vr, gedefinieerd als een tijdsinterval doorsneden. Dit levert de derde rij. Deze wordt met een set van even dagen doorsneden en levert uiteindelijk rij vijf met het gewenste resultaat.

Er zijn verschillende XML-representaties van een element met als type GTS denkbaar, maar in Nederland heeft een volledig element van type GTS altijd het formaat:

Het XML-element effectiveTime wordt gedeclareerd als SXPR (parenthetic set expression van type TS) en de set componenten <comp> als kindelementen toegevoegd.

Dat betekent dat binnen het XML-element gebruik gemaakt wordt van de Set Component elementen. In XML heeft dus een GTS datatype altijd het volgende patroon. <effectiveTime xsi:type="SXPR_TS"> <comp xsi:type="..."> ... </comp> <comp xsi:type="..." operator="A"> ... </comp> </effectiveTime>

Als set componenten zijn de datatypes PIVL<TS> (periodic interval of time) en EIVL<TS> (event related interval of time) toegestaan. In Nederland wordt op dit moment alleen PIVL<TS> gebruikt. Een set component wordt door de xsi:type aanduiding tot een datatype PIVL_TS, IVL_TS of TS gemaakt. De set component kan echter ook zelf weer van type SXPR zijn, zodat een geneste structuur ontstaat. Voor de set componenten zijn operatoren beschikbaar (zie ook het voorbeeld boven voor de set operaties) waarmee de verschillende componenten aan elkaar kunnen worden gerelateerd: de vereniging met het voorgaande tijdschema, het verschil met het voorgaande tijdschema of de doorsnede met het voorgaande tijdschema (zie beneden bij PIVL<TS> voor een verdere toelichting).

<effectiveTime xsi:type="SXPR_TS">
   <comp xsi:type="IVL_TS">
      een gewone intervalaanduiding
   </comp>
   >comp xsi:type="PIVL_TS" operator="A">
      periodieke intervalaanduidingen (hier met een operator tussen de twee sets)
   </comp> 
</effectiveTime>

Omdat GTS een superklasse van alle tijdsaanduidingen in HL7 is, kan een element van datatype GTS in een XML-instance ook tot bijvoorbeeld een interval worden gemaakt door het xsi:type attribuut te gebruiken. Stel dat effectiveTime is gedefinieerd als GTS in een model, dan zijn in de volgende XML-instances allemaal geldige tijdsaanduidingen.

<effectiveTime xsi:type="IVL_TS">
   <low value="20050924"/>
   <high value="20050925"/>
</effectiveTime >

<effectiveTime xsi:type="SXPR_TS">
   <comp xsi:type="IVL_TS">
      <low value="20050901"/>
      <width value="90" unit="d"/>
   </comp>
   <comp xsi:type="PIVL_TS" operator="A">
      <period value="2" unit="d"/>
   </comp> 
</effectiveTime>

File:Info.png

Merk op dat ten aanzien van het gebruik van GTS bij het doorgeven van doseerschema's in medicatievoorschriften aanvullende richtlijnen (in de vorm van restricties) zijn vastgelegd binnen het NICTIZ-project Medicatiegegevens.

 

PIVL<TS> (Periodic Interval of Time - periodiek herhalend tijdsinterval)

Definitie: Een tijdsinterval (of tijdsmoment) dat zich periodiek herhaalt.

Attribuut:

@operator		bewerking op verzameling (CS)
@alignment		uitgelijnd op ... (CS)
@institutionSpecified		stiptheidsindicator (BL), niet gebruiken in NL

Elementen:

<phase>		basisinterval (IVL<TS>)
<period>		herhaalperiode (PQ [time])

Structuur: Het datatype PIVL<TS> is een extensie op datatype SXCM (Set Component) en is dus bedoeld als onderdeel van een verzameling. In dit specifieke geval bestaat zo'n verzameling uit tijdspecificaties die tezamen de beschrijving geven van een bepaald tijdschema. De tijdspecificaties worden daarbij aan elkaar gerelateerd d.m.v. operatoren (set operators), zoals 'vereniging', 'verschil' en 'doorsnede'. Dit is niet eenvoudig uit te leggen zonder voorbeelden te geven, hetgeen hieronder dan ook uitgebreid zal gebeuren.
Toepassing: berichtelementen met datatype PIVL<TS> komen alleen voor als onderdeel van het (abstracte) datatype GTS. Deze General Timing Specification geeft een zeer algemene methode om tijdschema's weer te geven en bestaat per definitie uit een verzameling aan elkaar gerelateerde componenten. Eén van de belangrijkste soorten componenten is het datatype PIVL<TS>. Hiermee worden terugkerende patronen in de tijd weergegeven, zoals '2x per dag', of 'om de 2 weken op maandag van 10:00 tot 10:30'.

XML-voorbeelden

2x per dag

<comp xsi:type="PIVL_TS">
   <period value='0.5' unit='d'/>
</comp> 

Elke 2 weken op maandag van 10:00 tot 10:30

<comp xsi:type="PIVL_TS" alignment='DW'>
   <phase>
      <low value='200508291000'/>
      <width value='30' unit='min'/>
   </phase>
   <period value='2' unit='wk'/>
</comp> 

Noot: in beide bovenstaande voorbeelden heeft het berichtelement de naam <comp>. Dit geeft aan dat het elementen zijn binnen het datatype SXPR (Parenthetic Set Expression), hetgeen de vorm is waarin PIVL<TS> meestal voorkomt. Meer uitleg over SXPR is te vinden bij het datatype GTS (General Timing Specification) elders in dit document.

@operator

bewerking op verzameling (CS)

Zoals gezegd is PIVL<TS> bedoeld als onderdeel van een verzameling componenten. Deze componenten duiden een tijdschema aan door aan elkaar gerelateerd te worden. Dit kan het beste worden toegelicht aan de hand van een aantal voorbeelden uit de praktijk.

Stel dat een medicatievoorschrift is uitgeschreven met een looptijd van 90 dagen vanaf 1-9-2005 (d.w.z. de beoogde toedieningsperiode loopt van 1-9-2005 t/m 29-11-2005).

Het element effectiveTime in het gebruiksvoorschrift heeft datatype GTS en bestaat uit een verzameling van het datatype SXPR (Parenthetic Set Expression), die begint met het interval tussen deze twee data. Het is dus een verzameling met daarin een IVL<TS>:

XML-voorbeelden

Beoogde toedieningsperiode

<effectiveTime xsi:type="SXPR_TS">
   <comp xsi:type="IVL_TS">
      <low value='20050901'/>
      <width value='90' unit='d'/>
   </comp>
<effectiveTime/>

Noot: In bovenstaand voorbeeld komt op zich het datatype PIVL<TS> nog niet eens voor, maar het dient als basis om uit te leggen hoe de operator in PIVL<TS> gebruikt wordt om de verzameling te definiëren. Zie verder de beschrijving bij het algemene datatype GTS.

Stel nu dat in de betreffende periode elke 2 dagen een toediening plaats moet vinden. In feite moet dan de doorsnede worden genomen van het aangegeven interval en een periodiek herhalend 'iets', waarvan alleen bekend is dat het elke 2 dagen plaatsvindt.

Elke 2 dagen binnen het aangeduide interval

<effectiveTime xsi:type="SXPR_TS">
   <comp xsi:type="IVL_TS">
      <low value='20050901'/>
      <width value='90' unit='d'/>
   </comp>
   <comp xsi:type="PIVL_TS" operator="A">
      <period value="2" unit="d"/>
   </comp>
<effectiveTime/>

De operator "A" in de hierboven toegevoegde PIVL<TS> component heeft de betekenis: 'Neem de doorsnede van de eerder aangeduide tijden (interval van 90 dagen vanaf 1-9-2005) met de herhaalperiode (period) die daarna wordt aangegeven. Het resultaat is dus 'elke 2 dagen van 1-9-2005 t/m 29-11-2005'. Dit levert dus 45 toedienmomenten op, zonder dat precies is aangegeven op welk moment van de dag deze momenten plaatsvinden.

De geldige operatoren bij PIVL<TS> (en alle andere componenten van een SXPR) zijn:

Domain SetOperator
Code	Definitie
I	Neem de vereniging met het voorgaande tijdschema.
E	Neem het verschil met het voorgaande tijdschema.
A	Neem de doorsnede met het voorgaande tijdschema.

File:Info.png

Het attribuut operator is verplicht binnen een PIVL<TS> berichtelement in alle gevallen waar het onderdeel is van een SXPR verzameling én niet het eerste element is. Bij 2e en verdere elementen van een SXPR verzameling moet immers worden aangegeven wat de relatie is met de voorgaande elementen (of liever gezegd met de tot dan toe opgebouwde verzameling).

Zie verder de algemene beschrijving bij GTS voor de toepassing van de set operator.

<phase>

basisinterval (IVL<TS>)

Het element phase geeft als het ware een voorbeeld (prototype) van het basisinterval (of basistijdstip) dat in het datatype PIVL<TS> periodiek herhaald wordt. Zo kan bijv. 'elke dag om 14:00' worden aangegeven in PIVL<TS> door als phase het tijdstip '14:00' op een willekeurige dag aan te duiden en bij period aan te geven dat dit dagelijks herhaalt.

Het element phase is niet verplicht, aangezien het ook voorkomt dat alleen een herhaalperiode moet worden aangeduid en geen basistijdstip of –interval nodig is. Zo is bij 'elke 2 dagen' in het laatste voorbeeld hierboven geen phase nodig, omdat niet relevant is op welk moment binnen elke 2 dagen de gebeurtenis plaatsvindt. Hieronder zullen enkele voorbeelden worden gegeven van situaties waarbij dat wel het geval is.

XML-voorbeelden

Elke dag om 8:00

<comp xsi:type="PIVL_TS">
   <phase>
      <center value="200509010800"/>
   </phase>
   <period value="1" unit="d"/>
</comp> 

Merk op dat het feit dat hier 1 september 2005 wordt gebruikt feitelijk niet relevant is! De phase is alleen aanwezig omdat het tijdstip 08:00 moet worden doorgegeven en dient dus als een prototype van zo'n tijdstip. Daarbij moet wel een datum worden vermeld, omdat het doorgeven van een los tijdstip in HL7 versie 3 (datatype TS) niet mogelijk is! Er had dus ook <center value="198812040800"> kunnen staan en dan zou de verwerkende software daar exact dezelfde conclusie uit moeten trekken (elke dag om 08:00).
Merk ook op dat phase altijd de vorm van een interval heeft (datatype IVL_TS). Als dus één enkel tijdstip (of één enkele dag) moet worden aangeduid, dan kan dat het beste gebeuren door het element <center> van IVL_TS toe te passen. Daarmee wordt het interval in feite gereduceerd tot een tijdstip, maar met behoud van de structuur van IVL.

Elke dag om 8:00, gedurende 10 minuten

<comp xsi:type="PIVL_TS">
   <phase>
      <low value="200509010800"/>
      <width value="10" unit="min"/>
   </phase>
   <period value="1" unit="d"/>
</comp> 

Het enige verschil met het voorgaande voorbeeld is dat de phase nu een 'echt' interval is i.p.v. een enkelvoudig tijdstip. Dit wordt bijv. gebruikt als een medicatietoediening, een fysiotherapiebehandeling of een andere activiteit gedurende een bepaalde tijd moet worden uitgevoerd. Dit kan ook voorkomen als het tijdstip feitelijk niet relevant is:

Elke dag, gedurende 10 minuten

<comp xsi:type="PIVL_TS">
   <phase>
      <width value="10" unit="min"/>
   </phase>
   <period value="1" unit="d"/>
</comp> 

In dit voorbeeld is van de phase alleen nog maar de duur (width) relevant.

@alignment

uitgelijnd op (CS)

Het attribuut alignment wordt gebruikt om aan te geven welk aspect van de phase (het basisinterval) relevant is voor de het bepalen van het herhaalpatroon. Dat klinkt in eerste instantie zeer verwarrend, maar het geeft de mogelijkheid om vrij eenvoudig herhaalpatronen als 'elke maandag' of 'elke 14e van de maand' of 'elke 2 mei' aan te duiden.

XML-voorbeelden

Elke maandag

<effectiveTime xsi:type="PIVL_TS" alignment="DW">
   <phase>
      <center value="20050829"/>
   </phase>
   <period value="1" unit="wk"/>
</effectiveTime>

De alignment 'DW' geeft hier aan dat het relevante aspect van de aangeduide phase de 'day of the week' is. Aangezien 29/8/2005 een maandag was, staat hier dus niets anders dan 'elke maandag'. Zoals eerder vermeld is de precieze waarde van phase niet relevant.

De geldige alignment varianten bij PIVL_TS zijn voor Nederland beperkt tot:

Domain CalendarCycle:
Code	Naam	Definitie
day of the week	DW	elke maandag, dinsdag, woensdag, …
day of the month DM	elke 1e, 2e, 3e, 4e, … van de maand
day of the year	DY	elke 1-1, 2-1, 3-1, 4-1, … van het jaar

Merk op dat het dus alleen zin heeft om een alignment mee te geven als de phase de vorm heeft van een enkelvoudig tijdstip of van een interval dat binnen één dag valt.

Elke 15e van de maand

<effectiveTime xsi:type="PIVL_TS" alignment="DM">
   <phase> 
      <center value="20050915'"/>
   </phase>
   <period value="1" unit="mo"/>
</effectiveTime>

Elke 1-3 en 1-8, van 14:00 tot 16:00

<effectiveTime xsi:type="SXPR_TS">
   <comp xsi:type="PIVL_TS" alignment="DY">
      <phase> 
         <low value="200503011400"/>
         <width value="2" unit="h"/>
      </phase>
      <period value="1" unit="a"/>
   </comp>
   <comp xsi:type="PIVL_TS" operator="I" alignment="DY"> 
      <phase> 
         <low value="200508011400"/>
         <width value="2" unit="h"/>
      </phase>
      <period value="1" unit="a"/>
   </comp>
</effectiveTime>

@institutionSpecified

stiptheidsindicator (BL)

Het attribuut institutionSpecified is bedoeld om aan te geven of de herhalende periode die door het PIVL<TS> datatype wordt aangeduid een 'harde' of 'zachte' tijdspecificatie is. Dat wil zeggen: mag de ontvanger bij een aanduiding van '3x per dag' zelf bepalen op welke tijdstippen de activiteit plaatsvindt of moet dit exact elke 8 uur (gelijke delen) gebeuren.

Er zijn drie redenen waarom dit attribuut vooralsnog in Nederland niet gebruikt wordt:

• Er bestaat nog de nodige discussie over de juiste interpretatie van dit attribuut.
• De naam is slecht gekozen, omdat hetzelfde fenomeen zich net zo goed voordoet bij bijv. ambulante medicatievoorschriften. In dat geval betekent institutionSpecified 'door de patiënt met gezond verstand te bepalen'.

<period>

herhaalperiode (PQ [time])

Het element period is verplicht aanwezig in elk berichtelement van datatype PIVL<TS> en geeft daarin aan wat de herhaalperiode is van de activiteit waarop het betrekking heeft.

De period heeft zelf het datatype PQ (Physical Quantity), met de beperking dat alleen aanduidingen van een tijdsduur mogen worden gebruikt. Het formaat is dus altijd:

<period value="<aantal>" unit=:<tijdseenheid>"/> 

De volgende tijdseenheden (conform UCUM) moeten daarbij altijd ondersteund worden:

Naam	Eenheid	Definitie
second	s	SI-eenheid "the duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium-133 atom at zero kelvins"
minute	min	60 s
hour	h	60 min
day	d	24 h
week	wk	7 d
year	a	365.25 d (zie noot)
month	mo	1 a/12

Noot: Merk op dat de definitie van het jaar (unit 'a', afgeleid van 'annum') gebaseerd is op de zogenaamde Juliaanse kalender (met een jaar van exact 365.25 dagen). Daar waar het belangrijk is dat een activiteit altijd op dezelfde dag van de maand of van het jaar valt, zal het alignment attribuut gebruikt worden, zodat geen misverstanden ontstaan.

In het simpelste geval kan op deze manier bijv. worden aangeduid dat een activiteit (bijv. het toedienen van medicatie) elke 2 uur moet worden uitgevoerd. Dit gebeurt zo:

XML-voorbeelden

Elke 2 uur

<comp xsi:type="PIVL_TS">
   <period value="2" unit="h"/>
</comp>

Bij medicatievoorschriften is het gebruikelijk om bijv. '3x per dag' aan te geven als frequentie voor de toediening. Dit kan binnen PIVL<TS> op twee manieren worden uitgedrukt:

3x per dag, in dagen

<comp xsi:type="PIVL_TS">
   <period value="0.3333" unit="d"/>
</comp>

3x per dag, in uren

<comp xsi:type="PIVL_TS">
   <period value="8" unit="h"/>
</comp>

In het tweede geval wordt dus omgerekend o.b.v. 1 d = 24 h. Omdat in het PIVL<TS> datatype geen frequentie, maar een herhaalperiode wordt toegepast, is '3x per dag' alleen in gehele getallen uit te drukken als 'elke 8 uur'. Gevoelsmatig klinkt dat laatste strikter, maar mathematisch zijn de twee aanduidingen op afronding na equivalent.

File:Info.png

Omdat de beide aanduidingen (o.b.v. dagen resp. uren) vergelijkbaar zijn, moet elke ontvangende applicatie in staat zijn om ze beide te verwerken. Binnen de verwerkende applicatie moeten ze leiden tot exact dezelfde interpretatie. Dit is nog niet triviaal, omdat de weergave in dagen (met een fractie) tot afrondingsfouten kan leiden. Waarschijnlijk is het dus nodig om deze 'hard' te herkennen en om te zetten naar de interne weergave. Een zendend systeem mag zelf bepalen welke methode de voorkeur heeft. Als richtlijn geldt wel dat bij een niet-gehele value (zoals 0.3333 hierboven) er maximaal 4 relevante decimalen na de punt worden doorgegeven.

Een vergelijkbaar fenomeen doet zich voor bij herhaalperiodes van meer dan één dag:

1x per 2 dagen

<comp xsi:type="PIVL_TS">
   <period value="2" unit="d"/>
</comp>

Deze situatie is eenvoudig, maar lastiger wordt het bij '3x per week' (op twee manieren):

3x per week, in weken

<comp xsi:type="PIVL_TS">
   <period value="0.3333" unit="wk"/>
</comp>

3x per week, in dagen

<comp xsi:type="PIVL_TS">
   <period value="2.3333" unit="d"/>
</comp>

Ook hier is het mogelijk om dit om te werken naar een geheel getal, maar dan moet worden gewisseld naar 'h' als eenheid. De keuze is ook hier aan het zendende systeem, maar elk ontvangend systeem moet in staat zijn om alle drie de varianten te verwerken.

3x per week, in uren

<comp xsi:type="PIVL_TS">
   <period value="56" unit="h"/>
</comp>

Het is ook mogelijk dat een frequentie wordt aangeduid als '2x per maand'. Daarbij moet worden aangetekend dat dit geen exacte aanduiding is (door het wisselende aantal dagen per kalendermaand), maar binnen PIVL<TS> kan het worden uitgedrukt op de volgende wijze:

2x per maand

<comp xsi:type="PIVL_TS">
   <period value="0.5" unit="mo"/>
</comp>

Of als de frequentie wordt aangeduid als '3x per jaar'

<comp xsi:type="PIVL_TS">
   <period value="0.3333" unit="a"/>
</comp>

File:Info.png

Merk op dat omrekenen van maanden of jaren naar dagen of weken niet wenselijk is, omdat dit onhandige waarden zal opleveren (als de exacte omrekenfactoren worden toegepast) of zelfs tot een andere interpretatie zal leiden (als bijv. 1 mo = 30 d of 1 mo = 4 wk als factor wordt gehanteerd).

Het is echter wel toegestaan om te rekenen tussen jaren en maanden onderling. Het voorgaande voorbeeld zou dan ook kunnen worden uitgedrukt met de volgende PIVL:

3x per jaar, in maanden

<comp xsi:type="PIVL_TS">
   <period value="4" unit="mo"/>
</comp>

Hier wordt dus gebruik gemaakt van de omrekenfactor 1 mo = 1 a/12. Feit is dat dit een minder 'harde' omrekenfactor is dan degene tussen seconden, minuten, uren en weken.

Dit levert de volgende tabel op met omrekeningen die moeten worden ondersteund:

unit unit	s	min	h	d	wk	mo	a
s	X	X	+	+	+
min	X	X	X	+	+
h	+	X	X	X	+
d	+	+	X	X	X
wk	+	+	+	X	X
mo						X	+
a						+	X

De "X" in deze tabel geven omrekeningen aan die door alle ontvangende systemen moeten worden ondersteund. De "+" geven omrekeningen aan die bij voorkeur moeten worden ondersteund. De niet gevulde cellen duiden op omrekeningen (van verzonden informatie naar opgeslagen interpretatie of andersom) die niet mogen plaatsvinden.

Vanaf de volgende release van de HL7v3 Data Type specification wordt het ook mogelijk om naast <period> een element <frequency> te gebruiken in PIVL. Op dat moment kunnen bovenstaande voorbeelden exact conform de intentie worden doorgegeven (waardoor bijv. het verschil tussen 3x per dag en 1x per 8 uur expliciet gemaakt kan worden.

 

ALGEMENE VOORBEELDEN

Om het gecombineerde gebruik van phase en period toe te lichten, worden hieronder nog enige voorbeelden gegeven waarbij er sprake is van een periodieke activiteit (bijv. een bepaalde medicatietoediening), die een vast ijkpunt en/of een vaste tijdsduur heeft.

Meestal zal dit dan voorkomen in combinatie met een SXPR component die het interval aangeeft waarbinnen de activiteit plaatsvindt. De volledige effectiveTime wordt dan:

XML-voorbeelden

3x per dag, telkens om 06:00, 14:00 en 22:00, gedurende 30 min., vanaf 2 sept. 2005 om 14:00

<effectiveTime xsi:type="SXPR_TS">
   <comp xsi:type="IVL_TS">
      <low value="200509021400"/>
   </comp>
   <comp xsi:type="PIVL_TS" operator="A">
      <phase>
         <low value="200509022200"/>
         <width value="30" unit="min"/>
      </phase>
      <period value="0.3333" unit="d"/>
   </comp>
</comp>

De PIVL<TS> component krijgt hier de operator "A", omdat de doorsnede genomen moet worden met het interval dat daarboven al in de IVL_TS is aangeduid ('vanaf 2-9-2005').

Merk op dat het feitelijke tijdstip in de phase component van de PIVL<TS> niet relevant is, d.w.z. het doet alleen dienst als ijkpunt voor de period, maar is verder willekeurig. Er staat op deze manier '3x per dag, gedurende 30 min.', maar daarbij wordt wel aangegeven dat deze herhaling steeds op 14:00, 22:00 en 06:00 moet vallen (aangezien 22:00 als ijkpunt voor de herhaling wordt gegeven). In combinatie met het interval erboven, levert dat de volgende momenten op waarop de activiteit moet plaatsvinden:

2 sept. 2005 om 14:00	(ook al ligt dit vóór het ijkpunt)
2 sept. 2005 om 22:00	(dit is 'toevallig' het ijkpunt)
3 sept. 2005 om 06:00
....	(en zo verder om de 8 uur)

Merk op dat als de duur van de activiteit niet relevant (of niet bekend) was geweest, de component width van de phase gewoon afwezig had kunnen blijven. Als zelfs de begintijd niet relevant (of niet bekend) was geweest, dan was de hele phase niet nodig geweest. Dit zou de onderstaande PIVL<TS> componenten in het eerdergenoemde voorbeeld opleveren:

3x per dag, telkens om 06:00, 14:00 en 22:00

<comp xsi:type="PIVL_TS" operator="A">
   <phase>
      <low value="200509022200"/>
   </phase>
   <period value="0.3333" unit="d"/>
</comp>

3x per dag

<comp xsi:type="PIVL_TS" operator="A">
   <period value="0.3333" unit="d"/>
</comp>

Vervolgens een vergelijkbaar voorbeeld met een herhaling op twee vaste weekdagen:
Elke ma en vr, om 13:00, gedurende 4 uur, tijdens sept. 2005

<effectiveTime xsi :type="SXPR_TS">
   <comp xsi:type="IVL_TS">
      <low value="20050901"/>
      <high value="20050930"/>
   </comp>
   <comp xsi:type="SXPR_TS" operator="A">
      <comp xsi:type="PIVL_TS" alignment="DW">
         <phase>
            <low value="200508291300"/>
            <width value="4" unit="h"/>
         </phase>
         <period value="1" unit="wk"/>
      </comp>
      <comp xsi:type="PIVL_TS" operator="I" alignment="DW">
         <phase>
            <low value="200509021300"/>
            <width value="4" unit="h"/>
         </phase>
         <period value="1" unit="wk"/>
      </comp>
   </comp>
</comp>

Merk op dat hier twee PIVL<TS> componenten worden gedefinieerd, die met elkaar verenigd worden (operator "I"). Gezamenlijk wordt deze subset weer doorsneden (operator "A") met het interval dat erboven is vastgelegd ('de maand september'). Dit is een voorbeeld van geneste toepassing van het datatype SXPR.
Merk tevens op dat het basisinterval van de eerste PIVL<TS> (voor de herhaling op maandag) niet eens binnen het interval ligt waarmee doorsneden wordt (29-8 wordt nl. als ijkpunt gebruikt). De relevante aspecten van het ijkpunt zijn alleen de weekdag (door de combinatie met de alignment op "DW") en het begintijdstip (vanaf 13:00). Met andere woorden: de PIVL<TS> beschrijft in feite elke maandag tussen 13:00 en 17:00, van het oneindige verleden tot in de oneindige toekomst. De doorsnede zorgt voor de inperking.

Al met al levert dit de volgende lijst met door deze structuur gedefinieerde momenten:

2 sept. 2005 om 13:00	(de eerste vrijdag van september 2005)
5 sept. 2005 om 13:00	(de eerste maandag van september 2005)
9 sept. 2005 om 13:00	(de tweede vrijdag van september 2005)
....
26 sept. 2005 om 13:00	(de laatste maandag van september 2005)
30 sept. 2005 om 13:00	(de laatste vrijdag van september 2005)

Tenslotte een voorbeeld waarin een bepaald interval periodiek wordt uitgesloten:

Pilschema: 21 dagen wel, 7 dagen niet, 1x per dag om 09:00

<effectiveTime xsi :type="SXPR_TS">
   <comp xsi:type="IVL_TS">
      <low value="20050901"/>
      <high value="20051130"/>
   </comp>
   <comp xsi:type="SXPR_TS" operator="A">
      <comp xsi:type="PIVL_TS">
         <phase>
            <low value="200509010900"/>
         </phase>
         <period value="1" unit="d"/>
      </comp>
      <comp xsi:type="PIVL_TS" operator="E">
         <phase>
            <low value="20050922"/>
            <width value="7" unit="d"/>
         </phase>
         <period value="28" unit="d"/>
      </comp>
   </comp>
</comp>

Ook hier worden twee PIVL<TS> componenten gedefinieerd, waarbij het verschil tussen de eerste en de tweede component wordt bepaald (de tweede wordt als het ware afgetrokken van de eerste). Gezamenlijk wordt deze subset weer doorsneden (operator "A") met het interval dat erboven is vastgelegd ('de maanden september t/m november').

Het effect is dat een herhalend patroon ontstaat met de volgende structuur:

3 weken met dagelijks gebruik om 09:00	01-09-2005 t/m 21-09-2005
1 week zonder gebruik	22-09-2005 t/m 28-09-2005
3 weken met dagelijks gebruik om 09:00	29-09-2005 t/m 20-10-2005
1 week zonder gebruik	21-10-2005 t/m 27-10-2005
3 weken met dagelijks gebruik om 09:00	28-10-2005 t/m 17-11-2005
1 week zonder gebruik	18-11-2005 t/m 24-11-2005
6 dagen met dagelijks gebruik om 09:00	25-11-2005 t/m 30-11-2005

De dagelijkse toediening wordt bepaald door de period in de eerste PIVL. De week zonder toediening wordt bepaald door de tweede PIVL, met een phase van 7 dagen, herhalend per period van 28 dagen, die wordt uitgesloten binnen het patroon van de eerste PIVL.

Merk op dat het wel degelijk relevant is welke datum als begindatum van de phase in de tweede PIVL<TS> wordt gekozen. Deze moet nl. zodanig samenhangen met de begindatum van het interval (niet per se met die van de phase in de eerste PIVL!) dat de periode zonder gebruik steeds in de 4e week valt (dus na een periode van 3 weken met gebruik).

  Naar boven

CMET's

Naar hoofdstuk CMET