# Latest ADL / AOM 1.5 & template specification drafts **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2010-02-24 15:01 UTC **Views:** 6 **Replies:** 3 **URL:** https://discourse.openehr.org/t/latest-adl-aom-1-5-template-specification-drafts/14965 --- ## Post #1 by @thomas.beale I have uploaded the latest drafts of the archetype and template specifications\. The page at http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypes gives a summary of all changes, as well as the links to the specification drafts\. I am hoping to have an upgraded version of the ADL workbench in the coming weeks demonstrating the full template semantics described in these documents\. The main aim of this work has been to integrate emerging new archetype requirements, as well as template requirements into a single reasonably elegant formalism \(i\.e\. an upgraded version of ADL/AOM 1\.4\)\. The work above is draft, and open to change\. Comments and questions are welcome\. \- thomas beale --- ## Post #2 by @thomas.beale A new draft is now up of the AOM 1.5 at [http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf](http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf) . This draft adds in group construct, providing the same capability as XML schema choice/sequence/group for ordering elements within container attributes. The AOM constraint model with this added in looks as follows: [http://www.openehr.org/wiki/download/attachments/196633/AOM_with_group.png](http://www.openehr.org/wiki/download/attachments/196633/AOM_with_group.png) The updated ADL specification will follow shortly. As usual, the main wiki page is at [http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypes](http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypes) - thomas beale --- ## Post #3 by @Gavin_Brelstaff Hi Thomas, Thanks for the new draft: adl\_1\.5\. I imagine that openEHR is the art\-of\-the\-possible so I really value your latest updates: In Section 6 \- Assertions I note the the advent \(in standard cADL syntax\) of Rules involving QUERY RESULTS from a data or knowledge context \- for example \(from Section 6\.5\.5\): $has\_diabetes:Boolean ::= query\("ehr", "has\_diagnosis", "snomed\_ct:1234567"\) $is\_female:Boolean ::= query\("ehr", "is\_female"\) Does this kind of rule provide some sort of basis for implementing generalized methods \(I'm thinking of OOD association relationships\) at the archetype level? Archetyped objects \- with their hermetically sealed inner states \- probably need to share some state info in order to do useful EHR\-related work\. And the way in which that state needs to be shared may reflect semantic order of the modeled EHR beyond that established by the containment/inheritance constraints envisaged by openEHR at the RM and CKM level\. Are we sure that this "semantic order" is best left to a set of external queries and, or, relegated to details of local template modeling? My pet ruse with openEHR has been that when we get down to the perspective of the data entry GUI \- the validity of the data\-input may depend on knowledge hermetically hidden way in another archetyped object \- and I'd like a principled way of generalizing the validation rule \(for reuse\) \- who knows: it might even be important semantic element of the pattern of system of archetypes\. And informal semi\-structured querying such as query\("ehr", "is\_female"\) still seems a bit of an abdication of responsibility to me\. Gavin Brelstaff CRS4 Sardinia Italy\. --- ## Post #4 by @thomas.beale Hi Gavin, thanks for the feedback.... see inline > ``` > In Section 6 - Assertions I note the the advent (in standard cADL > syntax) of Rules involving QUERY RESULTS from a data or knowledge context > - for example (from Section 6.5.5): > > $has_diabetes:Boolean ::= query("ehr", "has_diagnosis", "snomed_ct:1234567") > > $is_female:Boolean ::= query("ehr", "is_female") > > Does this kind of rule provide some sort of basis for implementing > generalized methods (I'm thinking of OOD association relationships) > at the archetype level? > > ``` at this stage I have not thought about putting method capability into ADL as such; I think for the moment that computational specifications should remain outside archetypes - but am happy to see alterntive proposals. If we were to include methods of some kind, I think we should be looking at a very functional style of language, no procedural stuff. But I think it might be for the next generation (ADL 2 ;-) > ``` > Archetyped objects - with their hermetically sealed inner states - > probably need to share some state info in order to do useful EHR-related > work. And the way in which that state needs to be shared may reflect > semantic order of the modeled EHR beyond that established by the > containment/inheritance constraints envisaged by openEHR at the RM and > CKM level. > > Are we sure that this "semantic order" is best left to a set of external > queries and, or, relegated to details of local template modeling? > > ``` I know what you are saying, and I have thought about this. I see two points of view: - yes, it is better this way, because it is better to keep the RM model of content clean, and not infect it with complex ideas of how querying should work across a whole EHR - no, because if we put external queries elsewhere, it fails to solve any interoperability problems - we will just end up with non-interoperable queries Now, we have a good handle on querying with AQL and a-path, so the second argument above is not so strong. > ``` > My pet ruse with openEHR has been that when we get down to the > perspective of the data entry GUI - the validity of the data-input may > depend on knowledge hermetically hidden way in another archetyped object > - and I'd like a principled way of generalizing the validation rule (for > reuse) - who knows: it might even be important semantic element of the > pattern of system of archetypes. > > And informal semi-structured querying such as query("ehr", "is_female") > still seems a bit of an abdication of responsibility to me. > > ``` well it is meant to be in the sense that I would not want to bury the actual query in the archetype; instead, I want to bury an abstract query-as-a-function that can be interpreted any way (via AQL or something completely legacy) elsewhere; as long as within the archetype the semantics are clear. In other words, I would not want the archetypes to be dependent on the particular query formalism (not even AQL). But you are right - the responsbility for expressing the query in a concrete processable form then still remains. But I think for the moment we need to do that - we need to assume that such queries could be answered by some existing non-openEHR system. I think it is better for archetypes to be usable in today's environments, not just 100% openEHR environments. I am very interested in alternative points of view - feel free to knock these arguments down ;-) - thomas --- **Canonical:** https://discourse.openehr.org/t/latest-adl-aom-1-5-template-specification-drafts/14965 **Original content:** https://discourse.openehr.org/t/latest-adl-aom-1-5-template-specification-drafts/14965