Patient health records

The brief

A hospital network keeps patient charts, orders, notes and scanned documents for 40 hospitals. Doctors need a chart in under a second, no saved note may be lost when a server or a building fails (in a whole-region disaster, at most the last minute of edits may need re-entering from the ward), and an auditor can walk in any day and ask you to prove who looked at what.

Think of a hospital's electronic records.

Users, scale and requirements

Who uses it

25,000 staff, 3 million patients (approx.)

Audience in plain numbers

25,000 users or devices

Normal peak

≈ 3,000 requests per second

Request mix

Read: 66%; Search: 10%; Write: 13%; Sign-in: 6%; Upload: 3%; Report: 2%

Speed for 99 of 100 requests

Read: ≈ 300 ms; Search: ≈ 500 ms; Write: ≈ 300 ms; Sign-in: ≈ 1,000 ms; Upload: ≈ 3,000 ms; Report: ≈ 10,000 ms

Successful requests

99.9%

Data safety

At most 1 minute of writes may be lost.

Monthly budget

≈ $52,000

Data at rest

≈ 120 TB

Where users are

North America: 100%

Home region

North America

Waiting deadlines

Read: 900 seconds; Search: 900 seconds; Write: 3,600 seconds; Sign-in: 900 seconds; Upload: 3,600 seconds; Report: 3,600 seconds

Minimum retained history

2,555 days on authoritative stores

Fresh reads

People must see their own changes. At most 0.1% of reads may be stale in the model.

Personal reads

95% of reads are private; a shared public copy cannot answer them.

Required proofs

Audit trail; Managed encryption keys; Personal data isolated; Tested backups; Signed-in access; Retention rules

≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.

• Records are kept for at least 7 years, approx.
• Sensitive fields are stored apart from the chart.
• Scored data retention: at least 2555 days on active authoritative stores. Copies used only for search or reports can be rebuilt. Local device history and rollup policies still require the separate protocol check.

Questions that shape the design

What happens if the system is down?

Staff fall back to paper, which is slow and risky. The target is 99.9 percent, about 45 minutes of downtime a month at most (approx.).

Who is allowed to see a chart?

Only staff involved in that patient's care, and every look is written to a log nobody can edit.

Can a copy of the records be kept in a second region?

Yes, under the same privacy contract. That is what makes a regional disaster survivable.

What is in the scans?

X-ray images and signed forms. They are big and rarely change.

The traffic day

Traffic concentrated in working hours. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

1. 09:30 · Leaked key

   An API key is pushed to a public repo. It must be rotated now.

   Restart window: ≈ 1,200 seconds.

2. 11:00 · Compliance audit

   An auditor checks your design: who did what, encryption keys, personal data, backups and consent.

3. 14:00 · Region outage

   A whole cloud region goes down.

   Duration: ≈ 5,400 seconds.

What a strong design has to handle

• Three things are asked of you besides speed: prove access, protect keys, survive a lost region. Which elements give each one?
• Acknowledge durable clinical edits and retain auditable access across recovery.
• Active-active costs about 100 percent of the main system again and recovers in about a minute. A warm standby costs about 40 percent and takes about 15 minutes; backup-and-restore is far cheaper and takes hours (approx.).
• The privacy vault (about $1,000 a month) is a fixed price you pay once, whatever the traffic, to keep sensitive fields in one controlled place.

Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.

Concepts to practise

• Proof built in
• Surviving a region
• Privacy by design
• Changing a running system
• Designs that other teams must live with