HOSPICE METRICS

How Hospice Metrics Turns Public CMS Data Into Something You Can Rely On

Medicare pays for almost all hospice care in the United States, and it publishes a great deal of data about what it is paying for. None of that data is hidden. It is spread across a dozen file families on different release schedules. It is written in measure codes. Some cells are suppressed and read as blanks. Any of those can lead you to a conclusion the file does not actually support.

We take those published files and turn them into reports where every figure says where it came from and can be checked against the source. Most of our clients are lawyers working Medicare cases, though nothing about the method is specific to litigation. If you have a reason to look hard at a hospice from the outside, this is how we would do it.

The reason we are strict about all of this is that a report may end up in front of a court, and a number you cannot defend under questioning is worse than no number at all. So the design goal is narrow: you should be able to check anything we show you, trace it to a public file, and get the same answer we did.

Where the numbers come from

Nothing here is private data. Every figure starts from a file CMS publishes for the whole country.

The provider files carry the claims-based measures: the live-discharge counts, the Hospice Care Index, per-beneficiary spending, and the mix of diagnoses and care settings. The survey files, which you may know as Form 2567 or QCOR, carry state inspection results down to the individual citation. CAHPS carries the family-experience scores. The ownership files list who owns each hospice and how those owners are enrolled with Medicare, and a separate pair of files records formal sales and transfers. The service-area file shows which ZIP codes a hospice declares. National and state baseline files supply CMS's own comparison points.

We load every release of all of them, several years back, so you can watch a hospice over time instead of squinting at one snapshot. That currently runs to more than a hundred distinct file releases covering close to eight thousand hospices.

Every number says where it came from

Next to each figure in a report is a small tag. Either the number is CMS-published, meaning we read it out of a CMS file and left it alone, or it is product-computed, meaning we worked it out here from public values and are showing you the denominator we used.

That sounds like a formatting choice. It is the spine of the product. You should never have to wonder whether a percentage came from the government or from us, and we do not keep a third category for numbers that are sort of both. Nothing here gets smoothed or blended until you can no longer see where it came from.

A check runs against every report before it can ship. A figure without a provenance tag stops the build.

Every rate carries its denominator

A percentage on its own can be read further than it will carry. Fifty percent of four patients is two people. Fifty percent of four thousand is two thousand. So you never get a rate from us without the count underneath it.

The uncomfortable version of that rule is the one we care about. When CMS does not publish a denominator, we do not estimate one, and we do not hand you the percentage as though it were solid. The family-experience scores are the case in point: CMS publishes the share of families who would recommend a hospice but not how many families answered. So you get the percentage and a plain statement that the respondent count is not published. A check confirms that every figure marked as a rate ships with its denominator or with the reason there isn't one.

A suppressed value is not a zero

CMS suppresses some cells deliberately, usually to protect privacy when a count is small. Suppressed means unknown. It does not mean zero.

Take a hospice whose live-discharge count was suppressed. Treat that blank as a zero and the hospice appears to have had none. What is actually true is that the count was not published. So three states travel through the whole system, from the raw file to the printed page to the spreadsheet export: published, suppressed, or not computable. Each looks different in a report, and none of them becomes a zero or a pass. The exports carry a status column for the same reason, so an empty cell can never be read as a real zero.

We do not score, rank, or conclude

This is the part people push back on. There is no grade. We do not rank hospices against each other, and we do not mark any of them for attention. You get the numbers, the comparison points that belong with them, and then we stop.

That is deliberate, and it is not modesty. What a number means depends on the question you brought to it, and you know that question better than we do. A high live-discharge rate can reflect how a hospice manages admissions, or a patient population whose illnesses are hard to time. Someone reviewing quality and someone reviewing billing integrity can read the identical figure in opposite directions and both be reasoning correctly. Deciding for you would mean guessing which of you we were talking to.

The live-discharge rate, done carefully

This is usually the figure you came for. It is also the easiest one to get wrong.

The arithmetic is plain: patients discharged alive, divided by patients discharged alive plus patients who died, times a hundred. We scope it to Medicare fee-for-service and compute it over a rolling eight-quarter window from the counts CMS publishes.

That plain sentence leaves out something worth knowing before you quote the number. When a patient moves from one hospice to another, CMS does not count it as a live discharge at all. The rule works off the discharge code on the claim, and the two codes for a transfer to another hospice are excluded, along with the death codes and the code for a patient still enrolled. Everything else counts, including a patient revoking the benefit and a discharge because the hospice decided the patient was no longer terminally ill. So the figure answers how often patients left hospice care alive, not how often they switched provider. It is also why our national number sits below the national rate in CMS's monitoring report, which counts transfers along with everything else.

One more piece of small print. The two counts are not in the same unit, because CMS does not publish them in the same unit. The discharge side counts discharge events, so a patient who leaves and comes back inside the window can appear twice. The other side counts people who died, once each. In practice they very nearly coincide, and we use both exactly as published instead of adjusting them ourselves. What you end up holding is a ratio of events to a mixed base, which is not quite a clean share of patients.

The care goes into the comparison. We show a hospice against the national figure, but the national figure is not size-neutral: small hospices run much higher live-discharge rates than large ones. Compare a large hospice to the overall national rate and the comparison runs in its favor. Compare a small one and it runs against it. So you also get the median rate for hospices of similar discharge volume, labeled as a comparison point. It is not a control group. The hospices in a band may share whatever the rate is responding to, so treating the band as a baseline can absorb the variation you were trying to see.

You also get two versions of the national comparison instead of one. The pooled rate weights by patient count, so large hospices pull harder. The facility median treats every hospice as one vote. These two can disagree about which side of the national line an operator falls on, and among operators large enough to measure both ways, a meaningful share land on opposite sides depending on which you pick. A report showing only one could tell a one-sided story and nobody would notice. You get both, so you can see when the story depends on the method.

We also check whether the size gradient is really case mix. Dementia patients decline unpredictably and are discharged alive more often, so a hospice with many of them can run a high rate on case mix alone. Hold the dementia share roughly constant and the size gradient is still there.

Inspections: citations per survey, not raw counts

Inspectors write citations when they find problems, and it is tempting to count them and treat a big number as a bad sign. The data itself shows why that is a mistake.

What mostly drives a hospice's citation total is how many times a surveyor came through the door. It tracks survey count far more closely than it tracks hospice size, and far more closely than it tracks anything you would call behavior. So we lead with citations per survey, show the raw count beside it with its own percentile, and let you see the gap between them.

Other distinctions survive too. A complaint survey, where somebody filed a grievance a state agency judged worth investigating, is not the same event as a routine recertification visit, and both are labeled. Surveys that found nothing are counted, because a complaint investigated and dismissed is part of the record, and dropping it would tilt the record. And the three regulatory regimes stay separate: care delivery, building and fire safety, and emergency planning are not interchangeable. A blocked fire door is a real finding. It is not a finding about nursing, and we do not let it pass for one.

Ownership and changes of ownership

Cases often turn on who owned a hospice and when control moved. CMS gives us two windows onto that, they disagree, and we show both.

The first is CMS's official record of change-of-ownership transactions. The second is one we reconstruct by watching the owner set change from one quarterly snapshot to the next. They measure different things. The official file records formal legal events, many of which happened before our observation window opened. Our reconstruction sees churn between snapshots, and what it can tell you is the window in which we observed a change. It cannot tell you the date of a transaction. We do not correct either one against the other. Each is labeled for what it is and they sit side by side, because forcing them to agree would leave you unaware that they answer different questions.

Rules we built and then rejected

Early on we tried building our own flags: simple rules to mark a hospice for closer review. Each one got a shuffle test, which asks a blunt question. If the components of this rule had nothing to do with each other, how often would chance alone produce the pattern we are looking at?

One rule flagged any hospice landing in the highest decile on at least two of four discharge-pattern measures. Tested properly, it flagged almost exactly the number chance alone produces. It was separating nothing that noise would not. So it went. A second rule combined early and late live discharges, which turn out to be two shares of the same denominator and therefore move in opposite directions by construction; it flagged fewer hospices than chance would. That went too.

Those rejected rules are printed in the report, with the evidence that rejected them. Showing a rule we considered and explaining why we do not trust it is more useful than dropping it quietly.

Same inputs, same report, every time

A report is worth as much as your ability to reproduce it. If you cannot re-run the work and land on the same answer, you are trusting us. That is not the same as knowing. So reproducibility is built in at the foundation.

A report is a pure function of three things: the CMS releases it used, the version of our code, and the version of the template. Give it those three and it produces the same document down to the byte. At the foot of every report is a manifest listing each release it drew on, with a checksum, so you can confirm you are holding the same source files we were.

There is also a quiet trap in the CMS data that we handle for you. CMS sometimes republishes an identical file under a new date. Treat that as new data and a trend line shows a change that never happened. We checksum the parsed content of every release, so we can tell when two releases are the same file wearing different dates, and mark the duplicate so trend calculations skip it. And a historical report is compared against the benchmark that was current when it was written, so the past gets measured against its own present.

How we check ourselves

None of the above would mean much untested. Before we trust a release of the software, we rebuild the entire database from the raw CMS files and re-derive every headline number to confirm it still matches a known value. The national live-discharge rate, the size of the comparison set, the facility and state counts, the ownership transaction totals, the citation benchmarks, and a set of specific example facilities and operators all have pinned values the rebuild has to reproduce. If one of them moves, the build stops until somebody works out why.

We treat our own past work the way we treat CMS data, which is to say we do not take it on faith. Reviewing a change means re-deriving the affected numbers from live data instead of trusting a summary of what the change was meant to do. That has already caught real mistakes in our own pipeline before they reached a report, which is the entire reason for doing it that way.

What this is not

The limits deserve to be as clear as the claims. A Hospice Metrics report is a structured view of public data. It is not legal advice. It is not a strategy. It is not a finding that a hospice did anything wrong. It makes no causal claim. It does not assert that any patient was ineligible for care. Treat a high number as a reason to look closer. It is not a verdict. What we show you comes from public records at a point in time, and any figure your case might rest on should be independently verified before it goes into a proceeding.

That is the design. We do not tell you what to think about a number. What you get instead is a number you can trace to its file, reproduce, and read as meaning exactly what it says and nothing further.

This is the long-form companion to the methodology reference. Every figure in an actual report traces to a published CMS file and is re-checked on each build.