Baseline data set: Difference between revisions

From Endeavour Knowledge Base
No edit summary
 
(131 intermediate revisions by 2 users not shown)
Line 2: Line 2:
Discovery Data Service contains health and care-related data.
Discovery Data Service contains health and care-related data.


These articles describe the nature of the types of data processed by the data service.<span class="mw_htmlentity">&nbsp;</span>
These articles describe the nature of the types of data currently held 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 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 c


= Overview =
<br />


Each main data type is called an entity.<span class="mw_htmlentity">&nbsp;</span>
== Scope of content and approach to categories ==


The entities described here are derived from health records. A health record consists of a set of "entries", each entry describing either an event that has occurred, an event that might occur, or a state. 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 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.&nbsp;


The approach to categorising the data types has been heavily influenced by HL7 FHIR. In this approach, entries are roughly categorised according to the type of business process that the entry describes.
A health record consists of a set of "entries", each entry describing the net result of a set of  machine level events  and is a  statement by the person or device making the record entry.&nbsp;&nbsp;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.


Within the full Discovery information model, entity types are semantically defined in an ontology, and the data model supports unlimited but ontologically controlled extensibility. This provides the potential for holding data at any granular level of specialisation.
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.


Only the broad categories are described here, for the purposes of information. The information model itself describes the extent of properties and their values that are supported at a particular point in time.<br/> &nbsp;
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.
<div>
 
= Generic entities =
Every entity, attribute and value in the model is defined in an ontology - an information model. This article simply tabulates a human approximation to the ontology
</div>  
 
This section deals with entities that are relevant to all parts of the model.
== &nbsp;Individuals ==
<div>
Records of persons, patients and professionals, included related persons.
== <span class="mw-headline" id="Provenance">Provenance</span> ==
 
</div>
=== The patient or person demographic ===
Discovery tracks data throughout the pipeline including the receipt of the data and the transformation of the data.<br/> 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.<br/> 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:
 
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
 
{| border="1"
|-
| colspan="2" |'''Patient / Person'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Property'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''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&nbsp;: 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
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" | Relationships
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''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&nbsp;: 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.
|-
|Is Person
|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
|}<br />
 
=== 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.]]
 
{| border="1"
|-
| colspan="2" |'''Related person'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" | Property
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 400px;" |'''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
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" | Relationships
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 400px;" |'''Description'''
|}
 
 
=== 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
 
{| border="1"
|-
| colspan="2" |'''Practitioner'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''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&nbsp;: 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&nbsp;: 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
|-
| colspan="2" | Linked items
|-
| Contact
| potentially used in contacting the practitioner. Each contact qualified by<br /> Concept&nbsp;: contact type e.g.... home telephone, mobile, email<br /> Contact details e.g.... address or telephone number about the patient to be
|-
| Identifiers
| Identifiers qualified by identifier type and code
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" | Relationships
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
| Work address
| Qualified by concept&nbsp;: address type (e.g.... work address)<br /> The address of the practitioner relevant to the role
|-
|}
 
 
 
=== Team ===
Teams are named groups of individuals that are linked to one or more services
 
&nbsp;
 
{| border="1"
|-
| colspan="2" |'''Team'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
| Team name
| Name of the team
|-
| colspan="2" | Links
|-
| Organisation or services
| The services or organisations this team reports to
|-
| Team members
| Practitioners that are part of the team
|}
&nbsp;
 
== Organisations services and locations ==
 
Records of entities that exist independently of people, including organisations, manufactured devices, services and locations
 
In Discovery, organisations are services 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 from the nature of the information transmitted.
 
The complex interrelationships between organisation locations and properties are illustrated as follows:
 
<br />
[[File:Organisations and locations - Page 1.jpg|center|thumb|800x800px]]
 
=== Organisation ===
An organisation and a service are considered interchangeable. There are a multiplicity of relationships between then which enable organisations to be differentiated from services. For example an organisation may commission services from another organisation and an organisation may provide services independently of whether that have been purchased.
 
Organisational relationships types form a  small ontology in their own right and therefore are not listed here
{| border="1"
|-
| colspan="2" |'''Organisation or service'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''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<br /> May be deduced when populating the organisational structures and relationships
|-
| Speciality
| The Speciality of the service e.g.... Cardiology
|-
| colspan="2" | Links
|-
| 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
|}
 
&nbsp;
 
=== Location ===
 
Information about an actual location, building or entity that is related to the organisation that operates from it
 
{| border="1"
|-
| colspan="2" |'''Location'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''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
|-
| colspan="2" | 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
|}
 
&nbsp;
 
== Provision of care ==
Records of the processes involved in the the provision of care for patients.
 
=== 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.
 
{| border="1"
|-
| colspan="2" |'''Care Episode (inherits patient event)'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''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<br /> May be inferred or derived from structured entry<br /> For example, a GP regular GMS patient or a temporary resident
|-
| Status
| Whether currently active (i.e.. no end date) or inactive
|-
| colspan="2" | Links
|-
| Initiating Referral
| A Link to the originating referral, whether self-referred, ambulance, GP referral etc.<br /> 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
|}<br />
=== 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.
 
{| border="1"
|-
| colspan="2" |'''General practice registration'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
| Status
| Status of registration or care episode processing<br /> 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
|}
 
&nbsp;
 
=== 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.


'''Provenance entity'''
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.


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.
&nbsp;


{| align="left" border="1" cellpadding="1" cellspacing="1" style="width: 748px;"
{| border="1"
|-
| colspan="2" |'''Encounter: (inherits patient event)'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
|-
! scope="col" style="text-align: left;background-color:#efefef" | Property
| Encounter Type
! scope="col" style="width: 651px;background-color:#efefef" | '''Description'''
| The overall nature of the encounter mapped to the encounter type ontology
|-
|-
| Entity type
| Completion Status
| style="width: 651px;" | The type of entity that is the provenance of&nbsp;
| 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
|-
|-
| Entity location
| End Date/ time
| style="width: 651px;" | The actual location of the entity which may be a database ID or URL
| 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<br /> 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)<br /> For example a branch surgery of a GP practice or bed 1, Ward 10
|-
| colspan="2" | 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
|}
|}


&nbsp;
&nbsp;
=== Specialised encounters ===
Within acute care and many specialities, 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


&nbsp;
&nbsp;


{| border="1"
|-
| colspan="2" |'''Example of encounter subtype extension properties'''
|-
|'''Encounter subtype'''
| colspan="2" |'''Sub Type of subtype'''
|'''Sub type Properties'''
|-
| Hospital encounter
| colspan="2" | Accident and emergency encounter
| a&e category of attendance<br /> a&e attendance source<br /> arrival mode'<br /> treatment function for service for which admitted
|-
|
&nbsp;
&nbsp;


'''Provenance activity'''
| colspan="2" | Critical Care Encounter
| critical care unit function<br /> admission source
|-
|
&nbsp;


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.
| colspan="2" | Hospital Outpatient attendance
| attendance status<br /> attendance outcome<br /> treatment function type
|}
 
&nbsp;
 
=== Referral Request or procedure request&nbsp; ===
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
 
{| border="1"
|-
| colspan="2" |'''Referral request&nbsp;: inherits patient event'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''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
|-
| colspan="2" | Links
|-
| Linked episode
| Linked care episode for which this is the originating referrals
|}
 
&nbsp;
 
== Scheduling of care ==
Records of the scheduling of the provision of care i.e. appointments
 
=== 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
 
{| border="1"
|-
| colspan="2" |'''Appointment schedule&nbsp;: inherits attribution'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''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
|-
| colspan="2" | Links
|-
| Linked appointment slots
| Linked appointments to the schedule
|-
| Practitioners
| Practitioners linked to this schedule
|}
 
=== Appointment (slot) ===
 
This is information about a particular appointment or slot as planned. The slot creation shares attribution with the schedule


{| align="left" border="1" cellpadding="1" cellspacing="1" style="width: 748px;"
{| border="1"
|-
| colspan="2" |'''Appointment'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
| Appointment category
| Concept: describing what type of appointment in terms of routine, urgent etc
|-
|-
! scope="col" style="text-align: left;background-color:#efefef" | Property
| Planned Reason
! scope="col" style="background-color:#efefef" | '''Description'''
| Concept: of reason for appointment from the appointment planning perspective
|-
|-
| Activity type
| Description
| style="width: 651px;" | The type of activity
| Any text description for the appointment slot
|-
|-
| Start time
| Start time
| style="width: 651px;" | The date and time the activity started
| Start date and time of slot
|-
|-
| End time
| End time
| style="width: 651px;" | The date and time the activity ended
| 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
|-
| colspan="2" | Links
|-
| Linked schedule
| Links to the schedule containing the appointment
|-
| Booking history
&nbsp;
 
| Links to booking history including<br /> Booked&nbsp;:cancelled<br /> Date and Time of booking
|-
| Attendance history
| Links to the attendance status history
|}
|}


&nbsp;
&nbsp;
=== Appointment attendance history ===
Historical Information about an actual attendance for a patient for an appointment i.e.. after the patient has arrived for appointment
{| border="1"
|-
| colspan="2" |'''Appointment attendance history'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''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
|-
| colspan="2" | Links
|-
| Appointment slot
| Links to the appointment slot
|}


&nbsp;
&nbsp;
<br />
== Patient characteristics ==
Records about the observations or assessments about the patient that include both clinical, social and other broader characteristics
<br />
=== 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
{| border="1"
|-
| colspan="2" |'''Simple Observation&nbsp;: inherits patient event'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
| Observation concept
| Concept: Nature of the observation, e.g.... sign, symptom, aim, target, goal , test header, or specialist type e.g.... blood pressure.<br /> 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<br /> 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)
|-
| colspan="2" | Links
|-
| Linked problems
| The problems the observation may be linked to including 1) Concept&nbsp;: Nature of link e.g.... evolved from 1) Problem
|-
| Flag
| Any flags associated with the entry
|}


&nbsp;
&nbsp;
==== Numeric observation ====
One of the commonest observations are pathology results and they often have numeric values as results. They extend simple observations
{| border="1"
|-
| colspan="2" |'''Numeric Observation&nbsp;: inherits simple observation'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''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&nbsp;: Units of measurements
|}


&nbsp;
&nbsp;


'''Provenance agent'''
==== Date time observation ====


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.
A less common observation is one where the result value is a date.


{| align="left" border="1" cellpadding="1" cellspacing="1" style="width: 748px;"
{| border="1"
|-
|-
! scope="col" style="text-align: left;background-color:#efefef" | Property
| colspan="2" |'''Numeric Observation&nbsp;: inherits simple observation'''
! scope="col" style="background-color:#efefef" | '''Description'''
|-
|-
| Agent type
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
| style="width: 651px;" | The type of agent involved
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
|-
| Agent identifier
| Result date
| style="width: 651px;" | The identifier of the agent which might be a DBID or URL
| Date time of the observation eg. Expected date of delivery or date of last period.
|}
|}


&nbsp;
&nbsp;


&nbsp; &nbsp;
==== Specialised observations - sub components ====


Specialised observation include specific subtypes with extensions that reflect particular types of observations.
In effect these operate as observation components but may be modelled in a way that describes a preferred arrangement for particular purposes. These are sometimes referred to as archetypes.
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 specialisation. For example, a 12 lead ECG would have significant subcomponents
=== Allergy, intolerance and adverse reaction ===
Allergies, intolerance 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.
{| border="1"
|-
| colspan="2" |'''Allergy&nbsp;: inherits simple observation'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''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
|-
| colspan="2" | Links
|-
| Observations
| Observations associated with the allergic reaction
|}
<br />
=== Problem or condition ===
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.
{| border="1"
|-
| colspan="2" |'''Problem'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''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
|-
| colspan="2" | Links
|-
| Parent problem
| A problem that this is a child of
|-
| Defining observations
&nbsp;
&nbsp;
| Observations that form the title of the problem
|-
| Linked entries
| Entries in the care record linked to this problem, e.g.... encounters, observations`
|}


&nbsp;
&nbsp;


'''Main Provenance relationships'''
==&nbsp;Diagnostics and investigations ==
Records relating to investigations and the various ways the investigation results are packaged up. Includes records of the things used in the investigations or how they were performed. In effect they are structured containers of other types of entries with various specialised subtypes
 
=== 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.


This is a high-level listing of the types of relationships between the provenance objects. An ontology of relationships can be viewed in the information model viewer
A diagnostic report has a header and set of components


{| align="left" border="1" cellpadding="1" cellspacing="1" style="width: 748px;"
{| border="1"
|-
| colspan="2" |'''Diagnostic report&nbsp;: inherits health event'''
|-
|-
! scope="col" style="text-align: left;background-color:#efefef" | Relationship
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="background-color:#efefef" | '''Description'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
|-
| Derived from
| Identifier
| style="width: 651px;" | Links an entity to another entity from which it was derived
| The report identifier as issued by the issuer of the report
|-
|-
| Generated by
| Status
| style="width: 651px;" | Links an entity to the activity that generated it
| Whether preliminary or final
|-
|-
| Attributed to
| Report type
| style="width: 651px;" | Links an entity to an agent that the entity is attributed to e.g. the author or owner
| Concept: for the type of report<br /> &nbsp;
|-
|-
| Was associated with
| Report issue date
| style="width: 651px;" | Links an activity to the agent that it was associated with, e.g. who performed it, including the role the agent was performing in
|  
This is an additional date to the clinically effective date.&nbsp;
 
|-
|-
| Acted on behalf of
| Service category
| style="width: 651px;" | Links an agent to the organisation (or other agent) that an agent acted on behalf of
| Concept: Diagnostic service category
|-
| Diagnostic service
| Actual service that performed the diagnostic service
|-
|&nbsp;
|&nbsp;
|}
|}


&nbsp;
==== Diagnostic report components and relationships ====
 
Below are the list of common components of a diagnostic report
 
{| border="1"
|-
| colspan="2" |'''Diagnostic report&nbsp;: 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


&nbsp;
|-
| Media
| List of media associated with the report
|-
| Request
| The service request this report is associated with
|}


&nbsp;
&nbsp;


== &nbsp; ==
=== Specimen ===


== &nbsp; ==
A specimen definition that is part of a diagnostic report


== &nbsp; ==
{| border="1"
|-
| colspan="2" |'''Specimen'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
| Status
| concept&nbsp;: 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&nbsp; blood<br /> &nbsp;
|-
| Collection time
| Date and time specimen was collected
|-
| Received time
| Date and time specimen was received into testing department
|-
| Method&nbsp;
| 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&nbsp;
|}


== &nbsp; ==
==== Specimen relationships ====
Specimens have some specialised relationships with other components
{| border="1"
|-
| colspan="2" |'''Specimen relationships&nbsp;: 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&nbsp;
|-
| container
| one or more containers that contain the specimen
|}


== Health Event ==
=== Container ===


A health event is an abstract class referring to 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.
Information about a container usually used by specimens that holds a specimen
<div>
= Individuals organisations devices and locations =


" data-mw-type="tag" data-mw-id="149991" data-mw-name="h1" data-mw-wikitext="%3Ch1%3EIndividuals%20organisations%20devices%20and%20locations%3C/h1%3E" contenteditable="false">
{| border="1"
|-
| colspan="2" |'''Container'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
| Container type
| Concept: Type of container
|-
| Container description
| narrative about the specimen container
|-
| Container capacity
| Volume of the container
|}


= <span class="mw-headline" id="Individuals_organisations_devices_and_locations">Individuals organisations devices and locations</span> =
<br />
</span></div>
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.
<div><span id="<@@@BTAG171239@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== The patient or person demographic ==


" data-mw-type="tag" data-mw-id="171239" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EThe%20patient%20or%20person%20demographic%3C/h2%3E" contenteditable="false">
== Treatment or intervention ==
Records of treatment and actions by health and care workers, including clinical activities, health prevention activities and the planing of care. There is significant overlap between these entries and observations. For example an entry may be an observation that an intervention took place. These type of entries tend to have special attributes that make them significantly different from normal observations.


== <span class="mw-headline" id="The_patient_or_person_demographic">The patient or person demographic</span> ==
=== Immunisation ===
</span></div>
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)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Note that in Discovery, a patient is considered as person in a role of patient (or client) in relation to ONE publisher.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Patient / Person<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>NHS Number The NHS number allocated to the patient<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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”<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Date of birth Date of birth of the patient, as far as is known<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Death indicator If a patient has died an indicator that they are now dead<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Date of Death If dead and if available, the date of death<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>PDS sensitive Flag to indicate whether the patient is marked as sensitive on the spine <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked items<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Address One or more entries including<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Qualified by Concept: address type (e.g. home address)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• The address of the patient relevant to the episode of care.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Status of the address<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• The date the address was valid from<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• The date the address was valid to<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Contact potentially used in contacting the patient, each contact qualified by <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Concept&nbsp;: contact type e.g. home telephone, mobile, email <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Contact details e.g. email address or telephone number about the patient<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Ethnicity Concept: Held in Discovery as an observation about the patient, indication as to the ethnic group the patient is part of<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Language Concept&nbsp;: 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<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked identifiers Identifiers – qualified by identifier type<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked relationships Linked relations
<div><span id="<@@@BTAG198643@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== The practitioner in role ==


" data-mw-type="tag" data-mw-id="198643" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EThe%20practitioner%20in%20role%3C/h2%3E" contenteditable="false">
Immunisation extends a simple observation by providing more information about the immunisation procedure and vaccine used.


== <span class="mw-headline" id="The_practitioner_in_role">The practitioner in role</span> ==
This is a summary of immunisation, (expected to be extended)
</span></div>
This term refers to any person who provides care or is part of the health care process, excluding personally engaged or family carers. <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span> 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<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Practitioner<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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”<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Gender Concept&nbsp;: 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<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Date of birth Date of birth of the patient, as far as is known<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Address Qualified by concept&nbsp;: address type (e.g. work address)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>The address of the practitioner relevant to the role<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Active/ Inactive An indication of whether the practitioner is active in the role or not<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Service or organisation The service or organisation that the practitioner is operating in relation to a particular role<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Role type Concept&nbsp;: The type of role e.g. Doctor, nurse, receptionist, secretary that the practitioner operates as in this role<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Speciality Concept: The speciality of the practitioner (e.g. Cardiologist) <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Contract period Start and end dates of contract with the organisation<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked items<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Contact potentially used in contacting the practitioner. Each contact qualified by <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Concept&nbsp;: contact type e.g. home telephone, mobile, email <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Contact details e.g. address or telephone number about the patient to be <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Identifiers Identifiers qualified by identifier type and code
<div><span id="<@@@BTAG118139@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== Family and kin Relationships ==


" data-mw-type="tag" data-mw-id="118139" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EFamily%20and%20kin%20Relationships%3C/h2%3E" contenteditable="false">
{| border="1"
|-
| colspan="2" |'''Immunisation&nbsp;: inherits simple observation'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
|
&nbsp;


== <span class="mw-headline" id="Family_and_kin_Relationships">Family and kin Relationships</span> ==
|
</span></div>
&nbsp;
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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Relationships (inherits attribution)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Related person information Information about the target person which may include Name, address, contact details<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Relationship type Concept: Relationship with source. 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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Status Status of relationship<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Related in Discovery Whether the related person is in Discovery or not<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Related patient Target may be a person in the Discovery Data service
<div><span id="<@@@BTAG144483@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== Related person ==


" data-mw-type="tag" data-mw-id="144483" data-mw-name="h2" data-mw-wikitext="%3Ch2%3ERelated%20person%3C/h2%3E" contenteditable="false">
|-
| 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
|-
| colspan="2" | Links
|-
| Reaction
| Link to observation describing reaction to immunisation
|}


== <span class="mw-headline" id="Related_person">Related person</span> ==
<br />
</span></div>
A related person may not be a patient in the Discovery service in which case the details of that person would be held independently<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Related person<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Name Name of related person<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Address Address of related person<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Contact Contact details of related person<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Family and kin relationships Information about the patient and the relationship typ<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Identifiers Identifiers of the related person (e.g. NHS number)
<div><span id="<@@@BTAG139089@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== Device ==


" data-mw-type="tag" data-mw-id="139089" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EDevice%3C/h2%3E" contenteditable="false">
=== Procedure ===
Procedure provides more information beyond a simple observation about an operation or observation relating to the outcome of the procedure.


== <span class="mw-headline" id="Device">Device</span> ==
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.
</span></div>
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<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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 <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Device<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Device Name Device name<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>UDI human readable Human readable bar code identifier<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>UDI machine readable Machine readable bar code<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Manufacturer Manufacturer of device e.g. business organisation<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Serial number Serial number of device<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Device type Concept: for the nature of the device e.g. cardiac pacemaker<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>This may be at any level of granularity as the information model uses additional attributes to fully define the device<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Device version Version of the device (e.g. software version if the device is software)
<div><span id="<@@@BTAG105634@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== Organisations departments and services ==


" data-mw-type="tag" data-mw-id="105634" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EOrganisations%20departments%20and%20services%3C/h2%3E" contenteditable="false">
{| border="1"
|-
| colspan="2" |'''Procedure: inherits simple observation'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
| Performed period
| Period of time the procedure took
|-
| End time
| Date and Time procedure ended
|-
| Outcome
| Concept: Outcome of procedure
|-
| colspan="2" | 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”
|}


== <span class="mw-headline" id="Organisations_departments_and_services">Organisations departments and services</span> ==
===<span style="font-size: 13px;">Medication authorisations or courses</span>===
</span></div>
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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Organisation or service<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Organisation identifier The nationally provided identifier or “ODS” code for the organisation or service if it exists<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Name Name of the organisation or service<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Address The address of the organisation or service<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Contact details Main contact for the service itself e.g. main telephone number<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Organisation/ service category Whether this is an organisation (e.g. Barts NHS Trust, Roya London Hospital) or a service e.g. Barts physiotherapy service or cardiology department<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>May be deduced when populating the organisational structures and relationships<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Speciality The speciality of the service e.g. Cardiology<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked Organisation A set of relationships between one organisational service entity and another each consisting of<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• A relationship type such as “part of” or “provided by” e.g. Royal London Hospital is “part of”<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• A target organisation e.g. “Barts NHS Health Trust”<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Used to populate the organisational structures in the information model<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Contacts Contact details for a person or team or department associated with the organisation consisting of<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Name<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Contact details<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Location Locations associated with the organisation<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Identifiers Other organisational identifiers
<div><span id="<@@@BTAG162379@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== Location ==


" data-mw-type="tag" data-mw-id="162379" data-mw-name="h2" data-mw-wikitext="%3Ch2%3ELocation%3C/h2%3E" contenteditable="false">
<span style="font-size: 13px;">Also referred as Medication statement entries, these are entries 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)</span>


== <span class="mw-headline" id="Location">Location</span> ==
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.
</span></div>
Information about an actual location, building or entity that is related to the organisation that operates from it <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Location<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Location identifier The nationally provided identifier for a location<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Name Name of the location<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Address The address of the organisation or service<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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 <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Organisation A set of relationships between one organisational service and location consisting of<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Contacts Contact details for a person or team or department associated with the location e,g, building maintenance, consisting of<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Name<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Contact details
<div><span id="<@@@BTAG191914@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== Team ==


" data-mw-type="tag" data-mw-id="191914" data-mw-name="h2" data-mw-wikitext="%3Ch2%3ETeam%3C/h2%3E" contenteditable="false">
{| border="1"
|-
| colspan="2" |'''Medication statement: inherits patient event'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
| Status
| Whether active or past (inactive)
|-
| Medication
| Concept: for the drug or appliance.<br /> 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:<br /> 1) administration times e.g.... 10 am 6 pm)Either<br /> 1) administration quantity e.g.... 2 1) administration units e.g.... capsulesAnd.or<br /> 1) drug quantity per administration e.g.... 250 1) drug quantity units e.g.... mg
&nbsp;


== <span class="mw-headline" id="Team">Team</span> ==
|-
</span></div>
| Order Quantity – number of units
Teams are named groups of individuals that are linked to one or more services<br/> Team<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Team name Name of the team<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Organisation or services The services or organisations this team reports to<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Team members Practitioners that are part of the team
| Quantity and units For the ensuing prescription order Number of tablets or capsules for the course e.g.... 28, 1
<div><span id="<@@@BTAG178189@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
|-
= Health event subtypes =
| 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
|-
| colspan="2" | Links
|}
 
&nbsp;
 
&nbsp;
 
=== 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
 
{| border="1"
|-
| colspan="2" |'''Medication order&nbsp;: inherits patient event'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
| Heading
| Context heading for entry
|-
| Status
| Whether active or past (inactive)
|-
| Medication
| Concept: for the drug or appliance.<br /> 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)<br /> or a structured dose concept including:<br /> 1) administration times e.g.... 10 am 6 pm)Either<br /> 1) administration quantity e.g.... 2 1) administration units e.g.... capsulesAnd.or<br /> 1) drug quantity per administration e.g.... 250 1) drug quantity units e.g.... mg
&nbsp;


" data-mw-type="tag" data-mw-id="178189" data-mw-name="h1" data-mw-wikitext="%3Ch1%3EHealth%20event%20subtypes%3C/h1%3E" contenteditable="false">
|-
| 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
|-
| colspan="2" | Links
|}<br />
 
== Decision support ==
Items that help directly to support decisions about the care of patients.They may be direct entries or derived from other entries following the application od decision support algorithms&nbsp;
 
=== 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


= <span class="mw-headline" id="Health_event_subtypes">Health event subtypes</span> =
{| border="1"
</span></div>
|-
This section covers events that describe various health or care events, most but not all relating to a patient.
| colspan="2" |'''Flag'''
<div><span id="<@@@BTAG142032@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
|-
== Patient event ==
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
| Status
| Status of flag (active, inactive)
|-
| Flag category
| Concept: Nature of flag for example<br /> 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....<br /> Do not stop taking this medication without professional advice
|-
| Text
| Alert text
|-
| colspan="2" | Links
|-
| Linked entry
| Entry to which the alert relates
|}


" data-mw-type="tag" data-mw-id="142032" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EPatient%20event%3C/h2%3E" contenteditable="false">
&nbsp;


== <span class="mw-headline" id="Patient_event">Patient event</span> ==
&nbsp;<div>
</span></div>  
== Audit provenance and consent ==
A patient event is a subtype of care 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<br/> Patient event (inherits health event)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Subject The patient to whom this event relates.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Note that a patient is considered as an individual person in the role of patient with respect of the organisation.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>There is no requirement to resolve common person identity in published data<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Part of An event that this event might be part of<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Encounter An encounter that this event might be part of<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>In section The section of the encounter that this event is placed in<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Part of problem The problem which this event may be linked to
Entries that record the meta data of entries from the perspective of tracking provenance. Also includes matters relating to privacy and consent
<div><span id="<@@@BTAG109646@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
= Care process related events =


" data-mw-type="tag" data-mw-id="109646" data-mw-name="h1" data-mw-wikitext="%3Ch1%3ECare%20process%20related%20events%3C/h1%3E" contenteditable="false">
===<span class="mw-headline" id="Provenance">Provenance</span>===
</div>
Discovery tracks data throughout the pipeline including the receipt of the data and the transformation of the data.<br />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.<br /> 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.[[File:Provenance simple.png|center|600x400px|Provenance simple.png]]


= <span class="mw-headline" id="Care_process_related_events">Care process related events</span> =
&nbsp;
</span></div> <div><span id="<@@@BTAG116275@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== Episode of care ==


" data-mw-type="tag" data-mw-id="116275" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EEpisode%20of%20care%3C/h2%3E" contenteditable="false">
The main entity types and main properties are listed here:


== <span class="mw-headline" id="Episode_of_care">Episode of care</span> ==
&nbsp;
</span></div>
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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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.<br/> Care Episode (inherits patient event)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>May be inferred or derived from structured entry<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>For example, a GP regular GMS patient or a temporary resident<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Status Whether currently active (i.e. no end date) or inactive<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Initiating Referral A Link to the originating referral, whether self-referred, ambulance, GP referral etc. <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>May be inferred from encounter information e.g. referral accepted, emergency admission<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Care episode Administration One or more links to care episode or registration administration processes that occur during the period of the care episode<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked Entries All encounters and many other entries may be linked to the care episode
<div><span id="<@@@BTAG124841@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== General practice registration ==


" data-mw-type="tag" data-mw-id="124841" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EGeneral%20practice%20registration%3C/h2%3E" contenteditable="false">
==== Provenance entity ====


== <span class="mw-headline" id="General_practice_registration">General practice registration</span> ==
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.
</span></div>
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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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. <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>General practice registration <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Status Status of registration or care episode processing<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>e.g. registration submitted, notification of registration, deduction received, deducted <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Status sub-type Granular subtypes of the status e.g. “death”, “embarkation” or “armed forces” when patient is deducted<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Patient type Type of patient from the perspective of administration e.g. GMS patient, temporary resident
<div><span id="<@@@BTAG106100@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== Encounter ==


" data-mw-type="tag" data-mw-id="106100" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EEncounter%3C/h2%3E" contenteditable="false">
Provenance entity would normally be subtyped.


== <span class="mw-headline" id="Encounter">Encounter</span> ==
{| border="1" cellpadding="1" cellspacing="1" style="width: 748px;"
</span></div>
|-
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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Encounters are often defined according to the publisher’s definition or even the nature of the IT system in use.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>In Discovery an encounter model is a superset of the different encounter models from the different domains and systems. The different patterns are differentiated by the use of Encounter types or archetypes.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Similarly an accident and emergency attendance may have a subsidiary encounter for the initial assessment.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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.<br/> Encounter: (inherits patient event)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Encounter Type The overall nature of the encounter mapped to the encounter type ontology<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Completion Status Concept: Status of encounter when this event is sent. It may be completed or ongoing or planne. In some systems encounters are created before they commence<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>End Date/ time Date time encounter ended<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Duration In the absence of an explicit start and end time, the duration may be estimated<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Providing Organisation/ services or departments Additional department and/ or services that define the encounter more fully than the main organisation<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>An entry may have a main organisation of Royal London, but the encounter may take place in the Royal London A<span class="mw_htmlentity">&</span>E department<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>For example a branch surgery of a GP practice or bed 1, Ward 10 <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked appointment The appointment to which the encounter may be related<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Subsidiary of An encounter that the encounter may be part of or sub<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked care episode The care episode the encounter is linked to.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Additional Practitioners Additional practitioners other than the main attributed practitioner involved in the encounter
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" | Property
<div><span id="<@@@BTAG179543@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
! scope="col" style="width: 553px; background-color: rgb(239, 239, 239);" |'''Description'''
== Context Headings or sections in encounters ==
|-
| style="width: 181px;" | Entity identifier
| style="width: 553px;" | The identifier of the entity in question providing sufficient information to determine the type and location
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Common Relationships'''
! scope="col" style="width: 553px; background-color: rgb(239, 239, 239);" |'''Description'''
|-
|&nbsp;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
|}


" data-mw-type="tag" data-mw-id="179543" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EContext%20Headings%20or%20sections%20in%20encounters%3C/h2%3E" contenteditable="false">
&nbsp;


== <span class="mw-headline" id="Context_Headings_or_sections_in_encounters">Context Headings or sections in encounters</span> ==
&nbsp;
</span></div>
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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Section<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Heading type Concept: for the heading<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>e.g.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Clinician entry/ Examination/ CVS Examination<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>CDS Entry/ Primary Diagnosis<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Clinician entry/ Past procedures<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Parent heading Link to the parent heading<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Order Order of heading in relation to its parent for display purposes<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked encounter The encounter that contains the heading
<div><span id="<@@@BTAG133813@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== Referral Request or procedure request ==


" data-mw-type="tag" data-mw-id="133813" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EReferral%20Request%20or%20procedure%20request%3C/h2%3E" contenteditable="false">
==== Provenance activity ====


== <span class="mw-headline" id="Referral_Request_or_procedure_request">Referral Request or procedure request</span> ==
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.
</span></div>
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 <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Referral inherits attribution<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Referral request &nbsp;: inherits patient event<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Priority Concept: Priority of referral request<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Referred by type Concept: The type of source the transfer originated as e.g. self referral, healthcare professional referral<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Source organisation Sender service or organisation<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Speciality requested Concept: the speciality of the referral request<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Procedure or Service type requested Concept: If available, the nature of the service requested e.g. Nephrology, chest xray<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Request Reason e.g. The clinical condition or problem that is reason for referral<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Recipient service or organisation The referral recipient organisation or service e.g. hospital or department<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Recipient location Location of the recipient<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Recipient practitioner If referred to a person, the practitioner<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Referral UBRN Unique referral booking number<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Referral mode Concept: Means of referral e.g. Verbal, written, ERS<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked episode Linked care episode for which this is the originating referrals
<div><span id="<@@@BTAG177525@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== Appointment session ==


" data-mw-type="tag" data-mw-id="177525" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EAppointment%20session%3C/h2%3E" contenteditable="false">
Activities would normally be implemented using activity subtypes


== <span class="mw-headline" id="Appointment_session">Appointment session</span> ==
{| border="1" cellpadding="1" cellspacing="1" style="width: 748px;"
</span></div>
|-
An appointment session is an appointment grouping implying a session or a clinic, which incorporates a number of appointments<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Appointment schedule&nbsp;: inherits attribution<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Organisation or service Organisation or service responsible for this schedule<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Location Location for the schedule<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Schedule type Concept: for the type of schedule e.g. diabetic review<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Schedule description Textual description of the schedule e.g. Dr Jone’s acupuncture clinic<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Speciality Speciality associated with the schedule<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Start date/ time Planned start date/ time of schedule<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>End date/time End date time of schedule<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked appointment slots Linked appointments to the schedule<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Practitioners Practitioners linked to this schedule
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 200px;" | Property
<div><span id="<@@@BTAG170886@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="  
! scope="col" style="background-color: rgb(239, 239, 239); width: 585px;" |'''Description'''
== Appointment ==
|-
| style="width: 150px;" | Start time
| style="width: 585px;" | The date and time the activity started
|-
| style="width: 150px;" | End time
| style="width: 585px;" | The date and time the activity ended
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 200px;" |'''Common Relationships'''
! scope="col" style="background-color: rgb(239, 239, 239); width: 585px;" |'''Description'''
|-
| style="width: 150px;" | used
| style="width: 585px;" | The entity the activity used
|-
| style="width: 150px;" | was associated with
| style="width: 585px;" | the agent associated with the activity
|}


" data-mw-type="tag" data-mw-id="170886" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EAppointment%3C/h2%3E" contenteditable="false">
&nbsp;


== <span class="mw-headline" id="Appointment">Appointment</span> ==
&nbsp;
</span></div>
This is information about a particular appointment or slot as planned. The slot creation shares attribution with the schedule<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Appointment <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Appointment category Concept: describing what type of appointment in terms of routine, urgent etc<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Planned Reason Concept: of reason for appointment from the appointment planning perspective <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Description Any text description for the appointment slot<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Start time Start date and time of slot<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>End time End date and time of slot<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Planned duration Planned duration of appointment (may or may not be timed)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Patient Patient booked into the slot<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Slot booking status Whether booked, reserved, free<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Attendance status Whether the patient arrived, sent for, left<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Booking urgency Indication as to whether it was booked as an urgent appointment (whether the appointment was marked as urgent or not<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Interaction type Whether face to face, telephone, skype etc<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked schedule Links to the schedule containing the appointment<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Booking history<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span> Links to booking history including<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Booked&nbsp;:cancelled<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Date and Time of booking<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Attendance history Links to the attendance status history
<div><span id="<@@@BTAG158961@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== Appointment booking history ==


" data-mw-type="tag" data-mw-id="158961" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EAppointment%20booking%20history%3C/h2%3E" contenteditable="false">
==== Provenance agent ====


== <span class="mw-headline" id="Appointment_booking_history">Appointment booking history</span> ==
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.
</span></div>
Information about booking and unbooking of an actual appointment prior to the patient attending<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Date and time of booking and by whom are attributed in attribution fields.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>The latest entry represents the information prior to the patient arriving or appointment attendance<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Appointment booking: inherits attribution<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Booking or cancellation Whether this is a booking or a cancellation<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Patient Patient booked into slot<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Booking urgency Whether the appointment was urgent (whether or not reserved as an urgent slot)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Patient related reason Reason for appointment from patient’s perspective (i.e. if booked)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Interaction type The actual interaction type when booked (e.g. telephone)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Appointment slot Link to the appointment slot
<div><span id="<@@@BTAG112128@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== Appointment attendance history ==


" data-mw-type="tag" data-mw-id="112128" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EAppointment%20attendance%20history%3C/h2%3E" contenteditable="false">
Agents would normally be supported by subtypes according to the relevant subtype in the entity or activity subtype


== <span class="mw-headline" id="Appointment_attendance_history">Appointment attendance history</span> ==
{| border="1" cellpadding="1" cellspacing="1" style="width: 748px;"
</span></div>
|-
Historical Information about an actual attendance for a patient for an appointment i.e. after the patient has arrived for appointment<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Appointment attendance history<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Status Concept: the status e.g. <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Patient Patient<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>start time The actual start time of this status<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>end time The actual end time of this status<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Actual duration The actual duration of the appointment<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Actual interaction type Nature of the actual interaction<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Appointment slot Links to the appointment slot
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 200px;" | Properties
<div><span id="<@@@BTAG142574@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
! scope="col" style="background-color: rgb(239, 239, 239); width: 599px;" |'''Description'''
== Care plan ==
|-
| style="width: 135px;" | Agent type
| style="width: 599px;" | The type of agent involved
|-
| style="width: 135px;" | Agent identifier
| style="width: 599px;" | The identifier of the agent which might be a DBID or URL
|-
! style="text-align: left; background-color: rgb(239, 239, 239); width: 200px;" |'''Common Relationships'''
! style="text-align: left; background-color: rgb(239, 239, 239); width: 135px;" |'''Description'''
|-
| style="width: 135px;" | Acted on behalf of&nbsp;
| style="width: 599px;" | Links an agent to the organisation (or other agent) that an agent acted on behalf of
|}


" data-mw-type="tag" data-mw-id="142574" data-mw-name="h2" data-mw-wikitext="%3Ch2%3ECare%20plan%3C/h2%3E" contenteditable="false">
&nbsp;


== <span class="mw-headline" id="Care_plan">Care plan</span> ==
== Correspondence and communication ==
</span></div>
Structures that support the exchange of information between professionals or between professionals and patients.
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<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Care plan &nbsp;: inherits attribution<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Document Status Whether the plan is draft, active, no longer active<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Type of plan Concept: for the type of care plan. For example, Asthma action plan, Cancer management plan<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Description Description of plan<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Time period The start and end date or period of the plan (the start date may precede the effective date)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked Headings Heading categorised, Activities, goals targets, observations linked to the plan<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked episodes Care episodes linked to the plan<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Parent plan Care plans this plan is part of<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Associated practitioners Additional practitioners or teams associated with the plan<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Associated teams Links to teams associated with plan <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked activities Links to care activities<br/> <br/> Care plan activities<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>These are modelled as observation types such as <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Activity<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Goal<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Target 
<div><span id="<@@@BTAG199117@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
= Clinical health events =


" data-mw-type="tag" data-mw-id="199117" data-mw-name="h1" data-mw-wikitext="%3Ch1%3EClinical%20health%20events%3C/h1%3E" contenteditable="false">
=== Document or composition ===
A structure of a document. This is a light weight definition as documents tend to specialise very quickly to many types, even in the context of a single provider.


= <span class="mw-headline" id="Clinical_health_events">Clinical health events</span> =
{| border="1"
</span></div>
|-
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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>In the Discovery model clinical data is modelled around observations i.e. different types of clinical characteristics inherit from simple observations.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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.
| colspan="2" |'''Document'''
<div><span id="<@@@BTAG153014@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
|-
== Observation ==
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
| Document Type
| Concept or Text: Type of document
|-
| Document content
| Text representation of content
|-
| colspan="2" | Links
|-
| Section
| The section, usually with a heading, used to structure the document
|-
| Component
| A reference to another entry, a copy of an entry, or the original entry of a component in the document
|}<br />
=== Care plan ===


" data-mw-type="tag" data-mw-id="153014" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EObservation%3C/h2%3E" contenteditable="false">
A dynamic document that notes the plan regarding the care of a patient. As in the document structure they tend to specialise and thus this highlights only the generic sections.


== <span class="mw-headline" id="Observation">Observation</span> ==
{| border="1"
</span></div>
|-
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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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. <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>The type of observation is deduced from the observation concept itself. <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>For example, a blood pressure would be modelled as 3 observations as follows:<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Observation 1 Blood pressure<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Observation 2 Systolic blood pressure value= 120, part of observation 1<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Observation 3 Diastolic blood pressure value= 80, part of observation 2
| colspan="2" |'''Care plan&nbsp;: inherits attribution'''
<div><span id="<@@@BTAG167221@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
|-
== Simple observation ==
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''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
|}


" data-mw-type="tag" data-mw-id="167221" data-mw-name="h2" data-mw-wikitext="%3Ch2%3ESimple%20observation%3C/h2%3E" contenteditable="false">
&nbsp;


== <span class="mw-headline" id="Simple_observation">Simple observation</span> ==
=== Care plan activities ===
</span></div>
These are modelled as observation types such as
A simple observation is the root for most clinical entries about a patient, ranging from a piece of text or codeable 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 <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Observations can be standalone or exist within a collection of observations with a parent observation<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Simple Observation&nbsp;: inherits patient event<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>It is inferred by the code within the observation, however it is modelled separately as it drives business logic<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Prompt Text representing a prompt on a form to which the observation represents the nature of the response to the prompt<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>This should not be confused with a parent observation such as a test order which has this observation as a test result,<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Description Text entry for the observation<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Is problem Whether the observation is part of the problem definition<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Problem episode Concept: Whether the observation is new or a review of a problem or other specialist episode e.g. flare, evolved from<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Normality A flag indicating whether the observation is marked as abormal (e.g. ABN, HI,LOQ)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked problems The problems the observation may be linked to including<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Concept&nbsp;: Nature of link e.g. evolved from<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Problem <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Flag Any flags associated with the entry
<div><span id="<@@@BTAG147899@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
=== Numeric observation ===


" data-mw-type="tag" data-mw-id="147899" data-mw-name="h3" data-mw-wikitext="%3Ch3%3ENumeric%20observation%3C/h3%3E" contenteditable="false">
  1) Activity
  1) Goal
  1) Target


=== <span class="mw-headline" id="Numeric_observation">Numeric observation</span> ===
&nbsp;
</span></div>
One of the commonest observations are pathology results and they often have numeric values as results. They extend simple observations<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Numeric Observation&nbsp;: inherits simple observation<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Operator Operator associated with the value e.g. <span class="mw_htmlentity"><</span> or <span class="mw_htmlentity">></span> or =Value Numeric value of result <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Range (s) List of qualified range each consisting of<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Range qualifier (e.g. normal, normal for males)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Lower limit<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Upper limit<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Units Concept&nbsp;: Units of measurements
<div><span id="<@@@BTAG166929@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
=== Date time observation ===


" data-mw-type="tag" data-mw-id="166929" data-mw-name="h3" data-mw-wikitext="%3Ch3%3EDate%20time%20observation%3C/h3%3E" contenteditable="false">
<br />
== Abstract structural artefacts and miscallaneous ==
Abstract classes from which most of the other record entities 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.


=== <span class="mw-headline" id="Date_time_observation">Date time observation</span> ===
In addition 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 which are equivalent to complex data types in FHIR, as well as specialised minor structures
</span></div>
A less common observation is one where the result value is a date.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Numeric Observation&nbsp;: inherits simple observation<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Result date Date time of the observation eg. Expected date of delivery or date of last period.
<div><span id="<@@@BTAG110453@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
=== Procedure ===


" data-mw-type="tag" data-mw-id="110453" data-mw-name="h3" data-mw-wikitext="%3Ch3%3EProcedure%3C/h3%3E" contenteditable="false">
=== Health record entry ===
A health record entry&nbsp;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).&nbsp;


=== <span class="mw-headline" id="Procedure">Procedure</span> ===
{| border="1" cellpadding="1" cellspacing="1" style="width: 748px;"
</span></div>
|-
Procedure provides more information beyond a simple observation about an operation or observation relating to the outcome of the procedure.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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. <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Procedure: inherits simple observation<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Performed period Period of time the procedure took<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>End time Date and Time procedure ended <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Outcome Concept: Outcome of procedure<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Complications Links to complication observation entries<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Follow ups Links to care plan follow up entries<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked problems Links to the observation reasons for procedure<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Devices used List of devices used in the procedure qualified by “main device” or “used device”
| colspan="2" | '''Health record entry (subclass of data model)'''
<div><span id="<@@@BTAG199278@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
|-
=== Allergy, intolerance and adverse reaction ===
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 154px;" | Property
! scope="col" style="background-color: rgb(239, 239, 239); width: 580px;" | '''Description'''
|-
| style="width: 154px;" | has data controller
| style="width: 580px;" | 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
|-
| style="width: 154px;" | is component of&nbsp;
| style="width: 580px;" | 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.
|}
<div>
&nbsp;
</div>


" data-mw-type="tag" data-mw-id="199278" data-mw-name="h3" data-mw-wikitext="%3Ch3%3EAllergy,%20intolerance%20and%20adverse%20reaction%3C/h3%3E" contenteditable="false">
=== Health event  ===
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.


=== <span class="mw-headline" id="Allergy.2C_intolerance_and_adverse_reaction">Allergy, intolerance and adverse reaction</span> ===
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.
</span></div>
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”<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>The additional data relates to more specific information about the substance and reaction.<br/> Allergy&nbsp;: inherits simple observation<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Status Whether active or inactive<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>End date Date allergy became inactive<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Substance Concept: indicating the substance that created the adverse reaction or allergy<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Manifestation Concept: indicating the nature of the reaction e.g. rash, anaphylactic shock<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Manifestation description More detail about the manifestation <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Severity Severity of the reaction or allergy<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Observations Observations associated with the allergic reaction
<div><span id="<@@@BTAG150593@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
=== Immunisation ===


" data-mw-type="tag" data-mw-id="150593" data-mw-name="h3" data-mw-wikitext="%3Ch3%3EImmunisation%3C/h3%3E" contenteditable="false">
Some entries represent inferred states. For example an event entry for an adverse reaction or allergy infers the persistence of the state of allergy.


=== <span class="mw-headline" id="Immunisation">Immunisation</span> ===
{| border="1" cellpadding="1" cellspacing="1" style="width: 748px;"
</span></div>
|-
Immunisation extends a simple observation by providing more information about the immunisation procedure and vaccine used.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>This is a summary of immunisation, (expected to be extended)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Immunisation&nbsp;: inherits simple observation<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<br/> Manufacturer Manufacturer of vaccine<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Batch number Batch number of vaccine<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Expiry date Expiry data of vaccine<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Vaccine product Concept: of the actual vaccine product<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Dose sequence Number within a sequence (may be deduced)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Doses required Number of recommended doses in series<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Reaction Link to observation describing reaction to immunisation 
| colspan="2" | '''Health event (subclass of health record entry)'''
<div><span id="<@@@BTAG147253@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="  
|-
== Problem ==
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 154px;" | Health event
! scope="col" style="background-color: rgb(239, 239, 239); width: 580px;" | inherits health record entry
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 154px;" | Property
! scope="col" style="background-color: rgb(239, 239, 239); width: 580px;" | '''Description'''
|-
| style="width: 154px;" | Start date time
| style="width: 580px;" | 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&nbsp;
|-
| style="width: 154px;" | End date time
| style="width: 580px;" | The end date time of the event, if recorded
|}


" data-mw-type="tag" data-mw-id="147253" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EProblem%3C/h2%3E" contenteditable="false">
&nbsp;


== <span class="mw-headline" id="Problem">Problem</span> ==
=== Patient health event ===
</span></div>
A patient event is a subtype of health&nbsp;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
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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>A problem is always associated with at least one observation and therefore automatically shares its attribution.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Problem<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Problem type Concept: for the term that the healthcare worker assigns to this construct e.g. Problem. Issue, need<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Status Terminological construct for the status, whether active inactive, dormant<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>End Date Time Date and time problem ended<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Significance Significance assigned to the problem by a user. May be inferred from a knowledge base<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Anticipated duration Whether likely to be temporary permanent, or duration<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Parent problem A problem that this is a child of<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Defining observations<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span> Observations that form the title of the problem<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked entries Entries in the care record linked to this problem, e.g. encounters, observations` 
<div><span id="<@@@BTAG184285@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== Medication statement ==


" data-mw-type="tag" data-mw-id="184285" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EMedication%20statement%3C/h2%3E" contenteditable="false">
Like a health event it is an abstract class and therefore entries in records are subclasses of this type


== <span class="mw-headline" id="Medication_statement">Medication statement</span> ==
{| border="1" cellpadding="1" cellspacing="1" style="width: 781px;"
</span></div>
|-
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).<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Medication statement: inherits patient event<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Status Whether active or past (inactive)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Medication Concept: for the drug or appliance.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>This may be an actual medicinal product, a virtual medicinal product or a virtual therapeutic moiety<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Dosage May be a free text dosage (one three times a day, or a structured dose concept including:<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• administration times e.g. 10 am 6 pm)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Either<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• administration quantity e.g. 2<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• administration units e.g. capsules<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>And.or<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• drug quantity per administration e.g. 250<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• drug quantity units e.g. mg<br/> 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 <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Course type Whether a repeat, acute , automatic repeat, repeat dispensing<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Number repeats authorised Number of prescriptions authorised as a repeat before medication review required e.g. 6<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Medication review Review date for this particular medication<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Prescription duration Anticipated Duration of each prescription e.g. 28<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Prescription duration units Duration units for prescription e.g. days<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Additional instructions Additional instructions to the patient<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Pharmacy instructions Additional instructions to the pharmacist<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Order in heading Order within the heading in encounter<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Management authority Nature of the domain organisation that manages the administration of this medication e.g. hospital only<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Originated by Domain type that originated this medication e.g. Hospital<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Reason for ending Textual or concept reason the medication was ended <span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>End date time Date and time medication was ended<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links
| colspan="2" | '''Patient event (subclass of health event)'''
<div><span id="<@@@BTAG193714@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
|-
== Medication order ==
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" | Relationships
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 600px;" | '''Description'''
|-
| has Subject
| The patient to whom this event relates.<br/> Note that a patient is considered as an individual person in the role of patient with respect of the organisation.<br/> There is no requirement to resolve common person identity in published data
|}


" data-mw-type="tag" data-mw-id="193714" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EMedication%20order%3C/h2%3E" contenteditable="false">
&nbsp;


== <span class="mw-headline" id="Medication_order">Medication order</span> ==
=== Context Headings or sections in encounters ===
</span></div>
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.
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<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Medication order&nbsp;: inherits patient event<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Heading Context heading for entry<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Status Whether active or past (inactive)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Medication Concept: for the drug or appliance.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>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)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Dosage May be a free text dosage (one three times a day)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>or a structured dose concept including:<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• administration times e.g. 10 am 6 pm)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Either<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• administration quantity e.g. 2<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• administration units e.g. capsules<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>And.or<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• drug quantity per administration e.g. 250<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• drug quantity units e.g. mg<br/> Order Quantity – number of units For the ensuing prescription order Number of tablets or capsules for the course e.g. 28, 1<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Order Quantity- units Unit concept for course e.g. (28)- capsules, (1) inhaler<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Course type Whether a repeat, acute , automatic repeat, repeat dispensing<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Number from authorised count Number of the prescription as compared to the authorised number in the linked medication (e.g. 2/6)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Prescription duration Anticipated Duration of each prescription e.g. 28<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Prescription duration units Duration units for prescription e.g. days<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Additional instructions Additional instructions to the patient<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Pharmacy instructions Additional instructions to the pharmacist<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Order in heading Order within the heading in encounter if noted in the encounter<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links
<div><span id="<@@@BTAG196740@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
== Document ==


" data-mw-type="tag" data-mw-id="196740" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EDocument%3C/h2%3E" contenteditable="false">
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


== <span class="mw-headline" id="Document">Document</span> ==
{| border="1"
</span></div>
|-
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<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Medication&nbsp;: inherits attribution<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Document Type Concept or Text: Type of document<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Document content Text representation of content<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Encounter Encounter linked to this observation<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Heading The heading in which the observation took place<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked medication Links to medication that was used as the template
| colspan="2" |'''Section'''
<div><span id="<@@@BTAG191862@@@>" class="mceNonEditable wikimagic mw-tag mceNonEditableOverlay mwspan" title="
|-
== Flag ==
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" | Property
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
| Heading type
| Concept: for the heading<br /> e.g....<br /> Clinician entry/ Examination/ CVS Examination<br /> CDS Entry/ Primary Diagnosis<br /> Clinician entry/ Past procedures
|-
| Order
| Order of heading in relation to its parent for display purposes
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Relationships'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Description'''
|-
| is part of encounter
| The encounter that contains the section
|-
| is subsection of
| Link to the parent heading
|}<br />
=== 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


" data-mw-type="tag" data-mw-id="191862" data-mw-name="h2" data-mw-wikitext="%3Ch2%3EFlag%3C/h2%3E" contenteditable="false">
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
{| border="1"
|-
| colspan="2" |'''Device'''
|-
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''Field'''
! scope="col" style="text-align: left; background-color: rgb(239, 239, 239); width: 181px;" |'''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)
|}
<br />
===UPRN and addresses===
The data  model incorporates details of properties, including the address and unique property reference number and geolocations of various kinds and links user entered addresses to a set of authoritative addresses provided by the [https://www.ordnancesurvey.co.uk/business-government/products/addressbase-premium AddressBase Premium] service provided by the Ordnance survey.


== <span class="mw-headline" id="Flag">Flag</span> ==
</span></div>
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<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Flag<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Field Description<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Status Status of flag (active, inactive)<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Flag category Concept: Nature of flag for example<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Flags related to the subject's dietary needs.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>• Flags related to the patient's medications.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Used in business logic to determine when the flag is displayed<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Flag type Concept: to describe the flag e.g.<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Do not stop taking this medication without professional advice<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Text Alert text<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Links<span class="single_linebreak" title="single linebreak"><mwspan>¶</mwspan></span>Linked entry Entry to which the alert relates


[[Category:Pages with broken file links]]
<div>
<br /></div>

Latest revision as of 15:12, 14 February 2021

Discovery Data Service contains health and care-related data.

These articles describe the nature of the types of data currently held 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 c


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 the net result of a set of machine level events and is a statement by the person or device making the record entry.  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.

Every entity, attribute and value in the model is defined in an ontology - an information model. This article simply tabulates a human approximation to the ontology

 Individuals

Records of 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.
Is Person 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


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


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

 

Organisations services and locations

Records of entities that exist independently of people, including organisations, manufactured devices, services and locations

In Discovery, organisations are services 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 from the nature of the information transmitted.

The complex interrelationships between organisation locations and properties are illustrated as follows:


Organisations and locations - Page 1.jpg

Organisation

An organisation and a service are considered interchangeable. There are a multiplicity of relationships between then which enable organisations to be differentiated from services. For example an organisation may commission services from another organisation and an organisation may provide services independently of whether that have been purchased.

Organisational relationships types form a small ontology in their own right and therefore are not listed here

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

 

Provision of care

Records of the processes involved in the the provision of care for patients.

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 specialities, 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

 

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

 

Scheduling of care

Records of the scheduling of the provision of care i.e. appointments

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 (slot)

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

 


Patient characteristics

Records about the observations or assessments about the patient that include both clinical, social and other broader characteristics


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 concept Concept: Nature of the observation, e.g.... sign, symptom, aim, target, goal , test header, or specialist type e.g.... blood pressure.
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.

 

Specialised observations - sub components

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

In effect these operate as observation components but may be modelled in a way that describes a preferred arrangement for particular purposes. These are sometimes referred to as archetypes.

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 specialisation. For example, a 12 lead ECG would have significant subcomponents

Allergy, intolerance and adverse reaction

Allergies, intolerance 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


Problem or condition

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`

 

 Diagnostics and investigations

Records relating to investigations and the various ways the investigation results are packaged up. Includes records of the things used in the investigations or how they were performed. In effect they are structured containers of other types of entries with various specialised subtypes

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
   

Diagnostic report 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

Specimens have some specialised relationships with other components

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


Treatment or intervention

Records of treatment and actions by health and care workers, including clinical activities, health prevention activities and the planing of care. There is significant overlap between these entries and observations. For example an entry may be an observation that an intervention took place. These type of entries tend to have special attributes that make them significantly different from normal observations.

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


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”

Medication authorisations or courses

Also referred as Medication statement entries, these are entries 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


Decision support

Items that help directly to support decisions about the care of patients.They may be direct entries or derived from other entries following the application od decision support algorithms 

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

Entries that record 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.

Provenance simple.png

 

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

 

Correspondence and communication

Structures that support the exchange of information between professionals or between professionals and patients.

Document or composition

A structure of a document. This is a light weight definition as documents tend to specialise very quickly to many types, even in the context of a single provider.

Document
Field Description
Document Type Concept or Text: Type of document
Document content Text representation of content
Links
Section The section, usually with a heading, used to structure the document
Component A reference to another entry, a copy of an entry, or the original entry of a component in the document


Care plan

A dynamic document that notes the plan regarding the care of a patient. As in the document structure they tend to specialise and thus this highlights only the generic sections.

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 

 


Abstract structural artefacts and miscallaneous

Abstract classes from which most of the other record entities 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.

In addition 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 which are equivalent to complex data types in FHIR, as well as specialised minor structures

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

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

 

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


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)


UPRN and addresses

The data model incorporates details of properties, including the address and unique property reference number and geolocations of various kinds and links user entered addresses to a set of authoritative addresses provided by the AddressBase Premium service provided by the Ordnance survey.