Hi dear Ian
According to openEHR-technical Digest, Vol 49, Issue 12 see bellow
statements: (in scope of ADL 1.4)
1- 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).
2- The archetype-node-id in a locatable constructed around the
archetype calling the archetypeslot is to be ignored.
I have a validation problem:
If 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,
means at0000(child archetype node id) instead of at0001(slot node id) so how
can I apply occurrence of slot? for example
Entry[at0000] matches { -- Encounter
content matches {
allow_archetype INSTRUCTION [at0001] occurrences matches {0..1}
matches {
include
domain_concept matches {/instruction.v1/}
}
allow_archetype OBSERVATION [at0002] occurrences matches {1..1}
matches {
include
domain_concept matches {/observation.v1/}
}
}
}
the object may be something like this:
<content xsi:type="INSTRUCTION"
archetype_node_id="at0000">
.....
</content>
<content xsi:type="OBSERVATION"
archetype_node_id="at0000">
.....
</content>
In the above example how I can apply occurrence for INSTRUCTION objects
optional or just one occurrence and OBSERVATION only one occurrence must be
appear.
Or maybe we must bypass constraint defined on slots?
What is the main constraint applied? Slot constraint or child archetype
constraint?
Thanks in advance
-----Original Message-----
From: [email protected]
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of
openehr-technical-request at openehr.org
Sent: Monday, August 23, 2010 5:05 PM
To: openehr-technical at openehr.org
Subject: openEHR-technical Digest, Vol 49, Issue 12
Send openEHR-technical mailing list submissions to
openehr-technical at openehr.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
or, via email, send a message with subject or body 'help' to
openehr-technical-request at openehr.org
You can reach the person managing the list at
openehr-technical-owner at openehr.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of openEHR-technical digest..."
Today's Topics:
1. Re: ArchetypeNodeId of an archetypeslot (Ian McNicoll)
2. Re: ArchetypeNodeId of an archetypeslot (Bert Verhees)
----------------------------------------------------------------------
Message: 1
Date: Mon, 23 Aug 2010 13:19:09 +0100
From: Ian McNicoll <[email protected]>
Subject: Re: ArchetypeNodeId of an archetypeslot
To: For openEHR technical discussions <openehr-technical at openehr.org>
Message-ID:
<AANLkTik70HRY1VVSHjUr+ufiCULjyvN=uM4q=jt5v9QD at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 at oceaninformatics.com
ian at 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 at 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
>
> http://www.openehr.org/300-OE.html?branch=1&language=1
>
> http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Special
> ised+Archetypes
>
> 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 at oceaninformatics.com
> ian at 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 at 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 at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>
>
> _______________________________________________
> openEHR-technical mailing
> listopenEHR-technical at openehr.orghttp://lists.chime.ucl.ac.uk/mailman/
> listinfo/openehr-technical
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.chime.ucl.ac.uk/mailman/private/openehr-technical/attachments/2
0100823/898b6785/attachment-0001.html
------------------------------
Message: 2
Date: Mon, 23 Aug 2010 14:34:37 +0200
From: Bert Verhees <[email protected]>
Subject: Re: ArchetypeNodeId of an archetypeslot
To: For openEHR technical discussions <openehr-technical at openehr.org>
Message-ID: <4C726ADD.5000403 at rosa.nl>
Content-Type: text/plain; charset="utf-8"
Thanks, Ian, your answer makes it clear to me.
kind regards
Bert
Op 23-8-2010 14:19, Ian McNicoll schreef:
> 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 at oceaninformatics.com
> <mailto:ian.mcnicoll at oceaninformatics.com>
> ian at mcmi.co.uk <mailto:ian at 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 <http://www.phcsg.org> / BCS Health Scotland
>
>
>
> On 23 August 2010 11:51, Bert Verhees <bert.verhees at rosa.nl
> <mailto:bert.verhees at 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
>>
>> http://www.openehr.org/300-OE.html?branch=1&language=1
>> <http://www.openehr.org/300-OE.html?branch=1&language=1>
>>
>> http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specia
>> lised+Archetypes
>>
>> 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/valu
>> e>= 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 at oceaninformatics.com
>> <mailto:ian.mcnicoll at oceaninformatics.com>
>> ian at mcmi.co.uk <mailto:ian at 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
>> <http://www.phcsg.org> / BCS Health Scotland
>>
>>
>>
>> On 22 August 2010 13:04, Bert Verhees <bert.verhees at rosa.nl
>> <mailto:bert.verhees at 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 at openehr.org
>> <mailto:openEHR-technical at openehr.org>
>>
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>>
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org <mailto:openEHR-technical at
>> openehr.org>
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org <mailto:openEHR-technical at openehr.org>
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.chime.ucl.ac.uk/mailman/private/openehr-technical/attachments/2
0100823/42ef3dcc/attachment.html
------------------------------
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
End of openEHR-technical Digest, Vol 49, Issue 12
*************************************************
