I’d like to this message could kick off the discussion about AQL - a common query language - for decision support.
Archetype Query Language (AQL) is a semantic query language. It is archetype specific, but neutral to system design/implementation. It can be used to query archetype-based data at any level of granularity within a system, cross system boundaries or enterprise-wide. It can retrieve all compositions of a particular EHR , all compositions specific to archetypes for a single EHR or across multiple EHRs, or retrieve entries, clusters, elements or data values etc. AQL is still under developing. It is currently used in Ocean Informatics products/components, e.g. EhrView.
Decision-Support systems need to access to patient data that is used by clinical guideline modules or workflow engine. AQL statement can be embedded within or referenced by the clinical guideline modules (which maybe written in difference guideline expression languages) or workflow definition. One major advantage of using AQL in decision-support systems is to be able to make the clinical guideline modules (or workflow definitions) sharable among different institutions.
So far, AQL hasn’t been used by any decision-support systems yet. I’d be greatly appreciate if anyone could help me to build a set of questions or requirements that might be required for decision support against which AQL can be tested. For instance, what data is normally required, data format, any arithmetic operators or functions etc. Or it is also very helpful if you could point me some relevant references, or authors.
The link below is the AQL specifications. There are some new features not in the spec yet (e.g. we have implemented part of “matches” operator). If you have any questions re the spec, please feel free to contact me.
Assesment of the current situation: knowledge that need to be gathered before a (full) conclusion can be made. Only if all the relevant questions are anserwed a conclusion such as ‘self-care advice’ can be drawn. These questions are about the current situation: which complaint, how long, severity etc. Typically such an assesment takes place at the start of a new episode: the client/patient wonders if he/she should visit the GP.
-History: knowlegde that can/ has to be derived from the EHR such as actual medication status and disease status/ history before a full conclusion can be made. A question could be: are A, B or C within the actual medication. Same for actual episodes: are episode C,D or E within the actual episodes. More complex questions could be: did episode F took place and was it closed less than 5 years ago (f.i. suspicion of recurrent cancer) or in case of suspicion of a diagnose G (‘running nose’): did an episode of G occur more than once in the past 2 years. In that case the work hypothesis running nose could change to hay fever.
decission rules (The whole system is based on ‘telephone triage guidelines’ provided by the Dutch council of GP’s)
This is a presentation from FDBE who provide the leading prescribing decision support engine in the UK. Although it is primarily about SNOMED, many of the issues equally relate to (and are better resolved by) archetypes and openEHR.