Information model: diagram

Classes toevoegen

• Naamgeving concepten

In de CCR hebben generieke concepten als 'Description' logischerwijs in alle secties dezelfde naam. Indien deze naamgeving in de bouwstenen overgenomen wordt, ontstaan er veel items met dezelfde naam (evt. zelfs binnen de bouwsteen). Daaarom moeten generieke namen, indien deze tot verwarring kunnen leiden, verder verbijzonderd worden.
We hanteren de volgorde Item-Attribuut. Dus: ProbleemType. Namen van concepten als 'BeginDatum', 'Type' en 'Status' hoeven niet perse te beginnen met de naam van de sectie. Een begindatum hoeft dus niet perse 'BehandelaanwijzingBegindatum' te heten indien de naam 'Begindatum' maar geen verwarring kan opleveren binnen die DCM. Met de DCM::DefinitionCode krijgt het concept alsnog een unieke definitie zodat verwarring over de secties heen is uitgesloten. Het is echter wel toegestaan om de naam van het concept te beginnen met de naam van de sectie. In dat geval staat de sectienaam altijd vooraan, bijvoorbeeld: 'AlertType', ‘ProbleemType.

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, wordt tenminste de volgende standaardtekst opgenomen in de definitie:
  • voor Rootconcepten: “Rootconcept van de bouwsteen <naam>. Dit rootconcept bevat alle gegevenselementen van de bouwsteen <naam>."
  • voor Containers: “Container van het concept <naam>. Deze container bevat alle gegevenselementen van het concept <naam>."

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.

Als een klasse met stereotype 'Rootconcept' wordt toegevoegd wordt de lijndikte van de box op 3 gezet.
(Doe het zo: Selecteer het rootconcept, kies het 'kwastje' en zet de lijndikte op 3)

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.
In de implementatie handleiding zullen we wel verwijzingen moeten opnemen. Daarvoor hebben we de definition codes ook nodig.

Daarom is besloten om een eigen lijst met concept definitie codes te maken. Hiervoor is een projectOID aangevraagd en toegekend. Idem voor een eigen lijst met ValueSets en klinische bouwstenen. Deze OID komt onder de Nictiz root.

• De project OID : 2.16.840.1.113883.2.4.3.11.60.40
  
• De OID voor bouwstenen: 2.16.840.1.113883.2.4.3.11.60.40.3
  
• De OID voor valuesets: 2.16.840.1.113883.2.4.3.11.60.40.2 (substituut hele OID = NL-CM-VS)
  
• De OID voor elementen: 2.16.840.1.113883.2.4.3.11.60.40.1 (substituut hele OID = NL-CM)
  

In de DCM nemen we per concept een DCM::DefinitionCode op in de vorm:
DCM::DefinitionCode = NL-CM: <sectienummer>.<DCMvolgnummer>.<elementnummer>
NL-CM staat voor : "Netherlands Content Models Elements".

We gebruiken in de DCM::DefinitionCodes de volgende aliases, zodat we niet steeds het hele lange OID hoeven in te tikken:

• 2.16.840.1.113883.2.4.3.11.60.40.1 = Content Models Elementen (alias 'NL-CM')
• 2.16.840.1.113883.2.4.3.11.60.40.2 = Content Modules ValueSets (alias 'NL-CM-VS' )
• 2.16.840.1.113883.2.4.3.11.60.40.3 = DCM bouwstenen (Geen alias. Wordt alleen in de metagegevens gebruikt. Daar schrijven we de OID voluit).
  

In het geval van Content Models Elements wordt de notatie ‘root:extensie’ gebruikt. De root is NL-CM (=2.16.840.1.113883.2.4.3.11.60.40.1) en de extensie heeft de vorm x.y.z waarin:

• X = sectienummer
• Y = DCM volgnummer (1 sectie kan meerdere DCM’s omvatten)
• Z = elementvolgnummer
  

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 sectie 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. In ieder geval tot er een projectOID is kunnen we de alias wel gebruiken. De notatie voor de valuesets wordt dan: NL-CM-VS.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 sectie social history is dan 2.16.840.1.113883.2.4.3.11.60.40.2.7.1.1

Voor DCM’s is de nummering in de vorm:
Project OID.3.x.y waarin:

• X = sectienummer
• 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.

Generalisatie of aggregatie

We gebruiken zo min mogelijk specialisaties in het model. Maar als iets echt een generalisatie/specialisatie ism mag die ook zo gemodelleerd worden.

Een bijzonder geval hiervan 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 in deze choice 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 composition relatie. Let op: zolang het concept binnen de boundary staat is de relatie niet zichtbaar in het diagram
  Je kan het bestaan van de relatie controleren 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.

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.
• Verplaats in de Project Browser het diagram naar de gemeenschappelijke container.

• Selecteer in het subdiagram de container en kies via de rechtermuisknop 'Advanced > Composite'.
• Sleep het diagram in de Project Browser terug naar de oorspronkelijke plaats.
• Ga naar het hoofddiagram en sleep de gemeenschappelijke container vanuit de Project Browser naar het diagram als 'Simple Link'.

Hoofddiagram

Submenu

Verwijzingen naar andere bouwstenen

Algemeen

Als in een bouwsteen verwezen wordt naar een (root)concept in een andere bouwsteen wordt een generieke klasse aangemaakt met stereotype <<context>>, <>, <<qualifier>> of <<state>> en 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 OverdrachtZorgverlener <<context, reference>> zijn en de verwijzing van indicatie naar probleem uit OverdrachtProbleem <<data, reference>> zijn.
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. 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::ReferencedDefinitionCode te vullen met de unieke DCM::DefinitionCode van het concept waarnaar verwezen wordt.
Bovendien wordt in het notes-veld bij de DCM::ReferencedDefinitionCode de volgende tekst opgenomen: “Dit is een verwijzing naar concept YYY in de bouwsteen XXXXX”, zodat ook voor de menselijke lezer duidelijk is naar welk concept verwezen wordt.

Bij verwijzing naar een concept wordt impliciet ook naar de onder dit concept hangende concepten verwezen.

N.B. Stereotype ‘context’ moet evt aangemaakt worden.

Zorgverleners

Zorgverleners komen in vrijwel alle secties voor.
Indien in deze secties het vermelden van deze betrokkenen klinisch relevant is, wordt dit gedaan door een verwijzing naar zorgverlener.
De modellering van zorgverlener verbeurt eenmalig in sectie 0.

Valuesets en codes

Valueset vermelding

Bij een concept van het type CD 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 een tagged value 'DCM::Valueset' waarbij het note veld gevuld wordt met de naam van de valueset en de OID van die valueset. Hiermee wordt de naam van de valueset aan de OID van die valueset gekoppeld.
Voorbeeld:

DCM::Valueset = SocialeAnamneseTypeCodelijst OID: 2.16.840.1.113883.2.4.3.11.60.40.2.7.1.1

Bij het concept waarop één of meer valuesets van toepassing zijn, worden alle relevante valuesets in een tagged value (DCM::Valueset) vermeld, ook de valuesets die als een document artifact aan dat concept zijn gerelateerd.

In tegenstelling tot hetgeen gebruikelijk is bij DCM's, spreken we voor dit project af, dat als er meer valuesets bij een concept genoemd worden, bij implementatie niet gekozen hoeft te worden uit één van de sets, maar dat het waardebereik de verzameling van alle vermeldde valuesets is.

Naamgeving en nummering

Alle valueset hebben een naam en een nummer in de vorm van een OID. Soms kunnen voor de bouwsteen betaande valuesets gebruikt worden. Als zo'n valueset in zijn geheel overgenomen wordt, dus zonder uitbreidingen of inperkingen, wordt de oorspronkelijke naam en OID gebruikt. In alle andere gevallen wordt zelf een 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.
• de OID wordt toegekend zoals in 'Codering van de concepten' is beschreven.

Opstellen valueset

Indien het waardebereik niet wordt vastgelegd in een losse valueset maar als enumeratie, is er voor gekozen dit niet te doen als enumeratie attributen bij het concept maar de waardenlijst aan 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:

• In de toolkit op ProjectPlace 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.
  
  

• 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
  

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

Omdat niet alle Value sets even goed beschikbaar zijn, zou ik willen voorstellen in dit document artifact een kopie van de set op te nemen met de naam van de beherende instantie erbij. Anders blijven die in spreadsheets staan.

Waarden buiten Valueset

Elk concept van het type CD 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)

Bovenstaande geldt ook voor datatype CO