Persisted Single and Only Shared Record
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 the suggested Shared Record Maturity Roadmap at the bottom of this page.
- Complex update processes when the provider system IS NOT your clinical system related to ownership and permissions.
Refer to the identical consideration above for Persisted Copy Shared Records.