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. If the reference architecture includes a 'message broker' then see Shared Medication Record Architectures.

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 notification interactions. These are not described in any further detail within this version of this implementation guide.

Prescribing and Dispensing systems act as FHIR servers

The most simple architecture for interoperability between a single prescribing system and single dispensing system.

(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

(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

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

Message broker acts as the FHIR server

In this example, the Message Broker system is akin to a Shared Record platform.

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

(2) The prescribing system directly sends an event notification to the dispensing system with the identifer for the MedicationRequest.

(3) The dispensing system GETs the MedicationRequest from the shared record system using the identifer.

(4) The dispensing system creates the MedicationDispense with a valid externally referencable identifer and POSTs this to the shared record system. The MedicationDispense is triggered when the MedicationDispense.status = completed. The message broker adds the logical id on receipt.

(5) The dispensing system directly sends an event notification to the prescibing system with the identifer for the MedicationDispense.

(6) The prescribing system GETs the MedicationDispense from the message broker using the identifer.

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

Note: This architecture is close to that implemented by the Electronic Prescription Service (EPS). The (2) event notification is implemented via a paper or electronic token containing the barcoded identifier (aka the EPS 'Prescription ID') that the patient presents to the pharmacy. Not yet implemented within the EPS are flows (5), (6) and (7).

Message broker acts as the FHIR server and events server

In this example, the Message Broker system is akin to a Shared Record platform an also acts as an events notification system.

(2) The message broker triggers an event, to notify subscribing systems of the new MedicationRequest; the dispensing system must be a subscriber for this event.