ePMA Implementation Guidance for FHIR STU3

This guidance is under active development by NHS Digital and content may be added or updated on a regular basis.
Please note: This guidance has been superseded by the Implementation guide for digitial medicines, which contains up-to-date information.

Interactions

Reference Architectures

There is no implied order for the reference architectures described below. Each includes the same three systems;

  • Prescribing System, the creator of MedicationRequest resources

  • Dispensing System, the creator of MedicationDispense resources

  • Integrated Care System (ICS) or Shared Record system, that provides services to share medication records with clinicians across local, regional and national care settings.

Combinations of the architectures described below would also be feasible. For example, the first architecture listed below but with a persisted copy Shared Record architecture.

Prescribing and Dispensing systems act as FHIR servers, with a federated Shared Record architecture


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


(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 only shared once ready for pharmacy processing so the status will only deal with valid end-states.

(2) The dispensing system creates the MedicationDispense with a valid externally referencable identifer and POSTs to the e system which adds the logical id on receipt. The MedicationDispense is only shared once ready to share with the pharmacy system so the status will only deal with valid end-states.

(3) The prescribing system is responsible for sharing records with the shared record system with the resource identifer akin to a primary key. It may choose to send an event notification to the shared record system that new records are available.

(4) The shared record system can query with a GET for records by identifer.

Dispensing system acts as the FHIR server, with a persisted copy Shared Record architecture


api-architecture-disp-is-fhir-server


(1) The prescibing system creates the MedicationRequest with a valid externally referencable identifer and POSTs to the dispending system which adds the logical id on receipt. The MedicationRequest is only shared once ready for pharmacy processing so the status will only deal with valid end-states.

(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 status values that represent both in-progress and end-states for the MedicationDispense record.

(3) The prescibing system POSTs records to the shared record system. These are likely to be as MedicationStatements, which could reference the source data from MedicationRequest and MedicationDispense records. Alternatively MedicationRequest and MedicationDispense records could be shared which the shared record system amalgamates and exposes as MedicationStatements for other consuming systems.

Prescribing system acts as the FHIR server, with a persisted copy Shared Record architecture


api-architecture-rx-is-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 status values that represent both in-progress and end-states for the MedicationRequest record.

(3) The dispending system creates the MedicationDispense with a valid externally referencable identifer and POSTs to the presribing system which adds the logical id on receipt. The MedicationDispense is only shared once ready to share with the pharmacy system so the status will only deal with valid end-states.

(4) The prescribing system POSTs records to the shared record system. These are likely to be as MedicationStatements, which could reference the source data from MedicationRequest and MedicationDispense records. Alternatively MedicationRequest and MedicationDispense records could be shared which the shared record system amalgamates and exposes as MedicationStatements for other consuming systems.

A persisted copy shared record system acts as the FHIR server, with an event notifications service


api-architecture-ics-is-fhir-server-and-notifies-rx-and-disp


(1) The prescribing system creates the MedicationRequest with a valid externally referencable identifer and POSTs this to the shared record system which adds the logical id on receipt. The MedicationRequest is only shared once ready for pharmacy processing so the status will only deal with valid end-states.

(2) The shared record system triggers an event, to notify subscribing systems of the new MedicationRequest; the pharmacy 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 shared record system adds the logical id on receipt. The MedicationDispense is only shared once ready to share with the pharmacy system so the status will only deal with valid end-states.

(5) The shared record system triggers an event notification to notify subscribing systems of the new MedicationDispense; the pharmacy system must be a subscriber for this event.

(6) The prescribing system GETs the MedicationDispense from the shared record system using the identifer.

A persisted copy shared record system acts as the FHIR server, with point-to-point notifications


api-architecture-ics-is-fhir-server-p2p-rx-disp


(1) The prescribing system creates the MedicationRequest with a valid externally referencable identifer and POSTs this to the shared record system. The shared record system adds the logical id on receipt. The MedicationRequest is only shared once ready for pharmacy processing so the status will only deal with valid end-states.

(2) The dispensing system directly sends an event notification to the pharmacy 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 shared record system adds the logical id on receipt. The MedicationDispense is only shared once ready to share with the pharmacy system so the status will only deal with valid end-states.

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

(6) The pharmacy system GETs the MedicationDispense from the shared record system using the identifer.

Specific FHIR data elements

There are a number of feasible application architectures that would support ePMA to Pharmacy interoperability, and wider interoperability with shared record platforms.

With regard to the use of the specific FHIR data elements, the architectures may change how and when the id, identifer and status elements are used.

Use of identifier

The identifier is the most important element of a FHIR resource for interoperability. It acts as the externally facing unique business identifier for the resource. A key phrase from the FHIR R4 standard is;

[for identifier] ...All resources that have an identifier element support searching by the identifier, so that records can be located by that method.

Use of id

By contrast, the resource id is normally an internally facing unique logical identifier. Within the FHIR R4 standard is the key phrase related to the logical id where it is:

[for id] ...assigned by the server responsible for storing it

Use of status

The different types of business status for MedicationRequest and MedicationDispense resources made visible within systems may change depending the interoperability architecture. Within some architectures, only valid end-states may be exposed, e.g. active MedicationRequests. Within other architectures, when systems query the system acting as the FHIR server, records or any state may be returned, including records that may be draft or other values that denote the business process has not yet completed.

Adoption of a common POST query syntax would allow the same software to, for example, POST a FHIR resource point-to-point to a dispensing system, POST a FHIR resource to a service like the Electronic Prescription Service (EPS), or POST a FHIR resource to a shared records service. A service like the EPS may require some additional data elements, but the mechanism of posting can be the same, using a different base URL technical end-point.

Adoption of a common GET query syntax would allow the same software to, for example, GET FHIR resources from a GP system or GET FHIR resources from shared records service. The query syntax can be the same, using a different base URL technical end-point.

POST Interactions

When POSTing a FHIR resource using a RESTful API use;

POST {fhir_server_base_url}/{resource}

For example;

POST https://myfhirserver.net/medicationrequest

with a Body containing a single FHIR resource. Other resources referenced must be referenced with valid identifer values to allow the FHIR server to locate those resources.

{
    "resourceType": "MedicationRequest",
    "identifier": "a54219b8-f741-4c47-b662-e4f8dfa49ab6"
    // etc.
}

When POSTing a FHIR Message use;

POST {fhir_server_base_url}/$process-message

with a Body containing a FHIR Bundle within which is a FHIR MessageHeader resources and multiple FHIR resources;

{
  "resourceType": "Bundle",
  "id": "0A1FD9EF-A3D5-4E95-84CD-552070A03083",
  "identifier": {
    "system": "https://tools.ietf.org/html/rfc4122",
    "value": "34470bbf-07cb-4b49-bef9-f958114f821f"
  },
  "type": "message",
  "entry": [
    {
      "fullUrl": "urn:uuid:0A1FD9EF-A3D5-4E95-84CD-552070A03083",
      "resource": {
        "resourceType": "MessageHeader",
        "id": "0A1FD9EF-A3D5-4E95-84CD-552070A03086",
        "eventCoding": { }, // etc.
        "sender": { }, // etc.
        "source": { }, // etc.
        "destination": { } // etc.
        }
    },
    {
      "fullUrl": "urn:uuid:a54219b8-f741-4c47-b662-e4f8dfa49ab6",
      "resource": {
        "resourceType": "MedicationRequest",
        "identifier": "a54219b8-f741-4c47-b662-e4f8dfa49ab6"
        // etc.
}

GET Interactions

To query a FHIR server for a specific resource by identifier;

GET https://{fhir_server_base_url}/{resource}?identifier={value}

For example;

GET https://myfhirserver.net/MedicationRequest?identifier=a54219b8-f741-4c47-b662-e4f8dfa49ab6

To query a FHIR server for a specific resources for a given patient;

GET https://{fhir_server_base_url}/{resource}?patient.identifier=https://fhir.nhs.uk/Id/nhs-number|{NHS_Number}

For example;

GET https://myfhirserver.net/MedicationRequest?patient.identifier=https://fhir.nhs.uk/Id/nhs-number|123543254
back to top