12.3 Business Continuity and Disaster Recovery Design
Key Takeaways
- Business continuity keeps care and essential operations running during a disruption (people, paper, downtime viewers, command). Disaster recovery restores IT systems and data after the disruption (backups, failover, rebuild).
- RTO is maximum acceptable downtime (how long the service may be unusable). RPO is maximum acceptable data loss measured backward in time (how stale the restored data may be). They are not interchangeable.
- HIPAA’s contingency standard already requires a data backup plan, a disaster recovery plan, and emergency-mode operation procedures; criticality analysis is how you tier systems instead of giving the warehouse the EHR’s RTO.
- Clinical EHR downtime is a designed mode of care: declare, communicate out-of-band, view on a surviving appliance, document on controlled paper, then backload in a named sequence (ADT first, then meds and orders, then results and notes).
- Ransomware is not weather. Geographic diversity does not save you if identity and backups replicate the infection; design immutable or offline copies and a clean-room restore.
12.3 Business Continuity and Disaster Recovery Design
Quick Answer: Business continuity (BC) keeps care going during a disruption. Disaster recovery (DR) restores systems and data afterward. RTO is how long you may be down. RPO is how much data you may lose. Design tiers, downtime procedures, and a ransomware path that is not a weather plan.
Task B.4 sits in systems design because architecture decides what is even possible after go-live. You cannot invent a 15-minute RPO from a nightly tape, and you cannot invent a downtime viewer if the only copy of the chart lives in a single SaaS region with no cache. Healthcare is not a generic DR exam. The product of the process is a med pass, a lab result, an airway—not a closed ticket.
BC versus DR — do not swap the labels
Business continuity is the capability to continue delivering care and essential operations during a disruption. It is people, command structure, communications, downtime viewers, paper MAR and order packets, alternate workflows, and staffing. Emergency-mode operation in the HIPAA Security Rule is the BC idea in federal language.
Disaster recovery is the capability to restore IT systems and data after a disruption. It is backups, replication, failover, rebuild, clean-room restore, and timed tests. The HIPAA disaster recovery plan is the DR idea.
BC without DR means you can work on paper until the organization collapses. DR without BC means you have a restore runbook and no one knows how to give medications for twelve hours. Design both. Calling a backup job “our BC plan” is an exam miss.
RTO versus RPO — do not swap the clocks
Recovery Time Objective (RTO) is the maximum acceptable time from the start of disruption until the service is usable again. It answers: how long can this system be down? An RTO of four hours means care and the technical restore must make the system usable inside four hours.
Recovery Point Objective (RPO) is the maximum acceptable age of the restored data, measured backward from the incident. It answers: how much data can we lose? An RPO of 15 minutes means you cannot accept losing more than 15 minutes of transactions. RPO is implemented by backup frequency, synchronous or asynchronous replication, and journal depth—not by how fast the restore team types.
They are independent knobs:
- A four-hour RTO with a 24-hour RPO can bring the EHR up quickly to yesterday’s chart. Clinically dangerous.
- A 15-minute RPO with a 72-hour RTO keeps data nearly current on media you cannot restore in time. Also dangerous.
- RTO is a clock running forward from failure. RPO is a clock running backward from failure.
Write both numbers on the design, the contract, and the test script. “As soon as possible” is not an RTO. “We back up daily” is a tactic, not an RPO statement, unless you also accept a day’s data loss.
HIPAA already requires the skeleton
The Security Rule contingency-plan standard is required. It includes a data backup plan (required), a disaster recovery plan (required), and emergency-mode operation procedures (required). Testing and revision, and an applications-and-data criticality analysis, are addressable—meaning a documented risk-based decision, not a skip (Chapter 5). Criticality analysis is how you tier. Emergency mode is BC. DR and backup are how you meet RTO and RPO. CPHIMS will let you use either the HIPAA names or the BC/DR names if you keep the ideas straight.
Tier the portfolio
Not every system earns a 15-minute RTO. Cost and complexity explode if the enterprise data warehouse is treated like the EHR.
| Tier | Examples | Typical RTO design target | Typical RPO design target | BC companion |
|---|---|---|---|---|
| Life-safety / 0 | Nurse call, infant security, some biomedical, emergency comms | Minutes; often local failover | Near-zero or local | Analog or local fallback that does not need the EHR |
| Clinical core / 1 | EHR, ADT, pharmacy, lab, radiology, BCMA, downtime viewer | Hours, often under four in large organizations | Minutes (synchronous or high-frequency replication) | Downtime procedures, BCP appliance, paper MAR |
| Operational / 2 | Scheduling, HIM coding work queues, some ancillary | 8–24 hours | Hours | Manual schedules, delayed coding |
| Administrative / analytic / 3 | EDW, BI, training, optional intranet | Days | Daily backup | Defer the work |
Write the tier on the diagram, the SLA, and the DR runbook. “Best effort” is not a tier. SaaS does not erase the need for a tier: it moves the restore mechanics and leaves you the BC and the contractual RTO/RPO.
Hot, warm, and cold sites (or multi-AZ versus multi-region cloud) are how you buy RTO. They still fail if identity dies with the site or if malware replicates to the “hot” peer.
Clinical EHR downtime is a designed mode of care
Downtime procedures are design artifacts, not a binder on a shelf:
- Declare. A named pair (house supervisor plus IS leader) declares downtime and the mode: read-only viewer, partial, or paper.
- Communicate. Out-of-band path—overhead, radios, mass notification, downtime phones. Do not rely on the email or chat system that just died (Chapter 5).
- View. A local or cached downtime viewer / BCP appliance on a path that can survive WAN or identity-provider failure when possible.
- Document and order. Controlled paper packets (orders, MAR, flowsheets) with downtime encounter identifiers. If the only packet is a PDF inside the EHR, the design failed.
- Identify. Downtime labels and census so the wrong-patient risk does not spike.
- Recover / backload. Sequence matters: ADT and census first, then medications and orders, then results, then notes. Named teams, not “everyone type faster.”
- After-action. Record realized RTO (how long down) and realized RPO (what was lost), then fix the design.
Rehearse on a unit. An untested dual WAN and an untested paper pack are not continuity.
Ransomware is not weather
| Dimension | Weather / facility (flood, fire, regional utility) | Ransomware / destructive cyber |
|---|---|---|
| Cause | Physical or utility | Compromised identity plus malware, often with backup encryption and data theft |
| Geographic diversity | Helps: second data center, other cloud region, paper at the bedside | May not help if identity and backups replicate the infection |
| What you restore from | Surviving site or intact media | Immutable, offline, or air-gapped copies the malware could not alter |
| Identity | Usually intact | Often the first casualty (directory, MFA, admin vaults) |
| Clinical look | Dark building or dark WAN | Locked screens, ransom note, or systems that look up while data leaves |
| Extra design | Generators, fuel, HVAC, flood elevation | Segmentation, least privilege, MFA, immutable backup, clean-room restore, ransom decision authority, legal/law-enforcement path |
Both need BC. Cyber needs you to assume the production domain is untrusted until proven clean. Restoring a VM onto the same infected identity plane is not DR. A second site that synchronously replicates encrypted files is a second victim, not a DR strategy.
Design tests that prove the numbers
- Restore test with a clock (prove RTO and RPO; do not trust a backup-console checkbox)
- Tabletop: weather versus ransomware versus EHR-vendor region loss
- Live unit drill: viewer plus paper plus declaration tree
- Identity recovery / break-glass drill
If you have never restored the EHR to a clean environment, you have a backup product, not a recovery design.
Scenarios and exam traps
Scenario. Finance wants one enterprise RTO of 24 hours “to save money.” Pharmacy and the ICU still need a clinical-core tier. Criticality analysis exists so the warehouse and the EHR do not share a target.
Scenario. Leadership says backups run nightly, so RPO is four hours because “restore usually takes four hours.” Four hours to return service is an RTO conversation. Nightly backups set an RPO near 24 hours unless there is another journal.
Scenario. A coastal storm is the only DR tabletop. Six months later ransomware encrypts production and the replica. Add a cyber scenario: immutable copies, identity recovery, and a decision-maker for ransom who is not the help-desk lead.
Scenario. The EHR is down. Staff cannot find the downtime packet because it is a file in the EHR. Design the packet and the viewer as surviving objects.
Watch these traps:
- Calling backups “business continuity.”
- Swapping RTO (downtime) with RPO (data loss).
- One RTO/RPO for the entire portfolio.
- Treating ransomware like weather (second site, same identity, same replicated malware).
- No downtime viewer because “we advertise 99.9 percent.”
- Backload with no sequence, or no after-action on realized RTO/RPO.
B.4 is scored when you can keep those pairs straight and design the clinical downtime path. Section 12.4 then asks whether new technology and unmanaged data will quietly destroy the RPO you just paid for.
A hospital states: “Our EHR RTO is 15 minutes because we replicate to the other data center every 15 minutes.” What did the statement confuse?
During an EHR outage, house supervisors open paper MAR packets and a read-only downtime viewer while IS begins a timed restore from last night’s backup. Which statement correctly separates the work?
Ransomware encrypts production EHR and the synchronously replicated DR site. Immutable backups exist but have never been restored. What is the CPHIMS-correct design reading?