Baseline data set

Discovery Data Service contains health and care-related data.

These articles describe the nature of the types of data processed by the data service

In addition to reading these articles, the reader can visit the information model viewer at [x] which enables the entire information model to be explored, including the ontology, the data model, and the various code sets and data sets that have been developed.

In addition, from an operational perspective the status of data sets as incorporated from different supplier systems can be seen on the current data sets article.

Overview of the data model

The Discovery common information model includes a data model. The data model covers the structural arrangements of care record entries and related entries such as information about people and organisations.

The data model is one of the main packages within the information model:

Only the broad categories of types of data are described in these articles. ,The information model viewer describes and defines precisely the extent of  support for types of data at a particular point in time. 

In order to understand the terms in use, it is useful to understand the basic building blocks of the model.  The article Concepts classes and properties describes some of the building blocks and provides access to the more specialised modelling language.

 

 

Data model vs semantic ontology

The data model is different to the semantic ontology. Although they both share the idea of classes and properties, the data model is configured for business purposes, whereas the semantic ontology is configured for meaning. A data model applies a closed world assumption, whereas the ontology applies an open world assumption.

Nevertheless, all concepts used in the data model are be defined by Axioms in the semantic ontology, providing a means by which data entity subtyping can take advantage of both reasoners and standard query. They are interrelated as in the following diagram with the data model entities on the left and their defning axioms in the ontology on the right.

 

Data model entities are defined by axioms in the semantic ontology They also have additional properties and relationships in the data model which are business related i.e. the data model attributes are over and above the properties needed to define the meaning of the entities. 

This presence of the data model entity in the ontology can be used to imply that a data model entry is a record of the thing that the entry is about. For example a hospital admission entry is a record of a hospital admission. This seeming tautology enables subsumption testing on data model entities and for the relevant data model attributes to be selected in query.  A user can ask the right question and get a consistent answer without any knowledge of the underlying complex relationships. The user need not care whether the concept they are looking for happens to be a value in a record, a property, or a table.

In addition this relationship enables unlimited extensions to data models, which is something that can be used to keep a relational database schema very simple.  How the mapping to a schema is managed is a subject of specialist articles elsewhere in the Wiki.

Scope of content and approach to categories

The entities described here are derived from actual health records. These are not a "standard" or set of statements of what a data model should be but instead reflect the type of data that actually exists in the Discovery data service after it has been organised categorised and made ready for machine based inference and health record query. 

A health record consists of a set of "entries", each entry describing either an event that has occurred, an event that might occur, a state, or statement by the person making the record.  In addition, entries contain references to external things, often organised into Directories. Thus an entity is either a type of entry or a type of thing that the entry refers to.

The approach to categorising the data types has been heavily influenced by HL7 FHIR. In this approach, entities are roughly categorised according to the type of business process that the entry describes. In that sense, the categorisation is entirely pragmatic.

Each entity has its own article and thus the data model is described by categorising articles along the same lines as the ontological classification of the entities themselves. However, there will always be some mismatch between the articles and the model itself and it is the model itself that should be relied on at all times.

 

 

 

 

  Individuals

This section categorises information about persons, patients and professionals, included related persons.

The patient or person demographic

Throughout the document the word “patient” is used to represent a person who is a user of the health or care service. (It is accepted that within the services themselves, service users may be referred to as patients, clients, service users or other terms)

This data covers the core demographics of the patient and their personal identifiers Whilst the table infers a one to one relationship, there is a one to many relationship between the patient and the related items in nearly all cases. For example the patient may change gender, change name, move home or acquire languages.

Note that in Discovery, a patient is considered as person in a role of patient (or client) in relation to ONE publisher.

A person is identified as being linked to many patient demographic records. Thus a person is held independently of the patient resulting in a “master person” register

Patient / Person
Property	Description
NHS Number	An identifier of type NHS number, The NHS number allocated to the patient
Name	Name information and title for the patient. Ideally structured as “Family name”, “Given names” (in the correct order of presentation), “prefix” e.g.... “Mr”, “Dr” and “suffix” e.g.... “Junior”
Administrative Gender	Concept: The administrative Gender of the patient i.e.. the gender that they consider themselves to be allocated to. May or not be the genetic or phenotypic gender
Date of birth	Date of birth of the patient, as far as is known
Death indicator	If a patient has died an indicator that they are now dead
Date of Death	If dead and if available, the date of death
PDS sensitive	Flag to indicate whether the patient is marked as sensitive on the spine
Ethnicity	Concept: Held in Discovery as an observation about the patient, indication as to the ethnic group the patient is part of
Language	Concept : Held in Discovery as an observation about the patient, and qualified by whether the patient speaks the language or is their preferred language. May be several entries as language characteristics change
Additional identifiers	Identifiers – qualified by identifier type
Relationships	Description
Main Residence current	The main residential (location identified by an address)
Contact	potentially used in contacting the patient, each contact qualified by 1) Concept : contact type e.g.... home telephone, mobile, email 1) Contact details e.g.... email address or telephone number about the patient
Related persons	Linked Related persons e.g. family members. This will be sub-typed by relationship type i.e a link table in RDB design. May be a family relationship e.g.... Father and may be qualified by genetic relationship. May be a relationship such as a carer or next of kin.
Person	If this is an organisational patient demographic entry, the person that this patient actually is (or is assumed to be)
Residences	Other residences (locations further identified by address) qualified by residence type (e.g. temporary) and period - start end end

Related Person

Patients are related to other people via a variety of relationships, some of which may be genetic and others not. Relationships may also include carer relationships or next of kin. This entity is linked to via the Patient related person link which has a relationship type (e.g. has parent). A related person also has a role of relation (e.g. someone is a mother) but they may also have other roles (they may also be a sister). Furthermore, the related person may or may not be an entity in the record store itself. Thus, relationships are handled in a slightly different way to many relationships.

The handling of relationships and related persons form a rich ontology, and the basic modelling is described in more detail in the article on relationships between people.

Related person
Property	Description
Name	Name of related person
Address	Location identified by Address of related person
Contact	Contact details of related person
Identifiers	Identifiers of the related person (e.g.... NHS number)
Status	Status of relationship
Related in Discovery	Whether the related person is in Discovery or not
Relationships	Description

Professionals organisations devices and locations

Most entries are attributed to patients, professionals, their organisations or services, locations or devices. In Discovery there is an attempt to uniquely identify these from the information provided, ideally using standard identifiers but in some cases deducing from names and context. In many cases these may be deduced only at the level of the sending systems by the use of internal identifier matching.

The practitioner in role

This term refers to any person who provides care or is part of the health care process, excluding personally engaged or family carers.

A practitioner in role means a person providing care in the context of an organisation or service. The same person may have a number of roles across a number of organisations in which case it is expected that several entries may be created. This may be inferred by Discovery

Practitioner
Field	Description
Name	Name information and title for the practitioner. Ideally structured as “Family name”, “Given names” (in the correct order of presentation), “prefix” e.g.... “Mr”, “Dr” and “suffix” e.g.... “Junior”
Gender	Concept : The administrative Gender of the practitioner i.e.. the gender that they consider themselves to be allocated to. May or not be the genetic or phenotypic gender
Date of birth	Date of birth of the practitioner, as far as is known
Active/ Inactive	An indication of whether the practitioner is active in the role or not
Service or organisation	The service or organisation that the practitioner is operating in relation to a particular role
Role type	Concept : The type of role e.g.... Doctor, nurse, receptionist, secretary that the practitioner operates as in this role
Speciality	Concept: The Speciality of the practitioner (e.g.... Cardiologist)
Contract period	Start and end dates of contract with the organisation
Linked items
Contact	potentially used in contacting the practitioner. Each contact qualified by Concept : contact type e.g.... home telephone, mobile, email Contact details e.g.... address or telephone number about the patient to be
Identifiers	Identifiers qualified by identifier type and code
Relationships	Description
Work address	Qualified by concept : address type (e.g.... work address) The address of the practitioner relevant to the role

Device

In the context of Discovery a device is normally used to relate to the entry of a record or in relation to its use in a procedure or operation

Devices are categorised and full defined via the information model relationships. Thus each device represents an instance of a kind of device defined in the information model

Device
Field	Description
Device Name	Device name
UDI human readable	Human readable bar code identifier
UDI machine readable	Machine readable bar code
Manufacturer	Manufacturer of device e.g.... business organisation
Serial number	Serial number of device
Device type	Concept: for the nature of the device e.g.... cardiac pacemaker This may be at any level of granularity as the information model uses additional attributes to fully define the device
Device version	Version of the device (e.g.... software version if the device is software)

 

 

Organisations departments and services

In Discovery, these concepts are amalgamated into a single structure and the entities are differentiated via the category and the relationships with the other entities as described below. In many cases the relationships will be inferred by Discovery from the nature of the information transmitted. There is no expectation that publishers are required to populate the relationships.

Because Discovery is an operational service, there are also some related entities that provide information such as when a particular publication was updated. Organisations and related entities can be illustrated as follows

Organisation or service
Field	Description
Organisation identifier	The nationally provided identifier or “ODS” code for the organisation or service if it exists
Name	Name of the organisation or service
Address	The address of the organisation or service
Contact details	Main contact for the service itself e.g.... main telephone number
Organisation/ service category	Whether this is an organisation (e.g.... Barts NHS Trust, Royal London Hospital) or a service e.g.... Barts physiotherapy service or cardiology department May be deduced when populating the organisational structures and relationships
Speciality	The Speciality of the service e.g.... Cardiology
Links
Linked Organisation	A set of relationships between one organisational service entity and another each consisting of 1) A relationship type such as “part of” or “provided by” e.g.... Royal London Hospital is “part of” 1) A target organisation e.g.... “Barts NHS Health Trust”Used to populate the organisational structures in the information model
Contacts	Contact details for a person or team or department associated with the organisation consisting of 1) Name 1) Contact details
Location	Locations associated with the organisation
Identifiers	Other organisational identifiers

 

Location

Information about an actual location, building or entity that is related to the organisation that operates from it

Location
Field	Description
Location identifier	The nationally provided identifier for a location
Name	Name of the location
Address	The address of the organisation or service
Location Type	Concept: Describes the location in the context of its purpose e.g.... a ward or Branch surgery, a mobile MRI scanning unit. Note that the service may hold the information about what the location is used for rather than the location
Links
Organisation	A set of relationships between one organisational service and location consisting of
Contacts	Contact details for a person or team or department associated with the location e,g, building maintenance, consisting of 1) Name 1) Contact details

 

Team

Teams are named groups of individuals that are linked to one or more services

 

Team
Field	Description
Team name	Name of the team
Links
Organisation or services	The services or organisations this team reports to
Team members	Practitioners that are part of the team

 

Episode of care

A care episode is an association between a patient and a healthcare provider during which time care is provided. The association implies that the provider has some responsibility for the provision of care during the period of time covered by the episode.

A care episode may be a concept that is explicitly stated. For example, GP registration is an explicit process by which the patient registers for care and in due course may be de-registered when they move elsewhere.

A care episode may otherwise be deduced from the data provided , usually relating to encounters. For example the acceptance of a referral or the attendance at accident and emergency provide episode of care start points. Discharge from an outpatient clinical may be used to deduce the end of a care episode.

Care Episode (inherits patient event)
Field	Description
Nature or type of episode	A concept that describes the nature of the episode from a terminology set or ad-hoc information provided by publisher and mapped to a concept May be inferred or derived from structured entry For example, a GP regular GMS patient or a temporary resident
Status	Whether currently active (i.e.. no end date) or inactive
Links
Initiating Referral	A Link to the originating referral, whether self-referred, ambulance, GP referral etc. May be inferred from encounter information e.g.... referral accepted, emergency admission
Care episode Administration	One or more links to care episode or registration administration processes that occur during the period of the care episode
Linked Entries	All encounters and many other entries may be linked to the care episode

General practice registration

General practice does not consider their patients to be related to a particular episode of care. Thus a variation on care episode is designed for GP patients.

This deals with the administration of patient reception and registration in the context of General practice. This is particularly formal in respect of GP practice registration.

General practice registration
Field	Description
Status	Status of registration or care episode processing e.g.... registration submitted, notification of registration, deduction received, deducted
Status sub-type	Granular subtypes of the status e.g.... “death”, “embarkation” or “armed forces” when patient is deducted
Patient type	Type of patient from the perspective of administration e.g.... GMS patient, temporary resident

 

Encounters and sub encounters

An encounter is an interaction between a patient and healthcare provider for the purpose of providing care, including assessment of care needs. Encounters are the mainstay of care provision and the concept covers encounters in any care domain. For example a GP consultation is an encounter and an in-patient stay is an encounter.

Encounters are often defined according to the publisher’s definition or even the nature of the IT system in use. In Discovery an encounter model is a superset of the different encounter models from the

Events within hospital are also considered encounters and in Discovery are subs encounters of the overall encounter. Examples of this may be admissions, discharges, ward transfer.

different domains and systems. The different patterns are differentiated by the use of Encounter types or archetypes.

For example, a spell in hospital would be considered an encounter. The admission event is also considered an encounter, subsidiary to the spell encounter, as a discharge would be.

Similarly an accident and emergency attendance may have a subsidiary encounter for the initial assessment.

The additional properties relating to encounter types (e.g.... method of admission, critical care function type) etc, are considered as non-core and are referenced via the information model concepts. Each property type has a concept and each value class is considered concept. Consequently these are not specified in this document but are available via the ontology.

 

Encounter: (inherits patient event)
Field	Description
Encounter Type	The overall nature of the encounter mapped to the encounter type ontology
Completion Status	Concept: Status of encounter when this event is sent. It may be completed or ongoing or planned. In some systems encounters are created before they commence
End Date/ time	Date time encounter ended
Duration	In the absence of an explicit start and end time, the duration may be estimated
Providing Organisation/ services or departments	Additional department and/ or services that define the encounter more fully than the main organisation An entry may have a main organisation of Royal London, but the encounter may take place in the Royal London A&E department
Location	Actual location of the encounter e.g.... a physical building, wing , ward, or room or bed In most cases this may not be known (as the organisation itself implies a location) For example a branch surgery of a GP practice or bed 1, Ward 10
Links
Linked appointment	The appointment to which the encounter may be related
Subsidiary of	An encounter that the encounter may be part of or sub
Linked care episode	The care episode the encounter is linked to.
Additional Practitioners	Additional practitioners other than the main attributed practitioner involved in the encounter

 

Specialised encounters

Within acute care and many specialties, a great deal of event related data are recorded against encounters.

The approach to this in Discovery is to “extend” encounters by providing the means to record semantically defined attributes and value sets in relation to particular specialised encounters.

Here are a set of example, properties associated with specialised encounters. This list is by no means complete

 

Example of encounter subtype extension properties
Encounter subtype	Sub Type of subtype		Sub type Properties
Hospital encounter	Accident and emergency encounter		a&e category of attendance a&e attendance source arrival mode' treatment function for service for which admitted
	Critical Care Encounter		critical care unit function admission source
	Hospital Outpatient attendance		attendance status attendance outcome treatment function type

 

 

Context Headings or sections in encounters

A heading is grouping construct that segregates clinical entries within an encounter, episode or a document such as a care plan for establishing human inferred context. Their presence is primarily for the purpose of display and context inference and represent the headings entered via a clinical or care planning system e.g.... a form template or consultation.

As a heading is a simple text structure label there is no requirement for attribution as it is assumed that attribution is shared with the parent encounter

Section
Property	Description
Heading type	Concept: for the heading e.g.... Clinician entry/ Examination/ CVS Examination CDS Entry/ Primary Diagnosis Clinician entry/ Past procedures
Order	Order of heading in relation to its parent for display purposes
Relationships	Description
is part of encounter	The encounter that contains the section
is subsection of	Link to the parent heading

Referral Request or procedure request

A referral request or (procedure request) includes request for advice or invitation to participate in care and is not limited to conventional referrals. A referral request often precedes the encounter or care transfer that occurs subsequently. Furthermore a referral request may accompany a care transfer e.g.... a request for input from a community health professional during the discharge process. The referral type is considered as the core observation concept

Referral inherits attribution

Referral request : inherits patient event
Field	Description
Priority	Concept: Priority of referral request
Referred by type	Concept: The type of source the transfer originated as e.g.... self referral, healthcare professional referral
Source organisation	Sender service or organisation
Speciality requested	Concept: the Speciality of the referral request
Procedure or Service type requested	Concept: If available, the nature of the service requested e.g.... Nephrology, chest x-ray
Request Reason	e.g.... The clinical condition or problem that is reason for referral
Recipient service or organisation	The referral recipient organisation or service e.g.... hospital or department
Recipient location	Location of the recipient
Recipient practitioner	If referred to a person, the practitioner
Referral UBRN	Unique referral booking number
Referral mode	Concept: Means of referral e.g.... Verbal, written, ERS
Links
Linked episode	Linked care episode for which this is the originating referrals

 

Appointment session

An appointment session is an appointment grouping implying a session or a clinic, which incorporates a number of appointments

In the Discovery model, all appointments are linked to a schedule (whether a schedule pre-authored or not) i.e.. a standalone appointment would have one schedule for the stand alone appointment

Appointment schedule : inherits attribution
Field	Description
Organisation or service	Organisation or service responsible for this schedule
Location	Location for the schedule
Schedule type	Concept: for the type of schedule e.g.... diabetic review
Schedule description	Textual description of the schedule e.g.... Dr Jone’s acupuncture clinic
Speciality	Speciality associated with the schedule
Start date/ time	Planned start date/ time of schedule
End date/time	End date time of schedule
Links
Linked appointment slots	Linked appointments to the schedule
Practitioners	Practitioners linked to this schedule

Appointment

This is information about a particular appointment or slot as planned. The slot creation shares attribution with the schedule

Appointment
Field	Description
Appointment category	Concept: describing what type of appointment in terms of routine, urgent etc
Planned Reason	Concept: of reason for appointment from the appointment planning perspective
Description	Any text description for the appointment slot
Start time	Start date and time of slot
End time	End date and time of slot
Planned duration	Planned duration of appointment (may or may not be timed)
Patient	Patient booked into the slot
Slot booking status	Whether booked, reserved, free
Attendance status	Whether the patient arrived, sent for, left
Booking urgency	Indication as to whether it was booked as an urgent appointment (whether the appointment was marked as urgent or not
Interaction type	Whether face to face, telephone, Skype etc
Links
Linked schedule	Links to the schedule containing the appointment
Booking history	Links to booking history including Booked :cancelled Date and Time of booking
Attendance history	Links to the attendance status history

 

Appointment booking history

Information about booking and unbooking of an actual appointment prior to the patient attending

Date and time of booking and by whom are attributed in attribution fields.

The latest entry represents the information prior to the patient arriving or appointment attendance

Appointment booking: inherits attribution
Field	Description
Booking or cancellation	Whether this is a booking or a cancellation
Patient	Patient booked into slot
Booking urgency	Whether the appointment was urgent (whether or not reserved as an urgent slot)
Patient related reason	Reason for appointment from patient’s perspective (i.e.. if booked)
Interaction type	The actual interaction type when booked (e.g.... telephone)
Links
Appointment slot	Link to the appointment slot

Appointment attendance history

Historical Information about an actual attendance for a patient for an appointment i.e.. after the patient has arrived for appointment

Appointment attendance history
Field	Description
Status	Concept: the status e.g....
Patient	Patient
start time	The actual start time of this status
end time	The actual end time of this status
Actual duration	The actual duration of the appointment
Actual interaction type	Nature of the actual interaction
Links
Appointment slot	Links to the appointment slot

 

Care plan

In the context of Discovery a care plan is a relatively simple data subset of a complex document structure for the purposes of tracking and analysis. There is no attempt to precisely define a care plan beyond the simple data items listed here

Care plan : inherits attribution
Field	Description
Document Status	Whether the plan is draft, active, no longer active
Type of plan	Concept: for the type of care plan. For example, Asthma action plan, Cancer management plan
Description	Description of plan
Time period	The start and end date or period of the plan (the start date may precede the effective date)
Linked Headings	Heading categorised, Activities, goals targets, observations linked to the plan
Linked episodes	Care episodes linked to the plan
Parent plan	Care plans this plan is part of
Associated practitioners	Additional practitioners or teams associated with the plan
Associated teams	Links to teams associated with plan
Linked activities	Links to care activities

 

Care plan activities

These are modelled as observation types such as

  1) Activity 
  1) Goal 
  1) Target 

 

Clinical health events

This section covers data about the patient that is generally considered “clinical” either observed characteristics of the patient or clinical procedures or measurements that have been carried out.

In the Discovery model clinical data is modelled around observations i.e.. different types of clinical characteristics inherit from simple observations.

Care records are usually structured according to a series of sections or “headings” a standard having been established by the PRSB. This enables records to be viewed as documents although the headings have no inherent meaning in themselves.

Observation

An observation is considered a type of health event that records some characteristic of the patient or some procedure performed on the patient, excluding the specialised events such as medication.

An observation in Discovery is much broader than an observation in FHIR. Because observations may be highly specialised, like encounters, only the generic properties are illustrated in this document.

The type of observation is deduced from the observation concept itself.

Observations may be linked at any level of nesting. In particular, tests and concept results observations are considered as 2 separate but linked observations, one for the test, the other for the result. This varies the Discovery observation model from the FHIR model that includes both test and result in the same observation.

For example, a blood pressure would be modelled as 3 observations as follows:

Observation 1Blood pressure

Observation 2Systolic blood pressure value= 120, part of observation 1

Observation 3Diastolic blood pressure value= 80, part of observation 2

Simple observation

A simple observation is the root for most clinical entries about a patient, ranging from a piece of text or coded concept including an advanced Snomed expression. Observations may be specialised by purpose (e.g.... observation, target, goal, aim, Various specialised observations such as allergies, numeric values, family history, immunisations, reports, documents and referrals extend the simple observation mode

Observations can be standalone or exist within a collection of observations with a parent observation

Simple Observation : inherits patient event
Field	Description
Observation type	Concept: Nature of the observation, including whether this is a sub-type entry (described elsewhere) or categorisation within the observation type itself e.g.... sign, symptom, aim, target, goal , test header, or specialist type e.g.... blood pressure. Equivalent to an archetype It is inferred by the code within the observation, however it is modelled separately as it drives business logic
Prompt	Text representing a prompt on a form to which the observation represents the nature of the response to the prompt This should not be confused with a parent observation such as a test order which has this observation as a test result,
Description	Text entry for the observation
Is problem	Whether the observation is part of the problem definition
Problem episode	Concept: Whether the observation is new or a review of a problem or other specialist episode e.g.... flare, evolved from
Normality	A flag indicating whether the observation is marked as abnormal (e.g.... ABN, HI,LOQ)
Links
Linked problems	The problems the observation may be linked to including 1) Concept : Nature of link e.g.... evolved from 1) Problem
Flag	Any flags associated with the entry

 

Numeric observation

One of the commonest observations are pathology results and they often have numeric values as results. They extend simple observations

Numeric Observation : inherits simple observation
Field	Description
Operator	Operator associated with the value e.g.... < or > or =
Value	Numeric value of result
Range (s)	List of qualified range each consisting of 1) Range qualifier (e.g.... normal, normal for males) 1) Lower limit 1) Upper limit
Units	Concept : Units of measurements

 

Date time observation

A less common observation is one where the result value is a date.

Numeric Observation : inherits simple observation
Field	Description
Result date	Date time of the observation eg. Expected date of delivery or date of last period.

 

Procedure

Procedure provides more information beyond a simple observation about an operation or observation relating to the outcome of the procedure.

Within Discovery, unlike FHIR a complex procedure description (that includes body site, laterality, method and nature of device) is represented by a Snomed expression in the observation concept.

Procedure: inherits simple observation
Field	Description
Performed period	Period of time the procedure took
End time	Date and Time procedure ended
Outcome	Concept: Outcome of procedure
Links
Complications	Links to complication observation entries
Follow ups	Links to care plan follow up entries
Linked problems	Links to the observation reasons for procedure
Devices used	List of devices used in the procedure qualified by “main device” or “used device”

Allergy, intolerance and adverse reaction

Allergies, intolerances and adverse substance reactions are grouped together and are extensions of simple observations whereby the simple observation code includes the full concept of the allergy e.g.... “allergy to penicillin”

The additional data relates to more specific information about the substance and reaction.

Allergy : inherits simple observation
Field	Description
Status	Whether active or inactive
End date	Date allergy became inactive
Substance	Concept: indicating the substance that created the adverse reaction or allergy
Manifestation	Concept: indicating the nature of the reaction e.g.... rash, anaphylactic shock
Manifestation description	More detail about the manifestation
Severity	Severity of the reaction or allergy
Links
Observations	Observations associated with the allergic reaction

Immunisation

Immunisation extends a simple observation by providing more information about the immunisation procedure and vaccine used.

This is a summary of immunisation, (expected to be extended)

Immunisation : inherits simple observation
Field	Description
Manufacturer	Manufacturer of vaccine
Batch number	Batch number of vaccine
Expiry date	Expiry data of vaccine
Vaccine product	Concept: of the actual vaccine product
Dose sequence	Number within a sequence (may be deduced)
Doses required	Number of recommended doses in series
Links
Reaction	Link to observation describing reaction to immunisation

Specialised observations - subcomponents

Specialised observation include specific subtypes with extensions that reflect particular types of observations.

In effect these operate as observation components.

A classic example of this is a blood pressure which contains a systolic and diastolic components.

These specialised observations, like specialised encounter types, are modelled to enable machines to detect the present of and search the components of, observational data that are hierarchically arranged.

There is no limit to the degree of componentisation. For example, a 12 lead ECG would have significant subcomponents

Problem

Problem is a patient and record management construct designed to help manage care. The main purposes of problem structures are to highlight significant issues and to group entries in the record to enable a narrative view categorised by a focus of care. In different care domains different terms are used such as “problem”, “issue” or “need” but from a structural perspective they are the same.

A problem is always associated with at least one observation and therefore automatically shares its attribution.

Problem
Field	Description
Problem type	Concept: for the term that the healthcare worker assigns to this construct e.g.... Problem. Issue, need
Status	Terminological construct for the status, whether active inactive, dormant
End Date Time	Date and time problem ended
Significance	Significance assigned to the problem by a user. May be inferred from a knowledge base
Anticipated duration	Whether likely to be temporary permanent, or duration
Links
Parent problem	A problem that this is a child of
Defining observations	Observations that form the title of the problem
Linked entries	Entries in the care record linked to this problem, e.g.... encounters, observations`

 

 

Diagnostic report

A diagnostic report is the set of information that is typically provided by a diagnostic service when investigations are complete. It includes a mix of component events often arranged hierarchically, some structured, some unstructured.

A diagnostic report has a header and set of components

Diagnostic report : inherits health event
Field	Description
Identifier	The report identifier as issued by the issuer of the report
Status	Whether preliminary or final
Report type	Concept: for the type of report
Report issue date	This is an additional date to the clinically effective date.
Service category	Concept: Diagnostic service category
Diagnostic service	Actual service that performed the diagnostic service

components and relationships

Below are the list of common components of a diagnostic report

Diagnostic report : Common components and relationships
Specimen	Specimens associated with the report
Observation results	Observation results within a report including narrative and structured text
Imaging study	Reference to the imaging study
Observation cluster or battery	A battery of results within a report. Note that a diagnostic report itself could be said to be a batter of results. Thus a diagnostic report
Media	List of media associated with the report
Request	The service request this report is associated with

 

Specimen

A specimen definition that is part of a diagnostic report

Specimen
Field	Description
Status	concept : status, for example whether available, unavailable, entered in error.
Specimen identifier	The laboratory issued identifier
Specimen type	Concept: for the type of specimen e.g.... venous  blood
Collection time	Date and time specimen was collected
Received time	Date and time specimen was received into testing department
Method	Concept: the method of specimen collection or taking of the specimen
Fasting status	Concept: Whether specimen taken when fasting
Fasting duration	Duration of the fasting
Specimen volume	Volume of the

Specimen relationships

Specimen relationships : Common components and relationships
Request	A request this specimen is associated with when the specimen is not part of a diagnostic report
Is part of	Specimen that this specimen is part of
container	one or more containers that contain the specimen

Container

Information about a container usually used by specimens that holds a specimen

Container
Field	Description
Container type	Concept: Type of container
Container description	narrative about the specimen container
Container capacity	Volume of the container

 

Medication Statement

Medication statement entries are templates for describing and authorising a course of medication or an intention to prescribe. Medication entries are precursors to the prescribing of a drug (medication order), dispensing of a drug (e.g.... chemist) or the administration of a drug (e.g.... medicine administration by nurse)

In General practice, acute prescriptions are based on medication entries with a single authorisation and repeat medications are based on medication entries with multiple authorisations. In hospital, the drug chart contains the medications.

Medication statement: inherits patient event
Field	Description
Status	Whether active or past (inactive)
Medication	Concept: for the drug or appliance. This may be an actual medicinal product, a virtual medicinal product or a virtual therapeutic moiety
Dosage	May be a free text dosage (one three times a day, or a structured dose concept including: 1) administration times e.g.... 10 am 6 pm)Either 1) administration quantity e.g.... 2 1) administration units e.g.... capsulesAnd.or 1) drug quantity per administration e.g.... 250 1) drug quantity units e.g.... mg
Order Quantity – number of units	Quantity and units For the ensuing prescription order Number of tablets or capsules for the course e.g.... 28, 1
Course type	Whether a repeat, acute , automatic repeat, repeat dispensing
Number repeats authorised	Number of prescriptions authorised as a repeat before medication review required e.g.... 6
Medication review	Review date for this particular medication
Prescription duration	Anticipated Duration of each prescription e.g.... 28
Prescription duration units	Duration units for prescription e.g.... days
Additional instructions	Additional instructions to the patient
Pharmacy instructions	Additional instructions to the pharmacist
Order in heading	Order within the heading in encounter
Management authority	Nature of the domain organisation that manages the administration of this medication e.g.... hospital only
Originated by	Domain type that originated this medication e.g.... Hospital
Reason for ending	Textual or concept reason the medication was ended
End date time	Date and time medication was ended
Links

 

 

Medication order

A medication order is the actual prescription for a medication item. It represents the instance of the order derived from the medication statement. It inherits MOST fields from medication and has some additional items. However, field values for the order may be different from the field values of the medication statement so they are repeated for clarity

Medication order : inherits patient event
Field	Description
Heading	Context heading for entry
Status	Whether active or past (inactive)
Medication	Concept: for the drug or appliance. This may be an actual medicinal product (e.g.... Ventolin HFA 200 mcg inhaler), a virtual medicinal product (e.g.... a generic - salbutamol 200 mg inhaler) or a virtual therapeutic moiety (e.g.... salbutamol 200 mg inhalation)
Dosage	May be a free text dosage (one three times a day) or a structured dose concept including: 1) administration times e.g.... 10 am 6 pm)Either 1) administration quantity e.g.... 2 1) administration units e.g.... capsulesAnd.or 1) drug quantity per administration e.g.... 250 1) drug quantity units e.g.... mg
Order Quantity – number of units	For the ensuing prescription order Number of tablets or capsules for the course e.g.... 28, 1
Order Quantity- units	Unit concept for course e.g.... (28)- capsules, (1) inhaler
Course type	Whether a repeat, acute , automatic repeat, repeat dispensing
Number from authorised count	Number of the prescription as compared to the authorised number in the linked medication (e.g.... 2/6)
Prescription duration	Anticipated Duration of each prescription e.g.... 28
Prescription duration units	Duration units for prescription e.g.... days
Additional instructions	Additional instructions to the patient
Pharmacy instructions	Additional instructions to the pharmacist
Order in heading	Order within the heading in encounter if noted in the encounter
Links

Document

Used to provide the content of a document A medication order is the actual prescription for a medication item. It represents the instance of the order derived from the medication statement. It inherits MOST fields from medication and has some additional items. However, field values for the order may be different from the field values of the medication statement so they are repeated for clarity

Medication : inherits attribution
Field	Description
Document Type	Concept or Text: Type of document
Document content	Text representation of content
Links
Encounter	Encounter linked to this observation
Heading	The heading in which the observation took place
Linked medication	Links to medication that was used as the template

 

Flag

A flag is a warning or notification of some sort presented to the user - who may be a clinician or some other person involve in patient care. It usually represents something of sufficient significance to be warrant a special display of some sort - rather than just a note in an entry

Flag
Field	Description
Status	Status of flag (active, inactive)
Flag category	Concept: Nature of flag for example 1) Flags related to the subject's dietary needs. 1) Flags related to the patient's medications.Used in business logic to determine when the flag is displayed
Flag type	Concept: to describe the flag e.g.... Do not stop taking this medication without professional advice
Text	Alert text
Links
Linked entry	Entry to which the alert relates

 

 

Audit provenance and consent

This section lists the data model entities that relate to the meta data of entries from the perspective of tracking provenance. Also includes matters relating to privacy and consent

Provenance

Discovery tracks data throughout the pipeline including the receipt of the data and the transformation of the data.
Discovery also retains any provenance related information relating to the item as is was originally recorded in the publisher system, including any provenance information that the publisher may have.
Discovery itself, broadly speaking, follows the W3C PROV standard in that it records Entities, activities and agents and any number of relationships between them based on sub-properties of the main W3C provenance relationships.

 

The main entity types and main properties are listed here:

 

Provenance entity

This is a reference to a stored item of data which is of sufficient importance to require a record of provenance. The data may be a record entry, or in the case of a deleted record, the previous entry. In addition, it may point to messages or files that were stored or created as part of the processing of health data.

Provenance entity would normally be subtyped.

Property	Description
Entity identifier	The identifier of the entity in question providing sufficient information to determine the type and location
Common Relationships	Description
was derived from	another entity from which it was derived
was attributed to	an agent that the entity is attributed to e.g..... the author or owner
was generated by	the activity that generated it

 

 

Provenance activity

In order to have generated some data, or changed some data, or deleted some data, some form of activity has taken place. This entity holds the nature of the activity that took place and the date and time it took place. Provenance can be illustrated by providing a timeline of all linked activities, operating as a chain going back in time.

Activities would normally be implemented using activity subtypes

Property	Description
Start time	The date and time the activity started
End time	The date and time the activity ended
Common Relationships	Description
used	The entity the activity used
was associated with	the agent associated with the activity

 

 

Provenance agent

This is a person or thing that performed an activity, or is responsible for an entity. Agents operate in the context of roles, which are represented as properties of the relationship between the agent and the activity.

Agents would normally be supported by subtypes according to the relevant subtype in the entity or activity subtype

Properties	Description
Agent type	The type of agent involved
Agent identifier	The identifier of the agent which might be a DBID or URL
Common Relationships	Description
Acted on behalf of	Links an agent to the organisation (or other agent) that an agent acted on behalf of

 

Abstract classes

This section lists the abstract classes from which most of the other entries inherit. These are best viewed via a the information model viewer, class view as that illustrates the subclass structure of the data model. They are included here for reference.

Health record entry

A health record entry is a high level abstract class and parent class referring to an entry made into a health related record that is controlled by an organisation 9as data controller). It is differentiated (disjoint) with directory entries such as organisations, and structural artefacts (e.g.... quantity measures). 

Health record entry (subclass of data model)
Property	Description
has data controller	The data controller of the entry. This may not be the same as the place the event took place. This is metadata in the sense that it does not add to the description of the event, but is placed here because of its critical importance in sourcing entries
is component of	An record entry this entry might be part of. Subtypes of health record entry have more specialised components. For example, observations may be part of other observations and specialised observations such as a diastolic blood pressure may be a component of the blood pressure.

 

Health event (abstract class)

A health event is an entry that represents something that has happened, or may happen, at a point in time, or over a period of time, related to the health or care or a person.

Most entries on health records are health events. The crucial difference between an event and other entries is that it has a start and an (optional) end i.e may be over a short or long period. When an event is completed the event details do not persist. For entries that make statements that persist (a problem of Angina or active medication) these are state entries modelled in a different category.

Some entries represent inferred states. For example an event entry for an adverse reaction or allergy infers the persistence of the state of allergy.

Health event (subclass of health record entry)
Health event	inherits health record entry
Property	Description
Start date time	The effective start date and time of the event i.e.. the date and time the event took place, and not the date and time it was recorded
End date time	The end date time of the event, if recorded

 

Patient health event

A patient event is a subtype of health event relating to a patient and usually recorded in the context of an encounter, a section within an encounter, or as part of another event

Like a health event it is an abstract class and therefore entries in records are subclasses of this type

Patient event (subclass of health event)
Relationships	Description
has Subject	The patient to whom this event relates. Note that a patient is considered as an individual person in the role of patient with respect of the organisation. There is no requirement to resolve common person identity in published data

 

Structural artefacts

This section deals with entities that are relevant to all parts of the model and include abstract classes from which other structures inherit. This also includes things whith are equivalent to complex data types in FHIR, as well as specialised minor structures