Technology

How the system works

Most AI vendors show you a chat window. We would rather show you the test harness. This page explains how Mohenara is built, and why we spent our first months building a fake payer instead of a demo.

We built the testbed before the product

Denial recovery has a data problem: you cannot develop on real claims without touching protected health information, and you cannot evaluate quality without knowing the right answer for every case. So we built a synthetic claims testbed first.

750 synthetic denial cases, each a complete transaction chain: 270/271 eligibility check and response, the 837P professional claim, the 277CA clearinghouse acknowledgment, the 835 remittance with denial codes, and the treatment note behind the claim.
Patients, providers, and coverage histories derive from CMS synthetic public-use data. No real patient data anywhere in the corpus.
Each case carries planted, known defects: the wrong payer, a missing authorization, units that exceed policy, a duplicate submission. Because we planted the defect, we know the right answer, which makes real evaluation possible.
A held-out set of cases is never used during development. Pipelines are scored against it by a simulated payer that adjudicates our outputs the way a real payer would.

Denials are nine problems, not one

A duplicate-claim denial is resolved by claim-history comparison. A medical-necessity denial needs chart evidence and a clinical argument. Treating those as one problem is how generic tools end up mediocre at both. Mohenara runs separate pipelines per denial group, each with its own deterministic checks, its own model steps, and its own evaluation suite:

Eligibility and coverage routing, including coordination-of-benefits denials
Claim-data corrections, where the right value already exists in the record
Authorization and referral denials
Documentation requests
Non-covered services and benefit limits
Medical necessity and clinical appeals, always human-gated
Coding, bundling, and units, scored against published coding rules
Timely filing, won by documentary proof of dates
Duplicates and crossed claims

The deterministic layer does what rules do best: eligibility logic, code-pair edits, date arithmetic, payer dialect differences. Models do what models do best: reading charts, drafting appeal narratives, spotting the defect a rule did not anticipate. Neither is asked to do the other's job.

Evaluation before production

Every pipeline change is scored against held-out cases before it ships: did it identify the planted defect, produce the correct fix, and draft output a payer would accept. We track cost and latency per case alongside accuracy, because a pipeline that cannot work a $30 denial profitably is not a product, it is a demo.

Models and infrastructure

Frontier language models served through AWS Bedrock, on an account covered by a Business Associate Agreement, in US regions. Every model call is instrumented for cost and latency. Client data is never used to train models.

Humans gate judgment

Clinical reasoning, signature authority, and payer-specific judgment calls stop for human review, by design and by contract. The pipeline's job is to make that review take minutes instead of hours.

This page understates the details on purpose. If you want the deeper walkthrough, ask: hello@mohenara.com