Hi Sam, I would agree. I found something similar when modelling the RCPA histopathology archetypes. While it seemed sensible to model certain aspects e.g. 'Lymph node findings' and 'excision margins' as generic clusters, it became clear that the different reporting requirements of each cancer type forced me to include more and more variants in the child cluster archetypes, most of which needed to be constrained out at template level for individual cancer reports. Increasing fragmentation also adds to the burden of authoring and reviewing archetypes. If/when I revisit the histpoath archetypes I would reduce the number of separate Clusters and model more in-line for each individual cancer.
There are opportunities to re-use patterns at CLUSTER and occasionally ELEMENT level but there are drawbacks, as many of these seeming patterns end up being elusive and unhelpful. Ian On 3 May 2012 22:47, Sam Heard <sam.heard at oceaninformatics.com> wrote: > 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> <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 listopenEHR-technical at > lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > openEHR-technical mailing listopenEHR-technical at > lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > -- > [image: 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 listopenEHR-technical at > lists.openehr.orghttp://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/20120504/0b21e117/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/0b21e117/attachment-0001.jpe>
