Implementation guide for interoperable medicines

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

Reference Architectures

Note: This section of the implementation guidance is work-in-progress.
READER ACTION: Decide which reference architecture best suits your ecosystem; the combination of care settings, organisations, existing and proposed new clinical systems.

To describe how interactions could work, a collection of reference architectures are described below. All contain at least two clinical systems;

  • Prescribing System, the creator of MedicationRequest resources

  • Dispensing System, the creator of MedicationDispense resources

Some reference architecture include a Message Broker system which is akin or could be part of a Shared Records platform. In some implementations, especially those within an acute trust, there may be an Integration Engine system/service sitting between the clinical systems and the Message Broker or Shared Record. Combinations of the architectures described below would also be feasible.

Note: Some of the reference architectures described here include Event notification interactions. These are not described in any further detail within this version of this implementation guide.

The first architectural decision will be to choose between a point-to-point messaging or a query shared records high level architecture.

Point-to-Point Messaging

These are the most simple architectures for interoperability between a single prescribing system and a single dispensing system.

Potential Benefits
  • Simple architecture
  • Suitable for a initial implementation or when only two systems need to be interoperable.

Key Design Consideration
  • Which system acts as the Provider and which acts as the Consumer?

Prescribing and Dispensing systems act as FHIR servers

api-architecture-both-rx-and-disp-are-fhir-servers-simple


(1) The prescribing system creates the MedicationRequest with a valid externally referencable identifer and POSTs to the dipensing system which adds the logical id on receipt. The MedicationRequest is triggered when the MedicationRequest.status = active.

(2) The dispensing system creates the MedicationDispense with a valid externally referencable identifer and POSTs to the prescribing system which adds the logical id on receipt. The MedicationDispense is triggered when the MedicationDispense.status = completed.

(3) On receipt, the prescribing system can set the MedicationRequest.status = completed.

Dispensing system acts as the FHIR server

api-architecture-disp-is-fhir-server-simple


(1) The prescribing system creates the MedicationRequest with a valid externally referencable identifer and POSTs to the dipensing system which adds the logical id on receipt. The MedicationRequest is triggered when the MedicationRequest.status = active.

(2) The prescribing system queries the dispending system via a GET using the unique identifer from the MedicationRequest, i.e. "get the dispensing record for this request". The dispensing system assigns the logical id. The GET request may be sent at any time so the dispensing system may choose to expose MedicationDispense.status values that represent both in-progress and end-states for the dispensing record.

(3) When the dispensing system returns a MedicationDispense.status of completed, the prescribing system can set the MedicationRequest.status = completed.

Prescribing system acts as the FHIR server

api-architecture-rx-is-fhir-server-simple


(1) The prescribing system sends an event notification to the pharmacy system when a new MedicationRequest is ready for processing. The notification must include the external externally referencable identifer. The prescirbing system assigns the logical id.

(2) The prescribing system GETs the MedicationRequest using the identifer. The GET request may be sent at any time so the pharmacy system may choose to expose MedicationRequest.status values that represent both in-progress and end-states for the prescribing record.

(3) The dispensing system creates the MedicationDispense with a valid externally referencable identifer and POSTs to the prescribing system which adds the logical id on receipt. The MedicationDispense is triggered when the MedicationDispense.status = completed.

(4) On receipt, the prescribing system can set the MedicationRequest.status = completed.

Key Design Consideration
  • Does not scale for multiple provider and consumer systems with risk of bespoke interfaces.

Point-to-point messaging interoperability gets very complex when multiple provider and consumer systems are introduced. The number of point-to-point connections needed to integrate a given number of systems increases exponentially as additional systems are added.

To link up two ePMA system plus the hospital pharmacy system will require three point-to-point connections. By adding only two more systems, this changes to 10 connections. With N systems number of connections is N(N-1)/2. With 10 systems, that is 45 separate point-to-point implementations.

Add to that if each system wants subtly difference interfaces the complexity becomes unmanagable. Compare that to using a Shared Record, where the Shared Record sets the standard. All systems implement just one interface, to the Shared Record.

Shared Record Platforms

Integrated Care Boards (ICBs) within England are responsible for implementing their own Integrated Care Systems. At the heart of each will be a shared patient record of which medications are key. A view of a patient's current medication is essential information for most patient journeys.

Scotland and Wales are considering more of a national solution for their shared patient records.

There is no single or ideal architecture for a shared medication record, or at least not one that has universal support. This section outlines the following shared record architectures with a suggested maturity roadmap.

  1. Persisted Copy Shared Record
  2. Persisted Single and Only Shared Record
  3. Federated Shared Record
  4. Persisted Patient-Centric Shared Record
  5. Hybrid Shared Record

But first, for most Trust implementations, the role of a Trust Integration Engine (TIE) needs to be understood.

Role of a Trust Integration Engine (TIE)

Secondary care implementations generally depend on the interactions between multiple provider systems, often from different vendors. The Trust Integration Engine (TIE) enables access to these provider systems through one consistent, secure platform.

Without the TIE as the centrepiece in the architecture, the Trust Patient Administration System (PAS) has to take on the responsibility of integration between provider and consumer systems. This can be complex as the PAS already undertakes a number of responsibilities.

By implementing the TIE, which is solely involved with the task of integration, the platform becomes more flexible and scalable, and the flow of patient and clinical data more coherent and secure.

Where an implementation uses a Trust Integration Engine (TIE), this would logically sit between the provider/consumer systems and the Shared Record.

trust-integration-engine

Potential Benefits
  • Enhance the flow of patient information securely and seamlessly.
  • Increase safety of clinical data.
  • An integration platform that is more strategic, flexible and scalable.

Persisted Copy Shared Record

Provider systems contribute to a Shared Record which holds a persisted copy of the medication records. The Shared Record is incremental, with new records added rather than replacing previous records. The result is a longitudinal Shared Record. Consumer systems query the Shared Record.