Zib kardinaliteiten: verschil tussen versies
(→Voorbeelden) |
|||
Regel 134: | Regel 134: | ||
Bij de ‘rode’ nee-velden wijzigt niets: de bovengrens van de kardinaliteit kan niet zomaar in een specifieke usecase ruimer zijn dan in de zib. Dat vereist een wijzigingsvoorstel voor de zib. | Bij de ‘rode’ nee-velden wijzigt niets: de bovengrens van de kardinaliteit kan niet zomaar in een specifieke usecase ruimer zijn dan in de zib. Dat vereist een wijzigingsvoorstel voor de zib. | ||
+ | ==Over deze informatie== | ||
+ | Publicatiedatum: 24-11-2020 | ||
+ | Versie: 1.4 |
Versie van 25 nov 2020 om 16:10
Inhoud
Samenvatting
Voor zibs introduceren we een andere definitie van kardinaliteit dan gebruikelijk: ‘conceptuele’ kardinaliteiten. Deze geven de essentie aan van een relatie en worden daarom niet beïnvloed door bijvoorbeeld beschikbaarheid, wenselijkheid en toegankelijkheid van de informatie. Vaak zal de conceptuele kardinaliteit van de zib overeenkomen met de gewenste kardinaliteit bij een specifieke usecase (informatiestandaard).
Indien de gewenste kardinaliteit bij de usecase afwijkt van de conceptuele kardinaliteit van de zibs, zijn er specifieke regels beschreven, die aangeven of de combinatie conceptuele kardinaliteit van de zib en de gewenste kardinaliteit in de usecase toegestaan is, dat wil zeggen ‘conform de zib’ is.
Aanleiding, scope en geschiedenis
Bij gegevensopslag ten behoeve van applicaties in bijvoorbeeld databases is het gebruik van kardinaliteiten redelijk overzichtelijk. Als conceptueel duidelijk is hoe informatie met elkaar verbonden is, bieden de kardinaliteiten de mogelijkheid correcte vulling te faciliteren en om de integriteit van de gegevens te bewaken. Bijvoorbeeld: als geboortedatum een kardinaliteit ‘1’ heeft en je vult niets in, dan zal de applicatie weigeren de gegevens op te slaan. Over het gebruik van de informatie zeggen de kardinaliteiten weinig. De relaties zorgen ervoor dat je de juiste gegevens krijgt, maar als je geen geboortedatum wil weten, is dat prima.
Bij zibs ligt dit aanzienlijk anders. Immers, zib-modellen (en dus ook de kardinaliteiten) moeten gelden voor alle usecases. In het verleden (project Generieke Overdrachtsgegevens 2012/2013) werd nog geprobeerd om de kardinaliteiten zodanig vorm te geven, met een aantal ‘1’-kardinaliteiten, dat een instantiatie van een zib in een overdracht altijd zinvolle informatie zou bevatten. Ook toen al werden voorbeelden ten tonele gevoerd om aan te tonen dat de verplichting niet mogelijk was. Informatie die niet bekend was, werd als aanleiding gezien om kardinaliteiten die met een ‘1’ begonnen, te schrappen.
Toen er meer toepassingen van zibs kwamen en nieuwe publicaties van de zibs zorgbreed (en niet alleen voor overdracht) werden gepositioneerd, werd de onduidelijkheid met de kardinaliteiten groter. Kwaliteitsregistraties en onderzoek vereisen specifieke informatie waarbij soms de (conceptuele) verplichting in de weg staat. Zo mogen bepaalde partijen sommige informatie gewoon niet ontvangen. Bovendien kan het voorkomen dat voor kwaliteitsdoeleinden niet-verplichte gegevenselementen essentieel zijn.
Ook bij de mapping van zibs op FHIR-modellen ontstond onduidelijkheid. FHIR-modellen zijn toch voornamelijk op communicatie gericht, bovendien vaak gebaseerd op een andere werkelijkheid en daarom vertegenwoordigen FHIR-modellen soms andere afwegingen.
Scope van deze notitie.
Deze notitie gaat over de betekenis van kardinaliteiten in de zibdocumentatie en de mogelijke vertaling hiervan naar kardinaliteiten in usecase-specifieke datasets binnen Informatiestandaarden (toepassingen).
Daarnaast moet er een document/notitie komen over de betekenis van kardinaliteit en conformiteit (M, R, O en IHE’s uitbreiding R2) in datasets van informatiestandaarden en bijvoorbeeld de toepassing van NullFlavors in het licht van de zibkardinaliteiten. Dit is het terrein van de implementeerbare informatiestandaarden (het raakt o.a. de leveranciers), en niet het terrein van de zibs.
Vanwege de verschillende bevoegdheden en betrokkenheden beperkt deze notitie zich tot het onderwerp ‘Zibs en kardinaliteit’ en moet er een andere notitie komen over de betekenis van kardinaliteit en conformiteit in datasets van informatiestandaarden.
Wat zijn Kardinaliteiten?
Voor niet-informatici of mensen die minder bekend zijn met de verzamelingenleer: in het algemeen geeft de kardinaliteit in de wiskunde (met name in de verzamelingenleer) de omvang van de verzameling aan. Het aantal elementen dus. De verzameling {rood, groen, blauw} heeft dus een kardinaliteit van ‘3’.
In informatiemodellen wordt kardinaliteit op vergelijkbare wijze gebruikt om de multipliciteit van een relatie tussen twee elementen aan te geven. Daarbij wordt de notatie ‘m..n’ gebruikt, waarbij ‘m’ de minimale multipliciteit is en ‘n’ de maximale. In het model wordt de kardinaliteit genoteerd bij het element waarvoor dit geldt. Dus als er tussen element A en element B en relatie bestaat en bij element B de kardinaliteit m..n staat, betekent dit dat een element A minimaal met ‘m’ elementen B een relatie heeft en maximaal met ‘n’ elementen B (voorbeeld: een auto heeft 3..6 wielen).
De relatie is hier als een compositie weergeven. De verschillen tussen compositie en aggregatie vallen buiten de scope van dit document.
![]() |
Ook bij element ‘A’ kan een kardinaliteit staan, b.v. p..q. Op vergelijkbare wijze zou dit betekenen dat een element ‘B’ minimaal met p elementen A een relatie heeft etc.
Bij de zib-UML-modellen gebruiken we dit laatste niet. Er wordt impliciet van uitgegaan dat deze laatste kardinaliteit ‘1’ is. Dit komt omdat patiëntgegevens uit privacyoverwegingen hiërarchisch geordend zijn, met de patiënt aan top van de hiërarchie.
Een voorbeeld van een situatie waarin beide kardinaliteiten gebruikt worden is een E-R-diagram van een relationele database. Voor zo’n databaseontwerp is het efficiënt dat bijvoorbeeld een patiënt een 0..1-kardinaliteit heeft met een woonplaats van inschrijving en dat een woonplaats een 0..*-relatie heeft met patiënt: er wonen meer patiënten in een plaats.
Voor optimalisatie van de database wil je de woonplaats in de meeste gevallen niet meerdere malen opslaan.
Voor een patiëntdossier zou het echter ondenkbaar zijn dat bij een aandoening die de patiënt heeft, het mogelijk zou zijn om te zien welke patiënten die aandoening nog meer hebben.
Voorstel ten aanzien van kardinaliteiten
Voor zibs introduceren we een andere definitie van kardinaliteit dan gebruikelijk: ‘conceptuele’ kardinaliteiten. Deze geven de essentie aan van een relatie en worden daarom niet beïnvloed door bijvoorbeeld beschikbaarheid, wenselijkheid en toegankelijkheid van de informatie.
Vaak zal de conceptuele kardinaliteit overeenkomen met de gewenste kardinaliteit bij een registratie-usecase.
Omdat simpele voorbeelden de boodschap het beste beschrijven: een patiënt heeft een geboortedatum: één. Dus niet ‘geen’ en ook niet twee. Dit staat los van het feit of je het hebt vastgelegd, het weet, mag weten of wil weten. Dus de (conceptuele) kardinaliteit van geboortedatum in de zib Patient is 1..1.
Het feit of je het vastgelegd heb, het weet, mag weten of wil weten is allemaal usecaseafhankelijk. En dat kan dan daardoor in de informatiestandaard worden bepaald.
Dat betekent concreet over de verhouding tussen conceptuele kardinaliteit van de zib ten aanzien van de kardinaliteit in een informatiestandaard:
- onderwaarde kardinaliteit in de zib mag in een informatiestandaard afwijken. Minder kon al en ruimer eventueel met pas-toe- of leg-uit-regel. HL7 gebruikt hiervoor bijvoorbeeld NullFlavor-waarden waarmee de reden van de afwezigheid van de informatie aangegeven kan worden.
- bovenwaarde kardinaliteit in de zib mag in een informatiestandaard afwijken. Minder mag nu al maar verruimen niet en dat blijft zo. Dat laatste is namelijk een conceptueel vraagstuk: je kan niet zomaar twee geboortedatums hebben. Wijziging kan alleen via wijzigingsverzoek op de zib.
De overweging om toch een minimale kardinaliteit aan te geven, ondanks dat deze gemotiveerd mag afwijken, is dat daarmee wordt aangesloten bij wat je uit de werkelijkheid mag verwachten. Voor elke specifieke usecase worden vervolgens keuzes gemaakt hoe deze toe te passen.
Voorbeelden
Kardinaliteit in zib | Kardinaliteit in Informatiestandaard | Is de beschreven combinatie kardinaliteit in zib/Informatiestandaard toegestaan, d.w.z. ‘conform de zib’? |
0..1 | 0..1 | Ja |
1..1 | Ja | |
0..* | Nee | |
1..* | Nee | |
1..1 | 0..1 | Ja |
1..1 | Ja | |
0..* | Nee | |
1..* | Nee | |
0..41 | 0..1 - 0..4 | Ja |
1..1 - 1..4 | Ja | |
0..5 - 0..* | Nee | |
1..5 - 1..* | Nee | |
1..41 | 0..1 - 0..4 | Ja |
1..1 - 1..4 | Ja | |
0..5 - 0..* | Nee | |
1..5 - 1..* | Nee | |
0..* | 0..1 | Ja |
1..1 | Ja | |
0..* | Ja | |
1..* | Ja | |
1..* | 0..1 | Ja |
1..1 | Ja | |
0..* | Ja | |
1..* | Ja |
14 is hier een voorbeeld en heeft verder geen speciale betekenis
De ‘groene’ ja-velden geven situaties aan die nu ook al toegestaan zijn omdat de kardinaliteit in de informatiestandaard daar hetzelfde of strenger is, de nieuwe ‘oranje’ ja-velden vertegenwoordigen de gevallen waarin de ‘conceptuele’ kardinaliteit van de zibs strenger zijn.
Bij de ‘rode’ nee-velden wijzigt niets: de bovengrens van de kardinaliteit kan niet zomaar in een specifieke usecase ruimer zijn dan in de zib. Dat vereist een wijzigingsvoorstel voor de zib.
Over deze informatie
Publicatiedatum: 24-11-2020 Versie: 1.4