Reference 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
resourcesDispensing 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.
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
(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
(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
.
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.
(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 message broker triggers an event, to notify subscribing systems of the new MedicationRequest
; the dispensing system must be a subscriber for this event.
(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 message broker triggers an event notification to notify subscribing systems of the new MedicationDispense
; the prescribing system must be a subscriber for this event.
(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
.