1 Introduction and overview 1.1 Background and Purpose of document Discovery receives and hosts health related data and provides health data on request. This document describes the nature of some basic types of data. The data is described in conceptual terms in this document. The layout and concept definitions in this document can be used to inform the content and format of the actual data held. It represents a conventional “data set style” approach to the structure of records within Discovery. The actual structure is conceptually specified using the Discovery information model language – OWL2 The scope of this document is limited to the data description. It does not cover the data format or the transmission mechanisms. The document assumes the reader is familiar with the Discovery programme and the approaches to the Governance of the data and secure means of transmission. In as much as these issues affect data content, this will be described in the appropriate section. However, there are some significant issues in respect of IG that affect the breadth of the data as a whole. These are: 1. The Discovery Data Service is hosting data on behalf of the trust and the trust retains control of the data. The data processing agreement enables Discovery to receive personal sensitive data and therefore this is included. 2. As a result of the above, identifiable data may be transmitted and patient consent is not required beyond the implied consent by the patient for publishers to hold data on their behalf. However, any data marked as especially confidential or private in the source system must also be marked as confidential or private when transmitted. 3. IG requires that data should not be shared if the patient withdraws consent for their data to be shared. Different organisations and systems have different ways of representing consent (over and above confidential items) but if consent is captured it should be transmitted.
1.2 Generic publisher system data requirements Discovery is neutral as to the data format of data that is sent to it. It is also neutral as to the nature of properties (fields) or terminology subject to the following caveats: 1. That the data submitted closely represents data as entered into the provider system by the user. 2. That the provider system supports some kind of event based approach to modelling data e.g. an encounter or observation. 3. That the provider system is able to generate deletion indicators as well as added data. 4. That the data submitted is internally consistent, including any referential integrity. 5. That the meaning of field names and values is either self-evident or documented. 6. That patients, organisations and health professionals have a reliable internal identifier for tracking the data 7. That patients will have been assigned NHS numbers within the publisher environment, or will be assigned NHS numbers in the near future after initial transmission. 8. That the data will be exported at no less frequency than once a day.
1.3 General approach The document is laid out using Word tables in order to provide some categorisation of the data items. There is no requirement for actual tables or actual fields to be created in this way. Within Discovery, health data is seen as a set of chronological entries (or items), each entry describing either an event that has occurred and has been recorded by a user or a device or a state described by the entry. An event may be the observation of a characteristic of a person, or may be a care event, whether that process be an administrative process such a hospital admission, or a clinical process such as an operation. A state is a statement about the patient that lasts over time. Examples are problems or medication authorisations All events are characterised by a time (as a point in time or period), an entity responsible for the recording of the event (e.g. a professional, or organisation), the category of the event, and the relevant details of the attributes relating to the event. In addition, as data is likely to be received on an incremental basis, the transmission of an event entry may result in a new entry in Discovery, change a previous entry, or delete an entry, thus there has to be a mechanism of matching an event entry to one sent previously. Most events are related to a person acting as a service user. Throughout the document the word “patient” is used to represent a person who is a user of the service. It is accepted that within the services themselves, service users may be referred to as patients, clients, service users or other terms and the term used is configurable accordingly. Events within the Discovery model can be categorised in a way consistent with the FHIR R4 standard set of resources e.g. categorisations of procedure, observation, medication order, referral request, patient, practitioner. However, the description in this document simplifies the elements using non-technical language, flattens the structure, thus there is no requirement to be familiar with FHIR before reading this document. Cardinality is not documented in this document. An assumption is made that the data actually produced may not match with a particular field description in this data set, or may map to a number of fields and entry types. In many cases the field values in this data set may either be inferred or deduced during the Discovery inbound translation process. For example, in some cases dates and times may not be readily available and may need to be inferred. The data set in this document forms a major part of the structural part of the Discovery data model which, together with the semantic part, is a freely available model for use by the public domain. The document uses an element of inheritance, which means that an entry type that inherits from another entry type includes the fields from that entry type. Therefore the fields that are inherited are not repeated in the tables for brevity. Links represent associations between one entry type and another type either described elsewhere in the document or described in line in the link description. This data set does not mandate a particular cardinality in respect of the links. Field values are often labelled as “concepts”. This means that the field value will be treated as a referenceable concept for analysis in Discovery. Concepts are powerful as they enable concept attributes to be modelled within the data model thus supporting advanced analytics based around types (i.e. subsumption queries). Concepts may or may not be clinical and cover even simple field value sets. The next section deals with the issues relating to transmission of information, moves on to fields that are common to many entry types (i.e. will be inherited) and then describes the particular entry types. 2 Generic properties This section deals with properties that are common to many types of data. These elements may be incorporate into the data entities themselves or may be linked via entity relationships 2.1 Transaction When transmitting data from system A to system B, there needs to be a mechanism by which a data item transmitted may be related to the same data item previously transmitted. For example, one entry may supersede another, so there needs to be an indication as to whether an entry has been replaced or deleted. In addition, data items will need to be uniquely identified if linked to other items. Use of IDs is essential to this process. It is recognised that the facility is limited to certain publisher systems and the transaction may need to be deduced from data already present in the Discovery data service. Transactions Field Description Transaction type Concept : Whether the entry is a) Add (i.e. a new entry) b) Edit (i.e. a change to a prior entry) c) Delete (i.e. the previous entry should be deleted) In many cases the transaction type may be inferred as “add” e.g. a new observation of “edit” e.g. change to a date of birth. Identifier A field within a data item that uniquely identifies that item for a particular system and publisher. Ideally a GUID but may be an internal system id or may not be available. N.B The ID is also used to link related items (e.g. foreign keys)
2.2 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.
However, a provenance “summary” is also provided and this records the following data
Provenance
Field Description
Date and Time entry recorded The data and time the entry was made into the publisher system. This may not be the same as the date and time the event took place and may be inferred from inbound data if not available
Recorded by The person or device who recorded the entry. This may or may not be the same as the person responsible for the description of the event. E.g. may be a secretary recording a diagnosis made by a clinician.
Responsible practitioner The person responsible for the entry, usually a professional health worker
Owning organisation The organisation or service within an organisation responsible for the entry of the event data into the record. This may be a service or an organisation.
In Discovery this attribute is the attribute that is used for Data sharing agreements with the service acting as a publisher or subscriber. Services may be linked to other organisations to create a hierarchy or organisations or services.
Within Discovery, the service in this field is also linked to the Data controller organisation for the purposes of validation of publisher and subscriber services and the DSA.
This should be differentiated from a service or department as modelled within specialised entries such as encounters as these may have a number of granular organisations services or departments associated with a single encounter
Confidentiality Type Concept : An indicator of the nature of confidentiality
2.3 Health Event A health event is an abstract class referring to any entity type that represents something that has happened, or may happen, at a point in time, or over a period. It can be considered separate to a “state” in that the relevant date and time is of significance.
Provenance Field Description Start date and time The start date and time to which the event refers. It may be unknown, or imprecise (e.g. a year or month). It may be a point in time or a period of time (e.g. an encounter lasting 15 minutes) or a hospital encounter lasting several days For events that take place over a period of time this refers to the start of the event End date and time Optionally, if recorded the end of the event
3 Individuals organisations devices and locations
Most entries are attributed to patients, professionals, their organisations or services, locations or devices. In Discovery there is an attempt to uniquely identify these from the information provided, ideally using standard identifiers but in some cases deducing from names and context. In many cases these may be deduced only at the level of the sending systems by the use of internal identifier matching.
3.1 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
Field Description
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
Linked items
Address One or more entries including
• Qualified by Concept: address type (e.g. home address)
• The address of the patient relevant to the episode of care.
• Status of the address
• The date the address was valid from
• The date the address was valid to
Contact potentially used in contacting the patient, each contact qualified by
• Concept : contact type e.g. home telephone, mobile, email
• Contact details e.g. email address or telephone number about the patient
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
Linked identifiers Identifiers – qualified by identifier type
Linked relationships Linked relations
3.2 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 patient, as far as is known Address Qualified by concept : address type (e.g. work address) The address of the practitioner relevant to the role 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
3.3 Family and kin Relationships 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. Relationships (inherits attribution) Field Description Related person information Information about the target person which may include Name, address, contact details 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. Status Status of relationship Related in Discovery Whether the related person is in Discovery or not Links Related patient Target may be a person in the Discovery Data service
3.4 Related person
A related person may not be a patient in the Discovery service in which case the details of that person would be held independently
Related person
Field Description
Name Name of related person
Address Address of related person
Contact Contact details of related person
Links
Family and kin relationships Information about the patient and the relationship typ
Identifiers Identifiers of the related person (e.g. NHS number)
3.5 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)
3.6 Organisations departments and services
In Discovery, these concepts are amalgamated into a single structure and the entities are differentiated via the category and the relationships with the other entities as described below. In many cases the relationships will be inferred by Discovery from the nature of the information transmitted. There is no expectation that publishers are required to populate the relationships.
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, Roya London Hospital) or a service e.g. Barts physiotherapy service or cardiology department
May be deduced when populating the organisational structures and relationships
Speciality The speciality of the service e.g. Cardiology
Links
Linked Organisation A set of relationships between one organisational service entity and another each consisting of
• A relationship type such as “part of” or “provided by” e.g. Royal London Hospital is “part of”
• A target organisation e.g. “Barts NHS Health Trust”
Used to populate the organisational structures in the information model
Contacts Contact details for a person or team or department associated with the organisation consisting of
• Name
• Contact details
Location Locations associated with the organisation
Identifiers Other organisational identifiers
3.7 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
• Name
• Contact details
3.8 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
4 Health event subtypes This section covers events that describe various health or care events, most but not all relating to a patient. 4.1 Patient event 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
Patient event (inherits health event) Field Description 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 Part of An event that this event might be part of Encounter An encounter that this event might be part of In section The section of the encounter that this event is placed in Part of problem The problem which this event may be linked to
5 Care process related events 5.1 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 5.2 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 5.3 Encounter 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 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 planne. 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
5.4 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 Field Description Heading type Concept: for the heading e.g. Clinician entry/ Examination/ CVS Examination CDS Entry/ Primary Diagnosis Clinician entry/ Past procedures Parent heading Link to the parent heading Order Order of heading in relation to its parent for display purposes Linked encounter The encounter that contains the heading
5.5 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 xray 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
5.6 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
5.7 Appointment This is information about a particular appointment or slot as planned. The slot creation shares attribution with the schedule Appointment Field Description Appointment category Concept: describing what type of appointment in terms of routine, urgent etc Planned Reason Concept: of reason for appointment from the appointment planning perspective Description Any text description for the appointment slot Start time Start date and time of slot End time End date and time of slot Planned duration Planned duration of appointment (may or may not be timed) Patient Patient booked into the slot Slot booking status Whether booked, reserved, free Attendance status Whether the patient arrived, sent for, left Booking urgency Indication as to whether it was booked as an urgent appointment (whether the appointment was marked as urgent or not Interaction type Whether face to face, telephone, skype etc Links Linked schedule Links to the schedule containing the appointment Booking history Links to booking history including Booked :cancelled Date and Time of booking Attendance history Links to the attendance status history
5.8 Appointment booking history Information about booking and unbooking of an actual appointment prior to the patient attending Date and time of booking and by whom are attributed in attribution fields. The latest entry represents the information prior to the patient arriving or appointment attendance Appointment booking: inherits attribution Field Description Booking or cancellation Whether this is a booking or a cancellation Patient Patient booked into slot Booking urgency Whether the appointment was urgent (whether or not reserved as an urgent slot) Patient related reason Reason for appointment from patient’s perspective (i.e. if booked) Interaction type The actual interaction type when booked (e.g. telephone) Links Appointment slot Link to the appointment slot
5.9 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
5.10 Care plan In the context of Discovery a care plan is a relatively simple data subset of a complex document structure for the purposes of tracking and analysis. There is no attempt to precisely define a care plan beyond the simple data items listed here Care plan : inherits attribution Field Description Document Status Whether the plan is draft, active, no longer active Type of plan Concept: for the type of care plan. For example, Asthma action plan, Cancer management plan Description Description of plan Time period The start and end date or period of the plan (the start date may precede the effective date) Linked Headings Heading categorised, Activities, goals targets, observations linked to the plan Linked episodes Care episodes linked to the plan Parent plan Care plans this plan is part of Associated practitioners Additional practitioners or teams associated with the plan Associated teams Links to teams associated with plan Linked activities Links to care activities
Care plan activities
These are modelled as observation types such as
• Activity
• Goal
• Target
6 Clinical health events
This section covers data about the patient that is generally considered “clinical” either observed characteristics of the patient or clinical procedures or measurements that have been carried out.
In the Discovery model clinical data is modelled around observations i.e. different types of clinical characteristics inherit from simple observations.
Care records are usually structured according to a series of sections or “headings” a standard having been established by the PRSB. This enables records to be viewed as documents although the headings have no inherent meaning in themselves.
6.1 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 1 Blood pressure
Observation 2 Systolic blood pressure value= 120, part of observation 1
Observation 3 Diastolic blood pressure value= 80, part of observation 2
6.2 Simple observation 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 Observations can be standalone or exist within a collection of observations with a parent observation Simple Observation : inherits patient event Field Description Observation type Concept: Nature of the observation, including whether this is a sub-type entry (described elsewhere) or categorisation within the observation type itself e.g. sign, symptom, aim, target, goal , test header, or specialist type e.g. blood pressure. Equivalent to an archetype It is inferred by the code within the observation, however it is modelled separately as it drives business logic Prompt Text representing a prompt on a form to which the observation represents the nature of the response to the prompt This should not be confused with a parent observation such as a test order which has this observation as a test result, Description Text entry for the observation Is problem Whether the observation is part of the problem definition Problem episode Concept: Whether the observation is new or a review of a problem or other specialist episode e.g. flare, evolved from Normality A flag indicating whether the observation is marked as abormal (e.g. ABN, HI,LOQ) Links Linked problems The problems the observation may be linked to including • Concept : Nature of link e.g. evolved from • Problem Flag Any flags associated with the entry
6.2.1 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
• Range qualifier (e.g. normal, normal for males)
• Lower limit
• Upper limit
Units Concept : Units of measurements
6.2.2 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.
6.2.3 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”
6.2.4 Allergy, intolerance and adverse reaction Allergies, intolerances and adverse substance reactions are grouped together and are extensions of simple observations whereby the simple observation code includes the full concept of the allergy e.g. “allergy to penicillin” The additional data relates to more specific information about the substance and reaction.
Allergy : inherits simple observation Field Description Status Whether active or inactive End date Date allergy became inactive Substance Concept: indicating the substance that created the adverse reaction or allergy Manifestation Concept: indicating the nature of the reaction e.g. rash, anaphylactic shock Manifestation description More detail about the manifestation Severity Severity of the reaction or allergy Links Observations Observations associated with the allergic reaction
6.2.5 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
6.3 Problem Problem is a patient and record management construct designed to help manage care. The main purposes of problem structures are to highlight significant issues and to group entries in the record to enable a narrative view categorised by a focus of care. In different care domains different terms are used such as “problem”, “issue” or “need” but from a structural perspective they are the same. A problem is always associated with at least one observation and therefore automatically shares its attribution. Problem Field Description Problem type Concept: for the term that the healthcare worker assigns to this construct e.g. Problem. Issue, need Status Terminological construct for the status, whether active inactive, dormant End Date Time Date and time problem ended Significance Significance assigned to the problem by a user. May be inferred from a knowledge base Anticipated duration Whether likely to be temporary permanent, or duration Links Parent problem A problem that this is a child of Defining observations Observations that form the title of the problem Linked entries Entries in the care record linked to this problem, e.g. encounters, observations`
6.4 Medication statement Medication statement entries are templates for describing and authorising a course of medication or an intention to prescribe. Medication entries are precursors to the prescribing of a drug (medication order), dispensing of a drug (e.g. chemist) or the administration of a drug (e.g. medicine administration by nurse). In General practice, acute prescriptions are based on medication entries with a single authorisation and repeat medications are based on medication entries with multiple authorisations. In hospital, the drug chart contains the medications. Medication statement: inherits patient event Field Description Status Whether active or past (inactive) Medication Concept: for the drug or appliance. This may be an actual medicinal product, a virtual medicinal product or a virtual therapeutic moiety Dosage May be a free text dosage (one three times a day, or a structured dose concept including: • administration times e.g. 10 am 6 pm) Either • administration quantity e.g. 2 • administration units e.g. capsules And.or • drug quantity per administration e.g. 250 • 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
6.5 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: • administration times e.g. 10 am 6 pm) Either • administration quantity e.g. 2 • administration units e.g. capsules And.or • drug quantity per administration e.g. 250 • 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
6.6 Document Used to provide the content of a document A medication order is the actual prescription for a medication item. It represents the instance of the order derived from the medication statement. It inherits MOST fields from medication and has some additional items. However, field values for the order may be different from the field values of the medication statement so they are repeated for clarity Medication : inherits attribution Field Description Document Type Concept or Text: Type of document Document content Text representation of content Links Encounter Encounter linked to this observation Heading The heading in which the observation took place Linked medication Links to medication that was used as the template
6.7 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
• Flags related to the subject's dietary needs.
• 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