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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100320/790bd06d/attachment.html>
