Brontekst bekijken van Gebruik van UML voor DCM modellering

Dit topic is met toestemming overgenomen uit hoofdstuk 5 van [http://www.parelsnoer.org/uploaded/FILES/htmlcontent/CI%20documenten/Richtlijn%20detailed%20clinical%20model%20(DCM).pdf "Richtlijn Detailed Clinical Model"] van het [http://www.parelsnoer.org Parelsnoer Instituut]


== '''Inleiding''' ==

In de voorgaande hoofdstukken is beschreven welke informatie opgenomen is in een DCM. We kunnen deze informatie indelen in drie categorieën:

:# De ''DCM Beschrijving'', met de weergave van de inhoud proza van een DCM in gewone taal. Dit zijn onderdelen zoals “Concept”, “Doel”  en  “Instructie” en de uitwerking daarvan.
:# Het ''Informatie Model'', waarin de data elementen zijn beschreven die de informatie van een DCM bevatten, inclusief hun onderlinge relaties  en de verbinding met terminologie.
:# De ''Metadata'' van de DCM, waarin zaken vastgelegd kunnen worden als versie, auteurschap, trefwoorden en status van de DCM. 

Waar de vorige hoofdstukken ingingen op de inhoudelijke aspecten van deze informatie, laat dit hoofdstuk zien hoe we deze informatie  vastleggen  met behulp van de Unified Modeling Language, oftewel UML. Dit hoofdstuk geeft dus al deze onderdelen een plaats in een UML-modelleertool en  gebruikt standaard UML  onderdelen voor de notatie van de gegevens die bij de onderdelen horen.

De onderdelen van de ''DCM Beschrijving'' worden in UML weergegeven in een structuur van ''UML-packages''. De gehele DCM is zelf het "hoofd"  package, met daaronder sub-packages die de verschillende onderdelen representeren. Ook het ''Informatie Model'' is een package, dat één of  meer  ''klassediagrammen'' bevat. De ''Metadata'' vinden een plaats in de vorm van ''Tagged values'' op het “hoofd” package. Ook het ''Informatie  Model''  kent  enkele gestructureerde attributen die we als ''Tagged values'' aanbrengen op specifieke onderdelen van het klassediagram.

NB: De voorbeelden en beschrijving in dit document gaan uit van het gebruik van Enterprise Architect van Sparx Systems voor het modelleren, maar  legt geen wezenlijke beperkingen op aan het werken in een andere tool. 

NB2: De DCM's kunnen worden uitgewisseld tussen tools en repositories met behulp van XMI, een format dat door vrijwel alle UML tools wordt  ondersteund. Binnen de XMI standaard bestaan verschillende varianten dus om uitwisselbaarheid tussen tools van verschillende aanbieders te  bereiken is het belangrijk om in de context van deze methodiek enkel XMI1.1/UML1.3 te gebruiken.



== '''De DCM beschrijving in UML''' ==

Het UML-document begint, zoals gesteld, met het “hoofd”-package dat het gehele DCM voorstelt. We stellen de naam van het package daarom  samen uit de naam van de DCM, voorafgegaan door de internet domeinnaam van de organisatie die de DCM opstelt. Dit laatste is dan bijvoorbeeld  “<nowiki>nl.re</nowiki>sults4care”, “<nowiki>nl.pa</nowiki>relsnoer” of “<nowiki>nl.ni</nowiki>ctiz”. Hierachter nemen we dan het versienummer van de DCM op, bijvoorbeeld “v2”. De volledige naam  van  een DCM "Bloeddruk" wordt zo dus “<nowiki>org.pa</nowiki>relsnoer.Bloeddruk.v2".

Deze werkwijze is bedoeld om de namen van de DCM's (inter)nationaal uniek te houden, zowel bij nieuwe versies als voor gelijknamige DCM van  verschillende organisaties. Als later een andere organisatie de DCM onder  zijn hoede neemt, betekent dit niet dat de naam van een DCM  veranderd hoeft te worden. Het actuele houderschap is geregistreerd in de  metadata (zie verderop) van de DCM, en kan dus afwijken van de naam  van het hoofdpackage in de DCM. Deze blijft na aanmaken dus  onveranderd.

Onder het ‘hoofd’ package vallen de packages die behoren bij de onderdelen van de DCM Beschrijving. Deze onderdelen hoeven niet bij elk  DCM  allemaal aanwezig te zijn en zullen ook niet voor elke doelgroep even relevant zijn. De volgorde is wel van belang: deze komt overeen met  de  volgorde van de beschrijving in deel 2 Inhoud van een DCM. In dit hoofdstuk is per onderdeel ook steeds een tabel opgenomen met de  aspecten  “Naam”, “Inhoud”, “Soort gegeven” en “Verplicht/optioneel”. Deze laatste kolom bepaalt of een onderdeel verplicht moet worden  opgenomen, of  weggelaten mag worden.

De kolom “Naam” bevat de vaste, voorgeschreven naam voor het package. Deze namen zijn in het Engels gesteld. Dit betekent niet dat de DCM  ook in het Engels beschreven is, het gebruik van deze kopjes is een "technische" indeling in de UML tool. 

De kolom “Soort gegeven” beschrijft welke inhoud we binnen het package kunnen plaatsen. Hierbij bestaan de volgende mogelijkheden:

'''''Tekst'''''

Veel onderdelen bevatten enkel tekst. Deze wordt opgenomen in de ''Note'' van het package en kan eventueel opmaak bevatten, als de gekozen  UML-tool dit ondersteunt.

'''''Diagrammen'''''

De inhoud kan ook een standaard UML-diagram zijn, zoals het ''klassediagram'' of een ander niet-UML diagram zoals een ''mindmapdiagram''.  Deze  diagrammen worden direct onder het betreffende package opgenomen. Het is mogelijk een toelichting op het diagram op te nemen in de ''Note'' van  het diagram.

'''''Illustraties of afbeeldingen'''''

Ten slotte kan het package een illustratie of afbeelding bevatten. Dit is ook toegestaan als een diagram wordt voorgeschreven in de kolom  “Soort  gegeven”, maar de gebruikte tool dit diagram niet ondersteunt. Veel UML-tools laten dit toe door een afbeelding (in de vorm van  bijvoorbeeld een  JPEG of tiff bestand) op te nemen in een ''custom diagram''. We gebruik een apart diagram voor elke afbeelding. Het is mogelijk  een toelichting op  het diagram op te nemen in de ''Note'' van het diagram.



== '''Overzicht van de standaard-packages''' ==

We onderkennen binnen een DCM een aantal "hoofdstukken" die de verschillende aspecten van een DCM documenteren. Deze hoofdstukken zijn  gedefinieerd en beschreven in hoofdstuk 4. 

Deze hoofdstukken worden in UML gemodelleerd als packages met vaste namen die gelijk zijn aan de eerste kolom van de beschrijvende tabellen  in hoofdstuk 4, zoals “Purpose” of “Interpretation”. Merk op dat  de namen in het Engels gesteld zijn. Dit betekent niet dat de DCM ook in  het  Engels beschreven is, het gebruik van deze kopjes is een "technische"  indeling. In documenten die je uit een dergelijk UML-model genereert,  is  het natuurlijk wenselijk deze kopjes af te beelden in hun Nederlandstalige  equivalent. Een suggestie hiervoor staat tussen de vierkante haken  achter de Engelse kopjes.

In principe bevat elk package maximaal één diagram, die dezelfde naam heeft als als het package. Vooral het Information Model-package kan  meerdere  diagrammen bevatten, maar deze zitten dan elk in een eigen sub-package. De elementen van een model zitten in hetzelfde package en  op het zelfde  niveau als het diagram.

De verschillende hoofdstukken in de DCM worden beschreven in het hoofdstuk DCM Beschrijving.

Los hiervan heeft een DCM metadata (versienummer, auteur, publicatiestatus etcetera), die niet in de vorm van een package, maar als "tagged-  values"  worden genoteerd. Dit worden beschreven in het bijbehorende hoofdstuk over Meta Data.

Omdat dit hoofdstuk zich richt op het modelleren van de informatie in de DCM, gaat de rest van het hoofdstuk vooral in op de inrichting van het  package  "Information Model". 



== '''Information Model''' ==

Het package "Information Model" bevat klassediagrammen die de concepten uit het  domein visueel representeren. In een DCM worden deze  concepten omgezet in “(data) elementen”, met relaties en coderingen, zoals beschreven in hoofdstuk 4. Het informatiemodel mag, voor de  overzichtelijkheid, met behulp van één of meer klassediagrammen worden weergegeven. Eén van de diagrammen moet de naam “Information Model”  dragen en is het startpunt voor het model.

De diagrammen moeten exact genoeg zijn om er voor te zorgen dat verschillende implementaties van de DCM dezelfde semantische  content  hebben, maar inzichtelijk genoeg blijven om door niet-UML-experts op hoofdlijnen te kunnen worden begrepen.  

Een DCM is onafhankelijk van technische standaarden, zodat er niet al tijdens het ontwerp van een DCM beslissingen in het modelleren sluipen die  implementatie van het model in de ene techniek bevorderen of in een andere onmogelijk maken. Dit betekent dat het informatiemodel geen  vastgesteld referentiemodel kent, zoals HL7 of openEHR. 

Welke eisen stellen we aan een modelleertechniek om de concepten, zoals beschreven in deel 2, te kunnen vastleggen? In veel opzichten zijn dit  mogelijkheden om concepten te definiëren die overeenkomen met de mogelijkheden van UML in de vorm van klassediagrammen, maar met enkele  uitbreidingen die talen als OWL (van w3c) en ADL (van openEHR/ISO 13606) bezitten om tot klassedefinities te komen. Het gaat dan om de volgende mogelijkheden: 

* Het definiëren van elementen
* Het vastleggen van associaties tussen elementen 
* Het definiëren van kenmerken van associaties 
* Het introduceren van elementen die gebaseerd zijn op bestaande elementen
* Het definiëren van elementen die data representeren
* Het definiëren van elementen die gecodeerde gegevens representeren
* Het kunnen herbruiken van bestaande DCM’s in de definitie van een nieuwe DCM.



Hoe we in UML aan deze eisen kunnen voldoen is per eis in de volgende secties beschreven. Waar UML niet toereikend is wordt van Object  Constraint Language (OCL) gebruik gemaakt. Reden om voorlopig UML en OCL te gebruiken is dat dit industriestandaarden zijn waar een grote  hoeveelheid experts beschikbaar voor zijn. 

NB: In de onderstaande tekst gebruiken we zowel de term “concept” als “element”. Deze termen zijn subtiel verschillend. Met concept duiden we  het begrip aan in het domein dat we modelleren, met “element” de gemodelleerde weerslag hiervan in het informatiemodel.



=== '''Het introduceren van nieuwe elementen ''' ===

Een (data)element wordt in het informatiemodel gerepresenteerd door middel van een UML Class in verschillende verschijningsvormen. 

De klassen krijgen een naam die in het Nederlands is, waarbij de naam geen spaties mag bevatten. Door middel van "PascalCasing" kunnen  woordgrenzen worden aangegeven. Naast een naam kunnen concepten ook een gebruiksvriendelijke toelichting krijgen in de vorm van een ''Label.'' 

Deze alias kan in EA worden getoond als alternatief voor de technische naam.

[[image:Picture 33.png]]

Figuur 1. Introductie van nieuwe elementen.

De meeste elementen worden gerepresenteerd als een normale Class, zoals "Bovendruk" in de afbeelding hierboven. 

Elementen die onderdeel zijn van de gegevensset, maar afgeleid worden uit andere gegevens, krijgen het stereotype &lt;&lt;derived&gt;&gt;.  De modelleur  moet in dat geval via een OCL expressie beschrijven via welk algoritme dit gegeven afgeleid wordt.

Een element dat het hoofdelement is van een DCM, wordt aangeduid met het stereotype &lt;&lt;rootconcept&gt;&gt;, zoals bij  "Bloeddruk"  hierboven. Het  &lt;&lt;rootconcept&gt;&gt; wordt visueel onderscheiden van de overige concepten door een dikke lijn (lijndikte 3 pixels) om de klasse (zie bloeddruk in figuur  1)

Elementen kunnen ''abstract'' zijn. Dit betekent dat het element alleen geïntroduceerd wordt als generiek begrip, dat als basis dient voor specifiekere  afgeleide elementen via een generalisatie-relatie (zie verderop in dit deel). Abstracte elementen worden in UML voorgesteld als klasse waarvan  de  naam in schuinschrift (italics) is geschreven (zie figuur 1, de klasse "Bloeddrukmeetwaarde").

==='''Nadere rubricering van de elementen'''===

Zoals beschreven in hoofdstuk 4 kunnen elementen gerubriceerd worden als qualifier, data of state.

* Qualifier: Deze concepten krijgen het stereotype &lt;&lt;qualifier&gt;&gt;, zoals in figuur 2 bij "Meetapparaat".  Om de leesbaarheid van het diagram te  verhogen geven wij deze klassen een gele achtergrond (kleurcode #ffffa0 of RGB 255,255,160).
* Data: Deze  concepten  krijgen het stereotype &lt;&lt;data&gt;&gt;, zoals in figuur 2 bij Onderdruk. Om de leesbaarheid van het diagram te verhogen  geven wij  deze klassen een blauwe  achtergrond (#A6caf0 of RGB166,202,240).
* State: Deze concepten krijgen het stereotype &lt;&lt;state&gt;&gt;, zoals in figuur 2 bij "Lichaamspositie". Om de leesbaarheid van het  diagram te  verhogen geven wij  deze klassen een groene achtergrond (#c0dcc0 of RGB192,220,192).

[[image:Picture 38.png]]

Figuur 2. Nadere rubricering van de elementen.

N.B.  Samengestelde elementen worden niet gerubriceerd en krijgen dus geen stereotype. Zij behouden de standaardkleur van een klasse in de  UML-tool.



=== '''De definitie van een element'''===

De exacte betekenis van een element wordt niet bepaald door de naam van de klasse. Hoogstens komt deze naam ook voor in de andere secties  van de DCM waar het element gedefinieerd is door middel van geschreven tekst. Om de semantiek exact vast te leggen moet elk element (en dus  klasse in het  diagram) verbonden worden met een code uit een code systeem, zoals bijvoorbeeld SNOMED CT. Hiertoe kent elk element een  "tagged-value" met de naam DCM::DefinitionCode, waarin de code uit een bestaand terminologie systeem is opgenomen, in de  vorm 

codeSysteem&gt;:&lt;code&gt;⌴&lt;omschrijving&gt;. 

Op de plaats van &lt;codeSysteem&gt; wordt de leesbare, officiele naam van een code systeem opgenomen zoals bepaald in Unified Medical Language  System (UMLS), bijvoorbeeld  "SNOMEDCT".  Voor Lichaamspositie wordt dit dus:

SNOMEDCT:397155001 body position (observable entity)  

Bij het gebruik van SNOMED-CT is het aan te bevelen de fully specified name (FSN) van het gecodeerde concept te gebruiken.

Deze DefinitionCode is met nadruk enkel bedoeld om de semantiek van het element vast te leggen, en legt geen eisen op aan de te gebruiken  code in  een uiteindelijke implementatie van de DCM in database of bericht.

=== '''Het vastleggen van relaties tussen elementen''' ===

Tussen twee elementen kan een samenhang bestaan die we in UML weergeven door middel van een relatie, ook wel associatie genoemd.

We gebruiken drie typen relaties uit de UML standaard in het Informatie Model: 

1) De generalisatie-relatie,

2) De compositie-relatie, en

3) De semantische relatie. 

'''''De generalisatie-relatie, specialisatie van concepten'''''

Een belangrijk aspect van de concepten in een model is dat zij gebaseerd kunnen zijn op bestaande concepten. Dit noemen we een ''specialisatie'' van  een  concept. In een DCM betekent dit dat een element een subklasse is van een bestaand element, dat als superklasse fungeert: de subklasse neemt alle elementen van de superklasse over en kan daar nieuwe elementen aan toevoegen. We staan ook toe dat een  subklasse geen elementen toevoegt, maar enkel extra validatieregels in de vorm van OCL. Validatieregels komen verderop in dit hoofdstuk aan  de  orde.

In het informatiemodel geven we deze relatie weer met de normale "generalisatie" notatie van UML (een open pijl): 

[[image:Image005.png]]

Figuur 3. De generalisatie-relatie

In figuur 3 zien we dat het element "Bloeddrukmeting" een specialisatie is van het meer generieke element "Meting", waarbij in de subklasse twee  elementen zijn toegevoegd ten opzichte van de superklasse, namelijk de data elementen: "SystolischeBloeddruk" en "DiastolischeBloeddruk". Het is belangrijk om in te zien dat door het  toevoegen van properties een element wordt gespecialiseerd: iedere Bloeddrukmeting is een Meting, maar alleen die Metingen met de twee nieuwe properties zijn Bloeddruk metingen.

'''''Compositie'''''

Een ''"compositie-relatie''" (een “pijl” met een dichte diamant) wordt gebruikt tussen een samengesteld element en de elementen die in deze container zitten. Dit kunnen dus zelf  weer samengestelde elementen zijn of data elementen. We zien een voorbeeld in figuur 4. 



[[image:Image007.png]]

Figuur 4. De compositie.

Merk op dat we, in vergelijking met gangbare klasse diagrammen, “properties” dus afbeelden met een compositie relatie en nieuwe klassen, en niet als properties van het samengestelde element. De inhoudelijke reden voor onze keuze is dat we verwachten dat veel elementen properties hebben die zelf ook weer samengesteld zijn. De duidelijke link die een relatie dan tussen de beide concepten legt, vertelt de lezer direct iets over de definitie van beide elementen en toont duidelijk de "boomstructuur" van de informatie. De notatie als attribuut legt deze link veel minder sterk, daar moet je als lezer “op zoek” naar de definitie van type van het attribuut elders in het diagram.

Op elke relatie kan eventueel een expliciete cardinaliteit gespecificeerd worden. Als we deze in het diagram onvermeld laten, betekent dit dat we  niets over de cardinaliteit zeggen en de uiteindelijke implementator hier voor de eigen organisatie en toepassing keuzen kan maken. We modelleren dit via de gebruikelijke UML notatie:

[[image:Image009.png]]

Figuur 5. 

In figuur 5 zien we dat een “Bloeddrukmeetserie”  opgebouwd is uit "0 of meer" Bloeddrukmetingen. Dit komt volledig overeen met  het  normale  gebruik  in UML.



'''''Semantische relatie'''''

De laatste relatie categorie  die we hier willen onderscheiden is er een tussen twee "gelijkwaardige" concepten, dus een verhouding waarbij een  concept niet duidelijk ondergeschikt is aan de ander. Je kunt dan niet zeggen dat een concept een "property" van de andere is, of dat een concept  opgebouwd is uit een ander concept. De concepten zijn dan ook een apart feit of handeling die in een dossier los van elkaar staan en onderdeel kunnen zijn van verschillende DCM's. Een dergelijke relatie wordt weergegeven door middel van een associatie-relatie (de “gewone”, onbepaalde relatie in UML), waarbij de natuur van de relatie als label bij de relatie is opgenomen. Als het label een lees volgorde heeft, moet de  pijl een navigatie richting krijgen.

[[image:Image011.png]]

Figuur 6. Semantische relatie.

We kunnen in figuur 6 met evenveel recht zeggen dat Feit "een onderbouwing" is van een Vermoeden of dat Vermoeden "onderbouwd wordt door" een Feit.  Voor de specificatie kiezen we een lees richting en leggen we de semantiek vast. Net als bij elementen, is het zichtbare label enkel  voor de menselijke lezer interessant, de relatie zelf heeft wederom een tagged value met een DefinitionCode, waarin de exacte definitie is   bepaald. 

De semantische relatie kan vooral worden gebruikt om door zorgverleners veronderstelde relaties tussen gegevens aan te duiden, zoals oorzaak  en gevolg, of tijdvolgordelijke relaties. Net als bij de compositie-relatie kan een semantische relatie een expliciete cardinaliteit dragen.

De semantische relatie komt overeen met de LINK klasse uit openEHR of het begrip "Semantische link" in de DCM-terminologie van Stan Huff, of  bij Snomed CT. 

Afhankelijk van de “grootte” van het DCM zal deze situatie niet vaak voorkomen: op het niveau van een individuele observatie zie je dit minder dan  op het niveau van een sessie of dossier, en kan dan ook gemodelleerd worden door een nieuw concept te introduceren waarvan beide concepten  “kinderen”  zijn.

'''''Waar kan ik de relaties gebruiken?'''''

Het is niet zo dat elke relatie overal zinvol gebruikt kan worden: afhankelijk van het type element dat men met elkaar relateert, zijn bepaalde relaties (on)bruikbaar. De volgende tabel laat zien welke combinaties van elementen met welke typen relaties verbonden kunnen worden, waarbij  de elementen in de linker kolom de elementen zijn aan de "source" of beginkant van de relatie, en de elementen in de bovenste regel de “target”  of eindkant van de relatie:

NB: In de hiërarchie van een DCM is bij compositie-associaties het kind-element de “source” en het bevattende samengestelde element de “target”. 

{|class="umctable" width="800"
|-
| style="width:25%" |
'''''Soort element (*)'''''

| style="width:25%" |
'''''Samengesteld'''''

| style="width:25%" |
'''''Data'''''

| style="width:25%" |
'''''Verwijzend'''''

|-
|
'''''Samengesteld'''''

|
generalisatie,

compositie,

semantisch

|
compositie

|
compositie,

semantisch

|-
|
'''''Data'''''

|
Niet toegestaan

|
generalisatie

|
Niet toegestaan

|-
|
'''''Verwijzend'''''

|
Niet toegestaan

|
Niet toegestaan

|
Niet toegestaan

|}


(*)  De soorten elementen worden in de volgende paragrafen verder beschreven.

=== '''Definiëren van elementen die data representeren'''===

Zoals beschreven bestaat de structuur van een DCM uit een boom, met samengestelde elementen die zelf samengestelde elementen of data elementen  kunnen bevatten. Uiteindelijk zijn de bladeren van de boom dus data elementen. Deze elementen zijn atomair, bevatten een enkel, ondeelbaar gegeven en bevatten zelf geen geneste elementen meer.

Een DCM gebruikt data elementen om precies uit te drukken hoe data vastgelegd moeten worden. Een ''data element ''is dus bijvoorbeeld een nummer, een code, een hoeveelheid, een datum, een boolean-waarde etcetera.

De data elementen worden gedefinieerd aan de hand van de data typen uit ISO 21090: Harmonized datatypes for information interchange, en zijn  in het diagram te herkennen omdat ze direct of indirect subklassen zijn van de klassen uit deze standaard. De klassen uit ISO 21090 staan  conceptueel op een iets hoger niveau dan de basis typen van veel programmeertalen zoals strings, integers en floats. De ISO 21090 data typen  hebben daarom zelf enkele properties, die we in onze UML notatie uitdrukken als attributen, en niet als associaties. We geven het data type aan   door het leaf-element “af te leiden” van het data type. Zo is het leaf-element een specialisatie (verbijzondering) van het data type.

In figuur 7 is een voorbeeld waarin het data element Hellingshoek uitgedrukt wordt als het ISO 21090 type "PQ" (physical quantity):

[[image:Image013.png]]

Figuur 7. Weergave van data type (ISO 21090.

In dit diagram is zichtbaar dat Hellingshoek een data element is van het type PQ, met twee constraints op de  waarden van deze attributen om het gebruik van de PQ verder vast te leggen. Dit wordt verderop nader toegelicht bij "Het specificeren van  validatieregels". 

Naast PQ zijn de volgende data types de meest voorkomende:

{| class="umctable" width="800"
|-
|
'''Datatype'''

|
'''ISO 21090'''

|-
|
Tekst

|
ST

|-
|
Number

|
INT of REAL (afhankelijk van schaal/ precisie)

|-
|
Hoeveelheid (met eenheid)

|
PQ

|-
|
Tijdstip

|
TS

|-
|
Telwaarde

|
CO

|-
|
Boolean

|
BL

|-
|
Term

|
CD

|-
|
Numeriek interval 

|
IVL&lt;INT&gt; of IVL&lt;REAL&gt;

|-
|
Interval van hoeveelheid

|
IVL&lt;PQ&gt;

|-
|
Tijdsinterval (periode)

|
IVL&lt;TS&gt;

|-
|
Ratio (hoeveelheid)

|
RTO&lt;PQ&gt;

|}
Opmerkingen:

* TS ("timestamp"). Representeert een min of meer precies tijdstip. Kent een attribute "value" dat het tijdstip bevat.
* INT ("integer"), REAL ("reëel getal"). Beide types bevatten een attribuut "value" dat een integer respectievelijk reëel getal voorstelt.  Wordt minder vaak gebruikt dan je zou denken, omdat veel waarden eigenlijk een PQ zijn. 
* BL ("boolean"). Kent een attribuut "value" dat een true/false waarde bevat.
* IVL&lt;TS&gt;. Een interval periode van tijd. Het interval kan volledig gespecificeerd (met zowel boven of ondergrens) of open zijn.

ISO 21090 kent nog veel meer typen, en elk van deze typen kent een schat aan attributen. Veel van deze typen zijn niet relevant voor een DCM:  Zo is een patiënt-identificatie (type II) heel nuttig in een EPD, maar niet in een DCM. Een DCM houdt zich immers bezig met de uitvoering dan  wel de uitkomsten van een klinische handeling, en dit zijn vaak uitgevoerde taken en/of gestructureerde meetgegevens, geen patiëntnummers.

=== '''Weergave van gecodeerde data elementen''' ===

Het informatiemodel maakt vaak gebruik van gecodeerde elementen: keuzelijsten zijn hiervan een voorbeeld. Deze bevatten lijsten met termen die, bij communicatie of opslag, als code worden vastgelegd. Deze data elementen zijn daarom afgeleid van het type "CD" of “CO” (code met een score). Bovendien wordt de lijst met mogelijke termen (de “value set”) opgesomd in de vorm van een UML enumeratie: 



[[image:Image015.png]]

Figuur 8. UML Enumeratie.

Het gecodeerde data element Meetapparaat is hier dus uitgedrukt als een UML Class met het stereotype &lt;&lt;enumeration&gt;&gt;, waarbij de keuzen  als attributen worden gemodelleerd. 

In de huidige versie van de DCM methodiek hebben we een voorlopige "codebinding" geïntroduceerd om een informatieve keuze voor daadwerkelijke codes te kunnen maken. Hiervoor kennen we aan elk attribuut van de enumeratie een tagged-value "DCM::DefinitionCode"  toe, net als bij klassen, waarin de term uitgedrukt is in een code.

'''''Externe specificatie'''''

Er zijn een aantal scenario’s te bedenken waarom het uitschrijven van alle mogelijkheden in de vorm van een UML enumeratie niet altijd praktisch is: 

:# de lijst kan niet expliciet opgesomd worden, omdat hij gebaseerd is op een selectie uit een bestaand codesysteem via een selectie- criterium in een formele taal (zoals een SNOMED CT expression). 
:# de lijst is zo groot dat omzetten niet zinvol is.

In deze gevallen laten we de enumeratie weg, en vervangen we deze door respectievelijk een “ContentExpression” tagged-value die het selectie-  criterum bevat danwel een “ContentReference” tagged-value die een URL bevat waar de volledige lijst met termen gevonden kan worden. NB: Op  dit moment schrijven we nog niet voor hoe deze lijst er precies uit moet zien.



'''''Abstracte value sets'''''

We kunnen een data element ook ''abstract'' maken. In dat geval laten we de termen (gedeeltelijk) weg uit de enumeratie. Dit is voornamelijk nuttig wanneer we een algemene DCM bouwen, waarbij voor enkele data concepten het rijtje met termen nog onbepaald moet blijven. Als we de  algemene DCM vervolgens herbruiken als onderdeel van een andere DCM, dan kan dit DCM het abstracte data concept verder aanvullen. Een  voorbeeld hiervan is te vinden in paragraaf 'Refereren naar bestaande DCM's. 



'''''Gecodeerde scores'''''

Sommige gecodeerde data elementen worden gebruikt in scores of tellingen. De termen uit een value set krijgen dan tevens een “ordinale waarde” toegekend. Deze waarde is een numerieke waarde of weging die bij bijvoorbeeld vragenlijsten is vastgesteld voor het uitrekenen van een  totaalscore. De score wordt per item van de enumeratie weergegeven als de “initial value”, zodat deze zichtbaar wordt in het diagram:

[[image:Image017.png]]

Figuur 9. Ordinale waarde.



'''''Hiërarchische value sets'''''

De termen in een enumeratie kunnen ook een hiërarchisch verband hebben, waarbij zowel specifiekere en algemenere termen opgenomen zijn.  Het is zinnig om deze verbanden zichtbaar te maken in de enumeratie, zodat duidelijk is hoe de termen precies samenhangen:



[[image:Image019.png]]

Figuur 10. Hiërarchische value set.

In figuur 10 is zichtbaar dat de term “Jeuk” binnen deze value set valt onder de algemenere term “Irritatie”. De hiërarchie is zichtbaar gemaakt door de naam van de term vooraf te laten gaan met een underscore (“_”). Elk niveau dieper levert een extra underscore op die aan de naam vooraf gaat.



=== '''Het specificeren van validatieregels''' ===

In aanvulling op de visuele uitbeelding van het informatiemodel, kunnen we ook specifieke validatieregels noteren,  zoals voor het beperken van de toegestane waarden van data elementen. In figuur 11 zijn enkele elementen met dergelijke constraints te zien. De constraints zijn, via hun leesbare naam, zichtbaar onderin de UML klasse van een element. Deze informele beschrijving is voor ontwikkelaars niet voldoende, zodat achter deze leesbare naam een in OCL uitgeschreven validatie schuil gaat, hier afgebeeld door een UML ''note'' element. Een voorbeeld: 



[[image:Image021.png]]

Figuur 11. Weergave van validatieregels.



<nowiki>In figuur 11zien we het element "Bloeddrukmeetwaarde", onderin. Dit is een subklasse van PQ en beperkt, via OCL, de  "unit" van Bloeddrukwaarde tot enkel "mm[Hg[" (millimeter kwikdruk in UCUM)  en de waarde van de druk tot tussen de 0 en 1000.</nowiki>

Het concept "Polsdruk" erft van Bloeddrukmeetwaarde, maar voegt daar nog een extra regel aan toe: Polsdruk is derived, en in OCL is daarom beschreven hoe de polsdruk berekend kan worden: “bovendruk – onderdruk”.

[[image:Image023.png]]

Figuur 12. 

Het is belangrijk om een validatieregel (constraint) op te nemen op de plek, van waaruit alle onderdelen van de regel beschikbaar zijn. In figuur 12  is de regel 'AlleenStopPeriodeAlsGestopt' opgenomen op 'Rookgedrag'. De regel zorgt ervoor dat geen stopdatum  hoeft  te worden opgegeven  als nooit gerookt is. De cardinaliteit (aanwezigheid) van 'GestoptSinds' wordt bepaald vanuit het samengestelde element. Dat is 'RookGedrag'.  Daarom moet de regel bij dat element worden opgenomen.

Naast OCL kunnen bij sommige datatypes ook tagged values worden gebruikt om het waardendomein te beperken. Strings (ST) bijvoorbeeld, kunnen worden ingeperkt met “DCM::StringFormat“. Deze en andere tagged values zijn te vinden in de tabel in 'Notatiewijze van de waarde.



=== '''Refereren naar bestaande DCM's''' ===

Bij het modelleren van een DCM is het mogelijk een bestaande DCM te hergebruiken. Dit houdt in dat   de DCM dus gegevens bevat  waarvan de definitie in een andere DCM beschrijving vastgelegd is. Een belangrijk voordeel van hergebruik is dat de originele DCM niet in zijn geheel gekopieerd wordt, waardoor bij wijzigingen inconsistenties kunnen ontstaan. Ook is door naar de bron DCM te refereren het mogelijk dat deze meer of minder ongelimiteerd kan worden hergebruikt in andere DCM. Denk aan een DCM als Lichaamshouding die als onderdeel relevant is bij tientallen DCM en op deze manier niet gekopieerd hoeft te worden. 

Deze referentie wordt in het DCM Informatie Model gemodelleerd met een ''verwijzend element'' en krijgt het stereotype &lt;&lt;reference&gt;&gt;. 

Een verwijzend element wordt gemodelleerd als een UML Class, die het &lt;&lt;rootconcept&gt;&gt; van het gerefereerde DCM voorstelt. Daarbij mag elke relevante andere klasse uit de gerefereerde DCM ook opgenomen worden als dit voor de lezer de inhoud van het hergebruikte DCM duidelijker maakt. Alle klassen die voorkomen in het gerefereerde DCM worden geplaatst binnen een UML Boundary.  Het verwijzende element krijgt de tagged value 'DCMIdentifier'. Dit is hetzelfde unieke ID als dat van de “Id” uit de metadata van de gerefereerde DCM. 

Merk op dat, alhoewel je technisch gezien refereert aan de klasse die het &lt;&lt;rootconcept&gt;&gt; van een DCM is, je logischerwijze altijd refereert aan de  gehele DCM, inclusief de interpretatie en andere secties, niet enkel het Informatie Model. 

[[image:Image025.png]]

Figuur 13.

In figuur 13 zien we hoe een DCM “Bloeddruk” de eerder gedefinieerde DCM “Lichaamspositie” hergebruikt. Hierbij wordt de inhoud van de enumeratie “Positie” (die in de oorspronkelijke DCM nog abstract en dus leeggelaten was) hier concreet ingevuld voor het gebruik binnen deze DCM.

 

=== '''Vertalen van modeleigenschappen naar een modelnotatie in UML'''===

Elementen, relaties en valuesets kunnen een groot aantal eigenschappen hebben, die in dit document uitgebreid beschreven worden. Deze  eigenschappen moeten in het UML-diagram worden opgenomen, zodat ze integraal onderdeel worden van de DCM. In de volgende tabellen  is  voor iedere eigenschap beschreven welke plek hij krijgt in de UML-notatie:

'''''Element'''''

{| class="umctable" width="800" 
|-
|style="width:15%"|
'''Eigenschap'''

|style="width:3%"|
'''<nowiki>#</nowiki>'''

|style="width:37%"|
'''UML'''

|style="width:15%"|
'''Voorbeeld'''

|style="width:30%"| 
'''Opmerkingen'''

|-
|
Name

|
1..1

|
‘name’ van de  Class

|
“Toedieningswijze”

|


|-
|
Description

|
1..1

|
‘notes’ bij de Class

|
“De manier waarop  een  medicijn  wordt  toegediend”

|


|- 
|
DisplayText

|
0..1

|
Taggedvalue ‘DCM::DisplayText’ bij de class

|
“Toediening”

|


|- 
|
Label

|
0..1

|
‘alias’ van de Class

|
“Glucose &gt; 12  mmol/L”

|
In EA kun je bij diagram  properties aangeven dat  het  alias gebruikt moet  worden  voor  de weergave  (Use  Alias if  Available). Dit  is  handig voor de  communicatie, omdat dan  niet  de (aan regels  gebonden) naam hoeft te  worden getoond.

|-
|
Id

|
1..*

|
Tagged value Id

|


|


|-
|
DataType

|
0..1

|
Als ‘parent’ data  type  (generalization)  van  de  class

|
PQ

|
Deze eigenschap is  verplicht  voor data  elementen en verboden  voor  andere elementen

|-
|
ExampleValue

|
0..1

|
Tagged value  ‘DCM::ExampleValue’.  De  voorbeeldwaarde  houdt zich aan de  voor  het datatype  gebruikte  notatie.

|
21,5 mg/ml

|
Deze eigenschap is alleen  van  toepassing op data  elementen

|-
|
DefinitionCode

|
1..*

|
Tagged value  ‘DCM::DefinitionCode’  (CD)

|
SnomedCT:  364075005 heart  rate

|
Er kunnen meerdere codes  zijn  die het concept  definiëren,  bijvoorbeeld uit  verschillende  codesystemen.

|- 
|
Domain

|
0..*

|
UML constraints  (dit  mogen er meer  zijn)  op de class  worden  gebruikt  om het  waardendomein te  registreren. Hierbij  wordt altijd  gebruikgemaakt  van   OCL-  expressies

|
“inv: value &lt; 0.5”

|
Zie verderop: OCL-  constraints

|-
|
Precision

|
0..1

|
Tagged value  ‘DCM::Precision’  (INT)

|
4

|
Dit item is alleen van  toepassing  op numerieke  data elementen

Definitie van Precision conform de ISO 21090

|-
|
StringFormat

|
0..1

|
Tagged value  ‘DCM::StringFormat’  (ST). Hierbij  wordt  gebruikgemaakt  van   regular  expressions

|
“\d\d\d\d”

|
Dit item is alleen van  toepassing  op data  elementen van het type  ST

|-
|
DerivationExpression

|
0..1

|
Een UML  constraint  (dit mag  er slechts  1  zijn)  wordt  gebruikt om  de  waarde van het  concept te  bepalen.

|
“inv: value =  (<nowiki>Bovendruk.va</nowiki>lue  +  <nowiki>Onderdruk.va</nowiki>lue) / 2”

|
Zie verderop: OCL-  constraints

|-
|
Classification

|
0..1

|
Stereotype op de  class

|
&lt;&lt;data&gt;&gt;

|
Classification stereotypes  kunnen worden  gecombineerd  met  functionele stereotypes als  &lt;&lt;reference&gt;&gt;,  &lt;&lt;enumeration&gt;&gt; of  &lt;&lt;derived&gt;&gt;. Ze kunnen  niet  worden gecombineerd  met  andere classification  stereotypes

|-
|
DCMIdentifier

|
0..1

|
Tagged value  'DCM::DCMIdentifier’ 

|
2.16.840.1.113883.2.4.3.28.1.1.2:14

|
Dit is het ID van de DCM,  waarnaar wordt verwezen

|}


'''''Relatie'''''

{|class="umctable" width="800"
|-
|style="width:15%"|
'''Eigenschap'''

|style="width:3%"|
'''<nowiki>#</nowiki>'''

|style="width:37%"|
'''UML'''

|style="width:15%"|
'''Voorbeeld'''

|style="width:30%"|
'''Opmerkingen'''

|-
|
Type

|
1..1

|
Een UML connector  van het type  ‘generalization’,  ‘composition’ of  ‘association’

|
[[image:Image027.png]]

|
Door het soort UML relatie wordt  deze eigenschap bepaald. Het  type (generalisatie, compositie  of  semantische relatie) volgt uit  deze keuze

|-
|
SourceElement

|
1..1

|
Het verbinden van een  UML class met het  startpunt van de  connector

|
[[image:Image029.png]]

|
Het verbinden met de connector  is voldoende om deze  eigenschap te bepalen

|-
|
TargetElement

|
1..1

|
Het verbinden van een  UML class met het  eindpunt van de  connector

|
[[image:Image031.png]]

|
Het verbinden met de connector  is voldoende om deze  eigenschap te bepalen

|-
|
SourceCardinality

|
0..1

|
Het aangeven van  multiplicity op de  source role van de  associatie

|
[[image:Image033.png]]

|


|-
|
TargetCardinality

|
0..1

|
Het aangeven van  multiplicity op de  target  role van de  associatie

|
[[image:Image035.png]]

|


|-
|
DefinitionCode

|
1..*

|
Tagged value  ‘DCM::DefinitionCode’  (CD)

|
SnomedCT:18669006  evidence for

|
Er kunnen meerdere codes zijn  die de relatie definiëren,  bijvoorbeeld uit verschillende  code systemen.

|}


'''''Value set'''''

{| class="umctable" width="800"
|-
|width="15%"|
'''Eigenschap'''

|
'''<nowiki>#</nowiki>'''

|
'''UML'''

|
'''Voorbeeld'''

|
'''Opmerkingen'''

|-
|
Name

|
1..1

|
‘name’ van de Class

|
“Weegmethode”

|


|-
|
Description

|
0..1

|
‘notes’ bij de Class

|
“De methode, die  werd gebruikt bij het  wegen van de patiënt”

|


|-
|
DisplayText

|
0..1

|
Tagged value ‘DCM::DisplayText’ bij de class

|
“Methode”

|


|-
|
Label

|
0..1

|
‘alias’ bij de Class

|
“Methode van wegen”

|
In EA kun je bij diagram  properties aangeven dat het alias  gebruikt moet worden voor de  weergave (Use Alias if Available).  Dit is handig voor de  communicatie, omdat dan niet  de (aan regels gebonden) naam  hoeft te worden getoond.

|-
|
Term

|
0..*

|
Voor iedere term wordt  een UML- attribute  toegevoegd op de  class. Dit attribute  heeft alleen een naam  (geen type). 

|
[[image:Image037.png]]

|
Een value set zonder terms kan  een abstracte value set zijn. Dit  wordt expliciet gemaakt door de  value set UML-class ‘abstract’ te  maken. Dit geeft aan dat de  terms in een later stadium  moeten worden ingevuld.

|}


'''''Term'''''

{| class="umctable" width="800"
|-
|width="15%"|
'''Eigenschap'''

|
'''<nowiki>#</nowiki>'''

|
'''UML'''

|
'''Voorbeeld'''

|
'''Opmerkingen'''

|-
|
DefinitionCode

|
1..*

|
Tagged value  ‘DCM::DefinitionCode’  (CD) op het UML-  attribute

|
SnomedCT:181286006 entire mitral valve

|
Er kunnen meerdere codes zijn  die het concept definiëren,  bijvoorbeeld uit verschillende  code systemen.

|-
|
Description

|
1..1

|
‘notes’ bij het UML-  attribute

|
“De mitraalklep van  het hart”

|


|-
|
Name

|
1..1

|
‘name’ van de Class

|
“Mitraalklep”

|


|-
|
DisplayText

|
0..1

|
Tagged value ‘DCM::DisplayText’ bij de class

|
“Mitraalklep”

|


|-
|
Label

|
0..1

|
‘alias’ bij de Class

|
“Mitraalklep hart”

|
In EA kun je bij diagram  properties aangeven dat het alias  gebruikt moet worden voor de  weergave (Use Alias if Available).  Dit is handig voor de  communicatie, omdat dan niet  de (aan regels gebonden) naam  hoeft te worden getoond.

|-
|
OrdinalValue

|
0..1

|
Initial value van het attribute

|
[[image:Image039.png]]

|
De ‘initial value’ kan worden getoond in de user interface, zodat hij zichtbaar is voor de gebruiker

|-
|
ParentTerm

|
0..1

|
Tagged value  ‘DCM::ParentTerm’  (naam van de term) op  het UML-attribute en  liggende streepjes ‘_’  voor de ‘child’-term

|
“Hart”

|
Hiermee wordt aangegeven dat  een term een verbijzondering is  van een andere term in dezelfde  value set. Voor de leesbaarheid  is  het noodzakelijk om de  verbijzonderde termen direct  onder de ‘parent’ op te nemen in  de UML-attributen. De  verbijzonderde term begint met  een liggend streepje ‘_’ voor  ieder niveau. Onder de term  ‘_Hart’ hangt dus een  ‘__Mitraalklep’

|-
|
ContentExpression

|
0..1

|
Tagged value  ‘DCM::ContentExpression’ (ST) op de UML-  class

|
SnomedCT, July 2010: &lt;404684003|clinical finding|

|
Met deze expression kunnen  termen worden geselecteerd uit  een bestaand  terminologie  systeem,  bijvoorbeeld SNOMED  CT. Dit  kan handig zijn als het  aantal  mogelijke termen zeer  groot is.

|-
|
ContentReference

|
0..1

|
Tagged value  ‘DCM::ContentReference’ (URL) op de UML-  class

|
SnomedCT, July 2010: “<nowiki>http://www.parelsnoer.org/dcm/valuesets/anatomischelocatie.xls</nowiki>”

|
Deze URL verwijst naar een  bron, die de termen uit de  value  set bevat. Dit is een andere  manier om termen te koppelen  als het aantal zeer groot is.

|-
|
ParentValueset

|
0..1

|
De abstracte UML  parent-class, die wordt  ingevuld door deze  value set. De twee  worden verbonden met  een generalization  association

|
[[image:Image041.png]]

|


|}


'''''OCL-constraints'''''

OCL-constraint worden gebruikt om het waardendomein of de afgeleide waarde van een concept te bepalen. Daarnaast kunnen ze worden  gebruikt om de cardinaliteit van attributen (verder) in te perken. OCL-constraints voldoen aan de specificatie van OCL. In het constraint kan  worden verwezen naar de concepten binnen de DCM of naar concepten buiten de DCM (bijvoorbeeld concepten in een DCM-verwijzing. Dit gaat als volgt:



{| class="umctable" width="800"
|-
|
'''Doel'''

|
'''Methode'''

|
'''Voorbeeld'''

|-
|
Het verwijzende concept, de  ‘parent’

|
Gebruik ‘owner’

|
'''owner'''.value = “nvt”

|-
|
Een concept waarnaar verwezen  wordt, het ‘child’ (composite)

|
Gebruik de naam van de UML-  class

|
<nowiki>Bovendruk.va</nowiki>lue &gt; 150

|-
|
Een concept, waarnaar via een  semantische relatie verwezen  wordt. 

|
Gebruik de naam van de UML-  associatie

|
Oorzaak.Methode = Excisie

|}


In OCL wordt altijd gerefereerd aan de naam van een concept, niet aan de alias of omschrijving. Bovendien wordt in veel gevallen gerefereerd  aan  het specifieke onderdeel van het ISO-datatype. In bovenstaande voorbeelden is dit de value. Deze zie je niet terug bij de methode  excisie,  omdat de excisie refereert aan beide velden van het CD-type.

In de OCL-constraints worden constantes opgenomen volgens de OCL-definitie. Een uitzondering daarop is de enumeratie. Waardes uit de  enumeratie worden zonder quotes opgenomen (zie het voorbeeld Excisie in de tabel hierboven).

Wordt een OCL-constraint gebruikt voor het inperken van cardinaliteit, dan zullen veelvuldig de OCL-functies “IsEmpty()” en “NotEmpty()”  worden  gebruikt. Hiermee geef je respectievelijk aan dat iets er niet mag zijn of er juist moet zijn.



=== '''Metadata in UML''' ===

De metadata van een DCM wordt in UML vastgelegd maar in de vorm van ''Tagged values'' op het hoofd-package van de DCM. De Metadata zijn  beschreven in  hoofdstuk 4, paragraaf 4.3 . De tabel in dit hoofdstuk beschrijft voor elk metadata attribuut onder andere de aspecten “Naam”,  “Cardinaliteit” en “Datatype”. Deze zijn van belang voor het vastleggen van de metadata in een Tagged value:

De kolom “Naam” geeft de naam van de tagged value weer, waarbij de ''namespace'' DCM nog toegevoegd moet worden. Het metadata attribuut  “Version” wordt dus de tagged value “DCM::Version”.

Over het algemeen hebben tagged values geen vooraf bepaalde structuur, zodat de UML-tool je in principe alleen de mogelijkheid biedt om vrije  tekst bij een tagged value op te nemen. Enkele van onze tagged values hebben echter wel degelijk een onderliggende structuur die behouden  moet blijven om verdere automatische verwerking te kunnen ondersteunen. Deze appendix beschrijft hoe we de waarde van een tagged value  noteren, afhankelijk van zijn type. Naar deze types wordt gerefereerd in andere delen van dit document.



==== '''''Notatiewijze van de waarde''''' ====

{| class="umctable" width="800"
|- 
| width="20%"|
string (ST)

|
Geen structuur, de inhoud wordt een op een overgenomen in de  tagged value.

|-
|
code (CD)

|
Een code uit een codesysteem wordt genoteerd als:

''&lt;naam codesysteem&gt;'':''&lt;code&gt;''⌴''&lt;beschrijving concept&gt;''

Een voorbeeld uit SNOMED-CT is: 

SNOMEDCT:72098002 left arm (body structure)

Als naam wordt de ''root source abbreviation'' gebruikt die  UMLS  gebruikt voor het betreffende codesysteem. Dus:

* SNOMED-CT wordt “SNOMEDCT” 
* LOINC wordt “LNC” 
* ICD-10 wordt “ICD10”   

|-
|
code (CS)

|
Dit is een gestandaardiseerde code uit een vastgesteld  codesysteem, bijvoorbeeld de lijst met twee-letterige  landafkortingen. De code wordt als volgt genoteerd:

''&lt;code&gt;''⌴''&lt;beschrijving code&gt;''

|-
|
identificatie (II)

|
Een tagged value van het type identificatie kent een uniek nummer  (de "extensie") uit een nummeringssysteem (de "root"). We  noteren  de identificatie in de tagged value  als ''&lt;root&gt;'':''&lt;extension&gt;.''  

Bijvoorbeeld: het BSN nummer 612345671 noteren we als:

2.16.840.1.113883.2.4.6.3:612345671

Hier is 2.16.840.1.113883.2.4.6.3 het oid van "een BSN  nummer".  en 612345671 het BSN-nummer zelf. Door deze  combinatie is een  identificatie altijd volstrekt uniek en het  nummeringssysteem is ook  altijd te achterhalen.

|- 
|
hyperlink (TEL.URL)

|
Dit is een URL, altijd voorafgegaan door "http:", "https:" of "ftp:"

|- 
|
telecom (TEL)

|
Dit is een telecommunicatieadres, voorafgegaan door het  "protocol".  Dit is "tel:" voor een telefoonnummer, "x-text-fax:"  voor een  faxnummer en "mailto:" voor een e-mail adres.  Bovendien noteren  we het nummer met internationale  toegangscode. Een Amsterdams  telefoonnummer ziet er dus als  volgt uit in de tagged value: tel: +31-  20-3467171 

|-
|
persoonsnaam (PN)

|
De naam van een persoon, geschreven zoals het voor die persoon  gebruikelijk is.

|-
|
organisatienaam (EN)

|
De naam van een bedrijf, als vrije tekst zonder structuur

|-
|
adres (AD)

|
Een adres, geschreven zoals gebruikelijk is in het land waarin het  adres zich bevindt. Delen van het adres (postcode, straat, land,  etc)  scheiden met een komma.

|-
|
getal (INT)

|
Een getal, geschreven zonder scheidingsteken voor duizendtallen,  met een "." als scheidingsteken voor de decimalen.  Dus:  3.1415926535

|-
|
tijdstip (TS)

|
Datum eventueel inclusief tijdstip, geschreven in ISO8601 formaat:

YYYY-MM-DD⌴HHmmSS, dus bijvoorbeeld:

1972-11-30 15:04:00

|-
|
data (ED)

|
Binaire data kan niet in een tagged value worden opgenomen, dus  hier nemen we enkel een URL in waar de data kan worden  verkregen.

|-
|
hoeveelheid (PQ)

|
Een getal en een eenheid, gescheiden door een spatie. Het getal  wordt genoteerd als een INT (zie boven) en de eenheid is een  bestaande eenheid uit de UCUM standaard. Dus bijvoorbeeld:

<nowiki>120,4 mm[Hg]</nowiki>

|}
  

==== '''''Herhalende en samengestelde tagged values''''' ====

Enkele van de tagged values kunnen herhaald voorkomen, zij hebben een cardinaliteit &gt; 1. Omdat de naam van de tagged value uniek moet  zijn,  wordt bij herhalingen gebruikgemaakt van een oplopend nummer achter de naam van de tagged value. Bij het tagged value  "DefinitionCode" wordt  bij een eventuele tweede "DefinitionCode" de naam dus veranderd naar "DefinitionCode2". De eerste tagged value  mag naar keuze of  "DefinitionCode" of "DefinitionCode1" zijn.

Sommige tagged values (vooral bij de meta-data) zijn samengesteld uit andere tagged-values. In dat geval wordt met een "." tussen de  componenten de nesting van kind tagged values binnen de bovenliggende tagged value aangegeven. De afspraken voor cardinaliteiten zoals  hierboven geschreven gelden onverminderd. Neem als voorbeeld de tagged value voor "DCM::ContactInformation". Dit is een samengestelde  waarde (met onderdelen Name, Address en Telecom) die meermaals mag voorkomen. De namen van de tagged values zijn dan:



DCM::ContactInformation1.Name 

DCM::ContactInformation1.Address

DCM::ContactInformation1.Telecom



en



DCM::ContactInformation2.Name 

DCM::ContactInformation2.Address

DCM::ContactInformation2.Telecom



Mochten enkele van de geneste values zelf weer vaker voorkomen (bijvoorbeeld Telecom) dan wordt dit op gelijke wijze herhaald:



DCM::ContactInformation2.Telecom

DCM::ContactInformation2.Telecom2 



Tagged values waarvan de naam op “List” eindigt, en die van het type ST zijn, bevatten een lijst met items, gescheiden door komma’s.