Introduction

Observation 'Round'

Traditionally Robert's records during his hospital inpatient stay would have been located at the end of his bed. The chart shown in the diagram below is recording NEWS2 Observations. NEWS2 (and also vital signs) contain a series of observations such as:

• Respiratory Rate
• Oxygen Saturation (SPO2)
• Blood Pressure
• Heart Rate
• Body Temperature

These observations are normally taken during a nursing observation round and is normally presented to practitioners on a chart.

These observations are also collected in other settings, these may be better described as Vital Signs as NEWS2 is defined type of Vital Signs. These include:

• GP Practice
• Community
• Emegency
• Miltitary ambulatory care

Recording Observations

Modern technology has given us new methods for capturing these observations alongside paper based forms.

On ward rounds, a nurse will likely record these observations in an application such as the example below. This form also automatically calculates a NEWS2 score from the observation values entered:

It is also possible devices are used to gather these observations. This device is recording: SPO2, Heart Rate, Blood Pressure and Respiratory rate. A connected device would be able to automatically populate the form or the nurse can copy the values into the form.

Citizens are also capturing and recording these observations. In the use case Robert had been issued an SPO2 measuring device, it's also possible he had personnel equipment which automtically recorded this and other observations.

Similar to use of devices in hospital setting, their can be electronic communication between the devices and the record system (e.g. Apple Health, Google Fit, etc)

Displaying Observations

Observations are typically displayed to practitioners and citizens as charts. This is very similar to the bed charts we discussed earlier.

Patient Journey, Pathways and Workflow

TODO This needs to read as a patient journey - So the process before Robert is in the ward in summary

HL7 v2 ADT concentrates on health administration event messaging and it largely ignores clinical event messaging. Here we mean important health events which other practitioners (and patients) should be made aware of. For example:

This event triggered Roberts pathway we have been discussing. It could have also occured in the ambulance, emergency department or the observation ward. It's possible this event would have triggered action by a practitioner or healh system.

Technically this would be solved via an event messaging system and/or publish/subscribe pattern

Here we are making a clear seperation between what data is recorded and what information is shared (notified). The previous section described a method for health administration notifications which was implemented using HL7 v2 ADT events. In our use case, the abnormal SPO2 measurement could have also been sent as an event.

This diagram uses Business Process Model and Notation to describe the workflow. BPMN diagrams often show a sequence of interconnected processes. In this diagram we have chosen to represent a high-level process which takes in

• input which is information required to perform the task. In our example the input is the abnormal SPO2 observation.
• output which is the information output from the task which is used to send key information to the next task. In our example, the abnormal observation triggered a ambulance dispatch request (via verbal communication).

These processes are commonly found in patient journey or pathway documentation. E.g. the process Medicines reconciliation (NICE) is found in several pathways.

Each process is normally an Encounter, this Encounter is documented in local records. Some of this encounter documentation is also output. Each process can use local record and shared records for additional input. Input and output often correlate with verbal communication used between practitioners delivering care, it is often a summary. E.g.

and not the detailed health records.

Planning the Ward Round

The observations and other actions to be taken with each patient is likely to be planned.

For Robert this would be something like 'take vital signs measurements', he will also have the scan as a workflow item.

TODO

Recording Patient Data

The introduction described recording information using a variety of use cases. We had three types of information being recorded. These are:

• documents The original format of these charts. Observations are still likely to occur in this format, due to practical reasons and digitisation of health will store these on Electronic Document Mangagement Systems (EDMS) after scanning.
• forms/templates Many practitioners will now use portable devices to record these observations. These will either be stored as forms in a Electronic Patient Record (EPR) and/or as observation entries in a EPR. Patients may also be asked to perform similar data in At Home Care Settings, i.e. the patient takes an observation from a device and manually enters this into a hospital Personnel Health Record (PHR) application.
• observation entries Systems capable of recording individual observations entries will record data this way. Most citizen based apps also record this way.

Common standards for recording this information are:

How observation entries are recorded is not a standardised entity but the structure is fairly standard across many EPR/PHR systems, some of the elements have associated standards:

If you are familiar with HL7 v2 or HL7 FHIR, this concept will be familiar. It is present in the HL7 v2 OBX Segment and also the FHIR Observation resource. The UK supplement to FHIR Observation UKCore-Observation brings in the UK SNOMED CT (see code element). The EPR requirement to use SNOMED CT is contained in NHS England SCCI0034: SNOMED CT

HL7 standards are not definitions of how records should be stored, however they have been used this way, for example, early UK GP Systems were based on HL7 v2 segment models.

Sharing Observations and Devices

Most EPR's will use their own native API's to both record and read data. When it comes to sharing the data or accessing EHR data via 3rd party applications such as a HIE, mobile application, Clinical Portal, etc, we start to find standards. The most common standard in this area in the UK is HL7 FHIR (see IHE QEDM below).

In addition we have devices which may have limited storage or display capabilties (e.g. a finger SPO2 monitor) and the observations need transfering to a EPR/PHR which handles this.

These use cases are quite different for the data capture which tended to focus around terms like NEWS2 or Vital Signs. Similarly standards used may be different. Several approaches are listed below:

Sharing Patient Documents/Records

EDMS systems (inc IHE XDS) are normally used as a store for unstructured data items. These include:

• Diagnostic Images
• Clinical Correspondence (discharge letters, outpatient letters, referral letters, etc.)
• Patient correspondence (images of health concern, letters, etc)

They are often accessed via 3rd party products (e.g. a GP System can use DocMan to recording and accessing documents) in the patients record n EPR application will access an EDMS to and they tend to have the following design:

This has three parts:

• Send Document (1 + 2) is used to store documents in the EDMS (Document Repository and Registry)
• Query Document (a) is used to search for patient documents.
• Retrieve Document (b) is used to view the document.

The EDMS product is very likely to have an application which talks directly to the repository, it may or may not use these API's. The API's are primarily for 3rd party access and is commonly used by EPR to display and store documents within those applications.

The number of EDMS accross health and social is quite large. Documents still count for a significant part of a patients health record. Within a single NHS Trust with one EDMS you are likely to find several systems generating documents (including the EPR). This can quickly get out of hand without some level of standardisation.

Shared Clinical Documents describes API options for sharing clinical documents.

Heathcare Administration Notifications

A secondary care hospital/trust will use a mix of different systems. Some of these systems are specific to specialty such as radiology/imaging, emergency, pathology/laboratory, etc systems.

These systems will often need to hold copies of the same information, typically this is around patient demographics, encounters and appointments.

We have a need to keep users of these systems informed of key changes and keep this data synchronised accross the system. These events and the data is known as admission, discharges, and transfers (ADT). Technically these are also known as Events.

By far the most common standard in this area (especially in Acute NHS Trusts/Boards) is:

This standard is based on pre JSON/XML encoding format, called pipe and hat.

MSH|^~\&|PAS|RCB|ROUTE|ROUTE|201010101418||ADT^A01^ADT_A01|1391320453338055|P|2.4|1|20101010141857|||GBR|UNICODE|EN||iTKv1.0
EVN||201010101400|||111111111^Cortana^Emily^^^Miss^^RCB55|201010101400
PID|1||3333333333^^^NHS||SMITH^FREDRICA^J^^MRS^^L|SCHMIDT^HELGAR^Y|196512131515|2|||29 WEST AVENUE^BURYTHORPE^MALTON^NORTH YORKSHIRE^YO32 5TT^GBR^H||+441234567890||EN|M|C22|||||A|Berlin|||GBR||DEU
PD1|||MALTON GP PRACTICE^^Y06601|G5612908^Townley^Gregory^^^Dr^^^GMC
PV1|1|I|RCB^OBS1^BAY2-6^RCB55|13|||C3456789^Darwin^Samuel^^^Dr^^^GMC|G5612908^Townley^Gregory^^^Dr^^^GMC|C3456789^Darwin^Samuel^^^Dr^^^GMC|300||||19|||||2139^^^VISITID|||||||||||||||||||||||||201010201716

Some examples of events messages sent during Roberts stay are shown in the table below:

NHS Trusts will normally use a system called Trust Integration Engine (TIE) to handle the broadcasting (distribution and transformation) of these event messages.

This event messaging can also be extended to other care settings, for example several GP systems accept HL7 v2 messages and this has been done by several NHS Trusts including Mid Yorkshire Hospitals NHS Trust. This allows both GP and Community practitioners to be aware of the patients current situation.

Summary

The previous sections have described various parts of a patient journey and illustratred the use of standards. This is illustrated in the diagram below:

The framework layer options are described in Technical Framework