Skip to Navigation | Skip to Content

openEHR-Technical mailing list archives

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: ArchetypeNodeId of an archetypeslot

Hi Bert,

I appreciate you will be currently using ADL1.4, but in essence, by aggregating archetypes as you suggest, you are creating a template. ADL 1.4 does not define this aggregation/template behaviour, which is why I pointed you to the ADL1.5 specs, which cover both the templates and specialised archetypes. We, therefore do not have an official ADL1.4 answer to your question but your final statement is correct :

The archetype-node-id in a locatable constructed around an archetype in an archetypeslot is the archetype-node-id it gets from its own archetype (which is called in the slot).
The archetype-node-id in a locatable constructed around the archetype calling the archetypeslot is to be ignored.

Also remember that there is no absolute requirement for a single slot to have an atnode name but Heather and I now pretty well always assign one routinely as it helps document the usage of the slot for downstream users.


Ian

Dr Ian McNicoll
office / fax  +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
ian@mcmi.co.uk

Clinical Analyst  Ocean Informatics
Honorary Senior Research Associate, CHIME, University College London
openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland



On 23 August 2010 11:51, Bert Verhees <bert.verhees@rosa.nl> wrote:
Thanks Ian,

I will not surprise you that I don't work with ADL 1.5.
So I have to understand your answer to this issue in ADL 1.4 context.

Archetypeslots are typically very convenient in templates, but also in archetypes.

In archetypes, the convenience is it makes it possible for easily archetype (code)-reuse.
But in an archetype the approach is different because the locatable constructed around the archetype (in the slot) is a property from the locatable constructed around the archetype which calls the archetype(slot).
(sorry the express this so complicated, I don't know a more simpler way to say this)

This is not the case in a template, because they serve another purpose.

I must confess, in my software I do not use templates, for now, but I will in the next release.
So the only purpose for me for archetype-slots is as a part of an archetype.

Please correct me if I state following wrong:

The archetype-node-id in a locatable constructed around an archetype in an archetypeslot is the archetype-node-id it gets from its own archetype (which is called in the slot).
The archetype-node-id in a locatable constructed around the archetype calling the archetypeslot is to be ignored.

Is this correct?

Thanks, Bert




Op 22-08-10 15:27, Ian McNicoll schreef:
Hi Bert,

This is essentially a template, with the slot 'filled' by an archetype reference, and is defined in the forthcoming ADL AOM 1.5 specifications


use_archetype OBSERVATION[openEHR-EHR-OBSERVATION.blood_pressure.v1] ∈ {
    /items ∈ {
        use_archetype EVALUATION[at0001, org.openehr::openEHR-EHR-OBSERVATION.blood_pressure.v1]
    }
}

In the resultant template, the atNode of the filler/called archetype (at0000) , identifies the 'filled slot' node, not the parent/caller (at0001) but is always qualified by the archetypeID

FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1]
CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1]
WHERE obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value >= 140
  
Note too that, specialised archetypes also support the same mechanism of filled lots, which allows compound archetypes to be defined i.e with some pre-filled slots.


Ian
Dr Ian McNicoll
office / fax  +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
ian@mcmi.co.uk

Clinical Analyst  Ocean Informatics
Honorary Senior Research Associate, CHIME, University College London
openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland



On 22 August 2010 13:04, Bert Verhees <bert.verhees@rosa.nl> wrote:
Hi,

Excuse me if (I) asked before, it stills keeps puzzling me.


When we have this archetype-definition (this from Rong's repository from
test-archetypes for the adl-parser)
----------------
definition
   Entry[at0000] matches {    -- Encounter
       content matches {
           allow_archetype CARE_ENTRY [at0001] occurrences matches
{0..1} matches {
               include
                   domain_concept matches {/blood_pressure.v1/}
               exclude
                   domain_concept matches {/blood_pressure.v2/}
                   domain_concept matches {/.*/}
           }
       }
   }
--------------
Imagine the allowed archetype definition to blood-pressure is like

definition
   OBSERVATION[at0000] matches {    -- Blood Pressure
       data matches {
           HISTORY[at0001] matches {    -- history
               events cardinality matches {1..*; unordered} matches {
                   EVENT[at0006] occurrences matches {0..*} matches
{    -- any event
                       data matches {
                           ITEM_LIST[at0003] matches {    -- blood pressure
                               items cardinality matches {0..*;
unordered} matches {
                                   ELEMENT[at0004] occurrences matches
{0..1} matches {    -- Systolic
                                       value matches {
                                           DV_QUANTITY <
                                               property = <[openehr::125]>
                                               list = <
                                                   ["1"] = <
                                                       units = <"mm[Hg]">
                                                       magnitude =
<|0.0..<1000.0|>
                                                       precision = <|0|>
                                                   >
                                               >
                                           >
                                       }
                                   }
                               }
                           }
                       }
                   }
               }
           }
       }
   }


We can see, there is an archetypeNodeId to this archetypeslot (at0001).
And in the called archetype there is also a archetypeNodeId (at0000)

In fact, the careentry has two archetypeNodeId's, one from the calling
archetype and one from the called archetype.
-----------------

Imagine there is an data object to the Entry which has the Care-Entry
worked out. What will be the archetypeNodeId to this CareEntry in a dadl
which represents these data completely worked out.

What will be the AQL which represents a query to a specific leaf-node in
the care-Entry, or are there two queries both possible for the same
leaf-node?
In that case, the situation differs from normal RM-Objects, because an
RM-object can only have one archetypeNodeID.

SO, please, help, a link to an explaining text somewhere will also do.

Thanks very much, and kind regards
Bert Verhees


_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical