Mahdi The ID needs to be the archetypeID not the archetype-node-ID if it is the root node of an archetype.
Cheers, Sam > -----Original Message----- > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > bounces at openehr.org] On Behalf Of mahdi.asgari at gmail.com > Sent: Saturday, 30 April 2011 6:02 PM > To: openehr-technical at openehr.org > Subject: RE: openEHR-technical Digest, Vol 49, Issue 12 > > Hi dear Ian > > According to openEHR-technical Digest, Vol 49, Issue 12 you saied two > bellow > statement are correct (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: openehr-technical-bounces at openehr.org > [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 <Ian.McNicoll at oceaninformatics.com> > 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 <bert.verhees at rosa.nl> > 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 > ************************************************* > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
