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.

ics-persited-copy-architecture


(1) Provider systems, e.g. prescribing or dispensing systems, creates FHIR Resources, such as the MedicationRequest and POSTs to the Shared Record.

(2) Consumer systems queries (GETs) the Shared Record to return FHIR Resoures they are interested in. This may be initiated via a manual process, such as a clinican requesting a patient's record, or via a polling mechanism.

Note: The addition of an Events Service can be used to notify subscribing systems of clinical events that can then trigger the query of the Shared Record.

(3) The Shared Record response contains the relevant FHIR Resource(s). The consumer system can choose to persist all, part or none of the data, as the data can be queried on demand.

Potential Benefits
  • Persisted data within a resilient shared record infrastructure gives protection from the risk of local provider system unavailability.
  • Aggregation of records within the shared record allows for data analytics across data sets.

Key Design Consideration
  • What are the trigger events within provider systems to update the shared record?

One approach would be to share every medicines-related event with a shared record, as it happens. This works well in primary care and community care settings triggered by events such as prescribing, dispensing, supply and administration. It becomes complex for the secondary care setting as some medicines administered to an in-patient would not be relevant to see outside that care setting, for example pre-operation pain relief medication.

An alternative approach for secondary care is to update a shared record when there is a transfer of care event, such as a hospital admission or discharge/transfer. It is at these events when a medicines reconciliation activity typically occurs, which can be used as the trigger to query and then update a shared record.

Key Design Consideration
  • What detail of record should be persisted?

Persisting the transactional FHIR resources such as MedicationRequest and MedicationDispense would give access to detailed records. However for the most common use case of querying for current medication, such records would be too detailed. The shared record could consider converting these on-the-fly to MedicationStatement resources when querying for current medication. Equally valid would be for the provider systems to create MedicationStatement resources from the source data and persist those in the shared record.

Key Design Consideration
  • A copy of the record is persisted within the shared record, so all provider systems need to implement update and delete processes.

When a clinical system shares a record, and it is persisted, if that record is updated or deleted within the clinical system, it also needs to be updated or deleted within the shared record. This adds complexity compared to the federated architecture.

Key Design Consideration
  • Complex update processes when the provider system IS NOT your clinical system related to ownership and permissions.

For example, an allergy record posted by one system but needs to be updated by another clinician from another care setting, using a different system.

Do all provider systems and users of those systems in the ecosystem have ownership and permission to update any part of the shared record?

Does only the source provider system and/or source clinician have ownership and permission to update the record that they posted to the shared record?

Should records never be physically updated but instead added and logically linked as superseded?

Are parallel processes, manual or integrated, required to enabling one clinician to request a change to a record owned by another clinican within the shared record?

Persisted Single and Only Shared Record

All systems use the shared record as their only record. Every system is both a provider and consumer. Every clinician in the shared record ecosystem reads and writes to the same record.

ics-persited-singleonlu-architecture

Potential Benefits
  • Records are truly shared, only stored once, logically separated from the clinical applications and available to all clinical systems within the ecosystem.
  • Consumer systems always access the latest/current data.
  • Negates the need to share/copy clinical data between systems following 'transfer of care' events such as admission, transfer or discharge. The 'event' will still exist as an interoperability exchange between systems, but the clinical data should not be included/duplicated, but instead linked or referenced back to the shared record.
  • Economies of scale. A large single and only shared record should cost less to operate and maintain than multiple vendor-centric medication records.

Key Design Consideration
  • Within England, the regional implementation of ICSs will require interoperability between regional shared records.

A likely architecture to support this would be a hybrid architecture with persisted single and only records within the ICS region, supplemented by records held in other regions obtained by query using a federated architecture. A service such as the NHS Digital National Record Locator (NRL) could be used to identify which other regions have records for the patient.

The same approach could be used for cross border interoperabiliy within the UK. If, for example, Scotland adopted a persisted single and only record architecture for shared records, but the patient also has records held within England, those records could be made available by federated queries.

Key Design Consideration
  • Resilience. What is the contingency plan if the shared record is unavailable?

The risk of information technology failure can never be totally negated. Some existing clinical systems are already totally relient on remote/cloud data so this is not a new or unique consideration. Every NHS organisation will need to define it's own contingency plans. The risk of failure should be sufficiently low so that it is not nessasary to duplicate/cache vast quantities of data locally for offline use.

Key Design Consideration
  • How to transition from current vendor-centric medication records or a single and only shared record?

See the suggested Shared Record Maturity Roadmap at the bottom of this page.

Key Design Consideration
  • Complex update processes when the provider system IS NOT your clinical system related to ownership and permissions.

Refer to the identical consideration above for Persisted Copy Shared Records.

Federated Shared Record

A Shared Record that persists no data but acts as a query proxy. Provider systems each expose a query API onto their patient records. Consumer systems query the shared record, which queries each provider system, amalgamating the results to present a consolidated response back to the consumer system.

ics-federated-architecture

Potential Benefits
  • Simple, therefore likely to succeed, especially as an initial implementation where provider systems are available to query, e.g. via GPConnect for England General Practice systems.
  • Records are stored once, within provider clinical systems, so no complex update or delete processes when the provider system is your clinical system.
  • Consumer systems always access the latest/current data.

Key Design Consideration
  • Complex update processes when the provider system IS NOT your clinical system.

For example, if an allergy record shared by a system needs to be updated by another clinician from another care setting. The original record cannot be remotely updated, leaving two options;

  1. Implement a parallel process, manual or integrated, enabling one clinician to request a change to a record owned by another clinican who is using a different provider system.
  2. An updated record is created by the clinician and made available to the shared record. If the old and new records can be logically linked plus, if possible, marked as superseding, then the shared record can show these records as previous/current. What must be avoided is consumer systems treating these records as separate or duplicate. The specifics of how this could be done using the FHIR standard are being worked through.
Key Design Consideration
  • Consumer systems are always accessing the latest/current data, what is the definition of 'current'?

A consumer system may query by date, e.g. effective=ge2020-05-11, which would return records dated from 11th May 2020. See the Query for Current Medication section within this guidance for a definition of 'current medication'.

Key Design Consideration
  • Resilience and availability of provider system query APIs.

If a provider system query API is temporarily unavailable then data from that system will not be accessible. The query response to the consumer system should include information for which provider system(s) were unable to be queried.

Key Design Consideration
  • Provider systems may be inconsistent with how they have implemented a standard such as FHIR.

Aligning to this implementation guidance will help mitigate against this risk. Some provider systems may expose medicines records events using transactional FHIR resources such as MedicationRequest and MedicationDispense. Some provider systems may expose medicines records as MedicationStatement resources, based on the underlying transactional FHIR resources such as MedicationRequest and MedicationDispense. Some may do both, as is the case for the GPConnect implementation within England, that returns both MedicationRequest and MedicationStatement resources for the patient's current medication.

Persisted Patient-Centric Shared Record

A radical shift from established regional or provider-centric architectures but a model that fully supports the NHS England data strategy policy to separate the data layer from the application layer.

ics-persited-patient-centric-architecture

Potential Benefits
  • Aligns with the NHS England 'Data Strategy' policy to “separate the data layer”.
  • Aligns with the political objective of patient-centric care, putting the patient in control of who uses their data.
  • Removes complexities related to geography. It does not matter where in each country or region you receive care, the clinical systems used access your record. Your record stays with you.
  • The record should be the ONLY record. Provider and consumer systems directly integrate with the record. They do not, and should not, need to persist a copy into any legacy provider-centric patient record. Removes all the complexity of persisting a copy of a record and needing to keep that in-sync with the source record.

Key Design Consideration
  • These technologies are not yet well understood. It will be a significant mental leap to go from provider-centric data stores to patient-centric data stores.

It will be a brave vendor who builds the first solution using patient-centric data stores at the heart. It will be a brave patient who first moves their NHS records into their own patient-centric data store. Someone has to be the first.

Key Design Consideration
  • How will systems ‘discover’ if a patient already has a patient-centric shared record?

Patient-centric records needs to be discoverable. Before any implementation creates a new shared record for a patient, the system needs to see if the patient already has a record. We want to avoid multiple patient-centric records being created. The solution here could be the NHS Digital National Record Locator (NRL). That could hold a pointer to every patient-centric shared record.

Key Design Consideration
  • The API standard(s) to give patient access, control and ownership are emerging. There is not yet a de-facto standard let alone a candidate to be a national standard.

The Solid Pod API may become the de-facto standard or there may be VHS vs Betamax / Blu-Ray vs DVD-HD battles before a standard is established for access, control and ownership of patient-centric cloud-based data stores.

Key Design Consideration
  • Existing providers who have made significant investment, or receive significant revenue from their data storage solutions will feel they are losing ownership and control, because they are losing ownership and control.

A provider-centric record could be turned into a patient-centric record by adding the necessary API to give the patient access, control and ownership. It does not need the record to be physically migrated to a different or special hosting platform. Technologies like Solid Pod can be hosted on any platform. What Solid Pod gives is the API. An equivalent API could be added to an existing shared record. The API standard(s) to give patient access, control and ownership are emerging. There is not yet a de-facto standard let alone a candidate to be a national standard.

Key Design Consideration
  • Should such records be a copy, or the single/master/primary record used by all connected clinical systems?

Should patient-centric records instead be a copy, populated from one or more regional shared records? This would need to be a two-way data feed, as some data may be added directly into the patient-centric record, e.g. from patient-facing apps. This could be a transition architecture where the patient-centric record starts as a synchronised copy, but transitions over time to become the ‘single and only’ record.

Key Design Consideration
  • Complex update processes when the provider system IS NOT your clinical system related to ownership and permissions.

Refer to the identical consideration above for the Persisted Copy Shared Records.

Hybrid Architecture Shared Record

= Any combination of the above.

Where provider systems are not able (yet) to implement a query API onto their records, but can POST data and have this persisted by the shared record.

Where provider systems can expose a query API, those records can be shared in real-time as per the federated architecture.

Where patients have chosen to use a patient-centric record, provider and consumer systems read and write to that record.

Provider systems can use the shared record as their single and only record, using data both persisted within the shared record, or made available via federated query from provider systems and/or patient-centric records.

ics-hybrid-architecture

Potential Benefits
  • Represents the real-world picture of provider systems. Some share data via bulk extracts, some support real-time query interfaces amd some push data based on business event triggers.
  • The likely transition architecture during the adoption of patient-centric stores as these will take time to mature, be understood and be accepted by the general public.

Key Design Consideration
  • The combined design considerations, and hence the combined complexity of all architectures.

Shared Record Maturity Roadmap (applies to England only)

Note: This is a suggested maturity roadmap for the architectural options described above and is work-in-progress.

It is based on the current assumption that the ultimate goal is a "patient-centric single and only" shared record.

shared-records-maturity-roadmap

The starting architecture will be dictated by ambition, but most likely, the available connected clinical systems within the shared record eco-system.

For example, if no existing systems can provide a query interface but can share data as part of bulk or event-based extracts then you will probably start with a persisted copy architecture.

NOTE: The following descriptions for transitions through the maturity roadmap are described at a very high level. The detailed complexity of these has not been over-looked and this guidance will be updated over time.

Transition: Federated to Hybrid (adding Persisted Copy)

  • Introduce a persistence layer to store records obtained by mechanisms such as event-sourcing or bulk data extracts.
  • Key design decisions will include what business triggers will result in data persistance.
  • Data returned to querying consumer systems is an amalgamation of data retreived from federated queries plus that retreived from persisted data.

Transition: Persisted Copy to Hybrid (adding Federated)

  • Introduce a query proxy for systems that have implemented a query interface.
  • Data returned to querying consumer systems is an amalgamation of data retreived from persisted data plus that retreived from federated queries.

Transition: Persisted Copy to Persisted Single and Only

  • Provider systems transition from accessing local records to shared records. This will take time and may start with a subset of records, i.e. maybe start with allergy records. This transition may seem enormous but for those clinical systems that already use cloud-based records, it is switching the provider cloud environment. Some data will remain in the local provider enviroment but the volume should decrease over time, as the size of shared records increases.
  • Provider systems transition their record queries from their propriatary APIs to a FHIR API; as shared records should be exposed via a FHIR API. The software change for this could be significant.

Transition: Hybrid to Persisted Single and Only

  • As per 'Persisted Copy to Persisted Single and Only' above.
  • Federated access to records may continue for those provider systems that have not moved across to using a persisted single and only shared record.

Transition: Patient-Centric Persisted Copy to Patient-Centric Single and Only

  • Provider systems transition from copying elements of the local record into the patient-centric record, to using the patient-centric record as the default/master. This will take time and may start with a subset of records, i.e. maybe start with allergy records.
  • This transition becomes more feasible once the volume of patients opting to use patient-centric stores increases.

Transition: Persisted Single and Only to Patient-Centric Single and Only

  • This transition could occur in two different ways;
    • A shared regional/provider-specific record has the nessasary APIs added to give the patient control and ownership, including, if requested, the ability for the patient to move their record to another provider.
    • A data migration from a regional/provider-specific shared record provider to a patient-centric shared record provider.
back to top