Health data across India and the US

A teleradiology company has radiologists in India reading scans overnight for US hospitals, and a growing business with Indian clinics. US hospitals want their patients' data in the US; Indian clinics want theirs in India; the radiologists in Bengaluru must read US scans as if they were local; and when a region fails at 3 a.m., reads must continue within an hour. The architecture that satisfies all four is built on one principle: the data stays where it belongs, and access travels to it.

1. The situation

NightRead provides overnight radiology reads: US hospitals upload CT and MRI scans, and radiologists in India report on them during the US night. It also serves 150 Indian clinics with daytime reads for Indian patients. 60 engineers; scans are large (a CT study can be hundreds of megabytes) and arrive around the clock.

2. What mattered

3. The options

4. The decision

ADR-009: Country cells, remote reading, in-country disaster recovery

Decision:
  - US cell (us-east-1, warm standby in us-west-2) holds all US patient data:
    scans, reports, audit logs, backups, encryption keys.
  - India cell (Mumbai ap-south-1, warm standby in Hyderabad ap-south-2) holds
    all Indian patient data, the same way.
  - A small global directory holds only routing data: tenant -> cell, and user
    identities via single sign-on. No patient data.
  - Radiologists in India read US studies in a server-side rendered viewer
    running in the US cell: pixels stream to the browser; no download,
    no local cache, watermark with reader ID, every view in the US audit log.
  - Backups and replicas never leave the cell's country (fitness function).
  - Restore tests quarterly in each cell; DR exercise twice a year.
Consequences:
  + Each data type has one country, which contracts, audits and breach
    notification can rely on
  + Losing a region in one country doesn't affect the other cell
  - Two cells to run and upgrade; the viewer needs a fast, steady link
  - Analytics across both countries only from aggregated, de-identified data

5. How it works

One night: a scan arrives from a hospital in Ohio, a radiologist in Bengaluru reads it, and then us-east-1 fails.

6. Choose the recovery strategy

Pick a strategy for the reading workflow (target: back within 1 hour, at most 5 minutes of lost work) and where the recovery site is. Costs are relative to running one region alone, and illustrative.

Typical recovery for each strategy, from the AWS disaster recovery whitepaper's four options (see the DR plan template); NightRead's own numbers would come from its exercises. Relative costs are rough illustrations.

7. How it played out

In the first DR exercise, failing the US cell over to us-west-2 took 38 minutes, inside the one-hour target, but the viewer's session store hadn't been replicated, so every radiologist had to log in again mid-read. The fix went into the runbook and the next exercise took 22 minutes. A hospital's security questionnaire asked where scans, reports, backups and logs live and who can see them; the answer was one table from the ADR. When an Indian clinic asked to use the reporting dashboard across all its sites in both countries, the answer was the aggregated, de-identified feed, not a copy of records.

8. Lessons

• Find where each requirement really comes from. HIPAA doesn't require US storage; the hospitals' contracts do. That matters when a contract is renegotiated or a new customer has different terms (Module 04).
• Data stays, access travels. Streaming rendered images across the border meets residency where copying files would not, at the cost of latency (threat modelling: the viewer is the trust boundary).
• Disaster recovery has a country too. The standby region must satisfy the same residency rules as the primary: two regions in one country (C10, C11).
• Cells limit the blast radius of everything. An outage, a breach or a bad deploy in one country stays there (C01 used the same idea).
• Exercise the failover. The first exercise found a session store nobody had listed. Plans describe; exercises discover.

9. Your turn

1. Map the data (15 min). For a system you know: each kind of personal data, the country it must stay in, and the source of that rule (a law, a contract, a policy).
2. Draw the trust boundary (10 min). Where does data cross a border or an organisation? What crosses: files, rendered views, aggregates?
3. Pick the standby (5 min). For your most important service, where would the recovery site be, and does it satisfy the same rules?

10. Check yourself

11. Sources and further reading