Project Management

Team

 Development Process

There are various possibilities for development of a query capability for openEHR, depending on the starting point. One querying language called AQL has already been developed and implemented to a reasonable extent by Ocean Informatics, and could form the starting point for an openEHR standard query language. On the other hand, if there are other candidates available, a selection process might be needed. Technically there is no reason why more than one querying approach cannot be described by openEHR, and there may be reasons to do this. The main requirement is that any/all querying solutions are mutually consistent, and consistent with all other aspects of openEHR.

Delivery Plan

Requirements

An 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:

• the query language used to search and retrieve EHR data must be neutral to system design and implementation. In another words, regardless of the persistence data model/schema design of a particular EHR system, the query statements should be same for all EHR systems. This is the key requirement. It helps to achieve:
  • 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.
• the query language is able to:
  • 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.
• the query language is archetype-aware, i.e. enables the knowledge of location and type of data items as provided by archetypes (in the form of paths and type & other constraints) to be used when constructing queries.
• the query language is terminology-aware, i.e. can be used with terminology to retrieve items on the basis of coding.

Candidate Solutions

The following candidates have been proposed as a query solution for archetypes openEHR data:

• AQL - Archetype Query Language Proposal (Ocean Informatics)
• A-path - Archetype Path Language + A-path proposal (Zilics)

References

1. ISO/TC 215 Technical Report: Electronic Health Record Definition, Scope, and Context. Second Draft, August 2003. (Accessed on 14/01/2008)