Information model
Inhoud
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
Het informatie model geeft een visuele representatie van de gegevens die een bouwsteen bevat en hun onderlinge relaties.
Het is een conceptueel, deel logisch model en bevat geen technische (implementatie) details en het kan één of meedere submodellen omvatten.
Een model bevat tenminste een rootconcept en één gegevenselement.
| Voorbeeld van een informatie model |
.png)
|
Classes toevoegen
Algemeen
Ieder informatiemodel begint met een rootconcept, dat de essentie van de bouwsteen vertegenwoordigt. Het rootconcept, en daarmee de bouwsteen, is altijd een enkelvoudige representatie van een begrip, geen lijst, dus Probleem en niet Problemen.
Om classes (rootconcept, container, dataelement, etc) toe te kunnen voegen aan het informatie model , moet het model eerst geopend worden.
Daaerna kunnen ze op twee manieren toegevoegd worden:
| 1. | Selecteer in de Toolbox, sectie Class de Class en sleep deze op het informatie model | |
|
| 2. | Selecteer in de Project Browser Common>DCM Datatypes en vervolgens het gewenste datatype. Sleep dit op het informatie model en kies Drop as Child. Vul de gewenste naam in. | ||||||
| |||||||
Doubleclick op de toegevoegde class. Het eigenschappen scherm opent zich.
Selecteer Stereotype en vul de gewenste waarde (rootconcept, container, data).
Vanaf MDG_Technology_for_HCIM versie 4.4.1 is een eigen profiel voor de zibs aangemaakt. De naam van het profiel is HCIM.
Indien het profiel niet zichtbaar is, moet eenmalig een fully qualified name van de het stereotype opgegeven worden: b.v HCIM::data. Dit kan rechtstreeks in het stereotype veld ingevoerd worden.
Tevens kunnen hier ook de benodigde tagged values ingevuld worden.
|
Als de juiste versie van de DCM Stereotypes file geladen is, worden de kleur en lijndikte automatisch goed ingesteld.
Naamgeving concepten
Veel bouwstenen hebben generieke concepten als 'Toelichting' of 'Naam' logischerwijs dezelfde naam. Hierdoor kunnen veel items ontstaan met dezelfde naam (evt. zelfs binnen de bouwsteen).
Daaarom moeten generieke namen, indien deze tot verwarring kunnen leiden, verder verbijzonderd worden.
Hiervoor wordt de volgorde Item-Attribuut gebruikt. Dus: ProbleemType. Namen van concepten als 'BeginDatum', 'Type' en 'Status' hoeven niet perse te beginnen met de naam van de bouwsteen.
Een begindatum hoeft dus niet perse 'BehandelaanwijzingBegindatum' te heten indien de naam 'Begindatum' maar geen verwarring kan opleveren binnen die bouwsteen.
Met de DCM::ConceptId krijgt het concept alsnog een unieke definitie zodat verwarring over de bouwstenen heen is uitgesloten.
Het is echter wel toegestaan om de naam van het concept te beginnen met de naam van de bouwsteen. In dat geval staat de bouwsteennaam altijd vooraan, bijvoorbeeld: 'AlertType', ‘ProbleemType.
Het rootconcept van een bouwsteen heeft dezelfde naam als de bouwsteen met weglating van de namespace, b.v. het rootconcept van de bouwsteen nl.zorg.Bloeddruk heet Bloeddruk.
Bij de naamgeving wordt PascalCasing (ook wel UpperCamelCasing) gebruikt. Dit houdt in dat de naam geen spaties mag bevatten en dat bij woorden die normaliter met een spatie gescheiden worden, de spatie en de daarop volgende letter vervangen worden door de corresponderende hoofdletter. In tegenstelling tot lowerCamelCasing begint de naam ook met een hoofdletter.
Definitie concepten
Als een klasse met stereotype 'Rootconcept' of 'Container' wordt toegevoegd, worden standaardteksten opgenomen in de definitie.
Voor de overige concepten bevat de definitie een korte maar heldere omschrijving van het concept. Overwegingen die geleid hebben tot deze tekst, horen hier niet bij.
Soms is het noodzakelijk om naast de definitie iets op te nemen over de context waarin de definitie gehanteerd wordt.
Welke items/class vullen
Naast de naam en de definitie kunnen bij ieder concept een 'alias' en één of meer attributen worden vastgelegd in de vorm van 'tagged values'.
In de sectie Afspraken en eisen staat voor de zibs uit de landelijke set opgegeven hoe het 'alias' gevuld moet worden en welke 'tagged values' per type concept vastgelegd kunnen of moeten worden.
Zie ook secties Verwijzingen naar andere bouwstenen en Valuesets en codes
|
Als het Tagged Values window niet zichtbaar is is dit op te roepen via tabblad ' Start/Explore', item ' Properties' > 'Tagged Values'. (EA versie 14)
Codering van de concepten
De DCM standaard eist dat voor ieder concept een definition code gedefinieerd wordt. Zonder codering is alles betekenisloos. Daarin kan alleen een Snomed CT code staan als je zeker weet dat het de juiste is, anders moet je een eigen code opvoeren en deze goed definieren. Die “eigen” code kan ook een Snomed CT extensie zijn. Foute SNOMED codes zouden juist misverstanden kunnen introduceren doordat je toch 'misbruik' maakt van een concept uit bv SNOMED, wat eigenlijk een semantische fout introduceert. Ook zijn er vaak geen definition codes voor ons type containers.
Daarnaast is het noodzakelijk om ieder concept uniek te kunnen identificeren. Daarvoor is de DCM::ConceptId tag geintroduceerd. Deze bevat als waarde een wereldwijd uniek id in de vorm van een OID.
Hiervoor is een projectOID toegekend onder de Nictiz OID. Onder deze OID zijn branches aangemaakt voor nummering van zibs, concepten en valuestes.
- De project OID : 2.16.840.1.113883.2.4.3.11.60.40
- De OID voor elementen: 2.16.840.1.113883.2.4.3.11.60.40.1 (substituut hele OID = NL-CM)
- De OID voor valuesets: 2.16.840.1.113883.2.4.3.11.60.40.2
- De OID voor bouwstenen: 2.16.840.1.113883.2.4.3.11.60.40.3
- De OID voor eigen codesystemen: 2.16.840.1.113883.2.4.3.11.60.40.4
In de DCM nemen we per concept een DCM::ConceptId op in de vorm:
DCM::ConceptId = NL-CM: <klassenummer>.<DCMvolgnummer>.<elementnummer> 1
NL-CM staat voor : "Netherlands Content Model Elements".
Bij de elementnummering wordt begonnen bij het rootconcept. Dit krijgt elementnummer 1. Voor de overige elementen wordt geen vaste volgorde voorgeschreven.
Voorbeeld: De eerste elementen van de eerste Bouwsteen in klasse social history zijn NL-CM:7.1.1, NL-CM:7.1.2 etc. De elementen van de tweede Bouwsteen zouden dan zijn NL-CM:7.2.1, NL-CM:7.2.2 etc.
Voor valuesets wordt gebruikelijk geen notatie in de vorm van een root en een extensie gebruikt, maar wordt achter de root OID doorgenummerd, met punten als scheidingsteken. Een alias is hierbij niet gebruikelijk. De notatie voor de valuesets wordt dan: 2.16.840.1.113883.2.4.3.11.60.40.2.x.y.z, echter Z is hier het volgnummer van de valueset binnen de DCM en niet het volgnummer van het element waar de valueset bij hoort. (let op het verschil in notatie, een ‘.’ ipv ‘:)
Voorbeeld: De eerste valueset/codelijst in de eerste DCM binnen de klasse social history is dan 2.16.840.1.113883.2.4.3.11.60.40.2.7.1.1
Voor codesystemen bestaat voor de extensie voor bouwsteen gebaseerde nummermethodiek. Deze worden naar behoefte uitgegeven.
Voor DCM’s is de nummering in de vorm:
Project OID.3.x.y waarin:
- X = Klassenummer
- Y = DCM volgnummer
Als er slechts één (1) DCM in de sectie voorkomt, dan heeft Y de waarde ‘1’ (en mag dan dus niet weggelaten worden).
Samenvattend zijn de afspraken voor het coderen van de element van de bouwstenen:
- Ieder element krijgt een code uit het NL-CM systeem, zoals hierboven beschreven.
- Het rootconcept krijgt binnen de bouwsteen elementnummer 1
- Het rootconcept krijgt nooit een andere(bv SNOMED-CT) code.
- Andere elementen inclusief containers kunnen wel codes uit andere codesystemen, zoals SNOMED-CT krijgen, uitsluitend als het element overeenkomt met het concept van de code.
1 Historisch zijn de bouwsteen Id's uitgegeven aan de hand van de CCR/CCD sectienummers waarin de betreffende bouwstenen gepositioneerd waren. Hoewel deze indeling niet meer leidend is, wordt de nummering nog wel gehandhaafd om de bouwstenen in klasses van gerelateerde concepten in te delen. Deze indeling is niet heel strak en de nummering heeft in principe geen belangrijke betekenis aangezien de Id's per definitie betekenisloos zijn.
Relaties maken
Met uitzondering van het legenda element worden alle elementen van een informatie model met elkaar verbonden door relaties.
De grafische representatie van zo'n relatie is een pijl. Zie ook de sectie over UML modellering.
In de zibs gebruiken we een aantal relatietypes:
|
|
|
In de zib's is de standaard toegepaste relatie een compositie (Composition to the whole). Een compositie-relatie loopt in de zibs altijd van een class of container element naar een container of rootconcept.
Aan de source kant van de relatie (niet-pijl kant) wordt de cardinaliteit van de relatie aangegeven. Deze kan zijn:
- 0..1
- 1
- 0..*
- 1..*
De cardinaliteit aan de destination kant van de relatie wordt altijd '1' verondersteld.
In speciale gevallen wordt een aggregatie relatie toegepast (Aggregation to the whole). De richting afspraak is daarbij hetzelfde.
Specialisaties worden in het informatie model van de zibs zelden gebruikt. Als iets echter echt een generalisatie/specialisatie is, kan die ook zo gemodelleerd worden.
In tegenstelling tot compositie/aggregatie relaties kunnen generalisatie relaties wel class elementen aan elkaar verbinden.
Een voorbeeld daarvan zijn de relaties met de DCM datatypes. Van ieder class element van een bepaald type loopt een generalisatie relatie naar dat datatype (deze is in het model echter niet als pijl zichtbaar).
Een notelink relatie wordt gebruikt tussen een note of constraint en het element waar deze betrekking op heeft.
Een dependency komt tussen een document artifact (valueset document) en het class element waar deze valueset bij hoort.
Een relatie wordt aangebracht door:
- de bron class te selecteren en met de muis de pijl rechtsboven naast de class vast te pakken
- de pijl naar de bestemming container te slepen
- de pijl los te laten en het juiste type te selecteren
|
Aggregatie
Een bijzonder geval van relaties tussen class elementen en een container is indien er slechts één element tegelijk mag voorkomen van de elementen die tot de aggregatie behoren.
Ga dan in het model als volgt te werk:
- Voeg een Boundary toe (uit de common elements van de toolbox)
- Voeg een Constraint toe met de tekst 'Precies één concept uit deze keuze box moet geselecteerd worden' en verbind deze constraint via een NoteLink met de Boundary.
- Verbind ieder concept binnen de boundary met de boundary met een aggregation relatie.
Dit doe je door vanaf het concept een dependency relatie te leggen naar de boundary, deze relatie daarna te selecteren en met de rechtermuisknop 'Advanced>Change Type...' te kiezen.
In de keuzebox die dan opkomt kan 'Aggregation' gekozen worden.
Let op: zolang het concept binnen de boundary staat is de relatie niet zichtbaar in het diagram
Het bestaan van de relatie kan gecontroleerdworden door het concept tijdelijk buiten de boundary te slepen
|
De container boven de boundary geeft de rol aan die de onderstaande concepten hebben in de bouwsteen.
Alle concepten binnen de boundary moeten deze rol ook kunnen vervullen. Indien dit niet zo is, moet een extra container geplaatst worden.
Notes
Notes elementen worden eventueel gebruikt om extra algemene informatie in het informatie model op te nemen over data, container, rootconcept of valueset artifacten. Werkwijze:
- Sleep een "Note" component uit de "Common" sectie van de toolbox naar het diagram.
- DoubleClick op het 'Note' element.
- De notes editor gaat dan open. Vul de gewenste tekst is en druk op 'OK'.
- Verbind de Note met een Notelink relatie met het bijhehorende element.
| Aanmaken van een note |
|
Constraints
Constaint elementen worden indien gewenst een inperking op de geldigheid, waardebereik, o.i.d. aan te geven die geldt voor een bepaald element, b.v. bij een valueset dat de set alleen geldig is voor volwassenen ouder dan 18 jaar. Werkwijze:
- Sleep een "Constaint" component uit de "Common" sectie van de toolbox naar het diagram.
- DoubleClick op het 'Constraint' element.
- De constraint editor gaat dan open. Vul de gewenste tekst is en druk op 'OK'. Het Constraint Type veld wordt niet gebruikt.
- Verbind de Constraint met een Notelink relatie met het bijhehorende element.
| Aanmaken van een constraint |
|
Verwijzingen naar andere bouwstenen
Algemeen
Als in een bouwsteen verwezen wordt naar (een rootconcept van) een andere bouwsteen wordt een generieke klasse aangemaakt met stereotype <<context>> of <<data>> én stereotype <<reference>>.
Welk eerste stereotype gekozen wordt, hangt van de aard van het verwijzende concept af. Zo zal de verwijzing bij hoofdbehandelaar naar het rootconcept van de bouwsteen Zorgverlener <<context, reference>> zijn en de verwijzing van indicatie naar probleem uit Probleem <<data, reference>> zijn.
Let op de volgorde! Om hier zeker van te zijn, verdient het aanbeveling om eerst stereotype <<context>> of <<data>> te selecteren en te accepteren en daarna stereotype <<reference>> en niet tegelijk.
Bij verwijzing wordt altijd naar het rootconcept van een bouwsteen verwezen. Indien de noodzaak bestaat om naar een deel van een andere bouwsteen te verwijzen, is dat een indicatie dat de bouwsteen waarnaar verwezen wordt, wellicht te groot is.
De naam van de klasse wordt Conceptnaam::GerefereerdeConceptnaam. De eerste conceptnaam is de naam in de verwijzende bouwsteen, de tweede is de naam in de de bouwsteen waarna verwezen wordt.
Beide conceptnamen benoemen is niet verplicht. Dit wordt alleen gebruikt als het nodig en zinvol is. Vaak zal de eerste naam een aanduiding zijn van de rol die de bouwsteen waarnaar verwezen wordt, speelt in verwijzende bouwsteen, b.v. Voorschrijver::Zorgverlener.
In de minimale vorm is de naam van de klasse GerefereerdeConceptnaam. De hele tekst van de klasse heeft 40% grijs als kleur (handmatig instellen).
De verwijzing wordt gecomplementeerd door bij het verwijzende concept de tag DCM::ReferencedConceptId te vullen met de unieke DCM::ConceptId van het rootconcept van de bouwsteen waarnaar verwezen wordt.
Bovendien wordt in het notes-veld bij de DCM::ReferencedConceptId een standaardtekst opgenomen, zodat ook voor de menselijke lezer duidelijk is naar welk concept verwezen wordt.
Bij verwijzing naar een rootconcept wordt impliciet ook naar de onder dit rootconcept hangende concepten verwezen.
|
Bij verwijzing naar een andere bouwsteen komt het soms voor dat deze bouwsteen één of meerdere valuesets bevat die veel generieker zijn dan in de verwijzing zinvol is (bv. een heel codesysteem als SNOMEC CT).
Vaak bestaat dan de wens om de valueset in de verwijzing in te perken. Indien de ingeperkte valueset een subset van de oorspronkelijke valueset is, wordt de bouwsteen feitelijk niet gewijzigd en is de ingeperkte valueset eigenlijk alleen een implementatie aanwijzing die het inzicht in de verwijzing en het gebruik van de bouwsteen eenvoudiger maakt.
Daarom is het inperken van een valueset bij verwijzing alleen onder bovengenoemde voorwaarde toegestaan.
In het model wordt dit als volgt gerealiseerd:
- Voeg een Boundary toe (uit de common elements van de toolbox) en geef deze de naam "Bouwsteen <naam zib zonder namespace>".
- Plaats de bouwsteen verwijzing (meestal data reference) binnen de boundary en voeg eveneens binnen de boundary een (nieuw) element toe en geef het dezelfde naam als het element uit de bouwsteen waar naar verwezen wordt en waar de betreffende waardelijst aan verbonden is.
De relatie tussen de bouwsteen verwijzing en de bovenliggende container blijft behouden. - Verbind ieder concept binnen de boundary met de boundary met een aggregation relatie.
Dit doe je door vanaf het concept een dependency relatie te leggen naar de boundary, deze relatie daarna te selecteren en met de rechtermuisknop 'Advanced>Change Type...' te kiezen.
In de keuzebox die dan opkomt kan 'Aggregation' gekozen worden.
Let op: zolang het concept binnen de boundary staat is de relatie niet zichtbaar in het diagram
Het bestaan van de relatie kan gecontroleerdworden door het concept tijdelijk buiten de boundary te slepen - Voeg buiten de boundary een waardenlijst document artifact toe met de ingeperkte waardenlijst
Het toegevoegde concept waar de waardenlijst mee verbonden is, moet het DCM::ConceptID krijgen van de zib waar naar wordt verwezen, de waardelijst krijgt een OID conform de regels voor waardenlijst OID's binnen de nummerruimte van de bouwsteen waar uit vandaan verwezen wordt.
|
Valuesets en codes
Valueset vermelding
Bij een concept van het type CD of CO wordt het waardebereik vastgelegd in een 'losse' valueset die in een document artifact aan het bijbehorende concept wordt gerelateerd (en dus niet als enumeratie attributen van dat concept).
Iedere valueset (dus ieder document artifact) krijgt in het CD/CO element een tagged value 'DCM::Valueset' waarbij het 'waarde' veld gevuld wordt met de naam van de valueset en het 'notes' veld de OID van die valueset. Hiermee wordt de naam van de valueset aan de OID van die valueset gekoppeld.
Voorbeeld:
DCM::Valueset = SocialeAnamneseTypeCodelijst en in de notes OID: 2.16.840.1.113883.2.4.3.11.60.40.2.7.1.1
Het notes veld van een tagged value wordt gevuld door de tagged value te selecteren en vervolgens het Notes icon te kiezen.
|
Bij het concept waarop één of meer valuesets van toepassing zijn, worden alle relevante valuesets in een tagged value (DCM::Valueset) vermeld. Dit geldt voor valuesets die een vergelijkbaar waardebereik vastleggen.
Bij implementatie moet dan gekozen worden welke valueset toegepast wordt.
Indien het waardenbereik een verzameling is van meerdere valuestes of codesystemen, moet een valueset aangemaakt worden die alle waarden bevat.
Naamgeving en nummering
Alle valuesets hebben een naam en een nummer in de vorm van een OID.
Soms kunnen voor de bouwsteen bestaande valuesets gebruikt worden. Hierbij wordt een eigen naam en een OID toegekend.
Hierbij is de afspraak, dat
- de naam wordt <Conceptnaam>Codelijst , waarbij <Conceptnaam> vervangen wordt door de naam van het concept waar de valueset aan gekoppeld is.
- Indien er meerdere valuesets aan één concept gekoppeld wordt, worden de namen <Conceptnaam><Toevoeging>Codelijst, bv. IngredientCodeATCCodelijst en IngredientCodeGPKCodelijst bij concept IngredientCode.
- de OID wordt toegekend zoals in 'Codering van de concepten' is beschreven.
Opstellen valueset
Bij de zibs is er voor gekozen om waardelijsten niet vast te leggen als enumeratie attributen bij het concept maar de waardenlijst aan het concept te koppelen middels een ‘document artifact’ (uit de Common elements). Dit doen we in alle gevallen voor enumeratie, dus niet alleen voor lange waardelijsten, maar ook voor korte.
Werkwijze:
- Op de download pagina vind je een Word-template waarin je de waardelijst kunt intikken (template voor valuesets.docx).
- Hierbij geldt de afspraak dat in de kolom ConceptName de de beschrijving staat zoals die in het codesysteem gegeven wordt. Dit zal dus vaak een Engelse term zijn. In de kolom Description komt de Nederlandse vertaling van het begrip met eventueel een additionele toelichting.
- Sleep een "Document" component uit de "Common" sectie van de toolbox naar het diagram.
- DoubleClick op het 'artifact'
- De document editor gaat dan open. Plak via copy/paste de waardelijst (tabel) uit het Word-document in de document editor.
| Aanmaken van een valueset |
|
- Sluit de document editor.
- Het document wordt vervolgens met het concept verbonden met een ‘Dependency Link’ (vanaf het document naar het concept). Vervolgens wordt de pijlkop van de link verwijderd door met de rechtermuisknop te kiezen: Advanced->Change Directions->Unspecified
Let op!: Doe dit eenmalig en edit daarna eventuele wijzigingen direct in de document editor van EA. Dit om te voorkomen dat je de waardelijst op twee plaatsen (in het Word-bestand en in EA) actueel moet houden.
N.B. Indien het waardebereik van een concept uit een compleet codesysteem bestaat, wordt een valueset aangemaakt die de naam en OID van dit codesysteem bevat en als conceptnaam 'Alle waarden'.
Het waardelijstelement kent twee tagged values
- DCM::ValuesetID : het eerder genoemde OID
- DCM::ValuesetBinding : Waarde die aangeeft in welke mate het gebruik van de waardenlijst verplicht is. Mogelijke waarden zijn Required, Extensible, Preferred, Example.
Required
Om conform te zijn met de zib, moeten alle elementen uit de gespecificeerde valueset komen.
Extensible
To be conformant, the concept in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
Preferred
Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
Example
Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
<TODO vertalen>
|
Bij zibs voor de nationale set worden valuesets uit één zib niet hergebruikt in een andere zib. Alle valuesets zijn gebonden (mede door hun OID's) aan de zib waarvoor ze aangemaakt zijn.
Als eenzelfde valueset ook nodig is in een andere zib wordt daar een kopie aangemaakt met een andere OID en evt. een andere naaam.
Waarden buiten Valueset
Elk concept van het type CD of CO heeft naast de value set een ‘overige’ mogelijkheid om te voorkomen dat bij gebrek aan een juiste waarde een foute waarde geselecteerd wordt (zeker bij verplichte items). Afspraak is dat deze overige waarden niet gecodeerde vrije tekst is. (in HL7 zal dit nullflavour OTH zijn met de tekst in originalText).
Indien de DCM::ValuesetBinding de waarde Extensible heeft, is het mogelijk de waardelijst uit te breiden met een code uit het codesysteem waartoe ook de andere waarden van de waardelijst behoren.
Het verdient aanbeveling om vervolgens de waardelijst formeel met de gekozen waarde uit te laten breiden.
Subdiagrammen
Als een diagram te groot of te complex wordt, kan het diagram opgeknipt worden in een hoofddiagram en subdiagrammen.
De verbinding tussen hoofd- en subdiagrammen verloopt via een gemeenschappelijke container. Als dit op de juiste manier gedaan wordt, kan met een dubbelclick op deze container in het hoofddiagram automatisch naar het subdiagram gesprongen worden.
De werkwijze daarvoor is als volgt. Uitgangssituatie is dat er een hoofdiagram is en dat de gemeenschappelijke container daar nog niet instaat.
- Voeg aan het Information Model een nieuw package toe.
- Indien dit niet automatisch gebeurt, voeg aan dit package een class diagram toe.
|
| |
|
- Vul het diagram met de gewenste concepten incl. de gemeenschappelijke container.
|
- Selecteer in het subdiagram de container en kies via de rechtermuisknop 'Add > Select Composite Diagram' en selecteer het subdiagram.
- Ga naar het hoofddiagram en sleep de gemeenschappelijke container vanuit de Project Browser van het subdiagram naar het hoofddiagram als 'Link'.
- Leg in het hoofddiagram vervolgens de relatie naar de bovenliggende container of het rootconcept en geef de cardinaliteit aan.
| Hoofddiagram en subdiagram | ||
|
| |
