| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
...
- the utilization of openEHR archetype path syntax in AQL. openEHR path syntax is used to locate clinical statements and data values within them using Archetypes. This path syntax is used to represent the query criteria and returned results. It It allows setting query criteria using archetype and node identifiers, data values within the archetypes, and class attributes defined within the openEHR RM. It also allows the returned results to be top-level archetyped RM objects, data items within the archetypes or RM attribute values.
- the utilization of containment mechanisms to indicate the data hierarchy and constrain the source data to which the query is applied.
- the utilization of ADL-like operator syntaxes, such as matches, exists, in, negation.
- Neutral expression syntax. AQL does not have any dependencies on the underlying RM of the archetypes. It is neutral to system implementation and environment.
- Supporting queries with logical time-based data rollback.
...
Parameters
AQL syntax supports parameterizationparameterisation. AQL parameters are used to indicate criteria, which will be substituted with values at run time. Supporting parameterization parameterisation is one of the mechanisms used to realise sharing AQL statements within a system or across system boundaries.
...
Parameters are needed when the same AQL query statement is used with different criteria values. This AQL example is to return all abnormal blood pressure values for a single specific EHR. This query has a parameter $ehrUid. This parameter will be substituted by a specific EHR.ehr_id value at run time. Consequently, this query can be reused for all EHRs either within an EHR system or by other EHR systems (Assuming assuming these EHR systems support AQL).
Where
...
and how parameters are resolved
AQL query parameters can be resolved at application level, or EHR system level. It depends on what the query parameters are used for and the design/implementation of the system or components. Query parameters would be normally resolved outside of a query engine.
If a query needs to be reusable across different EHR systems, any query parameters normally need to be registered in these EHR systems so that they can be resolved with real values from each environment. A typical example of this type of query parameter is $ehrUid. If the query is only used within an application, then the query parameters would be resolved by the application, such as the parameter of healthcare facility identifier or template identifier.
There is are no specific guidelines on how to resolve query parameters. Generally speaking, a parameter name is used as a key (or a key is associated with a parameter name) and the key needs to be unique within the boundary where the parameters are resolved. The EHR system or application needs to have the API functions to get the real value with a given parameter name or key.
...
A parameter always starts with a dollar sign $ followed by the parameter name, e.g. $ehrUid. Expect for AQL reserved words or characters, The parameter name can be any letter(s), alphanumeric values or underscore consist of letters, digits and underscores _. It cannot have a spacespaces and it cannot be an AQL reserved word.
A parameter can be used for all any criteria values within an AQL statement, e.g.:
within a predicate
No Format [$archetypeId], [at0003, $nameValue], [ehr_id/value=$ehrId]
...
AQL has three types of predicates: the standard predicate, the archetype predicate, and the node predicate.
Standard predicate
Standard predicate predicates always has have a left operand, operator and right operand, e.g. [ehr_id/value='123456'].
- The left operand is normally an openEHR path, such as ehr_id/value, name/value.
- The right operand is normally a criteria criterion value or a parameter, such as '123456', $ehrUid. It can also be an openEHR path (based on the BNF), but we do not have an example of this situation yet.
operators includeThe operator can be one of the following:
No Format >, >=, =, <, <=, !=
Archetype predicate
Archetype An archetype predicate is a shortcut of a standard predicate, i.e. the predicate does not have the left operand and operator. It only has an archetype id, e.g. [openEHR-EHR-COMPOSITION.encounter.v1]. Archetype The archetype predicate is a specific type of query criteria criterion indicating what archetype instances are relevant to this query. It is used to scope the the data source from which the query expected data is to be retrieved. Therefore, an archetype predicate is only used within an AQL FROM clause, for example,
FROM EHR [ehr_id/value='1234'] CONTAINS COMPOSITION c [openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS |
Node predicate
Node A node predicate is also a shortcut of a standard predicate. It has the following forms:
containing Containing an archetype node id (known as atcode) only, e.g.:
No Format [at0002]
containing Containing an archetype node id and a name value criteria/criterion, e.g.:
No Format [at0002 and name/value=$nameValue] [at0002 and name/value='real name value']
containing Containing an archetype node id and a shortcut of a name/value criteriacriterion, e.g.:
No Format [at0002, $nameValue] [at0002, 'real name value']
The above three forms are the most common node predicates. A more advanced form is to include a general criteria instead criterion instead of the name/value criteria criterion within the predicate. The general criteria criterion consists of left operand, operator, and right operand, e.g.:
No Format [at0002 and value/defining_code/terminology_id/value=$terminologyId]
Node A node predicate defines criteria on fine-grained data. It is only used within an identified path.
...
These advanced operators are not yet supported by the grammar. The operator syntax is borrowed from ADL specifications. These are proposed to improve the richness and flexibility of AQL so that AQL syntax supports more complicated query scenarios.
...