Hello Koray, Reading your issues around cardinallity, perhaps you can solve this issue with help of constrains/business rules. E.g. if you consider in the Archetype model the ability to have a cardinality between A and B of (0..N), you can constrain practically this cardinality to a maximum of e.g. 4. The risk of modelling you cardinalities so precise in the archetype model is that if in future this is changed, your system (e.g. database schema's or applications) needs to be updated if this cardinality changes. If you are able to define the reason of this cardinality in rules you may create the flexibility in future to adapt this without changing systems or applications. I am not sure if this will help you, but consider this mechanism to handle cardinalities issues. I hope this may help you in finding a solution for your issue, regards Roel
Roel Stap TNO-ICT Colosseum 27 7521 PV Enschede +31 53 4835212 +31 6 10968787 http://www.tno.nl/ict DISCLAIMER http://www.tno.nl/disclaimer/email.html ________________________________ From: [email protected] [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sam Heard Sent: zondag 7 januari 2007 17:39 To: For openEHR technical discussions Subject: Re: Problem in some sample archetypes and questions Thanks Koray Your expression of cardinality and occurrences is exactly correct - there are clearly some errors in the archetypes. The only reason to limit cardinality in the archetype is to force a choice when there are more than one child e.g. container x with cardinality 1..2 has children a (occurrences 1..1) b (occurrences 0..1) c (occurrences 0..1) This forces a choice between b and c. Cheers, Sam Cheers, Sam Koray Atalag wrote: Hi to all, While revising my MST archetypes, I came across some confusion on the use of cardinality and occurences. And when I reread ADL 1.4 and ADL2, inspected the sample archetypes and then created new ones with Archetype Editor and also tested with the Workbench my confusion got even more increased. Here is the problem description and some questions: As stated in ADL 1.4: "Cardinalities indicate limits on the number of members of instances of container types such as lists and sets". From a simpler point of view, what I understand it tells the min and max allowed number of beads (same or different beads) in a box. From a more sensible way in the realm of clinical archetypes written in ADL, it is used to constrain the min and max allowed number of run-time instances of child nodes of attributes which can be a container such as CLUSTER, ITEM_TREE, ITEM_LIST, HISTORY and so on. So far so good but I have a practical problem to model a situation like the following: PARENT_NODE (A container type and might not exist or repeat up to 2 times) a) CHILD_NODE (Must appear once) b) CHILD_NODE (May appear 0 to 8 times) So this roughly can be expressed as: CLUSTER occurences {0..2} any container attribute cardinality {1..9} QUANTITY occurences {1..1} ELEMENT occurences {0..8} PROBLEM-1: As understood from above description that cardinality simply depicts the number of instances of subchilds - REGARDLESS of their type (i.e. QUANTITY or ELEMENT), then above cardinality can be {1..9} or simply {1..*}. When I examine some sample archetypes such as Line 67 in autopsy.v1, Line 33 in respiration.v1 and Line 103 in microbiology.v1 the cardinality of container node is {0..1} and they have a number of child nodes with occurences >0 and it is clear clinically that almost ALL of those nodes should appear in runtime data. So there is either a misunderstanding of the use of cardinality here among most of us or I am totally lost here :) The above model is expressed in those archetypes roughly as follows: CLUSTER any container attribute cardinality {0..2} QUANTITY occurences {1..1} ELEMENT occurences {0..8} QUESTION-1: What is the correct approach for above problem? QUESTION-2: Assume in some other place in the archetype you reference the ELEMENT node with occurences {0..8} by use_node. And in this particular place you do not want to have up to 8 instances and but also you want it to be mandatory (i.e. 1..) or even want {3..5}. What is the solution? (other than writing the whole thing once again) QUESTION-3: Related with second question, I also need to disallow usage of some values when referencing by use_node entries. This I believe is not an uncommon requirement in clinical medicine.For me I have an element with a long list of values of sites of an organ (Esophagus, stomach, colon and so on) and in many places of an observation these sites repeat without change so I can reference original. But in some cases selection of certain site(s) is not logical and should better be restricted or selection of only one site makes sense. What is the solution? Thanks and happy new year to all... -koray _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. Ltd. <http://www.oceaninformatics.biz/> Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) Ph: +61 (0)4 1783 8808 Fx: +61 (0)8 8948 0215 This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070108/50c0481e/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: Stap, R.E..vcf Type: text/x-vcard Size: 248 bytes Desc: Stap, R.E..vcf URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070108/50c0481e/attachment.vcf> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
