Information model query

Background to IMQ

Its all very well modelling data, value sets, and ontologies. What about modelling the logical definitions of data sets or patient profiles, (these being usually referred to as query)?

IMQ is designed to facilitate the exchange of logical definitions of query via APIs.

IMQ is not a new query language or domain specific language. Instead, it is simply an object model of a subset of the main stream query language CYPHER and as such can be easily interpreted into plain CYPHER, SQL or SPARQL. In addition the classes includes a set of simple predicates that map to complex query syntax at run time.

The main purpose of the object representation is to enable easier build and maintenance of user interfaces and interpretation to system specific query engine languages. Because IMQ is in object form, and transportable as JSON-LD it is ideal for APIs and interoperability via messages.

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.

It is possible to model a query definition in SQL, but an SQL query brings with it the specific database schema. SQL as a language is huge and developing SQL interpreters to interpret SQL to SQL is hard. Also, it 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.

IM considers health data to be a conceptual Graph, with the modelling of types, properties, and values as nodes and relationships. This means that in query, the more natural languages are CYPHER and SPARQL, the latter being the standard language used for RDF graph query. The information model uses IRIs for its types and properties so SPARQL is a natural target. However, instance data in health records are bested suited to a property graph model and therefore the 'target' language of IMQ is CYPHER.

IMQ overview

The class 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. It also uses the CYPHER concepts in its construction so as to map precisely to CYPHER or other query languages.

IMQ simplifies certain complex syntactical constructs by providing some grammatical short cuts covering the following areas

1. Subsumption query. Essential for expression constraints, flags identifiers as including descendants or ancestors.
2. Sets, types and instances. By flagging identifiers as @set, @type, @id differentiates 'members of a set' from 'instances of a type', from instances.
3. The latest/earliest problem. This problem is common in health query as many queries are designed to infer state from events. In main stream queries these are variously modelled as subqueries, correlated subqueries, window functions and sub collections. In IMQ these are simplified in line with a plain language question 'for things that have X within the last 6 months, get the latest X and test whether it is Y'

Query Structure

Query structure is a class model, normally serialized as JSON-LD. In the following sections, ABNF is used to illustrate the predicates (json names) as well as JSON-LD and CYPHER equivalent examples.

Query Request

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 request consists of an optional context (Json-LD) object, optional arguments and either a query or path query. In this example the query references a stored query via its IRI.

{
"@context" : {
  "im" : "http://endhealth.info/im#",
  "rdfs" : "http://www.w3.org/2000/01/rdf-schema#"
},
"argument": [
    {
      "parameter": "$referenceDate",
       "value": "2023-01-01"
    }],
"query" : {"@id" :"http://endhealth.info/query#GMSRegisteredPatients"}
 
}

Context - prefix Map

The format for data exchange is JSON-LD and thus a context object is supported, consisting of a prefix to expansion map. Only simple maps are required

for example

{
"@context" : {
  "im" : "http://endhealth.info/im#",
  "rdfs" : "http://www.w3.org/2000/01/rdf-schema#"
}
}

Arguments

An argument consists of a list of parameter value pairs i.e. the name of the parameter and its value as either a string, an iri or a list or list of IRIs.

In this example, this query is parameterised by the reference date and an IMQ data model property of shacl class (i.e. a placeholder for a property in a query) and a list of IRIs for ranges as place holders for values of the property.

{
  "argument": [
    {
      "parameter": "$referenceDate",
      "value": "2023-01-01"
    },
    {
      "parameter": "aProperty",
      "valueIri": {
        "@id": "sh:class"
      }
    },
    {
      "parameter": "aRange",
      "valueIriList": [
        {
          "@id": "xsd:integer"
        },
        {
          "@id": "xsd:string"
        }
      ]
    }
  ]
}

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 definition of a pre-existing query is obtained from the "has Definition" property of a stored query entity.

Predefined Query

For example, the following query request gets the results of a pre-defined query for gms registered patients with a reference date of January 2023

{
"argument" : [
 {"parameter" : "$referenceDate",
  "value" : "2023-0-01"
} ],
"query" : {"@id" :"http://endhealth.info/query#GMSRegisteredPatients"}
}

Query Clauses

IMQ considers a query to be a set of steps, each step starting from a graph and resulting in a sub graph which is then the starting point of the next step. Sub queries within the steps are used to supplement the graph with results of other queries. Unions are used to merge sub graphs. Steps can reference results of other steps.

A query definition consists of a list of 1 or more match clauses and an optional return clause. Optionally a query may have one or many queries acting as further queries on the instances identified by the first match clause.

In this simple example, a query request contains a query with a single match clause identifying all instances of type patient and returning their age in years.

The neo4j cypher equivalent is included

IMQ	CYPHER
{ "@context" : { "im" : "http://endhealth.info/im#" }, "argument": [{"parameter": "referenceDate","value" : "2023-01-01"}], "query" : { "match" : [ { "@type" : "im:Patient" } ], "return" : [ { "property" : [ { "@id" : "im:age", "as" : "age", "unit" : "years" } ] } ] } }	:params { "referenceDate": "2023-01-01" } MATCH (p:Patient) RETURN { id: p.id, age :duration.between(p.dateOfBirth, date($referenceDate)).years }

With the object result being a list of entities as instances of patients with their age

{
  "entities": [
    {
      "@id": "urn:uuid:232dfsdserw23",
      "age": 74
    },
    {
      "@id": "urn:uuid:232d34gerw23",
      "age": 76
    }
  ]
}

Match

Takes a graph and identifies a subset of the graph before returning results. The clause consists of node and relationship (path) mapping out a graph traversal of any depth. Property values of nodes can be filtered using a where clause.

A match consists of : a node identifier reference, an exclusion operator, a boolean and/or operator (for unions), and optional where clause and order by clause as well as the sub matches for any union.

Match is modelled using CYPHER principles and includes 'Where' as a property filter mechanism.

At run time Boolean OR match clauses would be considered UNIONs, and a match clause with an order by would be considered a sub query applying the optimised syntax for the target database language (e.g. correlated subquery, window function, init/compare etc)

In this example there is a simple match for a medicinal product or any of its descendants

IMQ	Expression constraint lnguage
{ "match": [ { "@id": "sn:763158003", "name": "MedicinalProduct", "descendantsOrSelfOf": true } ] }	<<763158003|Medicinal Product (product)|

Subsumption query

A key differentiator of IMQ from standard SQL is the support for a variety of subsumption (entailment) 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 a set of pages.

IMQ classes are a subset of the IM meta model classes i.e. set of plain data classes.

Grammar

This is the section on grammar