Shared Medication Record Architectures
Regions within England are responsible for implementing their own Integrated Care Systems. At the heart of each will be a shared medication record. A view of a patient's current medication is essential information for most patient journeys.
There is not a single/ideal architecture for a shared medication record but there are two high-level architectures, and a combined hybrid architecture that would be ideal starting points for any implementation. These are;
- a federated architecture
- a persisted copy architecture
- a hybrid architecture combining both of the above.
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.
- 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.
- 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.
history search parameter against a FHIR server is not supported as per the international standard.
- 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.
- 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.
Persisted Copy Architecture
Provider systems contribute to the shared record which holds a persisted copy of the records. The shared record is incremental, with new records added rather than replacing previous records. The result is a longitudinal shared record. Consumer systems query the shared record.
-
Persisted data within a resilient shared record infrastructure gives protection from the risk of local provider system unavailability.
- Aggregation of records within the shared record allows for data analytics across data sets.
- What are the trigger events within provider systems to update the shared record?
One approach would be to share every medicines-related event with a shared record, as it happens. This works well in primary care and community care settings triggered by events such as prescribing, dispensing, supply and administration. It becomes complex for the secondary care setting as some medicines administered to an in-patient would not be relevant to see outside that care setting, for example pre-operation pain relief medication.
An alternative approach for secondary care is to update a shared record when there is a transfer of care event, such as a hospital admission or discharge/transfer. It is at these events when a medicines reconciliation activity typically occurs, which can be used as the trigger to query and then update a shared record.
- What detail of record should be persisted?
Persisting the transactional FHIR resources such as MedicationRequest and MedicationDispense would give access to detailed records. However for the most common use case of querying for current medication, such records would be too detailed. The shared record could consider converting these on-the-fly to MedicationStatement resources when querying for current medication. Equally valid would be for the provider systems to create MedicationStatement resources from the source data and persist those in the shared record.
- A copy of the record is persisted within the shared record, so all provider systems need to implement update and delete processes.
When a clinical system shares a record, and it is persisted, if that record is updated or deleted within the clinical system, it also needs to be updated or deleted within the shared record. This adds complexity compared to the federated architecture.
Hybrid Architecture
A mix of the two architectures above. Where provider systems are not able (yet) to implement a query API onto their records, but can send data, then this data can be persisted. Where provider systems can expose a query API, those records can be shared in real-time as per the federated architecture.
- Represents the real-world status of provider systems where many already support data extract and/or real-time query interfaces.
- The combined design considerations, and hence the combined complexity of both the federated and persisted copy architectures.