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.

Federated Architecture

The shared record persists no data. It 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.

Potential Benefits
  • Simple, therefore likely to succeed, especially as an initial implementation where provider systems are available to query, such as via GPConnect.
  • Records are stored once, within provider clinical systems, so no complex update or delete processes to implement.
  • Consumer systems always access the latest/current data.

Key Design Consideration
  • Consumer systems are always accessing the latest/current data, historic data may be more complex to share.

Provider systems may have to additionally provide a query API that can return historic records. A consumer system may ask for historic records via a data constraint such as effective=ge2020-05-11, i.e. records dated from 11th May 2020.

Where a federated shared record only returns 'current' data by default then a bespoke query parameter such as history=true may be an option.

NOTE: Technically the use of a history search parameter against a FHIR server is not supported as per the international standard.
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.

back to top