Healthcare Platform (EHR)

Patient records, appointments and orders

Design the system of record for a regional health network: one identity per patient, a trusted clinical record, appointments never double booked, orders that always meet their results, and an audit trail of every read.

Overview

An electronic health record (EHR) is the system of record for a health network's patients. Clinicians open a chart to see allergies, medications, problems, notes and lab results; front-desk staff book appointments; doctors place orders that go out to laboratories and pharmacies, and the results come back into the chart. Other systems (labs, pharmacies, insurers, patient apps) read and write through standard interfaces.

The traffic is small next to a consumer app: a few hundred requests a second at peak. What makes it hard is that the data is about people's health. A record merged with the wrong patient can put one person's allergies in another's chart. A lost lab result can delay treatment. Every read must be allowed by policy and recorded, because the HIPAA Security Rule asks for access control and audit controls, and a patient may ask who looked at their chart. The record must also be there at 3 a.m. in the emergency department, when the person who needs it may not be on the patient's care team.

This page is the system of record. The Healthcare AI Triage System and AI Healthcare Chatbot topics sit on top of a record like this one and are not repeated here.

Questions to ask first

Who uses it? — Clinicians, front-desk staff and patients (a portal); labs and pharmacies as partner systems
Scale? — 5 million patients, 50,000 encounters a day across hospitals and clinics
Which standards? — HL7 v2 messages to existing lab and hospital systems; FHIR R4 REST for apps and new partners
Who may read a chart? — Staff with a role that needs it and a current relationship to the patient; others only through break-the-glass
Regulation? — US: HIPAA Privacy and Security Rules; every read audited
Availability? — The chart is read-mostly and must survive a region outage; a read-only mode is acceptable for a short time

What you will be able to do

Keep one identity per patient with a master patient index, and explain why a wrong merge is worse than a duplicate.
Model the clinical record and book appointment slots so that two clerks can never book the same slot.
Walk a lab order out over HL7 v2 or FHIR and its result back into the chart.
Decide who may read a chart with roles, care relationships, consent and break-the-glass, and audit every read.
Map the design to the HIPAA Security Rule's safeguards and set availability and recovery targets.

Key concepts

Master patient index
Enterprise patient ID
Encounter-centered record
Slot contention
Orders and results
HL7 v2 interfaces
FHIR R4 REST
Relationship-based access
Break-the-glass
Audit trail

Functional requirements

Register patients and find or link them to one enterprise identity
Read and write the clinical record: encounters, notes, allergies, medications, problems, results
Search open slots and book, reschedule or cancel appointments
Place lab and medication orders and receive results and dispense updates
Exchange data with partners over HL7 v2 messages and a FHIR R4 REST API
Grant emergency access (break-the-glass) and record every access
Send appointment reminders and result notifications; host telehealth visits

Non-functional requirements

Chart reads under 300 ms at p99 inside the network (a target we chose)
99.95% availability for chart reads and order entry, about 22 minutes of downtime a month (a target we chose)
No acknowledged clinical write is lost: RPO under 1 minute across regions, RTO under 1 hour (targets we chose)
Every read and write produces an audit event; audit logs cannot be altered unnoticed
Data encrypted in transit (TLS 1.2 or later) and at rest
A slot is booked by at most one appointment unless overbooking is explicitly allowed

Interview questions

How do you make sure one patient has exactly one record?
Two clerks book the same slot at once. What happens?
How does a lab order flow out and its result flow back?
Who is allowed to read a patient's chart?
What does the HIPAA Security Rule ask of this design?
Why audit reads and not just writes?
How do you integrate with old systems and new apps at the same time?
What happens if a whole region goes down?