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.

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.


back to top