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.
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
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
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.
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
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
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.