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.