Summary
CMS replaced the Hospice Item Set with the HOPE assessment tool on October 1, 2025, turning hospice quality reporting into a real-time data-integrity test most hospice data stacks were never built to pass. This article walks through what a CMS-ready data foundation for hospice care agencies actually requires: how HOPE and HQRP work, why fragmented systems put the 4% payment penalty at risk, and how governance, integration, and strategy fix it.
Introduction
A hospice team compliance officer pulls the quarterly HOPE submission report in iQIES and finds a gap. Not a clinical gap. A data gap. The admission record sits in one system. The matching discharge sits in another. Nobody can quickly prove either one hit CMS’s 30-day window. The chart itself was accurate. The story it told CMS was not.
That scenario is playing out across the industry right now, because the rules changed underneath hospice organizations on October 1, 2025. CMS retired the Hospice Item Set (HIS) and replaced it with the Hospice Outcomes and Patient Evaluation tool, known as HOPE, and the shift is not cosmetic. It is a structural change in what CMS expects a hospice’s data infrastructure to be able to do. Most hospice data environments, built for the old retrospective model, were not designed for it.
This article is about what closes that gap: a healthcare data platform built specifically to be CMS-ready, meaning governed, integrated, and traceable enough to survive both a routine HOPE submission cycle and a Medicare Administrative Contractor’s review. We will walk through what HOPE actually requires, why the 90% threshold and 4% payment penalty exist, where hospice data infrastructure typically breaks, and what a real foundation is built from.
What Is the HOPE Assessment Tool, and How Does It Replace HIS?
HOPE (Hospice Outcomes and Patient Evaluation) is the CMS patient assessment tool that officially replaced HIS for all hospice admissions on or after October 1, 2025. CMS finalized the requirement under the FY 2025 Hospice Wage Index Final Rule, CMS-1810-F.
The difference between the two tools is not paperwork. HIS relied on retrospective chart abstraction: a hospice completed an admission assessment and a discharge assessment, and if something was inconsistent, there were usually weeks to reconcile it before submission. HOPE does not offer that cushion. It is built to collect patient-specific data in real time, based on actual interactions with the patient and family, with the clinical flexibility to accommodate varying needs across a hospice population.
Legacy HIS records did not disappear overnight. Hospices could still modify or inactivate HIS records inside the older QIES system through February 15, 2026, but only for admissions that predated the HOPE transition. For every patient admitted on or after October 1, 2025, HOPE is the only record CMS accepts.
Why Hospices Need Real-Time Data Collection Instead of Retrospective Entry
The retrospective model tolerated fragmentation because time absorbed the errors. A hospice could run its EHR, billing platform, and referral intake as three loosely connected systems, and a staff member could still reconcile the discrepancies by hand before a quarterly deadline arrived.
HOPE removes that buffer entirely. Data now needs to move from the point of clinical contact into CMS’s submission system on a rolling 30-day clock, timepoint by timepoint, for every patient. That single change is why so many hospice organizations that were never flagged for a documentation problem under HIS are now finding themselves exposed under HOPE. The clinical work has not changed. The tolerance for disconnected systems has.
HOPE Data Submission Requirements: HOPE-Admission, HUV, and HOPE-Discharge Records Explained
Every hospice patient generates up to three distinct HOPE records, and each one has to reach CMS on its own clock.
- HOPE-Admission: completed at the start of hospice care, establishing the baseline assessment.
- HOPE Update Visit (HUV): up to two update visits, timed to fall within the first 30 days after a beneficiary elects hospice. Not every patient requires both; the number depends on length of stay.
- HOPE-Discharge: completed at the end of the hospice stay, whether through death, transfer, revocation, or live discharge.
Each of these timepoints is submitted through iQIES, the Internet Quality Improvement and Evaluation System that replaced the older QIES platform specifically for HOPE data. iQIES is not optional infrastructure. Before a single record can move, a hospice needs at least one staff member registered as a Provider Security Official (PSO), the role responsible for approving every other iQIES user at that organization. Hospices that have not completed PSO registration are, in practice, unable to submit HOPE data at all, regardless of how complete their clinical documentation is.
Hospice HQRP Compliance in 2026: The 90% Threshold and the 4% Payment Penalty
The Hospice Quality Reporting Program, or HQRP, is where HOPE submission stops being a clinical workflow question and becomes a financial one.
Under HQRP, hospices must submit and have accepted at least 90% of HOPE records within 30 days of the relevant event date, whether that is the admission date, the discharge date, or the completion date of a HUV. That 90% compliance threshold applies to HOPE records collected in calendar year 2026 and determines the Annual Payment Update for fiscal year 2028, and the same mechanism repeats in subsequent years: data collected in 2027 affects the FY 2029 payment update, and so on.
Miss that threshold, and the consequence is not a warning letter. It is a 4-percentage-point reduction to the hospice’s Annual Payment Update, a penalty CMS has applied to non-compliant hospices since FY 2024 and continues to enforce. For a mid-sized hospice, that reduction compounds across an entire year’s Medicare census, and it applies regardless of how strong the clinical care behind the missed records actually was.
HQRP compliance also extends beyond HOPE. Hospices are required to participate in the CAHPS Hospice Survey for each calendar year, submitted through a CMS-approved vendor, and administrative claims data is pulled automatically from Medicare billing. HOPE, however, is the component most exposed to internal data infrastructure problems, because it is the one that depends entirely on a hospice’s own systems moving information correctly and on time.
How Data Fragmentation Puts Hospice HQRP Compliance at Risk
The 4% payment reduction gets attention because it is concrete. It shows up on a payment statement where nobody can ignore it. But CMS’s own guidance points to something less visible and more structural: hospices that fail HQRP requirements typically do so because they miss the 90% submission threshold, not because their clinical documentation was inaccurate.
That threshold failure traces back to a recognizable set of infrastructure gaps, over and over.
- No single source of truth. Admission data lives in the EHR. HUV completion dates live in a care-coordination tool or a shared spreadsheet. Discharge data lives somewhere else entirely, and no one owns reconciling the three.
- No data lineage. When a HOPE record arrives late or incomplete, nobody can quickly trace which system, or which handoff between systems, introduced the delay.
- No governance layer. Data quality rules, field ownership, and access controls exist informally if they exist at all, which means every new integration and every staff turnover creates a fresh point of failure.
- Manual submission workflows. Someone is still exporting, reformatting, or re-keying data before it reaches iQIES, and every manual step is a place where the 30-day clock keeps running unattended.
None of these are clinical failures. They are infrastructure failures wearing a compliance penalty. That distinction matters, because it means the fix is not more clinical training. It is a healthcare data platform built with governance, integration, and lineage as first-class requirements, not afterthoughts layered on once a hospice already has an audit flag against its name.
How to Select a Hospice Software Vendor for HOPE Compliance
Vendor selection is where a lot of this either gets solved or gets quietly deferred. Hospice leadership evaluating hospice data collection software should be asking harder questions than whether it has a HOPE form.
A vendor genuinely built for HOPE compliance should be able to demonstrate:
- Direct alignment with CMS’s current HOPE data specifications, including the exact item sets and validation rules CMS publishes for vendor testing through its HOPE Validation Utility Tool.
- Native submission to iQIES, not an export-and-reformat step that introduces manual risk into the 30-day window.
- Interoperability with existing hospice EMR systems, billing platforms, and referral intake tools, so HOPE compliance does not require ripping out systems clinicians already know.
- Built-in lineage and audit trails, so a compliance officer can answer a CMS reviewer’s question about any given record without reconstructing the timeline manually.
This is also where the difference between buying a point solution and building a governed foundation becomes clear. A tool that satisfies HOPE today but was not built for interoperability will need to be replaced again the moment CMS adds new requirements, and CMS has already signaled that more are coming.
Building an Interoperable Data Infrastructure for Hospice Quality Reporting
A CMS-ready data foundation is not a new EHR module, and it is not a HOPE-specific workaround bolted onto legacy systems. It is three disciplines working together as a single healthcare data integration platform, purpose-built for hospice reporting. Skip any one of them, and the other two stay exposed.
Data Governance in Healthcare: The Compliance Backbone
Data governance in healthcare is what turns “we have the data somewhere” into “we can prove where the data came from, who touched it, and when it moved.” For a hospice, effective healthcare data governance means defined data ownership across clinical, billing, and quality teams, so no HOPE field is an orphan nobody is accountable for. It means documented data quality rules that catch a missing HUV timestamp before it becomes a missed submission, not after. And it means an audit trail that can answer a CMS reviewer’s question in minutes, not weeks. Data Quality Governance and Compliance services exist specifically to build that layer, because without it, every other fix is temporary.
Data Engineering and Integration: One Platform Instead of Many Systems
Governance defines the rules. Integration is what actually makes the data move. Most hospices run on a patchwork of EHR, billing, referral, and care-coordination systems that were never designed to talk to each other, let alone feed a real-time submission pipeline into iQIES. Data Engineering and Integration services connect those systems into a single governed pipeline, so a HOPE-Admission record and its matching HUVs and discharge record move on the same timeline automatically, instead of depending on someone remembering to reconcile three separate exports before the 30-day window closes. In practice, this is where becomes the actual engineering work, not a slide in a pitch deck.
Underneath that integration layer sits the question of how the data itself is structured once it lands in one place. Hospices that get this right are typically organizing raw, cleaned, and reporting-ready data into distinct layers rather than one undifferentiated pile, an approach explained in .
That structure is also what makes lineage possible in the first place. Once data has a defined path from raw ingestion to a governed, reporting-ready layer, audit-ready data lineage that survives a CMS review stops being aspirational and becomes something a compliance officer can actually produce on request.
Data Strategy Consulting: Sequencing the Foundation for What Comes Next
Governance and integration solve today’s HOPE compliance problem. Strategy makes sure the foundation built to solve it also supports what is coming next: predictive staffing models, referral forecasting, and the AI-driven operational tools now moving into hospice care. Data Strategy Consulting services map that sequence, decide what gets built first, and make sure the foundation gets engineered once, for CMS reporting today and for the analytics and AI capabilities hospice leadership will need within the next two to three years.
What new quality measures will HOPE data support by FY2028?
HOPE is not just a reporting-format swap. CMS built it to eventually carry more analytical weight than HIS ever did. CMS has finalized two new process measures, Timely Follow-Up for Pain Impact and Timely Follow-Up for Non-Pain Symptom Impact, calculated directly from HOPE data, with implementation no sooner than FY 2028. Public reporting of HOPE-based quality measures more broadly is expected to begin around the same time, once CMS has enough calendar-year data behind it to report reliably.
That timeline matters for a specific reason: FY 2028 measures are built on data collected during calendar year 2026 and 2027. A hospice whose data infrastructure is still fragmented today is not just risking this year’s payment update. It is building the dataset that CMS will eventually make public, under measures that have not been finalized yet, using a foundation that was never designed to be analyzed at that level of scrutiny.
Why this is a foundation, not a fix?
Every hospice CXO evaluating this space eventually asks the same question. Is this a compliance project or an operational one? It is both. Treating it as only the former is how organizations end up rebuilding the same pipeline twice, once under HOPE pressure and again when the next operational priority arrives.
A governed, integrated healthcare data platform is what makes HOPE submission reliable. It is also the prerequisite for everything hospice leadership wants next: forecasting models that predict length of stay and staffing needs with numbers leadership can actually defend in a board meeting, and AI agents that support intake, documentation, and patient engagement without introducing new compliance risk. Neither of those works on top of fragmented, ungoverned data. The foundation comes first, not because of sequencing preference, but because there is no other order that holds up.
