This article describes a language used for creating information models used in health records, as well as the means by which health record queries can be defined in a system independent manner.

For those familiar with the semantic web languages, it is safe to assume that the language described herein is simply a dialect (or profile) of the standard W3C recommendations of RDF, RDFS, OWL2, SHACL and SPARQL. The profile is designed to simplify implementations of the model and to constrain it’s features to ensure relevance and optimum performance.

The language is designed to support an information model conceived as a graph and thus implementation of the model and related health data are represented logically as a graph.

Before tackling the language it is worth reading the article on [[Health Information modelling|information modelling.]]

 
== Purpose background and rationale ==
Question: Yet another language? Surely not.

Answer: No, not at all. What can be stated though is that it is not a health domain language. It is a language used commonly across all sectors across the world, applied to the health and social care domain.

One of the ambitions of the language is to free the representation of health data from the modelling silos within healthcare itself. This is based on the principle that the only difference between health data and other data is the vocabulary and ontologies used.

The language is used to enable the information model to be readable by machines. The language covers all areas of the model and uses different grammars for the different approaches.

# 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.
# 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, 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.
# An open source set of utilities that can be used to browse, search, or maintain the model.
# A modelling language using the World wide web semantic languages that can be used to exchange all elements of the model.

The main purpose of a modelling language is to exchange data and information about [[Discovery health information model|information models]] in a way that both machines and humans can understand. A language must be able to describe the types of structures that make up an information model as can be seen on the right. Diagrams and pictures are all very well, but they cannot be used by machines.

It is necessary to support both human and machine readability so that a model can be validated both by humans and computers. Humans can read diagrams or text. Machines can read data bits. The two forms can be brought together as a stream of characters forming a language.

A purely human based language would be ambiguous, as all human languages are. A language that is both can be used to promote a shared understanding of often complex structures whilst enabling machines to process data in a consistent way.

It is almost always the case that a very precise machine readable language is hard for humans to follow and that a human understandable language is hard to compute consistently. As a compromise, many languages are presented in a variety of grammars and syntaxes, each targeted at different readers. The language in this article all adopt a multi-grammar approach in line with this dual purpose.

Multi grammars are the norm in computer languages. Different software implementations use different technologies and different grammars are needed. The crucial point is that for systems to interoperate effectively, the different grammars must mean the same thing in the end, they are just presented in different ways with different syntaxes.

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

The language must be both human and machine readable in text form.

The language must use the recognisable plain language characters in UTF-8. For human readability the characters read from left to right and for machine readability a graph is a character stream from beginning to end.

Two grammars are required; one for human legibility, and the other for optimised machine processing. However, both must be human and machine readable.

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/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.] 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
* [https://www.w3.org/TR/shacl/ SHACL]. Used for everything that defines the shape of data where a closed world assumption is required. 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)

A model presented in the human legible grammar must be translatable directly to the machine representation without loss of semantics. In the ensuing paragraphs the human optimised grammar is illustrated but in the final language specification both are presented side by side to illustrate semantic translatability.

'''Example (OWL2)'''

Consider a definition of a grandfather, in the first example the grandfather is an equivalent to a person who is male ''and'' has children who are people that must have children.

using the turtle language
<syntaxhighlight lang="turtle" style="border:3px solid grey">
:Grandfather
owl:EquivalentClass [
owl:intersectionOf
:Person,
[owl:onProperty :hasGender;
owl:somValuesFrom :Male],
[owl:onProperty :hasChild;
owl:somValuesFrom [owl:intersectionOf
:Person,
[owl:onProperty :hasChild;
owl:someValuesFrom :Person] ) ])
.
</syntaxhighlight>

JSON is a popular syntax currently and thus this is used as an alternative.

JSON represents subjects , predicates and objects as object names and values with values being either literals or or objects.

JSON itself has no inherent mechanism of differentiating between different types of entities and therefor JSON-LD is used. In JSON-LD identifiers resolve initially to @id and the use of @context enables prefixed IRIs and aliases.

The above Grandfather can be represented in JSON-LD (context not shown) as follows:<syntaxhighlight lang="json-ld" style="border:3px solid grey">
{"@id" : ":Grandfather",
"owl:EquivalentClass" : [
{"owl:intersectionOf" :[
{ "@id": "Person"},
{ "owl:onProperty" : ":hasGender",
"owl:somValuesFrom": {"@id":"Male"}},

{ "owl:onProperty" : ":hasChild",
"owl:somveValuesFrom" : {
"owl:intersectionOf": [
{ "@id":"Person"},
{"owl:onProperty" : ":hasChild",
"owl:someValuesFrom" : {"@id":"Person"}}]]}}
</syntaxhighlight>

== Sublanguages and syntaxes ==

=== Foundation grammars and 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

* SPARQL for query

* 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.
*Proprietary JSON based object serializable grammar. This directly maps to the internal class structures used in Discovery and can be used by client applications that have a strong contract with a server.

=== Identifiers aliasing 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:

# Full IRI (International resource identifier) which is the fully resolved identifier encompassed by <>
# Abbreviated IRI a Prefix followed by a ":" followed by the local name which is resolved to a full IRI
#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:

# PREFIX declaration for IRIs, which enable the use of abbreviated IRIs. This approach is used in OWL, RDF turtle, SHACL and Discovery itself.
# 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.
# 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.

The following is an example of the use of the prefix directives for IRIs and to define aliases for some of the owl and rdfs tokens <pre style="background-color:#fcfaee">
@prefix : <http://www.DiscoveryDataService.org/InformationModel/Ontology#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#>.
@prefix sn: <ttp://snomed.info/sct#>.

rdfs:subClassOf :alias ("subClassOf").

owl:Class :alias ("Class").

:alias
a owl:DatatypeProperty;
<http://www.DiscoveryDataService.org/InformationModel/Ontology#alias>
("alias").

rdfs:label
a owl:annotationProperty;
:alias ("name" "label") .

owl:DataTypeProperty
a owl:DataTypeProperty;
:alias ("dataProperty") .
</pre>As the aliases are defined they can now be used in an abbreviated Turtle syntax, as well as the standard turtle syntax. For example, the following Snomed-CT code is defined as a class and a subclass of another Snomed-CT code. <pre style="background-color:#fcfaee">
sn:407708003
a Class;
name : "Sample appearance (observable entity)";
subClassOf sn:407708003.
</pre>

A JSON-LD equivalent of the above uses context to cover prefixes and aliases in a simpler manner <syntaxhighlight lang="jsonld">
"@context" : {

"alias" : {
"@id" : "http://www.DiscoveryDataService.org/InformationModel/Ontology#alias",
"@type" : "@id"
},
"@base" : "http://www.DiscoveryDataService.org/InformationModel/Ontology#",
"" : "http://www.DiscoveryDataService.org/InformationModel/Ontology#",
"rdf" : "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"sh" : "http://www.w3.org/ns/shacl#",
"owl" : "http://www.w3.org/2002/07/owl#",
"xsd" : "http://www.w3.org/2001/XMLSchema#",
"rdfs" : "http://www.w3.org/2000/01/rdf-schema#"
}
</syntaxhighlight>Resulting in the standard JSON-ld context based approach: <syntaxhighlight lang="jsonld">
{"@id" : "sn:12345",
"@type" : "owl:Class",
"subClassOf" : "sn:34568"
}
</syntaxhighlight>

=== Ontology - OWL2 DL ===

For the purposes of 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]

However, in addition some standard OWL2 DL axioms are used in order to provide a means of specifying additional relationships that are of value when defining relationships. The following table lists the main owl types used and example for each. Note that their aliases are used for brevity. Please refer to the OWL2 specification to describe their meanings
{| class="wikitable"
|+
!Owl construct
!usage examples
|-
|Class
|An entity that is a class concept e.g. A snomed-ct concept or a general concept
|-
|ObjectProperty
|'hasSubject' (an observation '''has a subject''' that is a patient)
|-
|DataProperty
|'dateOfBirth' (a patient record has a date of birth attribute
|-
|annotationProperty
|'description' (a concept has a description)
|-
|SubClassOf
|Patient is a subclass of a Person
|-
|Equivalent To
|Adverse reaction to Atenolol is equivalent to An adverse reaction to a drug AND has causative agent of Atenolol (substance)
|-
|Disjoint with
|Father is disjoint with Mother
|-
|Sub property of
|has responsible practitioner is a subproperty of has responsible agent
|-
|Property chain
|is sibling of'/ 'is parent of' / 'has parent' is a sub property chain of 'is first cousin of'
|-
|Inverse property
|is subject of is inverse of has subject
|-
|Transitive property
|is child of is transitive
|-
|Existential quantification
|Chest pain and
Finding site of - {some} thoracic structure
|-
|Object Intersection
|Chest pain is equivalent to pain of truncal structure AND finding in region of thorax AND finding site of thoracic structure
|-
|Individual
|All chest pain subclasses but not the specific i''nstance of acute chest pain''
|-
|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
|-
|Property range
|A property range of has causative agent is a substance
|}

==== The ubiquitous ISA and inferred views. ====
OWL has a number of ways of handling sub types. The axioms "subclass of", "sub property of" or "equivalent class" indicate sub types. In the information model, in line with Snomed-CT the predicate "is a" is used as a supertype in order to simplify the sub typing. In addition, 'is a' assumes that the ontology is classified i.e. from the stated axioms, a subtype hierarchy has been produced by a reasoner, and it is the sub type hierarchy that 'is a' refers to.

In other words, for every subclass or equivalent class stated axiom an 'is a' relationship is generated, and this is used throughout the model when using query.

Similarly, when querying for properties, the stated axioms can create complex sub property and sub range logic. Consequently, the 'inferred view' is assumed in query i.e. where a descendant concept inherits its properties directly, unless overridden by sub properties.

In practical implementation of the IM both isa and inferred properties are explicitly modelled as direct relationships enabling the ontology to be queries without the need for axioms within the query itself.

==== Use of Annotation properties for original codes====
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. Annotation properties can also be used for implementation supporting properties such as release status, version control, authoring dates and times and so on. 

Typical annotation properties are names and descriptions. They are also used as meta data such as a status of a concept or the version of a document.

Many concepts are derived directly from source systems that used them as codes, or even free text.

The concept indicates the source and original code or text (or combination) in the form actually entered into the source system. It should be noted that many systems do not record codes exactly as determined by an official classification or provide codes via mappings from an internal id.  It is the codes or text used from the publishers perspective that  is used as the source.

Thus in many cases, it is convenient to auto generate a code, which is then placed as the value of the “code” property in the concept, together with the scheme. From this, the provenance of the code can be inferred.

Each code must have a scheme. A scheme may be an official scheme or  proprietary scheme or a local scheme related to a particular sub system.

For example, here are some scheme/ code combinations
{| class="MsoTableGrid"
|-
| width="109" |Scheme
| width="316" |Original Code/Text/Context
| width="106" |Concept code/ Auto code
| width="224" |Meaning
|-
| width="109" |Snomed-CT           
| width="316" |47032000        
| width="106" |47032000        
| width="224" |Primary hydrocephaly
|-
| width="109" |EMIS- Read
| width="316" |H33-1  
| width="106" |H33-1  
| width="224" |Bronchial asthma
|-
| width="109" |EMIS – EMIS
| width="316" |EMISNQCO303
| width="106" |EMLOC_EMISNQCO303
| width="224" |Confirmed corona virus infection
|-
| width="109" |Barts/Cerner
| width="316" |Event/Order=687309281
| width="106" |BC_687309281
| width="224" |Tested for Coronavirus (misuse of code term in context)
|-
| width="109" |Barts/Cerner
| width="316" |Event/Order= 687309281/ResultTxt= SARS-CoV-2 RNA DETECTED
| width="106" |BC_dsdsdsdx7
| width="224" |Positive coronavirus result

 
|}Note that in the last example, the original code is actually text and has been contextualised as being from the Cerner event table, the order field having a value of 687309281 and the result text having a value of ResultTxt= SARS-CoV-2 RNA DETECTED

=== Data model ===
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.

'''Example'''

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">
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>

=== Set definitions ===
In line with expression constraint language, defining a set is a query over the ontology resulting in a set of concepts to use in a subsequent query.

The information model uses SHACL to define the set meta data (e.g. the name of the set, the fact that it is a set etc) and SPARQL for the expression constraint.

SHACL has the idea of "focus node" which is an RDF node that the shape wishes to validate. As the focus node of a set are all members of the class of concept, then there has to be a way of narrowing down the nodes from the millions of concepts. SHACL has the idea of 'custom target' which is a filter applied to the graph. A typical custom target is a SPARQL target and therefore a SPARQL target is used to specify the constraint.

==== Example - complex set ====
Lets say a commissioner needs to know who the patients are that have had Covid vaccines.

Covid vaccines are recorded either as immunisation records, or medication records, or both. To query the medication records, a set of vaccine medication concepts are searched for, these being stored in medication order record entries. Covid vaccines change every few weeks as new brands or strengths are released.

A definition of a covid vaccine is helpful, thus a concept set is defined.
 <syntaxhighlight lang="turtle">
im:CSET_CVSMeds
a im:ConceptSet,sh:NodeShape;
rdfs:label "Covid vaccine study medication set";
sh:target [ #Custom target for the shape
sh:targetType sh:SPARQLTarget; #Focus nodes are sparql results
sh:select """
Select ?this #Select concept
Where { #where the concept is….
{?this im:isA sn:39330711000001103} # is a Covid vaccine
UNION #or (
{?this im:isA sn:10363601000001109. # is a uk product
#and
?this sn:10362601000001103 sn:10362601000001103} } #has vmp Covd vaccine)

"""
].
</syntaxhighlight>The above states that a covid vaccine must be a subtype of either

a) a covid vaccine product

OR

b) a UK product and which is both an actual product which is a covid vaccine virtual medicinal product.

Note the direct use of inferred 'is a' and property restrictions, avoiding the need for complex axiom

==== Example Set with exclusion ====
It is common to remove certain subclasses. OWL Object complement cannot be used for this due to the open world assumption.

Exclusion assumes something to exclude against (i.e. a set of things from which to exclude)

Let us assume that we define an event type of 'procedure' and we model a procedure as having a property of 'concept' whose range is the class of procedures as defined by Snomed-CT. Within Snomed-CT, immunisations are also classified as procedures but within the data model they are classified as immunisations. Consequently in the procedure value set we wish to exclude immunisations.<syntaxhighlight lang="turtle">

im:VSET_Category_Procedures
a im:ValueSet, sh:NodeShape;
rdfs:label "Value set - Procedures" ;
sh:target [ #Custom target for the shape
sh:targetType sh:SPARQLTarget; #Focus nodes are sparql results
sh:select """
Select ?this
Where {
?this im:isA sn:71388002. # is a procedure
MINUS {
?this im:isa ?exclusions #Minus is a exclusions
VALUES ?exclusions { sn:33879002 sn:51116004 } #which are vaccination, passive immunisation
} } """
]

</syntaxhighlight> 
=== Data mapping and matching ===

This part of the language is used to define mappings between the data model and an actual schema to enable query and filers to automatically cope with the ever extending ontology and data properties. 

The processes involved in mapping and matching concepts are described in the article on [[Mapping and matching concepts|mapping of concepts codes and structures]]

=== Query ===
It is fair to say that data modelling and semantic ontology is useless without the means of query.

The current approach to the specification of query uses the GRAPHQL approach with type extensions and directive extensions.

Graph QL , (despite its name) is not in itself a query language but a way of representing the graph like structure of a underlying model that has been built using OWL. GRAPH QL has a very simple class property representation, is ideal for REST APIs and results are JSON objects in line with the approach taken by the above Discovery syntax.

Nevertheless, GRAPHQL considers properties to be functions (high order logic) and therefore properties can accept parameters. For example, a patient's average systolic blood pressure reading could be considered a property with a single parameter being a list of the last 3 blood pressure readings. Parameters are types and types can be created and extended.

In addition GRAPHQL supports the idea of extensions of directives which further extend the grammar.

Thus GRAPHQL capability is extended by enabling property parameters as types to support such things as filtering, sorting and limiting in the same way as an.y other query language by modelling types passed as parameters. Subqueries are then supported in the same way.

GRAPHQL itself is used when the enquirer is familiar with the local logical schema i.e. understands the available types and fields. In order to support semantic web concepts an extension to GRAPHQL, GRAPHQL-LD is used, which is essentially GRAPH-QL with JSON-LD context.

GRAPH QL-LD has been chosen over SPARQL for reasons of simplicity and many now consider GRAPHQL to be a de-facto standard. However, this is an ongoing consideration.

=== ABAC language ===
''Main article : [[Attribute based access control|ABAC Language]]''

The Discovery attribute based access control language is presented as a pragmatic JSON based profile of the XACML language, modified to use the information model query language (SPARQL) to define policy rules. ABAC attributes are defined in the semantic ontology in the same way as all other classes and properties.

The language is used to support some of the data access authorisation processes as described in the specification - [[Identity Authentication Authorisation|Identity, authentication and authorisation]] .

This article specifies the scope of the language , the grammar and the syntax, together with examples. Whilst presented as a JSON syntax, in line with other components of the information modelling language, the syntax can also be accessed via the ABAC xml schema which includes the baseline Information model XSD schema on the Endeavour GitHub, and example content viewed in the information manager data files folder

Health Information modelling language - overview

2021-09-26T10:25:21Z

DavidStables:

This article describes a language used for creating information models used in health records, as well as the means by which health record queries can be defined in a system independent manner.

For those familiar with the semantic web languages, it is safe to assume that the language described herein is simply a dialect (or profile) of the standard W3C recommendations of RDF, RDFS, OWL2, SHACL and SPARQL. The profile is designed to simplify implementations of the model and to constrain it’s features to ensure relevance and optimum performance.

The language is designed to support an information model conceived as a graph and thus implementation of the model and related health data are represented logically as a graph.

Before tackling the language it is worth reading the article on [[Health Information modelling|information modelling.]]

 
== Purpose background and rationale ==
Question: Yet another language? Surely not.

Answer: No, not at all. What can be stated though is that it is not a health domain language. It is a language used commonly across all sectors across the world, applied to the health and social care domain.

One of the ambitions of the language is to free the representation of health data from the modelling silos within healthcare itself. This is based on the principle that the only difference between health data and other data is the vocabulary and ontologies used.

The language is used to enable the information model to be readable by machines. The language covers all areas of the model and uses different grammars for the different approaches.

# 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.
# 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, 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.
# An open source set of utilities that can be used to browse, search, or maintain the model.
# A modelling language using the World wide web semantic languages that can be used to exchange all elements of the model.

The main purpose of a modelling language is to exchange data and information about [[Discovery health information model|information models]] in a way that both machines and humans can understand. A language must be able to describe the types of structures that make up an information model as can be seen on the right. Diagrams and pictures are all very well, but they cannot be used by machines.

It is necessary to support both human and machine readability so that a model can be validated both by humans and computers. Humans can read diagrams or text. Machines can read data bits. The two forms can be brought together as a stream of characters forming a language.

A purely human based language would be ambiguous, as all human languages are. A language that is both can be used to promote a shared understanding of often complex structures whilst enabling machines to process data in a consistent way.

It is almost always the case that a very precise machine readable language is hard for humans to follow and that a human understandable language is hard to compute consistently. As a compromise, many languages are presented in a variety of grammars and syntaxes, each targeted at different readers. The language in this article all adopt a multi-grammar approach in line with this dual purpose.

Multi grammars are the norm in computer languages. Different software implementations use different technologies and different grammars are needed. The crucial point is that for systems to interoperate effectively, the different grammars must mean the same thing in the end, they are just presented in different ways with different syntaxes.

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

The language must be both human and machine readable in text form.

The language must use the recognisable plain language characters in UTF-8. For human readability the characters read from left to right and for machine readability a graph is a character stream from beginning to end.

Two grammars are required; one for human legibility, and the other for optimised machine processing. However, both must be human and machine readable.

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/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.] 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
* [https://www.w3.org/TR/shacl/ SHACL]. Used for everything that defines the shape of data where a closed world assumption is required. 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)

A model presented in the human legible grammar must be translatable directly to the machine representation without loss of semantics. In the ensuing paragraphs the human optimised grammar is illustrated but in the final language specification both are presented side by side to illustrate semantic translatability.

'''Example (OWL2)'''

Consider a definition of a grandfather, in the first example the grandfather is an equivalent to a person who is male ''and'' has children who are people that must have children.

using the turtle language
<syntaxhighlight lang="turtle" style="border:3px solid grey">
:Grandfather
owl:EquivalentClass [
owl:intersectionOf
:Person,
[owl:onProperty :hasGender;
owl:somValuesFrom :Male],
[owl:onProperty :hasChild;
owl:somValuesFrom [owl:intersectionOf
:Person,
[owl:onProperty :hasChild;
owl:someValuesFrom :Person] ) ])
.
</syntaxhighlight>

JSON is a popular syntax currently and thus this is used as an alternative.

JSON represents subjects , predicates and objects as object names and values with values being either literals or or objects.

JSON itself has no inherent mechanism of differentiating between different types of entities and therefor JSON-LD is used. In JSON-LD identifiers resolve initially to @id and the use of @context enables prefixed IRIs and aliases.

The above Grandfather can be represented in JSON-LD (context not shown) as follows:<syntaxhighlight lang="json-ld" style="border:3px solid grey">
{"@id" : ":Grandfather",
"owl:EquivalentClass" : [
{"owl:intersectionOf" :[
{ "@id": "Person"},
{ "owl:onProperty" : ":hasGender",
"owl:somValuesFrom": {"@id":"Male"}},

{ "owl:onProperty" : ":hasChild",
"owl:somveValuesFrom" : {
"owl:intersectionOf": [
{ "@id":"Person"},
{"owl:onProperty" : ":hasChild",
"owl:someValuesFrom" : {"@id":"Person"}}]]}}
</syntaxhighlight>

== Sublanguages and syntaxes ==

=== Foundation grammars and 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

* SPARQL for query

* 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.
*Proprietary JSON based object serializable grammar. This directly maps to the internal class structures used in Discovery and can be used by client applications that have a strong contract with a server.

=== Identifiers aliasing 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:

# Full IRI (International resource identifier) which is the fully resolved identifier encompassed by <>
# Abbreviated IRI a Prefix followed by a ":" followed by the local name which is resolved to a full IRI
#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:

# PREFIX declaration for IRIs, which enable the use of abbreviated IRIs. This approach is used in OWL, RDF turtle, SHACL and Discovery itself.
# 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.
# 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.

The following is an example of the use of the prefix directives for IRIs and to define aliases for some of the owl and rdfs tokens <pre style="background-color:#fcfaee">
@prefix : <http://www.DiscoveryDataService.org/InformationModel/Ontology#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#>.
@prefix sn: <ttp://snomed.info/sct#>.

rdfs:subClassOf :alias ("subClassOf").

owl:Class :alias ("Class").

:alias
a owl:DatatypeProperty;
<http://www.DiscoveryDataService.org/InformationModel/Ontology#alias>
("alias").

rdfs:label
a owl:annotationProperty;
:alias ("name" "label") .

owl:DataTypeProperty
a owl:DataTypeProperty;
:alias ("dataProperty") .
</pre>As the aliases are defined they can now be used in an abbreviated Turtle syntax, as well as the standard turtle syntax. For example, the following Snomed-CT code is defined as a class and a subclass of another Snomed-CT code. <pre style="background-color:#fcfaee">
sn:407708003
a Class;
name : "Sample appearance (observable entity)";
subClassOf sn:407708003.
</pre>

A JSON-LD equivalent of the above uses context to cover prefixes and aliases in a simpler manner <syntaxhighlight lang="jsonld">
"@context" : {

"alias" : {
"@id" : "http://www.DiscoveryDataService.org/InformationModel/Ontology#alias",
"@type" : "@id"
},
"@base" : "http://www.DiscoveryDataService.org/InformationModel/Ontology#",
"" : "http://www.DiscoveryDataService.org/InformationModel/Ontology#",
"rdf" : "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"sh" : "http://www.w3.org/ns/shacl#",
"owl" : "http://www.w3.org/2002/07/owl#",
"xsd" : "http://www.w3.org/2001/XMLSchema#",
"rdfs" : "http://www.w3.org/2000/01/rdf-schema#"
}
</syntaxhighlight>Resulting in the standard JSON-ld context based approach: <syntaxhighlight lang="jsonld">
{"@id" : "sn:12345",
"@type" : "owl:Class",
"subClassOf" : "sn:34568"
}
</syntaxhighlight>

=== Ontology - OWL2 DL ===

For the purposes of 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]

However, in addition some standard OWL2 DL axioms are used in order to provide a means of specifying additional relationships that are of value when defining relationships. The following table lists the main owl types used and example for each. Note that their aliases are used for brevity. Please refer to the OWL2 specification to describe their meanings
{| class="wikitable"
|+
!Owl construct
!usage examples
|-
|Class
|An entity that is a class concept e.g. A snomed-ct concept or a general concept
|-
|ObjectProperty
|'hasSubject' (an observation '''has a subject''' that is a patient)
|-
|DataProperty
|'dateOfBirth' (a patient record has a date of birth attribute
|-
|annotationProperty
|'description' (a concept has a description)
|-
|SubClassOf
|Patient is a subclass of a Person
|-
|Equivalent To
|Adverse reaction to Atenolol is equivalent to An adverse reaction to a drug AND has causative agent of Atenolol (substance)
|-
|Disjoint with
|Father is disjoint with Mother
|-
|Sub property of
|has responsible practitioner is a subproperty of has responsible agent
|-
|Property chain
|is sibling of'/ 'is parent of' / 'has parent' is a sub property chain of 'is first cousin of'
|-
|Inverse property
|is subject of is inverse of has subject
|-
|Transitive property
|is child of is transitive
|-
|Existential quantification
|Chest pain and
Finding site of - {some} thoracic structure
|-
|Object Intersection
|Chest pain is equivalent to pain of truncal structure AND finding in region of thorax AND finding site of thoracic structure
|-
|Individual
|All chest pain subclasses but not the specific i''nstance of acute chest pain''
|-
|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
|-
|Property range
|A property range of has causative agent is a substance
|}

==== The ubiquitous ISA and inferred views. ====
OWL has a number of ways of handling sub types. The axioms "subclass of", "sub property of" or "equivalent class" indicate sub types. In the information model, in line with Snomed-CT the predicate "is a" is used as a supertype in order to simplify the sub typing. In addition, 'is a' assumes that the ontology is classified i.e. from the stated axioms, a subtype hierarchy has been produced by a reasoner, and it is the sub type hierarchy that 'is a' refers to.

In other words, for every subclass or equivalent class stated axiom an 'is a' relationship is generated, and this is used throughout the model when using query.

Similarly, when querying for properties, the stated axioms can create complex sub property and sub range logic. Consequently, the 'inferred view' is assumed in query i.e. where a descendant concept inherits its properties directly, unless overridden by sub properties.

In practical implementation of the IM both isa and inferred properties are explicitly modelled as direct relationships enabling the ontology to be queries without the need for axioms within the query itself.

==== Use of Annotation properties for original codes====
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. Annotation properties can also be used for implementation supporting properties such as release status, version control, authoring dates and times and so on. 

Typical annotation properties are names and descriptions. They are also used as meta data such as a status of a concept or the version of a document.

Many concepts are derived directly from source systems that used them as codes, or even free text.

The concept indicates the source and original code or text (or combination) in the form actually entered into the source system. It should be noted that many systems do not record codes exactly as determined by an official classification or provide codes via mappings from an internal id.  It is the codes or text used from the publishers perspective that  is used as the source.

Thus in many cases, it is convenient to auto generate a code, which is then placed as the value of the “code” property in the concept, together with the scheme. From this, the provenance of the code can be inferred.

Each code must have a scheme. A scheme may be an official scheme or  proprietary scheme or a local scheme related to a particular sub system.

For example, here are some scheme/ code combinations
{| class="MsoTableGrid"
|-
| width="109" |Scheme
| width="316" |Original Code/Text/Context
| width="106" |Concept code/ Auto code
| width="224" |Meaning
|-
| width="109" |Snomed-CT           
| width="316" |47032000        
| width="106" |47032000        
| width="224" |Primary hydrocephaly
|-
| width="109" |EMIS- Read
| width="316" |H33-1  
| width="106" |H33-1  
| width="224" |Bronchial asthma
|-
| width="109" |EMIS – EMIS
| width="316" |EMISNQCO303
| width="106" |EMLOC_EMISNQCO303
| width="224" |Confirmed corona virus infection
|-
| width="109" |Barts/Cerner
| width="316" |Event/Order=687309281
| width="106" |BC_687309281
| width="224" |Tested for Coronavirus (misuse of code term in context)
|-
| width="109" |Barts/Cerner
| width="316" |Event/Order= 687309281/ResultTxt= SARS-CoV-2 RNA DETECTED
| width="106" |BC_dsdsdsdx7
| width="224" |Positive coronavirus result

 
|}Note that in the last example, the original code is actually text and has been contextualised as being from the Cerner event table, the order field having a value of 687309281 and the result text having a value of ResultTxt= SARS-CoV-2 RNA DETECTED

=== Data model ===
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.

'''Example'''

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">
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>

=== Set definitions ===
In line with expression constraint language, defining a set is a query over the ontology resulting in a set of concepts to use in a subsequent query.

The information model uses SHACL to define the set meta data (e.g. the name of the set, the fact that it is a set etc) and SPARQL for the expression constraint.

SHACL has the idea of "focus node" which is an RDF node that the shape wishes to validate. As the focus node of a set are all members of the class of concept, then there has to be a way of narrowing down the nodes from the millions of concepts. SHACL has the idea of 'custom target' which is a filter applied to the graph. A typical custom target is a SPARQL target and therefore a SPARQL target is used to specify the constraint.

==== '''Example - complex set''' ====
Lets say a commissioner needs to know who the patients are that have had Covid vaccines.

Covid vaccines are recorded either as immunisation records, or medication records, or both. To query the medication records, a set of vaccine medication concepts are searched for, these being stored in medication order record entries. Covid vaccines change every few weeks as new brands or strengths are released.

A definition of a covid vaccine is helpful, thus a concept set is defined.
 <syntaxhighlight lang="turtle">
im:CSET_CVSMeds
a im:ConceptSet,sh:NodeShape;
rdfs:label "Covid vaccine study medication set";
sh:target [ #Custom target for the shape
sh:targetType sh:SPARQLTarget; #Focus nodes are sparql results
sh:select """
Select ?this #Select concept
Where { #where the concept is….
{?this im:isA sn:39330711000001103} # is a Covid vaccine
UNION #or (
{?this im:isA sn:10363601000001109. # is a uk product
#and
?this sn:10362601000001103 sn:10362601000001103} } #has vmp Covd vaccine)

"""
].
</syntaxhighlight>The above states that a covid vaccine must be a subtype of either

a) a covid vaccine product

OR

b) a UK product and which is both an actual product which is a covid vaccine virtual medicinal product.

Note the direct use of inferred 'is a' and property restrictions, avoiding the need for complex axiom

==== Example Set with exclusion ====
It is common to remove certain subclasses. OWL Object complement cannot be used for this due to the open world assumption.

Exclusion assumes something to exclude against (i.e. a set of things from which to exclude)

Let us assume that we define an event type of 'procedure' and we model a procedure as having a property of 'concept' whose range is the class of procedures as defined by Snomed-CT. Within Snomed-CT, immunisations are also classified as procedures but within the data model they are classified as immunisations. Consequently in the procedure value set we wish to exclude immunisations.<syntaxhighlight lang="turtle">

im:VSET_Category_Procedures
a im:ValueSet, sh:NodeShape;
rdfs:label "Value set - Procedures" ;
sh:target [ #Custom target for the shape
sh:targetType sh:SPARQLTarget; #Focus nodes are sparql results
sh:select """
Select ?this
Where {
?this im:isA sn:71388002. # is a procedure
MINUS {
?this im:isa ?exclusions #Minus is a exclusions
VALUES ?exclusions { sn:33879002 sn:51116004 } #which are vaccination, passive immunisation
} } """
]

</syntaxhighlight> 
=== Data mapping and matching ===

This part of the language is used to define mappings between the data model and an actual schema to enable query and filers to automatically cope with the ever extending ontology and data properties. 

The processes involved in mapping and matching concepts are described in the article on [[Mapping and matching concepts|mapping of concepts codes and structures]]

=== Query ===
It is fair to say that data modelling and semantic ontology is useless without the means of query.

The current approach to the specification of query uses the GRAPHQL approach with type extensions and directive extensions.

Graph QL , (despite its name) is not in itself a query language but a way of representing the graph like structure of a underlying model that has been built using OWL. GRAPH QL has a very simple class property representation, is ideal for REST APIs and results are JSON objects in line with the approach taken by the above Discovery syntax.

Nevertheless, GRAPHQL considers properties to be functions (high order logic) and therefore properties can accept parameters. For example, a patient's average systolic blood pressure reading could be considered a property with a single parameter being a list of the last 3 blood pressure readings. Parameters are types and types can be created and extended.

In addition GRAPHQL supports the idea of extensions of directives which further extend the grammar.

Thus GRAPHQL capability is extended by enabling property parameters as types to support such things as filtering, sorting and limiting in the same way as an.y other query language by modelling types passed as parameters. Subqueries are then supported in the same way.

GRAPHQL itself is used when the enquirer is familiar with the local logical schema i.e. understands the available types and fields. In order to support semantic web concepts an extension to GRAPHQL, GRAPHQL-LD is used, which is essentially GRAPH-QL with JSON-LD context.

GRAPH QL-LD has been chosen over SPARQL for reasons of simplicity and many now consider GRAPHQL to be a de-facto standard. However, this is an ongoing consideration.

=== ABAC language ===
''Main article : [[Attribute based access control|ABAC Language]]''

The Discovery attribute based access control language is presented as a pragmatic JSON based profile of the XACML language, modified to use the information model query language (SPARQL) to define policy rules. ABAC attributes are defined in the semantic ontology in the same way as all other classes and properties.

The language is used to support some of the data access authorisation processes as described in the specification - [[Identity Authentication Authorisation|Identity, authentication and authorisation]] .

This article specifies the scope of the language , the grammar and the syntax, together with examples. Whilst presented as a JSON syntax, in line with other components of the information modelling language, the syntax can also be accessed via the ABAC xml schema which includes the baseline Information model XSD schema on the Endeavour GitHub, and example content viewed in the information manager data files folder

2021-07-10T15:55:21Z

DavidStables: /* Discovery data service status */

__TOC__
These articles describe the Discovery Data Service; the architecture that underpins the data service, the components that make up the service, the testing and assurance processes, and the resources, open source technologies, and software that are used to host, develop, and support the service.

==Discovery data service status==
The data service is live.

It currently stores and processes the data from 28 million linked organisational patient records in the uk.

It contains long term records on 14 million unique uk citizens who have been resident in London at some point in the last 30 years (including people who have left or died),

Data on individuals are held in a single common data model with data values represented by a super ontology composed of the world leading health ontologies.

Data in discovery is submitted by health providers who provide primary and secondary care and urgent care services to patients or clients.

Data is kept up to date in close to real time (at worst within 24 hours).

Data within the service is modelled in semantic web languages.

= Discovery overview =

These articles provide background to the ideas, philosophies and approaches that have resulted in the Discovery Data Service. They cover the original objectives, the approach to collaboration and shared tenancy, and the information governance rules that underpin the way privacy and sharing are balanced.

*[[What_is_Discovery|What is Discovery]]? - This article describes what Discovery is and how it is conceptualised at a very high level.
*[[Case studies]] - An overview of projects that access and utilise data from Discovery; information includes the applicant, project summary, and the latest status (Development/Live).
*[[Latest news]] - The latest information for all Discovery Data Service releases and changes, plus known issues and updates from system suppliers and other third parties.
*[[Current_data_sets|Current data sets]] - the broad types of data received from various systems.
*[[Current published data]] - provides the latest data publisher information by sector, geographical area, service, and system provider.

= Information model topics =

These articles provide information about the services, structure, and functionality that operate using the Information Models; one of the fundamental tenets of the Discovery Data Service. This is the starting point for those interested in health data and the information derived from it, and why Discovery may be different from other approaches:

*[[Discovery health information model|Health Information model]] - An overview of the approach to the Discovery information model, the purpose, and type of content.
*[[Health Information modelling language|Modelling language]] - The W3C standard languages used to build the various components of the information model
*[[Health_data_model_content|Basic health data set ]] - a very high level overview of the types of data mapped from data held within the Discovery data stores.
*[[Information model reference data|Reference data -]] an overview of additional data held in the information model.
*[[Mapping and matching concepts|Mapping and matching concepts and structures]] - Introduces the approaches to matching and mapping concepts and the structural mappings in the model
*[[Information_model_service|Information model services]] - the technical services , such as APIs and apps that enable an model instance to be used or to implement an EHR based on the model or particular data model

= Operational topics =
These articles provide information about how systems can interoperate with Discovery and provide further links into test APIs, schemas, and other documentation associated with data formats for sending and receiving data.

* [[Publishers]] - includes technical interface information, FHIR mapping, system requirements, and how to make changes to publishing services.
* [[Subscribers]] - includes set up, data mapping, and schema information.
*[[Monitoring and alerting]] - provides an overview of the monitoring and alert systems in place for the DDS and the infrastructure that supports it.

= Services and applications =

These articles provide information about the services and applications provided by the Discovery Data Service and the underlying functionality.

*[[Data Sharing Manager|Data Sharing manager]]- DSM provides a visual representation of data that is being shared and processed and by which organisations, regions, and/or services.

*[[UPRN address match application|ASSIGN- UPRN address matching application -]] a web based application that matches single or batches of hand entered address to authoritative addresses and assigns a unique property reference number.
*[[Information model manager]] - an application designed to provide a view of the common information model, and support the authoring of the content of the model.
*[[Information_model_service|Information model services]] - the technical services that enable the common information model to be used.
*[[FHIR Get Structured Record API]] - returns a complete patient record in a structured format following GP and Care Connect standards.
*[[HL7v2 API]] - Send HL7v2 ADT and ORU (clinical events) data to Discovery.
*Get health record - the service that obtains a fully structured health record about a person, in real time via a standards based API.
*Record publication service - the service that publishes data from health records for specific purposes, often immediately on receipt.
*Data set distribution service - the service that distributes sets of data for populations of patients where the definition is complex or where the subscriber is hosting a copy of the data permanently.
*[[NHS 111 Discovery frailty flagging]] / [[Frailty algorithm]]
*[[GitHub repositories]] - descriptions and information relating to the application source code.

= Architectures =
These articles provide information about the overall high level software architecture models providing a descriptions and visualisations of the Discovery Data Service and information service components and how they interact.

* The [[Data Storage Architecture]] illustrates how data is stored within the service and the various implementation options available for organisations that wish to use some or parts of the services.
*[[Identity Authentication Authorisation|Identity, authentication and authorisation]] specifies the approach taken by Discovery for accessing utilities and controlling some aspects of access to application functionality and some data resources, after all of the other locks have been opened.
*[[Application zone architecture]] illustrates how the data is accessed in different places and in different ways according to different use cases
*[[Pseudonymisation]] describes how Discovery generates pseudonymised data.
*[[Data linking]] describes how Discovery links several patient records into a single person/citizen record.

= Application help =

*[[Data_Sharing_Manager|Data Sharing Manager]] - Data Sharing Manager provides a visual representation of data that is being shared and processed and by which organisations, regions, and/or services.
*:You can also amend or cancel data sharing and processing agreements in real time.
*[[Record Viewer]] - Record Viewer shows a combined view of an individual's patient records, using data from different source organisations.
*[[Jira]] - Jira is an effective way to share and track information and helps to make sure that tasks and issues are completed, and signed off, by all relevant teams.

= Wiki tips =

*[[Adding a new page to the wiki]]
*[[Adding tables from word documents]]
*[https://www.mediawiki.org/wiki/Help:Tables Mediawiki Help:Tables]
*[[Creating a DDS wiki watchlist]]
*[[Creating a new user]]
*[https://en.wikipedia.org/wiki/Help:List Wikipedia Help:Lists]
*[[Test page]]