Persisted Copy Shared Record
Provider systems contribute to a Shared Record which holds a persisted copy of the medication 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.
(1) Provider systems, e.g. prescribing or dispensing systems, creates FHIR Resources, such as the MedicationRequest and POSTs to the Shared Record.
(2) Consumer systems queries (GETs) the Shared Record to return FHIR Resoures they are interested in. This may be initiated via a manual process, such as a clinican requesting a patient's record, or via a polling mechanism.
(3) The Shared Record response contains the relevant FHIR Resource(s). The consumer system can choose to persist all, part or none of the data, as the data can be queried on demand.
-
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?