The short answer. Records created during an EHR outage should go back into the restored EHR only after five checks: the production environment is confirmed clean, each record is tied to the right patient, each record carries its original time and author, conflicts with what’s already in the chart are sent to a clinician instead of overwriting, and every write is logged. Skip the first check and you risk reinfecting a system you just spent weeks restoring. Skip the others and you get duplicate orders, misfiled results and a medication history nobody trusts.
Most recovery plans end when the EHR comes back online. For clinical and IT teams, that’s when a second, quieter project starts: getting two or three weeks of downtime records into the chart without breaking it.
Why sync-back goes wrong
The restore itself can carry the infection
Hospitals restore from backups, and backups are an attacker’s early target. Sophos found that 73% of healthcare organizations hit by ransomware restored encrypted data from backups, and that attackers tried to compromise backups in 95% of attacks, succeeding 66% of the time (Sophos, State of Ransomware in Healthcare 2024). If production comes back from a tainted copy, anything you write into it lands in an environment that may still be compromised. The sync-back has to wait for a clean bill of health.
Paper doesn't reconcile cleanly
When downtime runs on paper, every order and note written on a form has to be typed back into the EHR by someone who wasn’t there when it was written. Downtime already produces this kind of error. In a JAMIA study of 76 patient safety reports tied to EHR downtime, lab processes accounted for 48.7% of events, and patient identification problems made up about a quarter of those lab events (Larsen et al., JAMIA, 2017). Re-entry at scale, under pressure to reopen, multiplies the same risks.
The chart kept moving
Recovery rarely happens all at once. Some interfaces come back before others, and some units return to the EHR while others are still in downtime. A record created in a downtime system on day nine may conflict with something entered directly into the restored EHR on day ten. Without a rule for that conflict, the last write wins, and nobody knows which one that was.
Five checks every sync-back should pass
| Check | What it prevents | Who owns it |
|---|---|---|
| 1. Production is confirmed clean before any write | Reinfection and writing into a compromised system | Security team, incident lead |
| 2. Every record matches the right patient | Misfiled results and orders | HIM, with a required MRN on every record |
| 3. Original timestamp and author travel with the record | A chart that shows care happening at the wrong time, by the wrong person | Interface team |
| 4. Conflicts go to a clinician, not to "last write wins" | Duplicate orders, silent overwrites | Clinical informatics |
| 5. Every write is logged and exportable | An audit you can't answer | Compliance |
1
Gate the write on a clean environment
The sync-back should be blocked, not just discouraged, while production still shows signs of compromise. Put that decision in the security team’s hands, with a named sign-off, and build the tooling so the write path physically can’t open until they give it.
2
Match on a required identifier
Patient matching fails most often when identifiers are optional or free text. Require a medical record number on every downtime record, store other identifiers as typed fields, and reject anything that can’t be matched instead of guessing.
3
Keep time and authorship intact
HIPAA’s integrity standard requires covered entities to protect electronic protected health information from improper alteration or destruction (45 CFR 164.312(c)(1)). A downtime note re-entered on day 15 under a clerk’s login, with a day-15 timestamp, is an alteration of the clinical record in practice. The original time and the original author have to travel with the record.
4
Send conflicts to a person
When a downtime record disagrees with the restored chart, the answer is an exception queue reviewed by a clinician, not an automated overwrite. It’s slower, and it’s the only version that holds up when someone asks why a medication appears twice.
5
Log every write
Every record written back should be logged with what was written, when, from where and on whose authority. Your compliance team will want that log exported and kept, because the questions come months later.
Plan the sync-back before the outage. The week the EHR comes back is the worst possible time to decide who approves the write and where the log lives.
How Spare Tire handles sync-back
Spare Tire builds the first and last checks into the platform. Records can be validated before they’re written back to the primary EHR, and a primary environment still showing signs of compromise blocks the write. Records created during downtime are time-stamped and signed at creation, and conflicts surface as exceptions for clinical review instead of overwriting silently. The Activity Log can be exported to CSV for compliance review; exports are deleted after three days, so save them where your records policy says they belong.
How records come back depends on the clinical area. Radiology orders and results travel as discrete HL7 messages in both directions. For other clinical areas, the work done during downtime returns to the primary EHR as a validated summary report. Every Spare Tire record also carries the MRN as its own required field, which supports check two.
The best way to see this is a planned downtime window: run a unit in Spare Tire for a shift, then watch the records come back and review the exception queue with your informatics team.
Frequently asked questions
How do downtime records get back into the EHR?
Either by hand, from paper, or through an interface from a downtime system. Interface-based sync-back is faster and avoids retyping, but it should only run after the restored environment is confirmed clean and should route conflicts to clinicians.
Can syncing downtime data reinfect a restored EHR?
The records themselves are rarely the problem. The risk is writing into a production environment that was restored from a compromised backup, or opening a write path before security has cleared it. Sophos reports that attackers succeed in compromising backups in 66% of the healthcare attacks where they try (Sophos, 2024).
Who should approve an EHR sync-back after a cyberattack?
The security or incident lead approves when the environment is clean enough to receive writes. Clinical informatics owns conflict review. Compliance owns the log. Name all three in the downtime plan before you need them.