AQL

Decision Support (archive)
1

Dear All

Ocean’s proposal for an Archetype Query Language has been around for a year now:

For a general time line and introduction see:
http://www.openehr.org/wiki/display/spec/openEHR+Query+Specifications

The AQL Specifications:
http://www.openehr.org/wiki/display/spec/Archetype+Query+Language+(AQL)

Queries will be required to based elements of their select clauses and where statements on reference model attributes (e.g. the time of commital, the time of an observation) but the majority of information sought will be based on archetypes used as the specification for the data. Thus a weight will be returned from seeking out data stored against the ‘body weight’ archetype, symptoms from ‘Story’ observations and specific structured statements about symptoms using the ‘symptom archetype’.

There are a number of questions that come up from archetype based queries and how we should handle them. The first is about repeating elements in an observation. The event class of observation is repeating and as such will lead, at times, to duplicate data at different times. For this reason an observation class may return multiple instances of the same data. There are a number of different ‘rules’ that are starting to become clear.

  1. A generic approach to returning data with recurring data; should values should be repeated as in a relational query that has the same logical joins?

  2. The data may have different state values such as standing or sitting blood pressure. When this approach was designed it was felt that information should always display state information by default. Should this be enforced (or add a special statement not to return state information). It is this mechanism that would always return Fasting with a blood sugar for instance.

  3. We are also looking for ways to test the query language and help it grow rapidly. Recently Chunlan Ma has been working on returning linked data from within the health record for instance.
    I am trying to start a conversation here for those seeking to use AQL and openEHR. We could provide a some tooling to get this moving and would even be very pleased to have feedback on how the Query Interface might go best.

Hope to hear some ideas about how to progress this the best. We have recently enabled interactive editing of the language which does make it easier to test the capability of the engine. We would be happy to support people working in the open source space with developing the language further.

Cheers, Sam

(attachments)

OceanInformaticsl.JPG

2

Sam,

These types of problems I tried to address some time ago.
But I was not concerned about the duplicity at different times, but that data stored as a one time measurement will be found.
But those in time series will not be found unless explicitly searched for.

Gerard

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

3

I just noticed that there is a new BNF. I have been waiting for it to
appear since the one I had was dated 2006.

I have someone that will build a parser for this BNF and I will then map
the query to the query engine that we have in OSHIP. This will take 3-4
weeks and by then we should be able to persist some sample data and
start testing queries.

But at this point I do not have any feedback on the existing status of
AQL. Maybe in a couple of months.

Cheers,
Tim

4

Hi Tim,

Just out of curiosity, do you intend to use a parser generator for the task? I’ve had my eyes on Antlr for quite some time, for I think it has the benefit of supporting a lot of target languages, and it has great tooling support. Of course porting a grammar from one language to other is not easy task, even in Antlr, but still it’d be easier to maintain and enhance, by using a common tool for all openehr related parsing tasks. It’s a pitty I’ve never found the time to get started on this one.

Cheers

Seref

5

Hi Seref,

I won't be using Antlr. I looked at it when thinking about the ADL
parser and was concerned about questions regarding it's Python support.
I ended up going with Pyparsing because it is Pythonic and easier for me
to understand. As a bonus, ADL intrigued Paul McGuire (Pyparsing
author) enough that he wrote the ADL parser. :slight_smile:

There is a comparison of Antlr,PLY & Pyparsing as well as regex on a
small task here:
http://www.dalkescientific.com/writings/diary/archive/2007/11/03/antlr_java.html

Pyparsing is much slower but I'm not so sure it would be slower than
Antlr generated Python code on a grammar like ADL. Either way the speed
of processing ADL is not much of an issue in my implementation. Though
it will be in AQL. I'll just have to see how it performs at that time.

Cheers,
Tim

6

Hi Tim,
It is great to here that you are taking AQL seriously and plan to write a
python implementation, your feedback I am sure will be invaluable.

We have not done a lot of work on queries for some time but have recently
been doing some work related to projects and have started to think about
some changes to the current AQL proposal published on openEHR, to simplify
and generalise the grammar and supporting more advanced queries features
such as a matches operator.

I have started a wiki page,
http://www.openehr.org/wiki/display/spec/Proposed+AQL+changes, to briefly
list what changes we are thinking about. When we get the time to update the
BNF for these proposed changes, we will attach it.

If you have a look at these proposed changes you will see that they are
significant from a grammar (and parser perspective) but does not change the
general intent.

I would appreciate your (and anyone else) early feedback on these proposed
changes even if you have not had a chance to implement AQL yet (even at a
high level).

My main concern is that you invest time into implementing the current
proposal and make comments about issues when the proposed changes should
make that task easier and shortcut some of the issues you would have
commented on.

I would like to think that we can work closely together during your
implementation to ensure that we can address issues in real-time.

Heath

From: openehr-decisionsupport-bounces@openehr.org [mailto:openehr-
decisionsupport-bounces@openehr.org] On Behalf Of Tim Cook
Sent: Friday, 25 July 2008 1:59 AM
To: Discussions relating to enabling decision support in openEHR
Subject: Re: AQL

> I am trying to start a conversation here for those seeking to use AQL
> and openEHR. We could provide a some tooling to get this moving and
> would even be very pleased to have feedback on how the Query Interface
> might go best.
>
> Hope to hear some ideas about how to progress this the best. We have
> recently enabled interactive editing of the language which does make
> it easier to test the capability of the engine. We would be happy to
> support people working in the open source space with developing the
> language further.

I just noticed that there is a new BNF. I have been waiting for it to

appear

since the one I had was dated 2006.

I have someone that will build a parser for this BNF and I will then map

the

query to the query engine that we have in OSHIP. This will take 3-4 weeks

and

by then we should be able to persist some sample data and start testing
queries.

But at this point I do not have any feedback on the existing status of

AQL.