Disaster recovery for hospitals and healthcare providers
A hospital cannot tell patients to come back on Thursday. That single fact changes how disaster recovery is planned here: the question is rarely “how do we get everything back” but “which things have to come back first, and what does the ward do in the meantime”.
Two numbers, set per system
Every recovery plan rests on two figures, and the common mistake is setting them once for the whole estate.
- Recovery time objective (RTO) — how long a system may be unavailable.
- Recovery point objective (RPO) — how much recent data you can afford to lose.
Set them for the whole hospital and you will either overpay to protect the reporting database as though it were the EMR, or underprotect the EMR to a standard chosen for reporting. Set them per system and the budget goes where the clinical risk is.
What your copy interval costs you
RPO is not a target you choose freely. It is decided by how often you copy data, and no recovery process can beat that interval.
Read the top row carefully, because it is the one most hospitals are actually on. A nightly backup means a failure in the evening discards that day’s admissions, medication administration records and notes. Whether that is acceptable is a clinical decision, not an IT one, and it should be recorded as such with a name against it.
The lower rows cost more, and not only in licensing: synchronous replication requires the second site to be close enough that waiting for its acknowledgement does not slow every write, which constrains where you can put it. Asynchronous replication removes the distance limit and reintroduces a small window of loss. Most hospitals end up with a mix — replication for the clinical systems, snapshots for the administrative ones, nightly backups for everything else.
The part of the plan that is not technical
Between the failure and the restore, the hospital keeps running. A recovery plan that does not say how is incomplete.
- Downtime forms.Printed, current, and stored where the ward can reach them without the network. Forms that reflect a version of the system from four years ago are worse than none, because staff will trust them.
- Re-entry.Everything recorded on paper has to go back into the system afterwards, and that work lands on the same people who just worked an outage. Plan the hours.
- Who declares it.Most delay in a real incident is not technical. It is the half hour spent deciding whether this counts as a disaster and who is allowed to say so. Name the person and the threshold in advance.
- Communications that do not depend on the thing that failed.If the plan is circulated by email and email is down, there is no plan.
Testing, and what counts as a test
A restore that has never been performed is a hypothesis. Three levels of test, in increasing order of usefulness:
- Restore a file.Proves the backup is readable. Do it monthly, and automate the verification.
- Restore a system to an isolated environment.Proves the system comes up and the data is consistent. This is where you discover the dependency nobody documented — the licence server, the interface engine, the certificate.
- A declared exercise with the ward involved.Proves the people part works. It is the only test that ever finds the downtime forms are out of date.
Record the time each test takes. That number, not the target in the policy, is your real RTO.
Where this fits
The service is Disaster Recovery, and the sector context is Healthcare. It is usually specified alongside Data Protection, which covers the backup and retention side, and it is the reason testing restores matters more than backup success reports. Hospitals running AcmaCare should tier the modules separately rather than treating the platform as one system.
