File upload, AI-generated plain-English analysis, email delivery, and audit logging are fully automated end to end.

We use Anthropic's commercial API, which by contract does not use your submissions to train its models — different from consumer chat products.

Built, tested, deployed, and now wired into the live pipeline — verified end to end with a real MMR submission producing an accurate report. MMR uploads are parsed deterministically and checked by the Payment Integrity Engine before Claude ever narrates the result. Here's what's actually done:

Parser: every field in the CMS Monthly Membership Report is decoded against the real record layout published in CMS's MAPD Plan Communications User Guide (PCUG v19.3) — byte position by byte position, cross-checked against the source document rather than inferred. Covers all 90 fields and every code table (adjustment reason codes, dual-status codes, risk factor types), and correctly rejects any file whose structure doesn't actually match MMR instead of silently misreading it.

Payment Integrity Engine (codename Shadow MARx): independently recomputes each beneficiary's expected Part C and Part D payment from CMS's own published formulas and diffs it against what was actually reported — covering standard risk-adjusted payment, rebate-eligible and basic-premium plans, Hospice, ESRD, PACE, and MSP reduction, plus a fully closed-form Part D total-payment check. Validated against 8 scenario fixtures (6 formula-correct, 2 with deliberately injected errors) — 8/8 passing, including catching a $50 injected overpayment and a broken Part D sum.

Two things it honestly can't fully verify from the MMR alone, and flags rather than guesses at: (1) which bid-vs-benchmark scenario applies is inferred from which rebate/premium fields are populated, since the plan's actual bid isn't in the MMR; (2) for ESRD adjustments, CMS's formula references a Part A/B split of one rebate field that isn't reported separately in the file. Both are disclosed inline on every flagged record, not glossed over.

What's next: other CMS file types (835, PPR/PRS, MOR, cost reports) aren't in scope yet — deterministic parsing for those hasn't started.

Reads an uploaded clinical note (PDF, DOCX, or TXT), extracts every diagnosis mentioned, and runs it through a deterministic CMS-HCC V28 engine before Claude ever narrates the result — verified end to end with a real synthetic oncology/HIV note producing an accurate, hierarchy-correct report.

Extraction: Claude reads the free-text note and identifies every diagnosis mentioned, along with patient age and sex where documented. This step is AI-read, not byte-parsed — accuracy depends on how clearly a diagnosis is stated in the note.

HCC engine: every extracted ICD-10 code is mapped against CMS's own published 2024 CMS-HCC Model V28 crosswalk, hierarchy-suppression rules, and reference weights — loaded directly from CMS's files, not approximated. Findings are ranked by reference weight, hierarchy-suppressed codes are disclosed by name rather than silently dropped, and codes outside the roughly 7,770-code V28 crosswalk are flagged as "not recognized," with closest-match candidates surfaced for the coder to check by hand.

What it honestly doesn't do yet: no OCR (a scanned or image-only note comes back with little or no text); no MEAT-documentation check (it doesn't verify a diagnosis is specifically enough documented to survive an audit); reference weights shown are CMS's published model weights, not a beneficiary's personalized RAF, which also depends on demographic and enrollment-segment adjustments this engine doesn't yet apply; and submissions aren't yet written to a logged audit record the way MMR submissions are.

What's next: OCR for scanned notes, MEAT-criteria documentation checks, personalized RAF computation, multi-note / full-encounter-history ingestion, and wiring submissions into the same audit log as every other file type.

Anthropic will sign a BAA on our plan today. Our form and logging vendors require upgrading to their compliance-tier plans first. Make.com, our current automation layer, doesn't offer a BAA at any tier — so getting here means replacing it with a dedicated backend, not just upgrading a plan. See the table below for current status per vendor.

A lightweight scan for common PHI patterns (SSNs, MBI numbers, name+DOB pairs) as a safety net before a file is ever processed.

Moving to a dedicated backend with tenant isolation and encryption at rest, ahead of onboarding customers who need to submit real PHI.