...
Team: Chunlan Ma MD, Heath Frankel, Thomas Beale
Introduction
Integrated Care EHR (Electronic Health Record) is defined as:
"a repository of information regarding the health of a subject of care in computer processable form, stored and transmitted securely, and accessible by multiple authorised users" [1].
In any realistic health computing environment, EHRs will be maintained in systems of varying implementation, in terms of database (e.g. objects, relational), database schema (actual table design) and access mechanisms (variants of SQL, service interfaces etc). This will be true even for implementations all based on openEHR, since the choices for the back-end are still open to system designers. For a health authority that funds such systems, most of the economic value in the data is only available if the EHRs can be queried a) independent of the context of capture - i.e. screen form etc, and b) longitudinally for a given patient. As a result, the method of querying is of crucial importance. Clearly persistence details and even system vendors could change over time within the environment, and yet queries built to achieve a certain job must continue to function during and after such changes. This leads to the requirement for a query language independent of persistence design. We state the requirements as follows:
...
- users are able to write a query statement without knowing actual system design or data structure;
- the query statement is sharable within a system or across multiple systems;
- the query statement is reusable and future proof, which means that the query statement doesn't need to be changed whenever actual EHR system achitecture is changed or EHR system environment is changed.
...
- express the queries used for a single EHR as well as for a population of EHRs;
- express the queries used for retrieving an entire EHR, a clinical report, or fine-grained data within a clinical report or an entry;
- express the query criteria on both coarse-grained and fine-grained data items. For example, users can set query criteria on the name of the clinical report, or query criteria on a particular observation value (e.g. systolic blood pressure >= 140);
- express complicated query criteria. Some query criteria are very complicated. For example, this query scenario - Get the contact details of the women of child-bearing age who have not had a Pap smear in the past two years - is a population query, which has the criteria on gender, age, lab test name and date. It may also have criteria on terminology system, terminology id, data value, units etc.
- express the queries with logical time-based data rollback. This feature constrains the query to data that was available in the system within the specified time criteria. It allows the queries to be executed as though they were performed at a specified time.
...
Overview
Existing Query Languages
Currently, the available query languages, such as SQL, XQuery, or Object-Oriented Query Language, have dependencies on particular system data structure and working environment. Users must know the persistence data structure of an EHR in order to write an appropriate query. The query statement cannot be used by other systems which have different data store. Consequently, none of the these languages meet the aforementioned requirements and none of these can be used directly as the query language required by integrated care EHRs
...
What is AQL?
Archetype Query Language (AQL) is a declarative query language developed specifically for expressing queries used for searching and retrieving the clinical data found in archetype-based EHRs. It is applied to the openEHR EHR Reference Model (RM) and the openEHR clinical archetypes, but the syntax is independent of applications, programming languages, system environment, and storage models. The minimum requirement for data to be querying with AQL (including with archetype structures and terminology) is for the data to be marked at a fine granularity with the appropriate archetype codes and terminology codes. This may be native openEHR-structured data, or legacy system data to which the relevant data markers (mainly archetype paths and terminology codes) have been added. Unlike other query languages, such as SQL or XQuery, AQL expresses the queries at the archetype level, i.e. semantic level, other than at the data instance level. This is the key in achieving sharing queries across system boundaries or enterprise boundaries.
...