DavidStables (talk | contribs) |
DavidStables (talk | contribs) |
||
| Line 145: | Line 145: | ||
=== Query model specifications === | === Query model specifications === | ||
Specification of query clauses are described in two sets of pages. | Specification of query clauses are described in two sets of pages. | ||
One set describes the grammar of the [[IMQueryClauses|plain language approach]] and the other describes the same model as a one of the [[Meta model class specification|meta model classes]] i.e. set of plain data classes. | |||
Revision as of 09:51, 12 March 2023
Background to IMQ
Its all very well modelling data, value sets, and ontologies. What about modelling the logical definitions of data sets or profiles, this being usually referred to as query?
It is common practice in health care IT to model query definitions , intended for use in many different systems, in plain text documents, leaving the interpretation of the logic into run time query languages to the vendors internal informatics teams. This process creates a bottle neck and is prone to human error, partly due to ambiguity of plain language. An approach which uses machine readable definitions can reduce the time and remove much of the human error.
Each healthcare management system has their own database technologies, and database schemas. Each use their own approach to query, usually a combination of application code and SQL.
It is possible to model a query definition in SQL, but an SQL query brings with it the specific database schema. Also, using SQL as a means of modelling query brings the risk of poorly performing SQL, as SQL performs differently at different scales om different schemas. For example a correlated subquery on a huge database may perform poorly and sometimes better represented as a Window function. Most application use optimisation techniques to make sure the SQL performs to its best. One systems good SQL is another systems bad SQL.
Is is very difficult to construct understandable user interfaces directly from SQL or SPARQL, or vice versa, and thus most search and report applications create some form of intermediate representation, which is their own model.
IM considers health data to be a conceptual Graph, with the modelling of types, properties, and values as an RDF graph. This means that in query, the more natural language is SPARQL, which is the standard language used for RDF graph query. However, SPARQL is hard to understand visually and quite difficult to write interpreters for. Given that most systems use SQL, it seems fairly pointless adopting a language that is specific to RDF and would need interpreting anyway.
IM Query is a health query domain specific approach, designed to operate as an intermediary between plain language and the underlying run time query languages. The grammar is a constraint of main steam query languages and is a constraint on the query logic itself designed to match most health queries used in practice.
In particular IM Query uses a set of syntactical short cuts to encapsulate complex query syntax into some simple statements.
IMQ overview
IMQ can be considered as a DSL (a language with Grammar rules), or an Object model with query definitions as plain data objects that are instances of plain data classes . Both forms are supported. IMQ provides a pragmatic JSON based object model and a more succinct text to represent query definitions, and the IM services provide implementations in SQL and SPARQL via the use of interpreters.
The grammar or "structure" of an IMQ query definition precisely follows the logic of a plain language description of the the criteria to be applied to filter out sets from sets, and define the output required, and thus is ideal for data set definitions.
As health data is seen as a graph, the language follows the nodes and relationships in a direct acyclic manner, making graph traversal easier than the complex join syntax of SQL. Furthermore as most data sets include one to many relationships, IMQ supports and object form of output such as that used in GRAPHQL.
Implementation syntax includes a JSON object format (IMQ-JSON) and a succinct text language equivalent (IMQ-text)
An IM query definition follows a straightforward set of predicates which can be summarised as:
"From a set of things (e.g. patients)
where those things have certain properties and values, (e.g. observations, concepts and values), optionally ordered and limited (e.g. most recent)
Select the properties of those things (e.g. age or date of birth)
where the properties have certain values (where the values as objects further filtered e.g. latest blood pressure),
and optionally further select properties of the linked objects (e.g. a patient's-> home address-> postcode)
In line with the rest of the IM languages, IMQ uses an RDF approach to identifiers, thus enabling global identifiers for types, properties and value sets.
IMQ Structure
An IM query consists of a query request, which includes the necessary components to define a query, as well as a set of arguments that can be passed into the query and used at run time.
Query
A simple overall structure with nestable elements providing an object form input and output similar to GRAPHQL . A query may contain many queries, enabling a package of queries such as a column group report or full data set .
The request may fully define the query (dynamic query) or more commonly reference a pre-existing query definition via an IRI (i.e. a preformed query definition with variables resolved to the arguments passed in at run time). The pre-existing query definition is obtained from the "has Definition" property of a stored query entity.
High level query structure is as follows:
| Plain | Json |
|---|---|
query {
from {
where {
with {
then {}
}
}
}
select {
where {}
select {}
}
}
|
{"query" : {"from" : {
"where" :[ {
"with" : {
"then" : {}
}
]}
},
"select" :[{
"where" : {},
"select" :[ {}]
}],
"subQuery" :[ {}]
}
|
Simple example
Get me the full name of all patients aged >= 18 years.
| Plain | Json |
|---|---|
query {
from {
@:Patient
where {
:age >=18 units: years
}
}
select { :fullName}
}
|
{
"from" : {"@type": ":Patient",
"where" :{"id" : ":age",
"operator" : ">=",
"value" : 18,
"unit" : "YEARS"}
},
"select" : [ {"id" : ":fullName"}]
}
|
Subsumption query
A key differentiator of IMQ from sandard SQL is the support for a variety of subsumption or qualifiers of the identifiers in both the from and where clause. This makes IMQ compliant with expression constraint language when applied to concepts, but can also be used to incorporate subtypes of data model types.
The qualifiers are:
- Descendants Or Self Of subtypes (or subclasses) are incorporated at run time. The can apply either in the from clause, the where property, or the value.
- Descendants Of indicates only subtypes are examined (ECL compliance)
- Ancestors Of to enable the parent hierarchy to be transitively examined. Used in assessing allowable ranges and properties of concepts.
- Member of to use the instance members of a set in the From clause
- Type to use instances of a certain type in a from clause (e.g. patients) or when navigating the graph to illustrate node types (e.g. Hospital Admission)
ECL support
Expression constraint language is supported by IMQ as the from/where logic maps precisely concepts refinements, attributes and attribute groups
Query Request
IMQ supports conventional query for extract, query based updates (deletion) and a special 'path query' for determining paths between two classes. In addition to rule based query, a free text search using Lucene indexing is supported providing a term filter on the query rules.
Queries and updates are initiated by a Query Request passed as a payload to the API.
A query request can contain a set of arguments or parameter variables passed into the query to be used at tun time.
Query model specifications
Specification of query clauses are described in two sets of pages.
One set describes the grammar of the plain language approach and the other describes the same model as a one of the meta model classes i.e. set of plain data classes.
This is the section on grammar