Data synchronisation and conflict resolution

Why it matters

Clinical work cannot pause when a network does. An analysis of patient safety reports during electronic health record downtime found specimen identification errors, delayed results and medication administration errors [3]. A system that saves work on the device and synchronises later keeps care moving, but only if it reconciles changes safely.

Key points

• In the local first approach, data is written to local storage on the device and synchronised with other devices and servers in the background [1].
• FHIR R4 describes optimistic locking: the client sends the version it last saw, and the server rejects a stale write with a 412 Precondition Failed response rather than overwrite newer data [2].
• Last write wins is rarely acceptable for orders or allergies, because the later edit is not necessarily the correct one. A conflict held for review and resolved by an accountable person is safer.
• Data held on devices must be encrypted, governed by the same permissions as the server, and every action must reach the audit log.

In Moana

Moana performs on stable networks and is designed for unreliable connectivity: work is saved on the device and synchronised when the connection returns, and conflicting changes are presented to administrators for review.

Sources

1. Local first software: you own your data, in spite of the cloud, University of Cambridge repository (Onward! 2019), 2019
2. FHIR R4 RESTful API: managing resource contention and transactions, HL7 International, 2019
3. Implications of electronic health record downtime: an analysis of patient safety event reports, Journal of the American Medical Informatics Association, via AHRQ PSNet, 2018