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