FHIR Interactions

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:

• RESTful API
• Messaging
• Documents

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

Core Models in Electronic Health Records

Consider removing

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

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 also be the PAS.
• Clinical Observations system.

Interoperability Landscape

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.

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.

Interoperability Patterns

This supporting guide 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 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.

Related Patterns and Guidance

A general description of interoperability patterns, which covers similar patterns to this FHIR Implementation Guide can be found here:

NHS England Interoperability Handbook

The following table provides a map of the patterns.

NHS England Integration Patterns Book

The following table provides a map of the patterns.

For guidance on building healthcare applications (EHR) see:

NHS England Building healthcare software

Query Patient Care Data

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.

Description

The client sends an individual request for each data type they are interested in. For example if a practitioner wishes to view a patient (with id of 43210) conditions or problems. The practitioners app would run the following query

GET /Condition?patient=43210

This would list all the conditions recorded on the EHR system. The practitioner may only be interested in active problems, in this case the query is amended as follows.

GET /Condition?patient=43210&clinical-status=active

Not all system would support the active problem filter, it is an optional query parameter in IHE-QEDm. However if the EHR adheres to IHE-QEDm, patient support is mandatory. Searching by national identifiers (NHS or CHI Number) is not normally supported as a parameter, this is done via Patient Demographic Query which is used to obtain the patient id.

Example Implementations

• COVID-19 Test Results - FHIR API
• Immunisation History - FHIR API
• GP Connect Access Record: Structured - FHIR API FHIR STU3
• Care Connect API Suggested standard for FHIR STU3. UK equivalent of USCore

Patient Demographic Query

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.

Description

A list of IHE PDQm recommended search parameters can be found ITI-78 Search Parameters. A practitioner searching for a a patient via NHS or CHI Number would use the following query.

NHS Number - GET /Patient?identifier=https://fhir.nhs.uk/Id/nhs-number|9876543210

CHI Number - GET /Patient?identifier=urn:oid:2.16.840.1.113883.2.1.3.2.4.16.53|9876543210

Example Implementations

• Personal Demographics Service - FHIR API
• GP Connect Appointment Management - FHIR API FHIR STU3

Event Notifications

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)

Description

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.

Event Message

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

• Booking and Referral - FHIR API
• Digital Child Health - FHIR
• Personal Demographics Service Notifications - FHIR
• Electronic Prescription Service - FHIR API
• National Event Management Service - FHIR API
• Transfer of Care Emergency Care Discharge - FHIR
• Transfer of Care Inpatient Discharge - FHIR
• Transfer of Care Mental Health Discharge - FHIR
• Transfer of Care Outpatient Clinic Letter - FHIR
• Digital Medicine - FHIR

Task (/Requests)

Common use cases include:

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

Event Notifications is often used with Requests, together they form a workflow interaction and 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.

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.

[base]/ClaimResponse?request=Claim/[id]

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

• e-Referral Service Patient Care – FHIR API

Send Document

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

• GP Connect Send Document
• Transfer of Care Emergency Care Discharge - FHIR
• Transfer of Care Inpatient Discharge - FHIR
• Transfer of Care Mental Health Discharge - FHIR
• Transfer of Care Outpatient Clinic Letter - FHIR
• Digital Medicine - FHIR

Sharing Clinical Documents

Description

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.

(a). 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. This is typically a REST query ran on the registry

GET /DocumentReference?patient=43210

Searching by national identifiers (NHS or CHI Number) is not normally supported as a parameter, this is done via Patient Demographic Query which is used to obtain the patient id.

This query may return many documents, to reduce the results returned such as a filter on the date the document was created.

GET /DocumentReference?patient=43210&date=ge2020-01-01

(b). The consumer may view the document. This may be to a FHIR Binary endpoint but is often just a normal url.

Example Implementations

• National Record Locator - FHIR API Document Registry and implements interactions 2 and a in the above diagram.
• e-Referral Service Patient Care – FHIR API for referral supporting information.
• GP Connect Access Document - FHIR API FHIR STU3
• Care Connect API Suggested standard for FHIR STU3. UK equivalent of USCore.

Alert Communication

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. surgery 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 appropriate method of communication.

Example Implementations

• NHS App API

Structured Data Capture

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

• COVID-19 Medical Exemptions - FHIR API