What Home Health Revenue Cycle Analytics Is For
Home health revenue cycle analytics joins clinical, claims and payment data into one view you can act on: which 30-day periods are underpaid, which claims are aging toward a filing deadline, and which denial reasons are consuming the most money. Most agencies already own every number they need. The problem is that those numbers live in separate systems — the EHR, the billing or clearinghouse platform, payer portals, and the accounting ledger — that were never designed to agree with one another.
Analytics is also not the same thing as reporting. A report tells you what happened last month, after the period has closed and the payment has posted. Analytics answers a question someone can act on this week: is this claim likely to pay, is this period at risk of falling short of its visit threshold, is this payer's denial pattern getting worse. If a dashboard never changes a decision anyone makes, it is decoration.
Four Data Sources, Four Different AR Numbers
Home health revenue cycle reporting draws on four sources, each of which records a claim at a different moment. The first is the clinical record: OASIS assessments, visit documentation, and start-of-care dates, which determine how each 30-day period groups and what case-mix weight it should carry. The second is the claim itself — submission date, payer acknowledgement, and the status the payer reports. The third is the remittance advice: what the payer actually allowed, paid and denied, together with the claim adjustment reason codes that explain the difference. The fourth is accounting: cash received, deposits and write-offs.
Because each source captures a different event, they will disagree, and none of them is simply wrong. A claim marked accepted by the clearinghouse has only been received; it is not paid. A payer portal status can be several days stale. The ledger records money that has landed, not claims in flight. When two teams publish different days-in-AR figures, the disagreement is usually not arithmetic — it is the source and the timestamp behind it.
The practical fix is to declare one source of truth per metric and write the definition down. Days in AR calculated from expected reimbursement in the billing system is a workflow metric: it tells you what to work today. Days in AR reconciled to the ledger is a cash metric: it tells you what to forecast. Publishing both, labelled honestly, ends the argument faster than picking a winner.
Build on a Claim-Level Table, Not on Reports
Every reliable report starts from one table with one row per claim or per 30-day period, joined on stable keys rather than rebuilt from a monthly summary each time. At minimum, that row needs the period start and end date, primary payer, PDGM clinical grouping with functional and comorbidity levels, the case-mix weight, billed and expected amounts, submission date, first payer response, remittance date, allowed and paid amounts, patient responsibility, the reason codes, the current status, and the date the claim was last worked.
The unit of Medicare home health payment is the 30-day period, not the calendar month. A period that begins in March and ends in April carries one payment decision. Reporting it by calendar month splits that decision across two files and makes both of them wrong: visit counts are halved, per-period thresholds look missed, and the same claim can appear to be two separate problems to the person working it.
Keep a separate period table — one row per 30-day period — and count visits against periods rather than months. That single change removes more false alarms than any dashboard redesign, because it stops the reporting layer from inventing problems the operational layer does not have.
Five Traps That Skew Home Health Revenue Numbers
The first trap is calendar-month reporting on 30-day periods, described above: it splits payments and visit counts that belong together, and it makes month-over-month comparisons meaningless whenever period start dates shift.
The second is measuring AR on billed charges. A claim with a large charge and a modest allowed amount is not necessarily the most valuable one to work. Prioritising by expected reimbursement puts follow-up time where the money actually is, which is usually a smaller set of claims than the aging report suggests.
The third is treating a payer's first response as the final denial reason. A claim rejected on the clearinghouse front end, denied during payer adjudication, and denied again in the remittance advice can carry three different reason codes — and only the remittance code survives an appeal. Aggregate on remittance codes; use earlier codes as workflow signals, not as the basis for a trend line.
The fourth is averaging days in AR. An average hides the tail, and in home health the tail is where filing deadlines are lost: the 90-day-and-older bucket is where recoverable money quietly becomes uncollectible. Report accounts receivable by aging bucket and by dollars, and treat the average as a headline rather than a management number.
The fifth is counting submissions as revenue. A submitted or even accepted claim is not revenue until a remittance posts against it. Until then, the expectation for a period is its case-mix weight applied to the applicable base rate, and that is the number forecasting should use.
The Weekly Review That Keeps the Numbers Honest
A short weekly review against the same five questions keeps the reporting layer honest. First: which claims submitted last week were held, corrected or rejected before they ever became claims? Front-end failures never appear in an aging report, so they have to be counted deliberately or they disappear.
Second: how is accounts receivable distributed across aging buckets, and which claims are inside the last two weeks before their timely filing limit? Third: which denial reasons — taken from remittances — account for the largest share of unpaid dollars, and is the underlying cause coding, clinical documentation, eligibility, authorisation, or timing? Naming the cause is what converts a denial report into a work queue someone can clear.
Fourth: does the case-mix level on each 30-day period match what the OASIS assessment and the record support? A period grouped below what the documentation supports is the most expensive reporting error an agency can miss, because no one is tracking money that was never billed.
Fifth: exceptions while there is still time to act. A period tracking below its visit threshold while it is still open, a Notice of Admission that is not accepted within the filing window Medicare sets for it, an authorisation that expires mid-episode — these are the items where a few days of warning change the outcome, and where analytics earns its place over a month-end report.
Running It Without a Data Team
None of this requires a data engineer. It requires one scheduled export from each source, joined on the claim or period identifier in a spreadsheet or a lightweight business-intelligence tool, plus one named owner for the weekly review. The sequence that works is export, join, check, publish — never the reverse.
Write down one definition per metric and keep it where the team can find it. If two people calculate days in AR differently, publishing the definition and picking one is worth more than winning the argument about which formula is better.
Reconcile the model to the bank every month. Paid amounts in your table must equal deposits, or the table is wrong somewhere and every conclusion drawn from it is suspect. Automate alerts last: an exception rule that has not been reviewed by hand for a few weeks will teach the team to ignore it.
What to Ask an Outsourced RCM Partner About Reporting
When revenue cycle management is outsourced, reporting is often the only visibility an agency keeps, so it belongs in the contract. Ask for claim-level detail rather than monthly summaries, and ask which fields are included: period dates, case-mix weight, reason codes, worked dates.
Ask how the partner defines a 30-day period, how it calculates days in AR, and which source its denial reasons come from. Ask how exceptions reach your team, and whether that happens before or after filing deadlines. Then ask whether the numbers can be reconciled to your deposits and your general ledger — a partner who cannot answer that is reporting activity rather than money.
Finally, ask what changes in your own operations the reporting is meant to drive. A report that surfaces a documentation pattern your clinicians can fix, and predictive analytics-style alerts that arrive before a deadline, are worth far more than a longer list of charts nobody opens.
A Sensible Order of Operations
Resist adding metrics until the table underneath them is trustworthy. In the first two weeks, build the claim-level and period-level tables covering the last six to twelve months and change nothing else — an honest history is the baseline every later comparison depends on.
In week three, publish aging by bucket together with the timely-filing watchlist. In week four, add remittance-based denial reasons ranked by dollars, and the per-period comparison of case-mix level against the clinical record. Only then add alerting, one rule at a time, each verified by hand before it goes live.