The SQL trail that justified the build
Before proposing anything, I profiled six months of claims (Jan to Jun 2026) for Lakeview Specialty Partners, a synthetic 8-practice, 4-specialty group on the NewMed platform, directly in the claims warehouse. Each block below is one product question, the query, the actual result, and what it changed about the decision. Use the filters to slice everything by payer or specialty; expand any block to see the commented SQL. New to the vocabulary? There is a plain-English glossary.
Where the Co-Pilot sits in the revenue cycle
Revenue Cycle Management (RCM) is the pipeline from "patient books a visit" to "practice gets paid". The flow below is the whole cycle. Hover any step for the plain-English version. The structural problem: denials are born in steps 1 to 5, but only discovered at step 6, weeks later, and worked at step 7 when the fix is most expensive.
Pre-submission queue: the working product
This is the biller's 8:30 AM view: today's claims scored live in your browser by the trained model (open the console: it is a 15-weight logistic model, fully auditable). The AI recommends; the biller decides.
| Risk | Claim | Payer | Procedure | Charge |
|---|
Select a claim from the queue.
How I know it works, and how it would roll out
Evaluated by temporal backtest: trained on Jan to Apr claims, tested on May to Jun claims it never saw. That simulates deployment order; a random split would leak future payer behaviour into training and flatter the numbers. The operating threshold is a product decision, not a data-science decision: it trades biller review workload against denials caught. Drag the slider.
Operating threshold: flag claims above 30% predicted risk
Confusion matrix (test window)
Precision / recall / flag-rate vs threshold
Gated rollout: trust is earned in stages
0 · Offline backtest
- Would we have predicted last quarter's denials? (this page)
- Per-payer calibration review
- Ship gate: AUC > 0.80, per-payer recall floor
1 · Gated alpha
- 3 to 5 practices, one specialty, payer-heavy region
- 100% human review of every flag
- Weekly calibration vs actual remits (835s)
2 · Expand
- Add payers before adding specialties
- Fix-suggestion acceptance rate > 60%
- Override rate < 20% and falling
3 · GA
- Clean-claim-rate lift vs matched control practices
- In-product ROI reporting per practice
- Continuous retraining on new 835 outcomes
Risks I would manage from day one
- Payer rule drift: payers change edits quarterly. Mitigation: monitor per-payer precision weekly; retraining trigger when calibration error exceeds a set band; the 835 remittance stream is the free, continuous label source.
- Automation bias: billers rubber-stamping suggestions. Mitigation: sampled mandatory manual review (for example 5% of accepted fixes), and the override button is one click, never buried.
- False-positive fatigue: every wasted review erodes trust, exactly like a false churn flag. Mitigation: the threshold slider above is a per-practice setting tied to biller capacity, not a global constant.
- PHI / HIPAA: features are claim-metadata level; any deployment needs BAA coverage, minimum-necessary access, and audit logging. Named here because it shapes architecture, not as an afterthought.
- Cold start for small specialties: fall back to cross-specialty payer patterns until practice-level volume accrues.
The vocabulary, in plain English
Healthcare billing has its own language. Every term this prototype uses, explained the way I would explain it to a new engineer on the team, plus why it matters to this product. Back to the analysis.