AI PRD: NewMed Denial Prevention Co-Pilot
| Author | Nayan Lal (Product) |
| Version / status | v0.9 · draft for engineering review · July 2026 |
| Product line | NewMed Practice Management · claims & billing (fictional platform, portfolio case study) |
| Working prototype | Live demo · source on GitHub |
| Related | Discovery analysis (DISCOVERY.md) · eval methodology (EVALS.md) · companion: Ops Bottleneck Analyzer |
How to read this pack. Section 1 (functional) and Section 3 (design) are owned by product. Section 2 (TRD) is structured by product and completed with engineering: every field marked ENG TO CONFIRM carries product's suggested starting point and needs an engineering owner and estimate. Section 4 defines how we will know the product works before, during, and after release.
1. Functional specifications & requirements
1.1 Problem and goal
Practices lose material revenue to claim denials: 15.4% denial rate in the discovery dataset against a 10 to 15% industry norm, with 45.5% of denials written off entirely and about $79 average rework labour per denied claim. 80.1% of denial reasons are knowable before submission. Goal: raise the first-pass clean claim rate by scoring every claim for denial risk at claim-scrubbing time, explaining the risk in biller language, and offering a one-click fix, with the biller always in control.
1.2 Users
| User | Job to be done | Success looks like |
|---|---|---|
| Biller / billing manager (primary) | Get every claim paid on first pass | Works a short, trusted queue each morning instead of a reactive denial pile |
| Front-desk staff (secondary) | Verify coverage before the visit | Receives eligibility flags early enough to act at check-in |
| Practice administrator (secondary) | Predictable cash flow | Sees clean-claim rate and protected dollars per month |
| NewMed RCM services (internal) | Work denials efficiently at scale | Fewer preventable denials reaching their queue |
1.3 User stories with acceptance criteria
US-1 · Risk-scored queue. As a biller, I see today's pre-submission claims ranked by denial risk so I work the riskiest first.
Given claims in the pre-submission state When I open the queue Then each claim shows a risk percentage and band (Low / Moderate / Elevated / High), sorted descending, recomputed on every claim edit.US-2 · Explanation panel. As a biller, I see why a claim is flagged, in my language, so I can trust or challenge the flag.
Given a flagged claim When I open it Then I see every contributing factor with direction and relative strength, the predicted CARC denial code, and plain-language wording (no model jargon). Every factor maps to a field on the claim I can inspect.US-3 · One-click fix with undo. As a biller, I apply the suggested fix in one click, and can undo it, so acting is fast and safe.
Given a suggested fix When I click Apply Then the underlying workflow starts (eligibility recheck, PA request, modifier edit), the risk score recomputes immediately, and an Undo control appears that fully restores prior state and counters.US-4 · Override. As a biller, I can submit as-is against the model's advice in one click, without friction or guilt.
Given any flagged claim When I click Override Then the claim proceeds to submission, the override is logged as a labeled training event, and no additional confirmation is demanded.US-5 · Operating threshold per practice. As a billing manager, I set how many claims get flagged so the queue matches my team's capacity.
Given the threshold setting When I move it Then I see a live preview of expected flags/day, review hours, expected recall, and estimated dollars protected before saving.US-6 · Outcome reporting. As a practice administrator, I see what the Co-Pilot protected each month.
Given a closed month When I open the report Then I see clean-claim rate vs baseline, denials prevented (measured against matched control claims), rework hours avoided, and suggestion acceptance rate.1.4 Functional requirements
| ID | Requirement | Priority |
|---|---|---|
| FR-1 | Score every professional claim (837P, single line for MVP) on entry to the pre-submission state and on every edit | P0 |
| FR-2 | Display risk score, band, contributing factors with direction/strength, and predicted CARC | P0 |
| FR-3 | Suggested fix per detected gap (eligibility, prior auth, modifier, missing fields, timely filing) with one-click execution where the platform owns the workflow | P0 |
| FR-4 | Undo for every applied fix, restoring claim state and session counters | P0 |
| FR-5 | One-click override; logged as labeled feedback | P0 |
| FR-6 | Per-practice operating threshold with live workload/recall/economics preview | P1 |
| FR-7 | Feedback capture: fix applied / undone / overridden / eventual 835 outcome, joined to model version | P0 |
| FR-8 | Monthly outcome report per practice (clean-claim lift, protected dollars, acceptance, override rate) | P1 |
| FR-9 | Glossary and hover definitions for all billing vocabulary in the UI | P1 |
| FR-10 | Admin audit trail of every score, suggestion, and user action | P0 |
| FR-11 | Never auto-block or auto-edit a claim without explicit biller action | P0 (principle) |
1.5 Non-functional requirements
- Latency: score on claim save under 500 ms p95; full-queue nightly rescoring completes before 6:00 AM practice-local time.
- Availability: queue view 99.9%; scoring degradation must fail open (queue works unscored, clearly labeled) never closed.
- Auditability: every score reproducible from logged model version + feature vector for 7 years.
- Accessibility: WCAG 2.1 AA; risk never communicated by color alone (band label + percentage always present).
1.6 Out of scope (MVP)
- Auto-editing or auto-holding claims; medical-necessity prediction (needs chart data); institutional claims (837I); multi-line adjudication; appeals drafting (stage-7 Billing Assistant territory); payer integrations beyond what the platform already has.
2. Technical requirements document (TRD)
Structured by product; to be completed with the engineering team. ENG TO CONFIRM marks decision points where product proposes a starting point and engineering owns the final call, estimate, and design doc.
2.1 System context
2.2 Data contract at scoring time
| Field group | Fields (MVP) | Source | Freshness need |
|---|---|---|---|
| Claim core | payer, specialty, CPT, ICD-10, modifiers, charge, service date, submission lag | PM claims DB | at save |
| Eligibility | verified flag, last verification date, coverage status | 270/271 service | < 24 h |
| Prior auth | required flag (payer rules table), auth on file | PA module + payer rules | < 24 h |
| Payer rules | timely filing limit, modifier requirements | payer rules table | weekly review |
| History | resubmission flag, prior denials on patient/payer pair | claims history | nightly |
2.3 Model serving ENG TO CONFIRM
- Product's starting point: nightly batch rescoring of the whole pre-submission queue plus on-demand scoring on claim save. Model artifact is small (15 weights for MVP); a stateless service or even in-process scoring both plausible. ENG TO CONFIRM serving pattern, capacity, and cold-start behaviour.
- Versioning: every score logs model version; shadow-mode support (score-but-do-not-display) required for new versions. Rollback to previous version in one config change.
- Failure mode: scoring down means queue renders unscored with a visible banner. Never block submission.
2.4 Feedback event schema (proposed)
{
"event": "fix_applied | fix_undone | override | outcome_835",
"claim_id": "CLM-2026-04687",
"model_version": "denial-risk-v0.9.2",
"risk_before": 0.93, "risk_after": 0.55,
"gap_type": "pa_gap",
"actor": "user:biller_142 | system:835_ingest",
"outcome": { "status": "denied", "carc": "CO-197" }, // 835 events only
"ts": "2026-07-14T09:12:33Z"
}
2.5 Retraining and deployment ENG TO CONFIRM
- Triggers: scheduled monthly, plus alarm-driven when weekly per-payer calibration error exceeds the agreed band for 2 consecutive weeks.
- Gates: temporal backtest must clear AUC and per-payer recall floors (Section 4.1) before a version can leave shadow mode. Human approval on every promotion during alpha and beta.
- ENG TO CONFIRM: pipeline tooling, feature-store choice, canary strategy per practice cohort.
2.6 Security, privacy, compliance
- Features are claim-metadata level; no clinical notes in the MVP feature set. All the same, claims data is PHI: BAA coverage, encryption in transit and at rest, minimum-necessary access, and full audit logging are entry criteria, not enhancements.
- Model outputs (scores, factors) are treated as PHI-derived data with the same access controls as the claim itself.
- ENG TO CONFIRM: threat model review, retention windows per artifact, de-identification standard for the training store.
2.7 Open engineering questions
| # | Question | Product's starting position | Owner |
|---|---|---|---|
| Q1 | Score on save vs batch-only for MVP? | Both; on-save matters because billers edit and expect the number to move | ENG |
| Q2 | Where do payer rules (timely filing, modifier requirements) live today, and who maintains them? | Assume existing rules table; needs an owner and a weekly review loop | Product + ENG |
| Q3 | Can the eligibility (270/271) service be triggered per claim on demand, and at what cost per check? | Assumed yes; cost per check shapes the fix economics | ENG |
| Q4 | Event bus vs direct writes for feedback events? | No position; whatever the platform standard is | ENG |
3. Design prototype & design requirements
3.1 Design principles
- Explain before you automate. No score without its reasons, in biller language. Jargon always carries a hover definition.
- One primary action per flag. The suggested fix is a single button; everything else is secondary.
- Undo everywhere. Any applied action is reversible in one click. Safety produces adoption.
- Respect disagreement. Override is one click, never nagged, and framed as feedback rather than failure.
- Show the cost of being wrong. The threshold screen shows workload and missed-denial trade-offs honestly.
3.2 Wireframes
3.3 Design requirements
- Risk bands: Low <10%, Moderate 10 to 25%, Elevated 25 to 50%, High ≥50%; band thresholds are display constants, distinct from the operating threshold.
- Factor list is ordered by contribution and capped at what fits without scrolling on desktop; the full list expands on demand.
- Every billing term carries a hover definition sourced from one shared glossary; on touch devices, definitions live behind an info affordance.
- All charts and gauges size to their container; the product must be fully usable at 375 px width and at 1440 px+ without dead space.
- The live prototype (demo) is the hi-fi reference for interaction behaviour; visual design tokens to be aligned with the NewMed design system at implementation.
4. Evaluations & QA
4.1 Offline evaluation protocol (pre-ship gate)
- Temporal backtest only. Train on the past, test on the future (current prototype: trained Jan to Apr 2026, tested May to Jun). Random splits are prohibited: payer rules drift and random splits leak future behaviour into training.
- Current prototype results: AUC 0.853 on 2,008 unseen claims (16.2% base rate). At the default 30% threshold: precision 54%, recall 59%, 17.6% of claims flagged. Synthetic-data caveat: these numbers demonstrate the method; real-world targets get re-baselined per payer in alpha.
- Ship gates per model version: AUC > 0.80 overall; recall floor per major payer; calibration reviewed (a claim shown as 70% should deny about 70% of the time before GA).
4.2 Online evaluation (alpha and beta)
| Phase | Design | Gate to advance |
|---|---|---|
| Alpha | 3 to 5 practices, one specialty; 100% human review of flags; weekly calibration vs actual 835s | Acceptance > 60%; override < 20%; no workflow regression reported |
| Beta | Expand payers before specialties; matched control practices for lift measurement | Clean-claim-rate lift visible vs control; per-payer precision stable 4 weeks |
| GA | Per-practice ROI reporting on; continuous retraining on | Lift sustained 2 quarters |
4.3 QA plan
- Model QA: scoring parity test between training code and serving code on a golden claim set (the prototype ships exactly this: Python trains, JavaScript serves, same weights, asserted equal). Feature-drift tests on every input field.
- Data QA: fan-out checks (claims join to payers 1:1; line-item joins pre-aggregated to claim grain), duplicate claim detection, NULL-safe rate calculations, date-bucketing by service date not submission date.
- UX QA: apply/undo/override state machine covered by automated tests; counters always reconcile; the fail-open unscored state renders correctly; WCAG 2.1 AA audit.
- Regression pack: golden queue snapshot re-scored on every model or code change; alert on any claim whose band changes without a data change.
4.4 Production monitoring
| Signal | Cadence | Action trigger |
|---|---|---|
| Per-payer precision and recall vs actual 835s | weekly | >10-point calibration error 2 weeks running → retrain |
| Fix-suggestion acceptance rate | weekly | <60% → review suggestion quality per denial category |
| Override rate | weekly | >20% or rising → threshold and feature review with alpha practices |
| New dominant CARC per payer | continuous | feature/rule gap analysis |
| Automation-bias audit (sampled re-review of accepted fixes) | monthly | error rate above baseline → raise mandatory-review share |
| Clean-claim rate vs matched controls | monthly | flat after 2 quarters → revisit product, not just model |
4.5 Model risk register
| Risk | Mitigation |
|---|---|
| Payer rule drift | Weekly calibration monitoring; 835 stream as continuous labels; alarm-driven retraining |
| Automation bias (rubber-stamping) | Sampled mandatory review; undo prominence; acceptance-quality audits |
| False-positive fatigue | Per-practice threshold tied to capacity; precision floors per payer |
| Cold start (small payers/specialties) | Fall back to pooled cross-specialty payer patterns until volume accrues |
| PHI exposure | Metadata-only features; PHI-derived outputs inherit claim access controls; audit logging |
Appendix
A. Companion product. The Practice Ops Bottleneck Analyzer (live demo) applies the same discovery method to operational task data: rank each practice's manual-effort sinks and pair every bottleneck with an automation recommendation and a quantified saving.
B. Source and reproducibility. Everything regenerates from code: github.com/nayanlal029/portfolio-projects-newmed. The claims warehouse, the SQL discovery pack, model training, and this document's numbers are one python3 run_pipeline.py away.
NewMed is a fictional platform; all data is synthetic. Prepared by Nayan Lal, July 2026.