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?