Re: Latest ADL / AOM 1.5 & template specification drafts

[Thomas Beale <thomas.beale@oceaninformatics.com>]

Hi Gavin,

thanks for the feedback.... see inline

On 16/03/2010 10:43, gjb wrote:

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

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical