Gebruik van UML voor DCM modellering

Documentatie

• Inleiding
• Opzetten EA omgeving
• Datatypes
• UML Modellering
• Zib secties
• Sectie information model
• Afspraken en eisen
• Importeren en exporteren
• EA tips en tricks
• Downloads
• Uitgegeven Zib id's
• Zib Codesystems

De documentatie is gebaseerd op Enterprise Architect versie 14.
Niettemin zijn de acties zoveel mogelijk ook voor versie 12 beschreven.

Inleiding

Dit topic is met toestemming overgenomen uit hoofdstuk 5 van  "Richtlijn Detailed Clinical Model" van het Parelsnoer Instituut

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

1. 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.
2. 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.
3. 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 “nl.results4care”, “nl.parelsnoer” of “nl.nictiz”. Hierachter nemen we dan het versienummer van de DCM op, bijvoorbeeld “v2”. De volledige naam van een DCM "Bloeddruk" wordt zo dus “org.parelsnoer.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.

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 <<derived>>. 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 <<rootconcept>>, zoals bij "Bloeddruk" hierboven. Het <<rootconcept>> 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 <<qualifier>>, 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 <<data>>, 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 <<state>>, 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).

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>:<code>⌴<omschrijving>.

Op de plaats van <codeSysteem> 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)

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):

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.

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:

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.

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”.

Soort element (*)	Samengesteld	Data	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):

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:

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<INT> of IVL<REAL>
Interval van hoeveelheid	IVL<PQ>
Tijdsinterval (periode)	IVL<TS>
Ratio (hoeveelheid)	RTO<PQ>

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<TS>. 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:

Figuur 8. UML Enumeratie.

Het gecodeerde data element Meetapparaat is hier dus uitgedrukt als een UML Class met het stereotype <<enumeration>>, 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:

1. 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).
2. 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:

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:

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:

Figuur 11. Weergave van validatieregels.

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.

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”.

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 <<reference>>.

Een verwijzend element wordt gemodelleerd als een UML Class, die het <<rootconcept>> 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 <<rootconcept>> van een DCM is, je logischerwijze altijd refereert aan de gehele DCM, inclusief de interpretatie en andere secties, niet enkel het Informatie Model.

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

Eigenschap	#	UML	Voorbeeld	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 > 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 < 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 = (Bovendruk.value + Onderdruk.value) / 2”	Zie verderop: OCL- constraints
Classification	0..1	Stereotype op de class	<<data>>	Classification stereotypes kunnen worden gecombineerd met functionele stereotypes als <<reference>>, <<enumeration>> of <<derived>>. 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

Eigenschap	#	UML	Voorbeeld	Opmerkingen
Type	1..1	Een UML connector van het type ‘generalization’, ‘composition’ of ‘association’		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		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		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
TargetCardinality	0..1	Het aangeven van multiplicity op de target role van de associatie
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

Eigenschap	#	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).		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

Eigenschap	#	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		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	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: “http://www.parelsnoer.org/dcm/valuesets/anatomischelocatie.xls”	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

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:

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	Bovendruk.value > 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

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: <naam codesysteem>:<code>⌴<beschrijving concept> 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: <code>⌴<beschrijving code>
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 <root>:<extension>. 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: 120,4 mm[Hg]

Herhalende en samengestelde tagged values

Enkele van de tagged values kunnen herhaald voorkomen, zij hebben een cardinaliteit > 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.