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+Specialised+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 >> <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.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100823/42ef3dcc/attachment.html>
