Case study
Zero errors, wrong twice
We built a working billing pipeline: synthetic radiation oncology treatment events become FHIR R4 ChargeItems, pass a conformance gate, post to a mock EHR endpoint, and then get reconciled row by row against the ledger they came from. The interface logged 412 accepted and zero errors. The reconciliation found the two charges it got wrong anyway.
- Standard
- FHIR R4 ChargeItem
- Run
- 412 treatment events, 12 synthetic patients
- Verified with
- Full-volume reconciliation against the source ledger
- Work type
- Standfast internal research
The problem
Every treatment billing interface makes the same promise: what was delivered gets billed, once. But the interface reports on that promise in a vocabulary of accepted and rejected, and billing correctness is not a property of a message. It is a property of the relationship between a charge and the care that was actually delivered, and no message carries that relationship.
So the useful question is not whether an interface can produce valid FHIR. It is whether the system around the interface can prove, after every run, that the ledger of delivered care and the ledger of submitted charges are the same ledger. We built a prototype to show what that proof looks like.
What the prototype does
One pipeline, five stages, each one visible in the inspector.
Reads the source ledger
Synthetic radiation oncology treatment events: delivered fractions and treatment management visits across twelve synthetic patients. The ledger is the ground truth every later stage answers to.
Builds the charge
Each event becomes a FHIR R4 ChargeItem: real CPT codes correctly bound, service dates, quantities, and references back to the treatment record the charge claims to bill.
Gates before transmission
A three-layer conformance gate: structure, terminology, then plausibility. The plausibility layer checks each charge against the treatment actually delivered. Charges that fail are held and named, and never transmitted.
Submits like production
Charges post to a mock EHR FHIR endpoint that fails the way real endpoints fail: 502s, timeouts, and slow responses, not just clean acceptances.
Reconciles at full volume
After the run, every row of the source ledger is compared against every accepted charge, in both directions. Nothing is sampled and nothing is assumed.
Same pipeline, same run. The gate names the violation for every held charge, so a quarantine is attributable to a rule rather than to the gate as a whole.
Two silent failures the interface reported as success
The gate passed every charge and the endpoint accepted every submission. The interface logged 412 accepted, zero errors. It was still wrong twice.
One delivered IMRT fraction was never billed, because a single 502 was not retried. One treatment management charge was billed twice, because a timeout was retried without an idempotency key. Neither raised an alert, because from the interface's point of view nothing failed. One is missing revenue. The other is an audit finding.
Full-volume comparison against the source ledger is what finds them. A ten percent audit sample of this same run would have missed both, with probability 81 percent.
The arithmetic: a ten percent sample catches a given single-row failure ten percent of the time, so the chance of missing both independent failures is 0.9 times 0.9.
Three charges a schema validator accepts and the gate does not
In a second run, three charges arrive from the coding workflow rather than the delivery record. Each is valid FHIR R4: required elements present, real CPT codes correctly bound, dates that parse, quantities that are non-negative integers. A schema validator passes all three. The gate holds all three, and each is wrong in a way only the treatment record can show.
Two units, one fraction
Two units billed for a day on which one fraction was delivered. The quantity is a legal integer. It is also double the care that happened.
A charge with no treatment
A delivery charge for a date with no treatment record behind it. Every field is well-formed. The event it bills never occurred.
A quantity of zero
A billable charge carrying a quantity of zero. The schema permits it, downstream systems each handle it differently, and none of them should ever see it.
What makes them wrong is the relationship between the charge and the treatment actually delivered, and that relationship does not exist anywhere in the FHIR structure. No profile can express it, so no validator can check it. The interface has to assert it before transmission, or the charge posts.
Where the line is
This is a clean-room prototype built on open standards. The data is synthetic, twelve patients who never existed, and the endpoint it submits to is a mock built to behave like a production FHIR server, failure modes included. It contains no protected health information and required no access to any production system.
What carries over is the pattern. An unretried 502 and a retry without an idempotency key are not synthetic failure modes. They are the standard ways interfaces lose charges and duplicate them, and full-volume reconciliation against the source ledger is the check that catches both, regardless of whose endpoint is on the other side.