August 7, 2026 · Umer Jamil
Why we built a 750-case synthetic claims testbed before touching real data
The first thing we built at Mohenara was not the product. It was a fake world for the product to fail in. Before any real claim touches our system, every pipeline has to survive 750 synthetic denial cases where we already know the right answer. Here is why we spent our first engineering months on that instead of a demo.
Two problems, one fix
Building AI for claims work runs into two walls immediately. The first is privacy: real claims are protected health information, and "we experimented on real patient data" is not a sentence anyone should be able to say about their development process. The second is evaluation: even with permission to use real denials, nobody hands you the correct resolution for each one. Without known answers, you cannot measure whether a pipeline actually works, you can only collect impressions.
Synthetic data solves both at once, but only if it is built seriously. A CSV of made-up denial codes teaches you nothing. What we needed was the full paper trail a biller actually sees.
What a case looks like
Each of the 750 cases is a complete transaction chain:
- the 270/271 eligibility inquiry and response, showing what the payer knew on the date of service
- the 837P professional claim as submitted
- the 277CA clearinghouse acknowledgment
- the 835 remittance, with the payer's denial codes and payment math
- the treatment note behind the claim
Patients, providers, and coverage histories derive from CMS synthetic public-use files, so the demographics and utilization patterns are realistic while every individual is artificial. Payer behavior is modeled per payer, because a Medicare contractor and a commercial plan do not deny the same way or speak codes with the same dialect.
Planted defects are the answer key
Most cases carry one planted defect: the claim went to the wrong payer, the authorization number is missing, the units exceed policy, the visit was already billed. Because we planted the defect, we know exactly what a correct pipeline should find and fix. A set of clean cases is mixed in as controls, because a system that finds defects in everything is as useless as one that finds nothing. And a held-out portion of the corpus is never touched during development: pipelines meet those cases the way they will meet reality, cold.
The simulated payer
The last piece is the judge. We built a simulated payer that adjudicates our corrected claims and appeals the way a real payer would: against coverage history, policy limits, and code rules. A drafted fix either survives adjudication or it does not. This converts "the output looks right" into a pass-fail number we can track per pipeline, per denial type, per model change.
What this buys us, and our clients
Three things. Development speed: we can iterate all day without a single compliance question, because there is nothing sensitive in the building. Honest quality numbers: when we say a pipeline resolves a denial group correctly at a given rate, that number comes from held-out cases with known answers, not from vibes. And a clean security story: the first real patient data our system ever sees arrives under a signed BAA, into infrastructure that was already built, tested, and instrumented on data that could never hurt anyone.
The example case we share publicly, a denied Medicare outpatient physical therapy claim with its full transaction chain, comes from this corpus and is labeled synthetic on every page.