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.

Federated Shared Record

A Shared Record that persists no data but 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.

ics-federated-architecture

Potential Benefits
  • Simple, therefore likely to succeed, especially as an initial implementation where provider systems are available to query, e.g. via GPConnect for England General Practice systems.
  • Records are stored once, within provider clinical systems, so no complex update or delete processes when the provider system is your clinical system.
  • Consumer systems always access the latest/current data.

Key Design Consideration
  • Complex update processes when the provider system IS NOT your clinical system.

For example, if an allergy record shared by a system needs to be updated by another clinician from another care setting. The original record cannot be remotely updated, leaving two options;

  1. Implement a parallel process, manual or integrated, enabling one clinician to request a change to a record owned by another clinican who is using a different provider system.
  2. An updated record is created by the clinician and made available to the shared record. If the old and new records can be logically linked plus, if possible, marked as superseding, then the shared record can show these records as previous/current. What must be avoided is consumer systems treating these records as separate or duplicate. The specifics of how this could be done using the FHIR standard are being worked through.
Key Design Consideration
  • Consumer systems are always accessing the latest/current data, what is the definition of 'current'?

A consumer system may query by date, e.g. effective=ge2020-05-11, which would return records dated from 11th May 2020. See the Query for Current Medication section within this guidance for a definition of 'current medication'.

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