The example below I would say is taking things to extremes. Normally, if you are going to create separate archetypes, they have distinct semantics. Here you are trying to use one archetype for three purposes, but to nevertheless retain the semantic distinctions inside the parent archetype, rather than specifying them in the child archetypes. So one has to ask the question: why bother with separate archetypes here? If you really want to have this ELEMENT archetype for some the purpose of reuse, then you can constraint ELEMENT.name to be the coded term you want in each case i.e. 'systolic BP' etc.
I have to admit I don't see much use in having such an ELEMENT archetype, because it is not really saying anything much. Defining the same thing inline seems to be clearer and easier. Do you have any more realistic examples? - thomas On 03/05/2012 09:18, Diego Bosc? wrote: > Ok, let me make an example so I can explain me better. I'm not saying > this is the way we should model this case, but just to show that the > use case is there. > > If we get blood pressure archetype and decide to represent systolic, > diastolic, and mean arterial pressure as slots to another archetype > (in this case pressure_measurement), you get something like this > > http://img717.imageshack.us/img717/6919/a4e77856c56c4c5499c5d1b.png > > this is the ADL code: > > definition > ENTRY[at0000] occurrences matches {1..1} matches { -- Blood Pressure > items existence matches {0..1} cardinality matches {0..*; unordered} > matches { > CLUSTER[at0001] occurrences matches {0..*} matches { -- Blood > Pressure Measurement > parts existence matches {0..1} cardinality matches {0..*; > unordered; unique} matches { > allow_archetype ELEMENT[at0003] occurrences matches > {0..*} matches { -- Systolic > include > archetype_id/value matches > {/CEN-EN13606-ELEMENT\.pressure_measurement\.v1/} > } > allow_archetype ELEMENT[at0006] occurrences matches > {0..*} matches { -- Diastolic > include > archetype_id/value matches > {/CEN-EN13606-ELEMENT\.pressure_measurement\.v1/} > } > allow_archetype ELEMENT[at0009] occurrences matches > {0..*} matches { -- Mean Arterial Pressure > include > archetype_id/value matches > {/CEN-EN13606-ELEMENT\.pressure_measurement\.v1/} > } > } > structure_type existence matches {1..1} matches { > CS occurrences matches {1..1} matches { -- > codeValue existence matches {0..1} matches {"STRC01"} > codingSchemeName existence matches {0..1} matches > {"CEN/TC251/EN13606-3:STRUCTURE_TYPE"} > } > } > } > } > } > > ontology > terminologies_available =<"SNOMED-CT", ...> > term_definitions =< > ["es"] =< > items =< > ["at0000"] =< > text =<"Blood Pressure"> > description =<"Blood Pressure"> > > > ["at0001"] =< > text =<"Blood Pressure Measurement"> > description =<"a meassure of a BP"> > > > ["at0003"] =< > text =<"Systolic"> > description =<"Peak systemic arterial blood pressure - > measured in systolic or contraction phase of the heart cycle."> > > > ["at0006"] =< > text =<"Diastolic"> > description =<"Minimum systemic arterial blood pressure > - measured in the diastolic or relaxation phase of the heart cycle."> > > > ["at0009"] =< > text =<"Mean Arterial Pressure"> > description =<"The average arterial pressure that occurs > over the entire course of the heart contraction and relaxation cycle."> > > > > > > > > > constraint_definitions =< > > > term_binding =< > ["SNOMED-CT"] =< > items =< > ["at0003"] =<[SNOMED-CT::163030003]> > ["at0009"] =<[SNOMED-CT::6797001]> > ["at0006"] =<[SNOMED-CT::163031004]> > > > > > > > > In the cases like this, if you resolve pressure_measurement then you > get something like this > > definition > ENTRY[at0000] occurrences matches {1..1} matches { -- Blood Pressure > items existence matches {0..1} cardinality matches {0..*; unordered} > matches { > CLUSTER[at0001] occurrences matches {0..*} matches { -- Blood > Pressure Measurement > parts existence matches {0..1} cardinality matches {0..*; > unordered; unique} matches { > > ELEMENT[CEN-EN13606-ELEMENT.pressure_measurement.v1] occurrences matches > {1..1} matches { > value existence matches {0..1} matches { > PQ occurrences matches {0..1} matches { -- PQ > units existence matches {1..1} matches { > CS occurrences matches {1..1} matches { -- > codeValue existence matches {0..1} > matches {"mm[Hg]"} > codingSchemeName existence matches {0..1} > matches {"UCUM"} > } > } > value existence matches {1..1} matches > {|>0.0..<1000.0|} > } > } > } > > ELEMENT[CEN-EN13606-ELEMENT.pressure_measurement.v1] occurrences matches > {1..1} matches { > value existence matches {0..1} matches { > PQ occurrences matches {0..1} matches { -- PQ > units existence matches {1..1} matches { > CS occurrences matches {1..1} matches { -- > codeValue existence matches {0..1} > matches {"mm[Hg]"} > codingSchemeName existence matches {0..1} > matches {"UCUM"} > } > } > value existence matches {1..1} matches > {|>0.0..<1000.0|} > } > } > } > > ELEMENT[CEN-EN13606-ELEMENT.pressure_measurement.v1] occurrences matches > {1..1} matches { > value existence matches {0..1} matches { > PQ occurrences matches {0..1} matches { -- PQ > units existence matches {1..1} matches { > CS occurrences matches {1..1} matches { -- > codeValue existence matches {0..1} > matches {"mm[Hg]"} > codingSchemeName existence matches {0..1} > matches {"UCUM"} > } > } > value existence matches {1..1} matches > {|>0.0..<1000.0|} > } > } > } > } > > And as you can see, you have lost text, descriptions, and codes. > > This kind of problem can in fact show up. e.g. AIDS report should > require two different AIDS tests, one for the first test and another > for the confirmation test. > Another different example could be having a main diagnosis (as an > obligatory slot with their own code), and secondary diagnosis (0..* > slot with their own code) referring both to an hypothetical diagnosis > archetype > > > 2012/5/2 Thomas Beale<thomas.beale at oceaninformatics.com>: >> On 02/05/2012 16:58, Diego Bosc? wrote: >> >> so you have to define two different archetype id even if the >> archetypes are the same? >> and again, slot text, description and codes are lost with this kind of >> approach >> >> >> >> if the archetypes are the same, you just use that archetype once, and allow >> multiple occurrences. There is never a need to duplicate an identical >> constraint object in an archetype. >> >> I am not sure what you mean by the 'slot text, description and code being >> lost'. Everything is right there in its archetype. A template contains all >> the codes. It doesn't include copies of the description because it doesn't >> need it - flattened objects are operational entities ('compiled' entities) >> not source entities. It's the same when you compile Java source code - the >> comments disappear in the output. >> >> - thomas >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> Chartered IT Professional Fellow, BCS, British Computer Society <http://www.bcs.org.uk/> Health IT blog <http://www.wolandscat.net/> * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120503/11d18050/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120503/11d18050/attachment-0001.jpg>
