Menu
▾
▴
#12 Structure in <representingTemplate>
Het is relatief makkelijk bij opnemen van een concept in een representingTemplate iets te vergeten, b.v. een groep die boven een concept hangt. Deels is dit natuurlijk een kwestie van goed aanpassen, maar een voorstel zodat ART het af kan dwingen.
Bij gebruik van een concept in <representingtemplate> MOETEN altijd alle ancestors van dat concept mee-geërfd worden. Dus als ik een concept heb: </representingtemplate>
groep: bedrijf
groep: adres
groep: huisnummer
item: huisnummer_toevoeging
En ik gebruik huisnummer_toevoeging in een representingTemplate, moeten bedrijf, adres en huisnummer ook in die representingTemplate zitten (en dus voorzien worden van kardinaliteit etc.). ART kan dat dan controleren. Het houdt dat zaken die in een hiërarchie genest zijn in een dataset, op dezelfde wijze genest moeten zijn in een representingTemplate. Wanneer je dan een concept hebt waarvoor je dat niet wilt, neem je het in je dataset op als top-level.
Dus als je 'adres' wilt gebruiken in een representingTemplate op het hoogste niveau moet je niet dit doen:
dataset:
groep: zorgverlening
groep: bedrijf
groep: adres
groep: huisnummer
item: huisnummer_toevoeging
Maar dit:
dataset:
groep: adres
groep: huisnummer
item: huisnummer_toevoeging
groep: zorgverlening
groep: bedrijf
groep: inherits adres
Dus de herbruikbare concepten op het hoogste niveau definiëren in een dataset (niet onder een ander concept), en <inherit> gebruiken wanneer je die wilt gebruiken.</inherit>
Dit lijkt me een goede 'best practice', die bovendien ook nog door ART gecontroleerd kan worden.
Marc de Graauw 24 mei 2012 10:27 (UTC) Nu MOETEN ook al bij het gebruik van een concept in een scenario, alle groep(en) erboven meegenomen worden. Als dat niet gebeurt, is het een fout. (Mogelijke uitzondering is gebruik van een concept uit de blokkendoos in een ander DECOR bestand dat via een <inherit> overgenomen wordt.) Dat betekent dat de schematron regels die een DECOR.xsd controleren, daarop kunnen valideren. Een scenario editor moet dit ook zo inbouwen.</inherit>
AH bouwt controle in in DECOR schematron controles.
Een aanmaker van een representingTemplate mag alleen een item uit een groep kiezen maar net als bij het aanvinken van iets in een groep in andere applicaties ook moet op z'n minst de groep(en) zelf worden meegenomen die voor het gekozen item "een tehuis" voorstelt. Tricky is even de "automatische" cardinaliteit van de groep of de groepen want een gekozen item I 1..1 in groep A->B->C moet leiden tot I 1..1 in C 1..1 in B 1..1 in A 1..1, maar I 0..1 leid volgens mij tot C 1..1, B 1..1, A 0..1 of heb ik het mis?
Foutmelding via DECOR schema schematron lijkt me een goede plek, dat ART dit afperst ook. Zodra de schematrons voor de xsd klaar zijn kan dit ook nog als compile controle worden meegenomen bij het samenstellen van afgeleide artefacts zoals documentatie, schematron's enz.
Volgens KH in Skypecon 8-6 hoeft een groep niet meegenomen in scenario te worden, dus bij:
is het legaal een representingTemplate met alleen item Y te hebben.
summary: Structure with <inherit> and <representingtemplate> --> Structure in <representingtemplate></representingtemplate></representingtemplate></inherit>
assigned_to: Alexander Henket --> nobody
Current DECOR rules lead to ambiguity in representingTemplate. An item may occur in a representingTemplate WITHOUT its ancestor (group) concepts.
So this is allowed (simplified syntax):
And means only concept 3 occurs in this representingTemplate. Example: Patient.id parameter without Patient in queries.
The following example is ambiguous:
A processor cannot decide whether concept-3 is meant to be a child of concept-1 or a stand-alone top-level item. i.e. whether the concept tree should look like this:
or this:
There is no ambiguity in your last example in DECOR: if you choose concept-3 it is always
It means that the context of concept-3 is always wel-defined as a child of concept-1. If you use concept-3 in a query (which is a technical artifact) you are free to do so (= the representingTemplate offers a place for concept-3 only) but conceptually there is no stand-alone concept-3.
A good example from real world is:
It is obvious that you never have "color" as a standalone concept because you loose context then. Referring to item 2 always means "in the context of group 1".
Last edit: Kai U. Heitmann 2012-06-08
Why is it always:
A processor cannot decide, since concept-3 is allowed as a top-level and as well as a child. The processor can only decide if we have an explicit rule: "If concept X's ancestor concept Y is present in a representingTemplate, concept X is always the child of Y". Do you mean this is a rule in DECOR scenarios? If not, what rule is? (I cannot derive this rule from the schema, nor from what happens in ART, so I really need the exact rules which apply spelled out for the software which we are writing.)
Note that the rule as stated would prohibit:
If conceptually there is no stand-alone concept-3 as you state above, wouldn't it be better to require concept-1 to always be present in the representingTemplate, and then have a template which only serializes concept-3 to HL7v3 for queries? That way, the representingTemplate would reflect what conceptually is the case.
Maybe your picture is not complete... with
pointing to concept-3 always means including the group. If concept-3 should also act as a standalone concept and as part of the group the statement would rather be
If you check concept-3 here it always means the standalone concept, if you mean "concept-3" as part of the group this concept is actually concept-4 and would be a concept instance that inherits concept-3
Thus I cannot see any ambiguity while processing concept-3 or any other concept.
Last edit: Kai U. Heitmann 2012-06-12
Capture discussion in documentation before closing
obsolete discussion