In development · coming to pilot agencies
What happens after a denial.
MsJaneHH's QA workflow catches documentation problems before submission. The rev cycle module picks up what still gets denied — matching every denial code back to a specific CMS rule and the OASIS field it traces to, so appeals are built from documented fact, not guesswork.
Denial ingestion
Remittance data (835/ERA) is parsed into structured CARC and RARC codes — the same standardized codes every payer under HIPAA uses, whether Medicare or commercial.
Rule-based matching
Each denial code maps to a documented category — medical necessity, authorization, timely filing, documentation — and, where applicable, back to the specific OASIS field that likely drove it. No inference: this is a lookup table you can audit line by line.
Appeal draft
A rules-based draft is generated citing the relevant CMS policy — LCD, PDGM methodology, or payer-specific guidance — with supporting documentation pulled straight from the original assessment. Templated, not AI-generated: same input, same output, every time. This piece is built; automatic denial ingestion (below) is what's still rolling out.
Deadline tracking
Redetermination, reconsideration, and ALJ deadlines are tracked automatically per payer, so a missed filing window never becomes the reason revenue doesn't come back.
The loop that gets smarter
Every denial pattern feeds back into the same QA rules that review assessments before submission — so the documentation gaps that caused yesterday's denial get flagged before tomorrow's assessment goes out the door.
Status: the data model, CARC/RARC reference tables, and a rules-based appeal draft generator are built. The 835 parser (automatic denial ingestion) and the code-to-OASIS-field matching engine are in active development. This page will update as each piece goes live in pilot.