Testing clinical systems
Your test suite is green. That tells you the code does what you specified — not that the specification was safe, that the data is real, or that a nurse can use it at 3am.
In one line
A green test suite proves your code does what you specified. In clinical systems the specification is frequently the thing that's wrong — so testing has to reach past correctness into safety.
The pyramid still applies
Unit tests for logic, integration tests for the seams, a thin layer of end-to-end. Nothing exotic. But three additions matter here.
Validate against the profile, not just the schema. Your FHIR bundle parses. Congratulations — that means it's JSON. Run the FHIR validator against the actual implementation guide you claim to conform to, pinned to the version, in CI. "We produce FHIR" is not a testable claim; "we produce bundles that validate against NRCeS IG v6.5.0" is.
Test with realistic mess, not tidy fixtures. Your fixture patient has a first name, a last name, and a date of birth. Real Indian records have three transliterations of the same name, a 1st-January placeholder DOB, a missing surname, and a phone number shared by a family. Synthea generates far more realistic populations than any hand-written fixture — and never, ever test with real patient data.
Test the failure paths, because that's where harm lives. The out-of-order ADT, the duplicate message, the timeout mid-write, the consent revoked between check and read. Happy paths are the easy 20%.
What tests cannot tell you
This is the part that separates clinical software from ordinary software.
Your tests encode your assumptions. If you assumed weight is in kilograms, your tests assume it too, and they will pass beautifully while the interface sends pounds. The bug is in the specification, and a test written from that specification cannot see it. This is why UCUM exists, and why unit mismatches keep happening despite excellent test coverage.
Green does not mean safe. A CDS rule can be perfectly implemented, fully covered, and fire 400 times a month to catch two events — degrading attention across the hospital. No unit test fails. The harm is real and invisible to CI.
Usability is a safety property, and it isn't unit-testable. A confirmation dialog that reads "Are you sure?" for both "delete a draft" and "override an allergy alert" trains the muscle memory that dismisses the second. That's a defect. Your suite is green.
What to add
- Clinical-scenario tests. Not "checkOrder returns an alert" but "a 72-year-old with eGFR 26 is protected from a standard-dose metformin order." Written with a clinician, in clinical language, so the specification gets reviewed by someone who can spot that it's wrong.
- Golden files for interfaces. Real (synthetic) messages in, expected output snapshotted. Catches the accidental change nobody meant to make.
- Contract tests at the seams — because the other team will change their API and not tell you.
- Load tests at the shape of your actual peak — ward round, not uniform traffic.
- A connectathon, if you can. IHE's model remains the honest test: a spec is a hypothesis until two independent implementations meet. Everything before that is a vendor's claim about their own software.
And the one nobody schedules
Test the downtime and the recovery. Not whether the system fails over — whether the ward can work when it doesn't, and whether the reconciliation afterwards is safe. As the SRE entry argues, the medication errors cluster in the catch-up typing, not the outage.
Nobody tests that, because it isn't code. It's still the thing most likely to hurt someone.