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
