This is part 2 of a series of posts discussing the particulars and as the title says, confusing bits of AQL. Part 1 is here. I’m hoping to discuss what choices implementers of clinical data query language designers have and the implications of such choices.

AND operator takes the stage

So let’s talk a bit more about the FROM clause, and the query semantics it may express. Let’s take the previous simple AQL query from part 1 and extend it a bit. First, the simplest form I used:

SELECT ...
  FROM
    EHR E
    CONTAINS COMPOSITION C
    CONTAINS ACTION A

Let’s assume that instead of the above query, our user is interested in fetching data related to a scenario in which a clinician observes some clinical condition, then instructs something. Our user is therefore looking for data that’ll be in a COMPOSITION that contains an OBSERVATION and an INSTRUCTION:. _{Apologies if you’re a clinical modeller and I just butchered my way through openEHR modelling, you’ll have to live with it for the moment.}

AQL is one of the most clever things openEHR offers: a query language that allows users to access data they’re interested in, using the elements of openEHR reference model. Its primary author is Chunlan Ma, a real veteran of health IT, who has been a cornerstone of Ocean Informatics (Ocean Health Systems) for many years now. Heath Frankel is the other person from Ocean who made AQL possible.

It has a specification that explains its syntax, and how you can use it. Well, more or less. In case you have not seen it yet, Google is your friend.

As other openEHR vendors began to implement and market their platforms, AQL became a frequently used tool in both developing applications and analysing data. There is a lot to say about domain specific query languages, but I won’t digress, at least for the moment. I’d like to stick to some problems users (and even implementers) may find confusing and discuss the nature of the confusion.