Interactive demo · synthetic data only
Watch Ms. Jane catch what gets missed.
Step through five sample home-health cases. Each one hides a different kind of problem an OASIS reviewer, or an agency's bottom line, can miss — and each flag shows its reasoning, not just a red X.
Consistency
Scores that contradict each other within a chart.
Revenue accuracy
Documentation that doesn't match the patient's true status at a PDGM threshold.
Audit-proofing
Unexplained score changes across visits and clinicians.
Payment protection live
LUPA, NOA, and classification checks running on every episode.
Revenue recovery
What happens when a denial comes back anyway — preview.
All names and data are synthetic samples. No real patient information is used or stored.
Sample Case 1 · the obvious catch
Patient A
Score this functional assessment, then submit.
03 — Dependent: someone else must groom the patient
02 — Needs assistance
00 — Independent: bathes self with no help
⚠ Ms. Jane flags an implausible combination
M1800 Grooming = 03 · M1830 Bathing = 00A patient scored fully dependent for grooming but fully independent for bathing is physically implausible — bathing is the more demanding activity. One of these scores is very likely an entry error worth confirming before submission.
Ref: CMS OASIS-E2 Guidance Manual, Ch. 3 §G (Functional Status) — score each item on demonstrated ability; related ADL scores should be internally consistent. (paraphrased)Auditable, not a black box — you see the rule, not just a red X.
Sample Case 2 · the revenue catch
Patient B
This assessment sits right on a PDGM functional-level threshold.
02 — Requires a one-handed device (e.g., cane) to walk
02 — Needs assistance
02 — Needs assistance
Ms. Jane surfaces a documentation-accuracy check
The current functional-item scores place this 30-day period in the lower-paying PDGM functional group.
The visit narrative notes the patient "requires a two-handed device and standby assistance to ambulate." If M1860 reflects that documented status, it scores higher — moving the episode to the next functional group.
This is not "upcode it." It's a prompt to make the coded score match the patient's true, documented functional status — the framing that protects both revenue and the record in an audit.
Illustrative impact: an accurate functional level can shift a 30-day period by roughly $1,000–$2,000, depending on the agency's case-mix and base rate. Actual amounts vary — this figure is illustrative, not a quote.
Ref: CMS PDGM methodology — the functional impairment level is derived from specific OASIS items, and the coded response must be supported by documentation. (paraphrased)Sample Case 3 · the consistency catch
Patient C
This patient was seen twice, by two different clinicians. Submit Visit 2.
⚠ Ms. Jane flags an undocumented change
M1860 (Ambulation) improved from 02 to 00 between visits, but no clinical change or improvement is documented in the interim notes. Inter-clinician score drift with no supporting documentation is a common audit trigger.
Confirm the improvement with a documented reason, or correct the score before submitting.
Ref: CMS OASIS-E2 guidance — score changes across time points should be clinically supported and documented. (paraphrased)Sample Case 4 · the payment-protection catch live
Patient D
This isn't a single OASIS field — it's three checks Ms. Jane runs on the episode itself, all the time, not just at submission.
Filed on day 2 — within the 5-day window
3 of 5 required visits completed, 6 days remaining
Community — matches claims history
⚠ Ms. Jane flags a LUPA risk
3 of 5 visits · 6 days remainingAt the current visit pace, this episode is on track to fall under the LUPA threshold for its HHRG. NOA filing and admission source both check out — only the visit pace needs attention, while there's still time to add a visit.
Ref: CMS Home Health PPS — LUPA visit-count thresholds are set per HHRG; falling under the threshold changes payment to a per-visit rate instead of the full 30-day rate. (paraphrased)Live today — this runs on every active episode, not just at submission.
Sample Case 5 · the recovery catch preview — in development
Patient B
Three weeks later, this claim comes back denied. Here's what the rev cycle module does with it.
Non-covered services — not deemed a medical necessity by the payer
Decision was based on a Local Coverage Determination (LCD)
Ms. Jane matches the denial back to the chart
CARC 50 + RARC N115 — medical necessity, LCD-based. Generic on its own; the RARC is what makes it actionable.
M1860 Ambulation / functional status — the same field flagged as borderline at intake in Case 2. The appeal draft pulls the documented status directly from that assessment.
The appeal writes itself from the record — citing the specific LCD, quoting the documented functional status, no manual chart digging.
Ref: CARC 50 / RARC N115 — standardized CMS/X12 denial codes (paraphrased)Preview only — the rev cycle module is in development. This shows the matching logic already built into the data model.
Recap
5 patients. 5 catches. Here's what they would've meant.
- 1Consistency. Prevented an internally inconsistent, indefensible chart (M1800 vs M1830).
- 2Revenue accuracy. Prompted a documentation-accuracy review at a PDGM functional-level threshold — accurate coding, not gaming. Illustrative $1,000–$2,000 per 30-day period.
- 3Audit-proofing. Caught an undocumented inter-clinician score change before it became an audit flag.
- 4Payment protection. Flagged a LUPA risk while there was still time to act — live today, running on every episode automatically.
- 5Recovery. Denial matched straight back to the flagged documentation from intake — no manual digging to start the appeal. Preview of the rev cycle module, in development.
Synthetic demonstration only. Ms. Jane is a rules-based QA tool; it supports, and does not replace, clinical judgment. Case 4 (payment protection) reflects a live, shipped check. Case 5 (rev cycle) is illustrative of planned functionality — that module is in development, not a live feature.