Appeal Factory — Denial Appeals for Providers

No. It drafts, cites and tracks; a person on your team reviews and sends. Appeals are a legal and clinical assertion about a patient's care, and we're not willing to automate the signature on that — the leverage is in the drafting and the deadline discipline, which is where the hours actually go. The software has no send path at all; marking an appeal sent is something your biller does after they've sent it.

You load the policies your payers publish into the library, and every appeal is argued from them: the letter quotes the clause it rests on and names the section, and that citation is checked back against the document before the draft exists. If nothing in that payer's policy bears on the denial, the draft is refused rather than invented. The same check catches a model that writes a confident section number we never retrieved — the letter is thrown away and rebuilt from the text we actually hold.

81.2% top-one accuracy against a written-down table of which section should govern which denial code, and we ship the bench that measures it so the number can be re-run rather than believed. What that means in practice: a citation can be the wrong section of the right payer's policy, and your biller sees the quoted text beside the letter before anything goes out. What it can't be is a section that doesn't exist. That test also killed our own first improvement — weighting rare words scored worse, so it isn't in the product.

Straight answer: it is built and running entirely on synthetic claim data, and no real patient data touches it until a BAA, an encryption-at-rest review and a hosting decision are in place. The architecture is built for that from the start — per-organisation row-level isolation enforced by the database rather than by remembering to filter, encrypted member identifiers, an append-only hash-chained log of every claim-level read — and there's a test asserting the application can't bypass any of it. But we'd rather tell you the sequence than imply a compliance posture we haven't completed.

A founding-pilot engagement, not a self-serve login. The software is built: six agents, five screens, the citation gate, the deadline calendar computed two independent ways. Week one is us wiring it to your actual remittances and loading your payers' real policies — a working session, not a signup form. Being blunt about maturity: the parser has run against hundreds of synthetic 835s and none of yours yet, and no letter from this system has been sent to a payer. That's the honest reason these are priced as pilots and why we're taking a small number of them.

Yes, and here's exactly how, because it matters. Six research agents worked one domain each against a strict evidence rule: every demand claim had to come from an analyst report, a vendor's own pricing page, a dated funding round, public earnings, a named survey or a regulatory text — no forum posts, no vibes. That produced 41 candidates scored on demand evidence, contract value, how verifiable the gap was, buildability and defensibility; this one ranked second, and it's the second of the ten we've actually built. What that does NOT mean: that anyone has paid for it, or that it has run against a real payer. The research says the problem is real and expensive. Only a pilot says the product works.