Data Model

The data model is the part of the ontology that defines classes required for particular business purposes.

Business purposes vary from the need to store particular items of data through the need to display items in a certain way. This is the model that defines the ever evolving structure of health records held within multi-domain health records, varying from common high level classes through to specialised classes. An example of the former is an 'observation', and an example of the latter is a 'histological/immunological report on a breast carcinoma'.

N.B. in IS013606 these are called archetypes and their derivative templates. In HL7 FHIR, from a messaging and API perspective, they are referred to as resources and profiles.

Whilst the data model supports inheritance (in the ways described below), unlike the semantic ontology, the data model classes are not inherently semantically defined in relation to other concepts. In order to semantically define a data model class, a special property 'is of type' is used to link the semantic definition to the data model. This is described below.

The data model is built using the same OWL2 information modelling language as the semantic ontology. A major difference is the way in which the two are used. In the case of a data model, an application would use a 'closed world assumption' with the use of query language to filter and sort, whereas in the semantic ontology an application would use the 'open world assumption' with the use of reasoners to enable subsumption testing.

Data model classes and semantic definition

Data model classes often use terms that appear to have meaning that should be semantically defined, therefore a convention used is to name the different concepts by the use of a () qualifier.

For example a data model class of 'Encounter' would be named 'Encounter (data model)' whereas the encounter class that holds it's semantic definition may be called 'Encounter (type)'. (The qualifier 'type' is often omitted for brevity).

The two concepts are linked using the 'is of type' property so that a data model class can access its definition and a reasoner can access the data model for query.

For example, An 'Encounter (data model)' -> is of type -> 'Encounter (type)'.

The separation allows for many more 'subtypes' than there are data model entities. This enables implementers who use a relational design to have far fewer tables than there are types.

For example, an implementer may elect to have a single Encounter table for all encounters (including the 20,000 or so encounter sub types). To record a telephone triage an entry into the encounter table : 'Encounter' -> is of type-> Telephone triage consultation' may be all that is required.

Data model properties

Data model properties are modelled according to the business purpose of the data model class. There are two categories of data model properties, each category modelled in a slightly different way in the modelling language. Within the two categories there are 3 types of properties.

Core data model properties

Core data model properties are properties that would be expected to be populated in most circumstances and form part of the "business definition" of the class. Another way of describing them would be to say they are mandatory. However, the data model does not itself mandate the presence of value of the property with the handling of 'unknown' as nulls or or proxy values delegated to a business decision.

For example, a patient health event would have a property of 'has subject' the value being the patient to whom the event referred. Being an event it would also have a start date and time.

In the modelling language these are modelled as class expressions with the maximum cardinality defined where necessary. For example

Person (record of): Subclass of: Individual (record of)

      and 'has date of birth' exactly 1 'Date Time'

On the other hand, if there was a business purpose to record the 'quality of the call' in a telephone triage consultation, then a 'Telephone triage consultation (data model)' concept would be created as a subclass of 'Consultation (data model)'. An implementer who used a single encounter table has a choice of:

a) Create a table for telephone triage with the additional field of 'quality of call'

b) Use a triple extension table on the encounter table with field 1= Encounter id/ value =12345, field 2= Property/ value quality of call, field 3 = Object / value = 'good'.

And because the info

Model content

main article Discovery health data model

In line with the information model itself, the model content is constantly evolving. These articles provide an overview of content at a particular point in time, as high level background. There is likely to be a discrepancy between the documentation on this wiki and the information model itself. The model content is best viewed via the information model viewer, although the viewer itself may also reference the wiki.