Hi Diego,, In Ocean .oet files the 'Inital Test' and "Subsequent Test" semantics are represented by a name/value redefine on the archetype root nodes. In ADL1.5 we will be able to specialise the root node atCode to do the same thing but more safely. As you have correctly pointed out before this essetnially means creating a template for each slot fill. At first this seems like a considerable overhead just to allow the root node to be redefined but in fact we often have to apply different constraints to the filled slot e.g different mandation, other node renames or even further slot-fills which are different in each case. Unlike normal templates, these are generally local to the parent template and I understand that Thomas is figuring out how these can be represented in-line (as we do with .oet), rather than needing to create a separate file for each local template
So differentiating the slot-filled archetypes is not in itself a problem but you are correct in pointing out that the slot definition is lost in the process. This assumes that the parent slot definition always needs to be retained and is not subsumed by the slot-filling archetype. - In fact this is not always the case. In the example you gave, it could be argued that the 'prime semantics' are in the Observation archetype 'HIV test component' and not in the parent 'Initial test' / Confirmation test', and that we don't want to lose those semantics to the parent slot definition. As it stands we get the best of both worlds. The original semantics of the slot-filling archetypes are retained, with the option of re-defining the semantics if required by local templating and root archetype node/ name description redefinition by a specialised atcode. It would be useful if the tooling automatically offered to create the re-definition based on the parent slot semantics, including any suggested bindings. Ian On 8 May 2012 09:28, Diego Bosc? <yampeku at gmail.com> wrote: > A more realistic example: > > http://img96.imageshack.us/img96/8431/8566bdf17b8b46ad85acbb3.png > > definition > COMPOSITION[at0000] occurrences matches {1..1} matches { -- HIV report > content existence matches {0..1} cardinality matches {1..2; > ordered; unique} matches { > allow_archetype OBSERVATION[at0001] occurrences matches > {0..*} matches { -- Initial Test > include > archetype_id/value matches > {/openEHR-EHR-OBSERVATION\.HIV_Test\.v1/} > } > allow_archetype OBSERVATION[at0002] occurrences matches > {0..*} matches { -- Confirmation Test > include > archetype_id/value matches > {/openEHR-EHR-OBSERVATION\.HIV_Test\.v1/} > } > } > } > > This report includes an initial test and a confirmation test, both HIV > Tests (which in fact have their own snomed codes). Initial and > confirmation test can be checked using different techniques. > > Again, if you resolve the slot you are losing the information that one > is an initial test and the other is a confirmation test and you . > > > 2012/5/3 Thomas Beale <thomas.beale at oceaninformatics.com> > > > > > > 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 > > > > > > > > -- > > Thomas Beale > > Chief Technology Officer, Ocean Informatics > > > > Chair Architectural Review Board, openEHR Foundation > > Honorary Research Fellow, University College London > > Chartered IT Professional Fellow, BCS, British Computer Society > > Health IT blog > > > > > > > > _______________________________________________ > > 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 > -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120508/4bbd5101/attachment-0001.html>
