UKCore Hackathon Aide Memoire

This guidance is under active development by NHS Digital and content may be added or updated on a regular basis.


1.0 Introduction

FHIR is most often used as an common interface to Electronic Health Record (EHR) and as a method of enabling automated processes between practitioners and providers.

UKCore contains the common core data model to be used in the UK.

UKCore by itself does not define how these interactions are performed. That is defined in the international specification, and this has three main methods for exchanging these resources or enabling automated process which are:

A full list of exchanges can be found on FHIR Exchange Module

2.0 Core Models in Electronic Health Records

FHIR is not intended as the way Electronic Health Record (EHR) should be stored (persistence) but it is intended as the method of sharing EHR records. For example, openEHR is primarily a EHR persistence standard, it is not an exchange standard.

Overlaps between EHR and FHIR data models will naturally exist, for example an EHR recording Observations may code these using SNOMED CT concepts, UKCore-Observation also recommends SNOMED CT.

This same pattern exists within Electronic Document Management Standards (EDMS), for example IHE XDS (UK Supplement) will use SNOMED CT concepts to record document types, UKCore-DocumentReference will also recommend SNOMED CT.

Clinical data can exist in all these forms. For example, a list of medications a patient is currently on can be collected/recorded. For example, a patient or health practitioner facing application may use Forms, the health practitioner may collect this data in a Document or use an existing prescription (MedicationRequest Resource).

Persistence Model Type Example Uses Notes and other names
Resource Structured Patient Administration System (PAS), Electronic Patient Record (EPR), Laboratory Information Management Systems (LIMS), SQL Table
Document Unstructured Electronic Document Management System (EDMS), Radiology Information System Imaging
Resource + Document Structured and Unstructured Electronic Patient Record (EPR) Clinical Document Architecture. Used to record consultations.
Forms Semi Structured Electronic Patient Record (EPR) Template & Archetype

This mix of persistence models often occurs within the same system. For example, for Referrals, it is likely the high level/summary details uses resource (and physically in a SQL table). In FHIR this would map to FHIR ServiceRequest, the details such as assessments or supporting information is stored in a mix of Forms, Documents and Resources.

The same pattern exists within NHS organisations/providers. Details on the patient such as demographics, visit history and appointments will exist as resources typically with the Patient Administration System (PAS). Detailed clinical notes may exist in other systems:

  • Electronic Document Management System (EDMS)
  • Electronic Patient Record (EPR). This may als be the PAS.
  • Clinical Observations system.

3.0 Interoperability History

Healthcare has always involved interactions between different care providers. This has several high-level types, and which one is used depends on the use case and the urgency of care being delivered.

The table below shows how interoperability has evolved.

Patient Care Interactions Introduced Type Use Cases Standards and Specifications
Event Notifications mid 90's onwards Resource General use in acute (and to a limited extent to other care settings). Notifications of changes patients care status, such as admission or discharge to hospital/ward, changes to patient demographic details HL7 v2 Admission, Discharge and Transfer (ADT). HSCIC ITK HL7 v2 ADT
Event Messages late 90's onwards Multiple Resource Pathology Reports and Child Health Event Messages. Population of longitudinal care record, transmission of care records between providers. HL7 v2 Unsolicited Observations (ORU), NHS Pathology and National Event Messaging System (NEMS). Bookings and Referrals Standard (BARS), Urgent and Emergency Care (UEC) and Electronic Prescription Service (EPS). HL7 v3 and FHIR Messaging
Sharing Clinical Document circa Y2K Documents General use Cross Enterprise Document Sharing (IHE XDS)
Sending Clinical Documents Y2K Documents Population of longitudinal care record, Transferring Care between providers and exchanging Requests between providers Transfer of Care (TOC), Urgent and Emergency Care (UEC), Bookings and Referrals Standard (BARS) and Electronic Prescription Service (EPS). HL7 CDA, FHIR Documents and FHIR Messaging
Sharing Patient Care Data circa 2005 Resource General use (circa 2015) HL7 FHIR RESTful API, CareConnect API
Cross Enterprise Workflow circa 2015 Resource General Clinical Process support HL7 FHIR RESTful API and FHIR Workflow module

Health and Social Care have moved towards sharing data via API's rather than sending documents or messages. These API's also followed technical trends such as moving from XML to JSON payloads, SOAP to RESTful and Document to resource based. This led to the HL7 FHIR standard which is particularly suited to providing a common interface to the vast array of clinical information systems.

4.0 Interoperability Fundamentals

This aide-mémoire focuses on how standardised processes and how (HL7) technical standards can be used to solve them. This guide does not cover technical architecture approaches, this is discussed in:

This aide-mémoire does not cover building healthcare applications (EHR). For guidance in this area see NHS England Building healthcare software

This aide-mémoire looks at how use cases and processes can be supported by technical standards.

This table lists common interactions and standards which can be used to support them. It is divided by core data model types.

It is not expected one interaction (or even one core model) will be used in a single clinical process. For example, a patient registering at a GP practice may involve the following:

  • Patient completes a registration form (Structured Data Capture)
  • The form may be prepopulated with existing data (Patient Demographic Query)
  • The form is sent to the GP Practice (Structured Data Capture)
  • The practice adds or updates the patient records, which then triggers Event Notifications to inform other systems of the patient demographic changes.

5.0 Sharing Patient Care Data

One of the primary reasons for the HL7 FHIR was the ability to

5.1 Sharing Clinical Documents

Type Use Description Suggested Standard
Document Access to Health Documents (MHD) Profile defines one standardized interface to health document sharing (a.k.a. an Application Programming Interface (API)) for use by applications and mobile devices so that EDMS applications are more consistent and reusable. This is also the FHIR API compatible IHE XDS IHE MHD

This has both a client and consumer part. Client interactions

  1. The document is sent to a document repository using Send Document
  2. This repository then updates it's index called a document registry. In FHIR this index entry correlates with the FHIR DocumentReference resource. A client may directly add the index.

A document consumer interacts as follows.

  1. Consumer queries the index Document Registry, they may apply filters to the query to restrict results to a specific date range, care setting or document type.
  2. The consumer may view the document.

Example Implementations

5.2 Query Patient Care Data

Type Use Description Suggested Standard
Resource The Query for Existing Data for (QEDm) supports queries for clinical data elements, including observations, allergy and intolerances, conditions, diagnostic results, medications, immunisations, procedures, encounters and provenance by making the information widely available to other systems within and across enterprises. It defines a transaction used to query a list of specific data elements, persisted as FHIR resources. IHE QEDm

This pattern is quite common in Health Information Exchanges, Patient Portals and applications accessing data in other systems.

This can provide an open and consistent API standard to access patient data held in a range of existing systems such as PAS, EPR, EPMA, LIMS, etc. As data is retrieved when required by practitioners and patients, in real time, it does not have the concurrency issues which feature in methods such as Event Message Suppliers are not expected to provide API's for every data types, just those applicable their system, e.g.

  • LIMS would support diagnostic results and observations APIs
  • PAS would support encounter APIs.
  • EPMA would support medication APIs.

This is not a bulk EHR extraction method and each resource is expected to be called individually as and when a practitioner needs to the view patients data.

Example Implementations

5.3 Patient Demographic Query

Type Use Description Suggested Standard
Resource The Patient Demographics Query (PDQm) Profile defines a lightweight RESTful interface to a patient demographics supplier leveraging technologies readily available to applications and lightweight browser based applications. IHE PDQm

A lightweight RESTful interface to a patient demographics supplier leveraging technologies readily available to mobile applications and lightweight browser based applications.

The following list provides a few examples of how this may be used:

  • A health portal securely exposing demographics data to browser-based plugins
  • Medical devices which need to access patient demographic information
  • Mobile devices used by physicians (example bedside eCharts) which need to establish patient context by scanning a bracelet
  • Web based EHR/EMR applications which wish to provide dynamic updates of patient demographic information such as a non-postback search, additional demographic detail, etc.
  • Any low resource application which exposes patient demographic search functionality
  • Any application using the Sharing Clinical Documents to access documents may use Patient Demographic Query to find an appropriate patient identifier.
  • Any application using the Query Patient Care Data to access care records may use Patient Demographic Query to find an appropriate patient identifier.

Example Implementations

5.4 Clinical Portal

6.0 Sending Patient Care Events, Notifications and Data

6.1 Event Notifications

Type Use Case Suggested Standards
Resource Admission and Discharge Notifications, Observation alerts (high blood pressure, etc), Appointments, Patient demographics updates FHIR Workflow

The earliest form of Event Notification was a key focus of early HL7 standards and is normally referred to as the HL7 v2 Admission, Discharge and Transfers (ADT) standard. This covered a series of use cases, including:

  • patient was registered.
  • patient demographics have been updated.
  • patient has arrived or attended outpatient clinic.
  • patient has been admitted to, arrived at or discharged from hospital.
  • patient has an appointment or is scheduled to be admitted to hospital.
  • Significant clinical event (e.g. high blood pressure reading)

This interaction method differs from Event Message in that it is not intended to transfer/exchange records. It is purely a notification system and it typically used to complement Query Patient Care Data, which the recipient practitioner or system can use to view details on the event if they wish. Events Notifications in FHIR will generally use RESTful API

Example Implementations
  • See HL7 v2 above.

6.2 Send Document

Type Use Cases Suggested Standards
Document Send clinical documentation between two providers and populating a document registry IHE MHD

Use cases include:

  • Transmission of an Emergency Care Summary
  • Add documents to an Electronic Document Management System
  • Populating a longitudinal patient record

Another form of send documnt makes use of Event Notifications to inform the recipient that a clinical document has been created. The methods of sharing this document is covered in Sharing Clinical Documents

In Send Document, the format of the document can also adhere to Documents in HL7 v3 this was known a Clinical Document Architecture (CDA).

Example Implementations

6.3 Event Message

Type Use Cases Suggested Standards
Multiple Resources A method of sending multiple resources in one interaction which is particularly suited situations where time is important. FHIR Workflow AdHoc Option D

Certain use cases will want to perform the event and patient data sharing in one interaction. This is often between two providers and so is not considered a generic method of sharing Patient Care Data. This exchange method also has concurrency issues as it contains a point in time EHR snapshot.

Specific use cases include:

  • Sending a pathology report
  • Transmission of an Emergency Care Summary
  • Transmission of Child Health Data
  • Populating a longitudinal patient record

Events Messages and Send Document will generally use Messaging.

Example Implementations

6.4 Alert Communication

Type Use Cases Suggested Standards
Resource Crisis alerts and care reminders IHE mACM

A simple form of notification is SMS text and mobile application notifications. Example use cases include:

  • Public health Disease exposure notifications
  • Patient Appointment reminders
  • Practitioner alerts
  • Care provision changes (e.g. surgey closed)

These may be used in conjunction with Event Notification, for example a HL7 FHIR or v2 Appointment Notification is converted into a Alert Notification or the alerts are triggered within an EHR applications. The Alert Notification are not sent directly to a recipient, instead they are sent to a Communication Manager which performs this action. The Communication Manager optionally can select the appropiate method of communication.

Example Implementations

6.5 Structured Data Capture

Type Use Cases Suggested Standards
Forms The Structured Data Capture (SDC) Profile provides an infrastructure for capturing, exchanging and using patient data within electronic health record (EHR) systems for clinical research, adverse event reporting and public health reporting. The utility of EHR data for supplemental purposes has been limited due to a lack of uniformity in the terminology and definitions of data elements across EHRs. This limitation is compounded by the fact that in a typical clinician workflow patient information is often recorded in an unstructured free-text format well after the episodes of care. FHIR Structured Data Capture and IHE SDC

Structured data capture covers the use forms or questionnaires to collect structured data. Use cases include:

  • Patient care assessments
  • Nursing Forms
  • Doctor admission documentation
  • Physio, OT, Social Work, Pharmacists documentation
  • patient hospital admission forms

Example Implementations

7.0 Workflow

7.1 Requests

Type Use Cases Suggested Standards
Resource How do we ask for another person, device or system to do something? FHIR Workflow

Common use cases include:

  • laboratory orders
  • social insurance and prescription claims
  • referrals
  • prescriptions
  • administrative requests

The Event Notification part of workflow is described earlier. Request and Events are naturally related. For example:

  • Following a referral, a referrer would be sent admission and discharge notifications.
  • Following a prescription, the prescriber would be sent dispense and/or medication admission notifications.

The interactions used in Requests are the same as the methods described for Events in the previous section.

7.2 FHIR Workflow

In FHIR Workflow it is assumed patient care records are shared. So neither the Request or Event notification will contain patient care records (except in certain circumstances).

A receiver of a request (filler) will use Sharing Patient Care Data API's (or clinical portals, summary records, etc applications) to view the patients record. When the request is actioned, the filler will issue event notifications to inform other care provider of important events.

Similarly, the receiver of events with use Sharing Patient Care Data API's (or sharing applications) to view details on the received events.

Example Implementations

back to top