Hi All There is no limit to the complexity we can all support - but you will lose the clinicians if the level of fragmentation and reuse gets beyond a certain point. One advantage of openEHR is that we have pushed the very common patterns (e.g. timing, distributed workflow) into the reference model.
I would recommend using examples from current models. Cheers, Sam On 4/05/2012 1:31 AM, Thomas Beale wrote: > > 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/> > > > * > * > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120504/63000902/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120504/63000902/attachment-0001.jpe>
