Shared Medication Record Architectures
NHS Regions or local health and care organisations within England are responsible for implementing their own Integrated Care Systems. At the heart of each will be a shared patient record of which medications are key. A view of a patient's current medication is essential information for most patient journeys.
Scotland and Wales are considering more of a national solution for their shared patient records.
There is no single or ideal architecture for a shared medication record, or at least not one that has universal support. This section outlines some architectural options and a suggested maturity roadmap.
Trust Integration Engine
Secondary care implementations generally depend on the interactions between multiple provider systems, often from different vendors. The Trust Integration Engine (TIE) enables access to these provider systems through one consistent, secure platform.
Without the TIE as the centrepiece in the architecture, the Trust Patient Administration System (PAS) has to take on the responsibility of integration between provider and consumer systems. This can be complex as the PAS already undertakes a number of responsibilities.
By implementing the TIE, which is solely involved with the task of integration, the platform becomes more flexible and scalable, and the flow of patient and clinical data more coherent and secure.
Where an implementation uses a Trust Integration Engine (TIE), this would logically sit between the provider/consumer systems and the Shared Record.
- Enhance the flow of patient information securely and seamlessly.
- Increase safety of clinical data.
- An integration platform that is more strategic, flexible and scalable.
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, 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.
- 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;
- 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.
- 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.
- 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'.
- 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.
- Complex update processes when the provider system IS NOT your clinical system related to ownership and permissions.
For example, an allergy record posted by one system but needs to be updated by another clinician from another care setting, using a different system.
Do all provider systems and users of those systems in the ecosystem have ownership and permission to update any part of the shared record?
Does only the source provider system and/or source clinician have ownership and permission to update the record that they posted to the shared record?
Should records never be physically updated but instead added and logically linked as superseded?
Are parallel processes, manual or integrated, required to enabling one clinician to request a change to a record owned by another clinican within the shared record?
Persisted Single and Only Architecture
All systems use the shared record as their only record. Every system is both a provider and consumer. Every clinician in the shared record ecosystem reads and writes to the same record.
- Records are truly shared, only stored once, logically separated from the clinical applications and available to all clinical systems within the ecosystem.
- Consumer systems always access the latest/current data.
- Negates the need to share/copy clinical data between systems following 'transfer of care' events such as admission, transfer or discharge. The 'event' will still exist as an interoperability exchange between systems, but the clinical data should not be included/duplicated, but instead linked or referenced back to the shared record.
- Economies of scale. A large single and only shared record should cost less to operate and maintain than multiple vendor-centric medication records.
- Within England, the regional implementation of ICSs will require interoperability between regional shared records.
A likely architecture to support this would be a hybrid architecture with persisted single and only records within the ICS region, supplemented by records held in other regions obtained by query using a federated architecture. A service such as the NHS Digital National Record Locator (NRL) could be used to identify which other regions have records for the patient.
The same approach could be used for cross border interoperabiliy within the UK. If, for example, Scotland adopted a persisted single and only record architecture for shared records, but the patient also has records held within England, those records could be made available by federated queries.
- Resilience. What is the contingency plan if the shared record is unavailable?
The risk of information technology failure can never be totally negated. Some existing clinical systems are already totally relient on remote/cloud data so this is not a new or unique consideration. Every NHS organisation will need to define it's own contingency plans. The risk of failure should be sufficiently low so that it is not nessasary to duplicate/cache vast quantities of data locally for offline use.
- How to transition from current vendor-centric medication records or a single and only shared record?
See Shared Medication Record Architectures - Maturity Roadmap.
- Complex update processes when the provider system IS NOT your clinical system related to ownership and permissions.
Refer to the identical consideration above for the Persisted Copy Architecture architecture.
Persisted Patient-Centric Architecture
A radical shift from established regional or provider-centric architectures but a model that fully supports the NHS England data strategy policy to separate the data layer from the application layer.