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
