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.

This is a copy/paste of a few responses I sent to a discussion in the openEHR lists. I’m copying them here because images in my responses and responses themselves are not properly archived anywhere yet.

If you want more: I wrote a PhD thesis on this stuff, so if you want a deeper discussion of the topic here it is but I suggest you read the following first.

Here is the whole exchange from openEHR mail lists, with all responses, including mine:Read More »

Necessary clarification: Please note that the term implementation in the text below refers to development of a software platform based on openEHR. I realised that the term is overloaded in the health IT space, implying adoption of a standard sometimes. That is not what I mean by ‘implementation’.

Recently, I found myself in more than one discussion during which I was trying to explain what openEHR is to someone. It is common to adopt a different explanation of key concepts based on the occupation of the audience. The modelling side of things matter most to clinicians and policy makers and we talk in different terms than a conversation between software developers, architects etc.

The openEHR mail lists also reflect this natural distinction; there is technical, modelling, implementers etc.. I think I’ve realised something though, we end up having technical conversations with clinicians and implementation discussions with software developers. There is nothing wrong with it of course but I think the openness of the standard (it is in the name after all) is causing some problems in its adoption. This post is meant to express my thoughts about this pattern and it may or may not help you when you’re trying to understand some aspects of openEHR.Read More »

Recently, I heard a question targeted at my colleagues at Ocean, something in the lines of “what do you think is your greatest accomplishment ?”

Ocean’s software stack has a lot of impressive components, the template designer with its TDO support, the back end repository, Tom’s Eiffel work that is called the Archetype workbench, and clinical knowledge manager are all polished pieces of software with a lot of work behind them (and don’t forget the archetype designer)

However, my pick would not be one of these if I were to choose greatest thing out there. I’d choose the RM, the reference model of openEHR. Why? Well, it is because I have a past that has lots and lots of software development. The vendor that is trying to deliver a product to the clinician stands between the clinician an the technical infrastructure, code and hardware. If you work with all the common approaches and tools of recent times, that is, if you’re doing Object Oriented development with a mainstream language such as C# or Java, it is highly likely that you’ll go through the well known lifecycle of an application. Even if you use agile methods and good practices such as test driven development, there is one fundamental thing in this business you have to get right, if you want to succeed: requirements.

What helps with the requirements?

As scary as it may be, there is not a lot out there that may help with the requirements. In fact, I could argue that one of the reasons we have agile methodologies (and they are liked so much) is that we are expected to get the requirements wrong as software developers! Release early, release often, because most of the time you will release wrong stuff!

Tooling may help you get what you understand as requirements to code faster. A good UML tool that can generate code from models, or convention over configuration approach of frameworks such as Ruby on Rail will certainly help you deliver something fast, but none of these tools will help you understand the requirements better. They’ll just help you avoid mistakes during some key tasks you’re supposed to perform no matter what your software is supposed to do.

Sounds good, right? No matter what you’re supposed to do, these tools help you do it better. That is where the catch is: they won’t make it easier for you to figure out what you’re supposed to do. In order to that, you’d need tools that improve your communication with users and your understanding of the domain, tools that improve your communication with computers would not help here.

This is exactly what RM does, and this is why it is so important. If you’re a clinician, and you want to explain what you want, RM based modelling tools help you express your requirements, without knowing anything about computers, and if you’re a developer, RM based code and frameworks help you figure out how to represent those requirements in code. Someone else did all those rounds of asking the requirements, identifying patterns, and turning them into computable concepts. They’ve done the mistakes, paid the price, and shared what they’ve produced with you. That is one of the most valuable things you can get in this business.

For example, a software developer has a very different view of the concept of quantity, compared to a clinician. The developer has to figure out that quantities in clinical data come with units, magnitudes, reference ranges, and learning this takes time, and costs a lot of money for the software vendors. RM provides time tested components that can help clinicians, developers and computers communicate. Remember: doing it in the right way, and doing the right thing are different. You need better human to human communication for the latter, and if you have something like RM that is accessible to both developers and clinicians, that is your key to productivity.

When comparing RMs people usually forget that RM is not only about clinician to developer communication, once the developer gets his/her hands on the clinical model based on the RM, RM is supposed to improve communication to computers just as well as it has improved communication to clinicians. This is where most efforts fail. If you design your reference model with a very strong focus on human to human communication, diminishing the computability of RM to the point of computer readable (read: XML), you’re going to miss many advantages of an RM that can talk to computer languages better than yours. There are factors such as the granularity of data types, the level of abstractness of top level concepts, and the extend to which object oriented concepts are used. These factors determine how successful your RM will fit into programming language concepts, in other words, languages of computers, also spoken by developers.

openEHR RM has a good balance that lets it sit at a good point between developers (read: machine language speakers) and clinicians. You get too close to developers on that imaginary line, the clinicians lose their ability to express their requirements. You get too close to clinicians, the computers can’t understand what they’re being told. You have to have an RM that sits on the sweet spot.

Every other tool that sits on the RM can be written for other RMs, code generation, persistence, clinical modelling tools, you name it. The one that will succeed is the one that is build on the right RM. This, my friends, is why RM is the most precious asset of openEHR. It has been tested by lots of clinicians and developers, and it has been implemented in many computer languages. Most criticism comes from other methods that are either closer to developers, or to developers.

I am not saying that openEHR RM is the best it can be, because I am not qualified to make these kinds of big statements, but personally I have not seen any other alternative that performs as well. Please give this approach some thought, and think where your approach is putting you on the imaginary line I’ve defined. If you think you’re at a better position than what openRM provides, please let me know!