Health Information modelling language - overview: Difference between revisions

From Endeavour Knowledge Base
No edit summary
No edit summary
(21 intermediate revisions by the same user not shown)
Line 1: Line 1:
N.B Not to be confused with the [[Information model meta model|Information model meta model.]] which specifies the classes that hold the information model data, those classes described using the languages defined below
== Purpose and scope of the language==
== Purpose and scope of the language==


This article describes the languages used for creating querying and maintaining the information model, as well as the means by which health record queries can be defined in a system independent manner.
This article describes the languages used in the information model meta model. In other words, the underlying grammar and syntax used as the building bricks for the classes that make up the model, instances of those classes holding the model of information.


As the information model is an RDF graph, the modelling language uses the main stream semantic web languages. In addition there is a pragmatic json-LD based domain specific language for query definition which is based on a constraint of, and specialisation of, SPARQL with support for Graphql type queries.  
As the information model is an RDF graph, the modelling language uses the main stream semantic web languages with a small number of extensions to cope with the limitations of OWL.
 
Details on the W3C standard languages that make up the grammar are described below.


The language includes description logic, shape constraints, expression constraints, and a pragmatic approach to modelling query of real data.
The main reason these languages are used is to be able to exchange model data in an interoperable format without the need for any special parsers or applications. If a system can consume RDF in its two main syntaxes (turtle and Json-LD) then the model can be easily exchanged.


Details on the W3C standard languages that make up the grammar are described below.
The deliberate policy is to avoid using specialised health care so called "standards" such as HL7 or ENV-13606 or their bespoke subsets such as HL7-FHR or OpenEHR. These treat health data in a way that suggests health data is somehow different from data in general, which it is not.


It should be noted that these  are modelling languages, not the physical data schema or actual query. These are defined in the languages commensurate with the technology (e.g. sql)
RDF itself is a very simple language based on breaking down the description of the world into a phrase made up of a subject, a predicate, and an object, with an optional context of a 'graph' name, which can be used to indicate ownership of the triple, thus making up a quad.


The main purpose of a modelling language is to exchange data and information about [[Discovery health information model|information models]] in a way that machines can understand. It is not expected that clinicians would use the languages directly. The use of standard languages ensures that the models are interoperable across many domains including non health care domains.
Over time, some specialisations of the simple RDF language have been produced as W3C recommendations. This is achieved by the use of vocabularies, which themselves are RDF terms.


The languages cover the following areas:
The main advantage of RDF and the W3C standards is that types and properties are given internationally unique identifiers which are both humanly readable and can be resolved via the world wide web protocols.


# An ontology, which is a vocabulary and definitions of the concepts used in healthcare, or more simply put, a vocabulary of health. The ontology is made up of the world's leading ontology Snomed-CT, with a London extension and supplemented with additional concepts for data modelling.
Thus, in the information model, all classes,  properties and value types (subjects and predicates and objects) are IRIs which are defined by ontological techniques.
# A data model, which is a set of classes and properties, using the vocabulary, that represent the data and relationships as published by live systems that have published data to a data service that uses these models. Note that this data model is NOT a standard model but a collated set of entities and relationships bound to the concepts based on real data, that are mapped to a single model.
# A library of business specific concept and value sets, which are expression constraints on the ontology for the purpose of query
# A catalogue of reference data such as geographical areas, organisations and people derived and updated from public resources.
# A library of Queries for querying and extracting instance data from reference data or health records.
# A set of maps creating mappings between published concepts and the core ontology as well as structural mappings between submitted data and the data model.


== Contributory languages ==
== Contributory languages ==
Health data can be conceptualised as a graph, and thus the model is a graph model.
Health data can be conceptualised as a graph, and thus the model is a graph model.


When exchanging models using the language grammar both json-ld and turtle are supported as well as the more specialised syntaxes such as owl functional syntax or expression constraint language.
When exchanging models using the language grammar both Json-LD and turtle are supported as well as the more specialised syntaxes such as owl functional syntax or expression constraint language.


The modelling language is an amalgam of the following languages:
The modelling language is an amalgam of the following languages:


* [https://www.w3.org/TR/REC-rdf-syntax/ RDF.] An information model can be modelled as a Graph i.e. a set of nodes and edges (nodes and relationships, nodes and properties). Likewise, health data can be modelled as a graph conforming to the information model graph. RDF Forms the statements describing the data. RDF in itself holds no semantics whatsoever. i.e. it is not practical to infer or validate or query based purely on an RDF structure. To use RDF it is necessary to provide semantic definitions for certain predicates and adopt certain conventions. In providing those semantic definitions, the predicates themselves can then be used to semantically define many other things. RDF can be represented using either TURTLE syntax or JSON-LD.
* [https://www.w3.org/TR/REC-rdf-syntax/ RDF.] An information model can be modelled as a Graph i.e. a set of nodes and edges (nodes and relationships, nodes and properties). Likewise, health data can be modelled as a graph conforming to the information model graph. RDF Forms the statements describing the data. RDF in itself holds no semantics whatsoever. i.e. it is not practical to infer or validate or query based purely on an RDF structure. To use RDF it is necessary to provide semantic definitions for certain predicates and adopt certain conventions. In providing those semantic definitions, the predicates themselves can then be used to semantically define many other things. RDF can be represented using either TURTLE syntax or JSON-LD.
* [https://www.w3.org/TR/rdf-schema/ RDFS]. This is the first of the semantic languages. It is used for the purposes of some of the ontology axioms such as subclasses, domains and ranges as well as the standard annotation properties such as 'label'
* [https://www.w3.org/TR/rdf-schema/ RDFS]. This is the first of the semantic languages. It is used for the purposes of some of the ontology axioms such as subclasses, domains and ranges as well as the standard annotation properties such as 'label
* [https://www.w3.org/TR/owl2-primer/ OWL2 DL.]  For the ontology. This brings with it more sophisticated description logic such as equivalent classes and existential quantifications and is used in the ontology and for defining things when an open world assumption is required. This has contributed to the design of the IM languages but OWL is removed in the run time models.
* [https://www.w3.org/TR/shacl/ SHACL]. For the data models. Used for everything that defines the shape of data  or logical entities and attributes. Although SHACL is designed for validation of RDF, as SHACL describes what  things 'should be' it can be used as a data modelling language
* [https://www.w3.org/TR/sparql11-query/ SPARQL] Used as the logical means of querying model conformant data (not to be confused with the actual query language used which may be SQL)
*[[Information model query|IM Query Language]], used as a bridge between plain language and the mainstream query languages such as SQL or SPARQL


'''Example (OWL2)'''
*[https://www.w3.org/TR/shacl/ SHACL]. For the data models of types.  Used for everything that defines the shape of data  or logical entities and attributes. Although SHACL is designed for validation of RDF, as SHACL describes what  things 'should be' it can be used as a data modelling language


Consider a definition of chest pain
*[https://www.w3.org/TR/owl2-primer/ OWL2 DL.]  This is supported in the authoring phase, but is simplified within the model. This brings with it more sophisticated description logic such as equivalent classes and existential quantifications ,and is used in the ontology and for defining things when an open world assumption is required. This has contributed to the design of the IM languages but OWL is removed in the run time models with class expressions being replaced by RDFS subclass, and role groups.
*[https://confluence.ihtsdotools.org/display/DOCECL#:~:text=The%20Expression%20Constraint%20Language%20is,either%20precoordinated%20or%20postcoordinated%20expressions. ECL.] This is a specialised query language created for Snomed-CT, used  for simple concepts modelled as subtypes, role groups and roles, and is of great value in defining sets of concepts for the myriad of business purposes used in health.
*[https://confluence.ihtsdotools.org/display/DOCSCG/Compositional+Grammar+-+Specification+and+Guide SCG]. Snomed compositional grammar, created for Snomed-CT, which is a concise syntax for representing simple concepts modelled  as subtypes. role groups and roles and is a way of displaying concept definitions.
 
 
 
'''Example  multiple syntaxes and grammars'''
 
Consider a definition of chest pain in several syntaxes. Note that the OWL definition is in a form prior to classification whereas the others use the post classified structure (so called inferred)
<div class="toccolours mw-collapsible mw-collapsed">
Chest pain in Manchester syntax, SCG, ECL, OWL FS, IM Json-LD:
<div class="mw-collapsible-content">
<syntaxhighlight lang="turtle" style="border:3px solid grey">
<syntaxhighlight lang="turtle" style="border:3px solid grey">
Chest pain
# Definition of Chest pain in owl Manchester Syntax
  is Equivalent to : pain of truncated structure
  equivalentTo  sn:298705000 and sn:301366005 and (sn:363698007 sn:51185008)
                    and
 
                    has site : Thoracic structure  
#In RDF turtle
sn:29857009
  rdfs:subClassOf
        sn:301366005 ,
        sn:298705000;
  im:roleGroup [im:groupNumber "1"^^xsd:integer;
  sn:363698007 sn:51185008];
  rdfs:label "Chest pain (finding)" .
 
 
# In Snomed compositional grammar
=== 298705000 |Finding of region of thorax (finding)| +
    301366005 |Pain of truncal structure (finding)| :
            { 363698007 |Finding site (attribute)| = 51185008 |Thoracic structure (body structure)| }
 
# When using ECL to retrieve chest pain
<<298705000 |Finding of region of thorax (finding)| and  
    (<<301366005 |Pain of truncal structure (finding)| :
            { 363698007 |Finding site (attribute)| = 51185008 |Thoracic structure (body structure)| })
 
 
#When used in OL functional syntax
EquivalentClasses(
:29857009 |Chest pain (finding)|
ObjectIntersectionOf(
:22253000 |Pain (finding)|
ObjectSomeValuesFrom(
:609096000 |Role group (attribute)|
ObjectSomeValuesFrom(
:363698007 |Finding site (attribute)|
:51185008 |Thoracic structure (body structure)|
)
)
)
)
# In Json-LD
 
{
  "@id" : "sct:29857009",
  "rdfs:label" : "Chest pain (finding)",
  "im:definitionalStatus" : {"@id" : "im:1251000252106","name" : "Concept definition is sufficient (equivalent status)"},
  "rdfs:subClassOf" : [ {
    "@id" : "sct:301366005",
    "name" : "Pain of truncal structure (finding)"
  }, {
    "@id" : "sct:298705000",
    "name" : "Finding of region of thorax (finding)"
  } ],
  "im:roleGroup" : [ {
    "im:groupNumber" : 1,
    "sct:363698007" : [ {
      "@id" : "sct:51185008",
      "name" : "Thoracic structure (body structure)"
    } ]
  } ]
}
</syntaxhighlight>
</syntaxhighlight>
</div>
</div> <div class="mw-collapsible-content">&nbsp;</div>
== Query languages ==
For the information model to be used in any real sense, it must be queried. Two mainstream languages are used
*[https://www.w3.org/TR/sparql11-query/ SPARQL] Used as the logical means of querying model conformant data (not to be confused with the actual query language used which may be SQL). Used as the query language for the IM and mapped from IM Query Health queries would generally use SQL
*[https://opensearch.org/docs/latest/opensearch/query-dsl/index/ OpenSearch / Elastic.] Used for complex free text query for fining concepts using the AWS OpenSearch DSL (derivative of Lucene Query). Note that simple free text Lucene indexing is supported by the IM database engines and is used in combined graph/text query.
*[[Meta model class specification#Query .2FSet definition|IM Query.]] Not strictly a language but a class definition representing a scheme independent  way of defining sets (query results) including all the main health queries used by clinicians and analysts. 


== Grammars and syntaxes ==
== Grammars and syntaxes ==
Line 53: Line 123:
* A terse abbreviated language, TURTLE
* A terse abbreviated language, TURTLE


* SPARQL for query
* JSON-LD representation, which can  used by systems that prefer JSON (the majority) , and are able to resolve identifiers via the JSON-LD context structure.
 
* JSON-LD representation, which can  used by systems that prefer JSON, wish to use standard approaches,  and are able to resolve identifiers via the JSON-LD context structure.


'''Identifiers, aliasing  prefixes and context'''
'''Identifiers, aliasing  prefixes and context'''
Line 79: Line 147:
=== OWL2 and RDFS ===
=== OWL2 and RDFS ===


For the purposes of authoring and reasoning  the semantic ontology axiom and class expression vocabulary uses the tokens and structure from the OWL2 profile [https://www.w3.org/TR/owl2-profiles/#OWL_2_EL OWL EL], which itself is a sublanguage of the [https://www.w3.org/TR/owl2-syntax/ OWL2 language]
For the purposes of authoring and reasoning  the semantic ontology axiom and class expression vocabulary uses the tokens and structure from the OWL2 profile [https://www.w3.org/TR/owl2-profiles/#OWL_2_EL OWL EL] , which itself is a sublanguage of the [https://www.w3.org/TR/owl2-syntax/ OWL2 language]


In addition to the open world assumption of OWL, RDFS constructs of domain and ranges are used in a closed word manner.
In addition to the open world assumption of OWL, RDFS constructs of domain and ranges (OWL DL) but are are used in a closed word manner as RDFS.


Within an information model instance itself the data relationships are held on their post inferred closed form i.e. inferred properties and relationships are explicitly stated using a normalisation process to eliminate duplications from super types.  In other words, whereas an ontology may be authored using the open world assumption, prior to population of the live IM, classifications and inheritance are resolved. This uses the same approach as followed by Snomed-CT, whereby the inferred relationship containing the inherited properties and the "isa" relationship are included explicitly.
Within an information model instance itself the data relationships are held on their post inferred closed form i.e. inferred properties and relationships are explicitly stated using a normalisation process to eliminate duplications from super types.  In other words, whereas an ontology may be authored using the open world assumption, prior to population of the live IM, classifications and inheritance are resolved. This uses the same approach as followed by Snomed-CT, whereby the inferred relationship containing the inherited properties and the "isa" relationship are included explicitly.


In the live IM many these are replaced with the RDFS standard terms and simplified. For example OWL existential quantifications are mapped to "role groups" in line with Snomed-CT.
In the live IM OWL Axioms are replaced with the RDFS standard terms and simplified. For example OWL existential quantifications are mapped to "role groups" in line with Snomed-CT.


'''Use of Annotation properties'''
'''Use of Annotation properties'''
Line 170: Line 238:
|
|
|}
|}
<br />


=== SHACL shapes - data model ===
=== SHACL shapes ===
The shapes constraint language, as in the semantic ontology, the language borrows the constructs from the W3C standard SHACL, which can also be represented in any of the RDF supporting languages such as TURTLE or JSON-LD.
SHACL is used as a means of specifying the "data model types" of health record entities and also the IM itself as described directly in the [[Information model meta model#Meta model class specification|meta model article]].
 
SHACL is used in its standard form and is not extended.


'''Example'''
=== OWL extension : data property expressions ===
Within health care, (and in common parlance), data properties are often used as syntactical short cuts to objects with qualifiers  and a literal value element.


SHACL for part of Encounter record type data model, note that it is both a class and a shape so it is classified as a subclass of an event which means it inherits the properties of an event (such as effective date), but the super class "has concept" property has a range constrained to a London extension" which is the class of encounter types such as gp consultation.<syntaxhighlight lang="turtle">
For example, the data property "Home telephone number" would be expected to simply contain a number. But a home telephone number also has a number of properties by implication, such as the fact that its usage is "home", and has a country and area code.
im:Encounter
a sh:NodeShape , owl:Class;
    rdfs:label "Encounter (record type)" .
    im:isA im:Event ;
    im:status im:Active;
    rdfs:subClassOf im:PatientEvent;
   
    rdfs:comment "An interaction between a patient (or on behalf of the patient) and a health professional or health provider. It includes consultations as well as care processes such as admission, discharges. It also includes the noting of a filing of a document or report.";
   
    sh:property
          [sh:path im:additionalPractitioners;
          sh:class im:PractitionerInRole] ,
          [sh:path im:completionStatus;
          sh:class im:894281000252100] ,
          [sh:path im:duration;
          sh:minCount "1"^^xsd:integer;
          sh:class im:894281000252100] ,  
          [sh:path im:linkedAppointment;
          sh:class im:Appointment] ,
          [sh:path im:concept;
          sh:maxCount "1"^^xsd:integer;
          sh:minCount "1"^^xsd:integer;
          sh:class im:1741000252102]
        ......
       
</syntaxhighlight>


=== Query language ===
OWL 2 has a known limitation (as described in the OWL specification itself) in respect of data property expressions. OWL2 can only define data property expressions as data property IRIs with annotations.  
As the IM itself is held as RDF quads (triple+ graphs) the IM can be queried using SPARQL for graph query and Lucene query for text query. The IM manager also supports a full Elastic (AWS OpenSearch) index for advanced text queries.


But as the IM is designed to support query on actual health records (usually in relational format), the IM also has to enable SQL query.
In many health care standards such as HL7 FHIR, these data properties are object properties with the objects having the "value" as one of its properties..


Both SPARQL and SQL are complex specialised languages and to program using these languages the user must not only be a technical expert, but must have intimate knowledge of the RDF schema and /or the specific target health record schema.
For example, in FHIR  the patients home telephone number is carried explicitly as the property contact {property= telecom -> value =  {property use= Home, /property System= coding system,/ value = the actual number } } i.e. 3 ;levels of nesting.


Ordinary people express query concepts in plain language and most queries can be expressed using logical statements from plain language.  
Whilst explicit modelling is vital for information exchanged between systems with different data models, if stored in this way, queries would underperform, so the actual systems usually store the home telephone number perhaps in  a field "home telephone"  in the patient table or a simple triple.


IM employs a Json format domain specific language (DSL), that operates as an intermediary between plain language logical query statements, and the underlying query languages such as SQL or SPARQL.
To resolve the bridge between a complex object definition and simple data property the information model supports data property expressions (but without introducing a new language construct() as follows:


Even a DSL is highly technical so the IM also provides a user friendly application that enables a lay person to construct highly complex health queries without the need to understand  the query languages, or the technical storage formats of the IM.
# Simple data property against the class e.g. a "contact"
# Patient's home telephone number modelled as a ''sub property'' "homeTelephoneNumber with is a sub property of "telephone number", which is itself a sub property of "contact".
# A standard RDFS  property of the homeTelephone property entity - > "isDefinedBy" which points to a class expression which defines a home telephone number, (itself a subclass of a class expression TelephoneNumber) thus allowing all properties values to be "implicit but defined" as part of the ontology.


The approach to the design of IM Query is to take the various logical plain language patterns and map them directly to a DSL query format , and provide direct maps between the Json query DSL objects and the relevant SPARQL or SQL
By this technique subsumption queries that look for home contacts or home telephone numbers or find numbers with US country codes will find the relevant field and the relevant sub pattern of a data property..


IM query is specified more fully in the article on [[information model query]]
Implementations would still need to parse numbers to properties if they stored numbers as simple numbers but these would be part of a data model map against the IM models definition.


=== Form generator ===
== Information model meta classes ==
In order to maintain and edit the content of the information model there is a need to be able to build forms that enable something to be edited. Examples of things to edit are concepts, value sets, concept sets, queries (of the IM) , data models and maps.
See main article [[Information model meta model|Information model meta classes]]


The information model language uses an extension to SHACL shapes to enable form generation. Another way of putting it is that SHACL shapes define the structure and content of data, whereas a form generator provides instructions as to how a particular shape could be hand authored.
Using the above languages this defines the classes used to model all health data.


The language does not dictate the style or technology used in forms, only the things which a form based application would need when generating components on the screen.


The form generator language vocabulary and how it may be used is documented on the article on information model [[form generator language]]


== Language Grammar documentation ==
<br />

Revision as of 10:35, 11 October 2022

N.B Not to be confused with the Information model meta model. which specifies the classes that hold the information model data, those classes described using the languages defined below

Purpose and scope of the language

This article describes the languages used in the information model meta model. In other words, the underlying grammar and syntax used as the building bricks for the classes that make up the model, instances of those classes holding the model of information.

As the information model is an RDF graph, the modelling language uses the main stream semantic web languages with a small number of extensions to cope with the limitations of OWL.

Details on the W3C standard languages that make up the grammar are described below.

The main reason these languages are used is to be able to exchange model data in an interoperable format without the need for any special parsers or applications. If a system can consume RDF in its two main syntaxes (turtle and Json-LD) then the model can be easily exchanged.

The deliberate policy is to avoid using specialised health care so called "standards" such as HL7 or ENV-13606 or their bespoke subsets such as HL7-FHR or OpenEHR. These treat health data in a way that suggests health data is somehow different from data in general, which it is not.

RDF itself is a very simple language based on breaking down the description of the world into a phrase made up of a subject, a predicate, and an object, with an optional context of a 'graph' name, which can be used to indicate ownership of the triple, thus making up a quad.

Over time, some specialisations of the simple RDF language have been produced as W3C recommendations. This is achieved by the use of vocabularies, which themselves are RDF terms.

The main advantage of RDF and the W3C standards is that types and properties are given internationally unique identifiers which are both humanly readable and can be resolved via the world wide web protocols.

Thus, in the information model, all classes, properties and value types (subjects and predicates and objects) are IRIs which are defined by ontological techniques.

Contributory languages

Health data can be conceptualised as a graph, and thus the model is a graph model.

When exchanging models using the language grammar both Json-LD and turtle are supported as well as the more specialised syntaxes such as owl functional syntax or expression constraint language.

The modelling language is an amalgam of the following languages:

  • RDF. An information model can be modelled as a Graph i.e. a set of nodes and edges (nodes and relationships, nodes and properties). Likewise, health data can be modelled as a graph conforming to the information model graph. RDF Forms the statements describing the data. RDF in itself holds no semantics whatsoever. i.e. it is not practical to infer or validate or query based purely on an RDF structure. To use RDF it is necessary to provide semantic definitions for certain predicates and adopt certain conventions. In providing those semantic definitions, the predicates themselves can then be used to semantically define many other things. RDF can be represented using either TURTLE syntax or JSON-LD.
  • RDFS. This is the first of the semantic languages. It is used for the purposes of some of the ontology axioms such as subclasses, domains and ranges as well as the standard annotation properties such as 'label
  • SHACL. For the data models of types. Used for everything that defines the shape of data or logical entities and attributes. Although SHACL is designed for validation of RDF, as SHACL describes what things 'should be' it can be used as a data modelling language
  • OWL2 DL. This is supported in the authoring phase, but is simplified within the model. This brings with it more sophisticated description logic such as equivalent classes and existential quantifications ,and is used in the ontology and for defining things when an open world assumption is required. This has contributed to the design of the IM languages but OWL is removed in the run time models with class expressions being replaced by RDFS subclass, and role groups.
  • ECL. This is a specialised query language created for Snomed-CT, used for simple concepts modelled as subtypes, role groups and roles, and is of great value in defining sets of concepts for the myriad of business purposes used in health.
  • SCG. Snomed compositional grammar, created for Snomed-CT, which is a concise syntax for representing simple concepts modelled as subtypes. role groups and roles and is a way of displaying concept definitions.


Example multiple syntaxes and grammars

Consider a definition of chest pain in several syntaxes. Note that the OWL definition is in a form prior to classification whereas the others use the post classified structure (so called inferred)

Chest pain in Manchester syntax, SCG, ECL, OWL FS, IM Json-LD:

# Definition of Chest pain in owl Manchester Syntax
 equivalentTo  sn:298705000 and sn:301366005 and (sn:363698007 sn:51185008)

#In RDF turtle
sn:29857009
   rdfs:subClassOf 
         sn:301366005 , 
         sn:298705000;
   im:roleGroup [im:groupNumber "1"^^xsd:integer;
   sn:363698007 sn:51185008];
   rdfs:label "Chest pain (finding)" .


# In Snomed compositional grammar
=== 298705000 |Finding of region of thorax (finding)| + 
    301366005 |Pain of truncal structure (finding)| :
            { 363698007 |Finding site (attribute)| = 51185008 |Thoracic structure (body structure)| }

# When using ECL to retrieve chest pain
<<298705000 |Finding of region of thorax (finding)| and 
    (<<301366005 |Pain of truncal structure (finding)| :
            { 363698007 |Finding site (attribute)| = 51185008 |Thoracic structure (body structure)| })


#When used in OL functional syntax
EquivalentClasses(
	:29857009 |Chest pain (finding)|
	ObjectIntersectionOf(
		:22253000 |Pain (finding)|
		ObjectSomeValuesFrom(
			:609096000 |Role group (attribute)|
			ObjectSomeValuesFrom(
				:363698007 |Finding site (attribute)|
				:51185008 |Thoracic structure (body structure)|
			)
		)
	)
)
# In Json-LD

{
  "@id" : "sct:29857009",
  "rdfs:label" : "Chest pain (finding)",
  "im:definitionalStatus" : {"@id" : "im:1251000252106","name" : "Concept definition is sufficient (equivalent status)"},
  "rdfs:subClassOf" : [ {
    "@id" : "sct:301366005",
    "name" : "Pain of truncal structure (finding)"
  }, {
    "@id" : "sct:298705000",
    "name" : "Finding of region of thorax (finding)"
  } ],
  "im:roleGroup" : [ {
    "im:groupNumber" : 1,
    "sct:363698007" : [ {
      "@id" : "sct:51185008",
      "name" : "Thoracic structure (body structure)"
    } ]
  } ]
}
 

Query languages

For the information model to be used in any real sense, it must be queried. Two mainstream languages are used

  • SPARQL Used as the logical means of querying model conformant data (not to be confused with the actual query language used which may be SQL). Used as the query language for the IM and mapped from IM Query Health queries would generally use SQL
  • OpenSearch / Elastic. Used for complex free text query for fining concepts using the AWS OpenSearch DSL (derivative of Lucene Query). Note that simple free text Lucene indexing is supported by the IM database engines and is used in combined graph/text query.
  • IM Query. Not strictly a language but a class definition representing a scheme independent way of defining sets (query results) including all the main health queries used by clinicians and analysts.

Grammars and syntaxes

Foundation syntaxes - RDF, TURTLE and JSON-LD

Discovery language has its own Grammars built on the foundations of the W3C RDF grammars:

  • A terse abbreviated language, TURTLE
  • JSON-LD representation, which can used by systems that prefer JSON (the majority) , and are able to resolve identifiers via the JSON-LD context structure.

Identifiers, aliasing prefixes and context

Concepts are identified and referenced by the use of International resource identifiers (IRIs).

Identifiers are universal and presented in one of the following forms:

  1. Full IRI (International resource identifier) which is the fully resolved identifier encompassed by <>
  2. Abbreviated IRI a Prefix followed by a ":" followed by the local name which is resolved to a full IRI
  3. Aliases. The core language tokens (that are themselves concepts) have aliases for ease of use. For example rdfs:subClassOf is aliased to subClassOf,

There is of course nothing to stop applications using their own aliases and when used with JSON-LD @context may be used to enable the use of aliases.

Data is considered to be linked across the world, which means that IRIs are the main identifiers. However, IRIs can be unwieldy to use and some of the languages such as GRAPH-QL do not use them. Furthermore, when used in JSON, (the main exchange syntax via APIs) they can cause significant bloat. Also, identifiers such as codes or terms have often been created for local use in local single systems and in isolation are ambiguous.

To create linked data from local identifiers or vocabulary, the concept of Context is applied. The main form of context in use are:

  1. PREFIX declaration for IRIs, which enable the use of abbreviated IRIs. This approach is used in OWL, RDF turtle, SHACL and Discovery itself.
  2. VOCABULAR CONTEXT declaration for both IRIs and other tokens. This approach is used in JSON-LD which converts local JSON properties and objects into linked data identifiers via the @context keyword. This enables applications that know their context to use simple identifiers such as aliases.
  3. MAPPING CONTEXT definitions for system level vocabularies. This provides sufficient context to uniquely identify a local code or term by including details such as the health care provider, the system and the table within a system. In essence a specialised class with the various property values making up the context.

OWL2 and RDFS

For the purposes of authoring and reasoning the semantic ontology axiom and class expression vocabulary uses the tokens and structure from the OWL2 profile OWL EL , which itself is a sublanguage of the OWL2 language

In addition to the open world assumption of OWL, RDFS constructs of domain and ranges (OWL DL) but are are used in a closed word manner as RDFS.

Within an information model instance itself the data relationships are held on their post inferred closed form i.e. inferred properties and relationships are explicitly stated using a normalisation process to eliminate duplications from super types. In other words, whereas an ontology may be authored using the open world assumption, prior to population of the live IM, classifications and inheritance are resolved. This uses the same approach as followed by Snomed-CT, whereby the inferred relationship containing the inherited properties and the "isa" relationship are included explicitly.

In the live IM OWL Axioms are replaced with the RDFS standard terms and simplified. For example OWL existential quantifications are mapped to "role groups" in line with Snomed-CT.

Use of Annotation properties

Annotation properties are the properties that provide information beyond that needed for reasoning.  They form no part in the ontological reasoning, but without them, the information model would be impossible for most people to understand. 

Typical annotation properties are names and descriptions.

Owl construct usage examples IM live conversion
Class An entity that is a class concept e.g. A snomed-ct concept or a general concept rdfs:Class
ObjectProperty 'hasSubject' (an observation has a subject that is a patient) rdf:Property
DataProperty 'dateOfBirth' (a patient record has a date of birth attribute owl:dataTypeProperty
annotationProperty 'description' (a concept has a description)
SubClassOf Patient is a subclass of a Person rdfs:subClassOf
Equivalent To Adverse reaction to Atenolol is equivalent to An adverse reaction to a drug AND has causative agent of Atenolol (substance) rdfs:subClassOf


Sub property of has responsible practitioner is a subproperty of has responsible agent rdfs:subPropertyOf
Property chain is sibling of'/ 'is parent of' / 'has parent' is a sub property chain of 'is first cousin of' owl:Property chain
Existential quantification ( ObjectSomeValuesFrom) Chest pain and

Finding site of - {some} thoracic structure

im:roleGroup
Object Intersection Chest pain is equivalent to pain of truncal structure AND finding in region of thorax AND finding site of thoracic structure rdfs:Subclass

+

role groups

DataType definition Date time is a restriction on a string with a regex that allows approximate dates
Property domain a property domain of has causative agent is allergic reaction rdfs:domain
Property range A property range of has causative agent is a substance rdfs:range
Annotation Meaning
rdfs:label The name or term for an entity
rdfs:comment the description of an entity

SHACL shapes

SHACL is used as a means of specifying the "data model types" of health record entities and also the IM itself as described directly in the meta model article.

SHACL is used in its standard form and is not extended.

OWL extension : data property expressions

Within health care, (and in common parlance), data properties are often used as syntactical short cuts to objects with qualifiers and a literal value element.

For example, the data property "Home telephone number" would be expected to simply contain a number. But a home telephone number also has a number of properties by implication, such as the fact that its usage is "home", and has a country and area code.

OWL 2 has a known limitation (as described in the OWL specification itself) in respect of data property expressions. OWL2 can only define data property expressions as data property IRIs with annotations.

In many health care standards such as HL7 FHIR, these data properties are object properties with the objects having the "value" as one of its properties..

For example, in FHIR the patients home telephone number is carried explicitly as the property contact {property= telecom -> value = {property use= Home, /property System= coding system,/ value = the actual number } } i.e. 3 ;levels of nesting.

Whilst explicit modelling is vital for information exchanged between systems with different data models, if stored in this way, queries would underperform, so the actual systems usually store the home telephone number perhaps in a field "home telephone" in the patient table or a simple triple.

To resolve the bridge between a complex object definition and simple data property the information model supports data property expressions (but without introducing a new language construct() as follows:

  1. Simple data property against the class e.g. a "contact"
  2. Patient's home telephone number modelled as a sub property "homeTelephoneNumber with is a sub property of "telephone number", which is itself a sub property of "contact".
  3. A standard RDFS property of the homeTelephone property entity - > "isDefinedBy" which points to a class expression which defines a home telephone number, (itself a subclass of a class expression TelephoneNumber) thus allowing all properties values to be "implicit but defined" as part of the ontology.

By this technique subsumption queries that look for home contacts or home telephone numbers or find numbers with US country codes will find the relevant field and the relevant sub pattern of a data property..

Implementations would still need to parse numbers to properties if they stored numbers as simple numbers but these would be part of a data model map against the IM models definition.

Information model meta classes

See main article Information model meta classes

Using the above languages this defines the classes used to model all health data.