A data model is the part of the common information model 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 a 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 class's semantic definition to the data model class This is described further below.
A 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 and semantic definition
Data model classes often use terms that appear to have meaning that should be semantically defined. As described above, a separate concept is normally created in the semantic ontology and linked by the 'is of type' property. The potential ambiguity is resolved using a naming convention 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 and use a type field to differentiate.
For example, an implementer may elect to have a single 'Encounter' table for all encounters (including the 40,000 or so encounter sub types held in real records). 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 class inheritance
Data model classes inherit explicitly in the same way as semantic ontology classes i.e. may be subclasses. In doing so the following inheritance rules apply:
- All properties of the super class are available to the subclass (standard inheritance) and the subclass appears to extend the superclass.
- Where a subclass has a redeclared property which is the same as its superclass, the range of the property of the subclass must be the same as, or a subclass of, or derived data type of, the range of the super class. For example if an encounter (data model) -> is type of-> Encounter type, then a consultation (data model) (which is a subclass of encounter) -> is type of-> X, and X must be a subclass of 'Encounter type'
- Where the subclass has a property which is a subproperty of a property of the super class, then likewise, the range of the property of the subclass must be the same as, or a subclass of, or derived data type of, the range of the super class.
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. Nevertheless, an implementer using a relational model may create fields for these as could implementers using code classes.
For example, a patient health event class would have a property of 'has subject' the range being the patient to whom the event referred. Being an event it would also have a start date and time. There would be little point in having an entry for an observation (subclass of patient health event) unless it was linked to a patient.
The "is of type" property is an example of a core property for those objects that are subtyped by the value of this property.
In the modelling language these are modelled as OWL 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'
Extended data model properties
Extended data model properties are those properties that are deemed to be 'available' for a particular class but not always expected. Depending on the business these may also be used to constrain 'allowable' properties of a class. An example of the latter is the Snomed-CT concept model which constrains attributes of a subclass to a defined list.
For example, a record of an 'accident and emergency encounter' may record a 'treatment function' (for which the patient was admitted). But if the patient was never admitted the encounter would not have this property. This property is therefore modelled as an extended property. (These may also be referred to as optional properties).
in the modelling language these are modelled as OWL property domains. As such, an information model application may use the closed world assumption to determine the properties of an class as either core or extended. A reasoner can determine that when a user is querying on a property then the object must be a member of the property domain class.
Extended properties are of value when considering implementation design. For example, using the example of the 'telephone triage consultation' there may be a business purpose for recording the 'quality of the call' .
Firstly The 'Telephone triage consultation (data model)' concept would be created as a subclass of 'Telephone Consultation (data model)'. An extended property would be created 'quality of call' with a domain of telephone consultation.
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 an encounter table with field 1= Encounter id, value =12345, field 2= Property, value =quality of call, field 3 = Object , value = 'good'.
Types of data model properties
Whether core or extended, properties fall into 3 main types:
- Object properties, whose range is an instance of a class, this either being a class or a value set with class members.
- Data properties, whose range is a literal e.g. an integer or string.
- Relationships, a type of object property whose range is another data model class
Property Cardinality
Within the data model cardinality modelling is implied in the following way:
- A core property is stated within the class expression as either having an exact cardinality, maximum cardinality or one or more (or any combination). Minimum cardinality (of 1) is implied.
- An extended property is either a functional property (Cardinality of 1) or unstated in which case it is assumed there may be zero or more than one. Explicit cardinality of extended properties is not supported directly and such a property would be modelled as core. Minimum cardinality of zero is implied as an extended property.
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.