How Hospice Organizations Build a CMS-Ready Data Foundation

Summary

On October 1, 2025, CMS replaced the Hospice Item Set (HIS) with the Hospice Outcomes and Patient Evaluation (HOPE) tool. The core compliance rule did not change: at least 90% of required records must be submitted and accepted within 30 days, or the hospice loses 4 percentage points from its Annual Payment Update. What changed is everything around that rule: up to twice as many records per patient, tightly timed clinical windows in the first 30 days of care, a new submission system, and mandatory third-party encoding. This article explains what HOPE requires of hospice care organizations, where data infrastructure comes under pressure, and what a CMS-ready data foundation is built from.

Introduction

It is late in the quarter.

A hospice compliance officer runs the Timeliness Compliance Threshold Report in iQIES and sees the on-time rate drifting toward 90%. The clinical work was done. The visits happened and were documented. But several HOPE Update Visit records were completed in the EHR and never left it, a batch of discharge records was rejected at validation and never resubmitted, and nobody saw the pattern until the report did. By then the 30-day windows had closed.

Nothing in that scenario is a clinical failure. It is a data-movement failure, and HOPE has made it far easier to have one. The 90% / 30-day timeliness rule itself is not new: CMS finalized it in the FY 2016 Hospice Wage Index final rule and phased it in from 70% for FY 2018 to 90% under HIS. What HOPE changed is the volume, timing, and technical path of the records that rule applies to.

That is the real question for hospice leadership: can a data environment built for HIS carry HOPE’s workload? This article covers what HOPE requires, why the 90% threshold and 4-percentage-point penalty matter more now, where hospice data stacks come under strain, and what a governed, integrated foundation looks like in practice. Connecting EHR, billing, and CMS reporting with a robust hospice EMR and referral data integration is one of the mainstays of this foundation.

What Is HOPE, and What Actually Changed from HIS?

HOPE is the standardized patient-level data collection tool CMS finalized in the FY 2025 Hospice Wage Index Final Rule (CMS-1810-F). According to CMS, it is a modification and functional replacement for the HIS, and it became the only accepted tool for patients admitted on or after October 1, 2025.

The transition closed cleanly on CMS’s side. Hospices could submit corrected or late HIS records with target dates of September 30, 2025 or earlier through February 15, 2026; after that, the legacy QIES ASAP system was decommissioned and the free HART data-entry tool was retired. A patient admitted before October 1, 2025 but discharged after it receives a HOPE-Discharge, not an HIS discharge, which is exactly the kind of edge case a transition-era data pipeline must handle correctly.

The practical differences look like this:

Sources: CMS Getting Started with the HQRP (Jan 2026); CMS HIS and HOPE webpages; CMS HOPE training materials.

Two of those rows deserve emphasis. First, CMS states that HOPE data collection consists of collecting real-time patient-level data or abstracting data from patient clinical records, so the shift is not a ban on abstraction; it is a design built around the timing of actual patient interactions. Second, hospice providers now need a vendor or third party to encode their HOPE assessments. Every hospice is therefore running a multi-party data supply chain, whether or not it thinks of it that way.

HOPE Timepoints: Four Records, Each on Its Own Clock

HOPE layers clinical timing windows on top of regulatory submission deadlines. Per CMS training and guidance:

• HOPE-Admission: collected within five days after the effective date of the hospice election, establishing the baseline.
• HOPE Update Visit 1 (HUV1): on or between days 6 and 15 of the hospice stay.
• HOPE Update Visit 2 (HUV2): on or between days 16 and 30. Whether a patient needs one, both, or neither HUV depends on length of stay.
• HOPE-Discharge: at the end of the stay, whether by death, transfer, revocation, or live discharge.
• Symptom Follow-up Visit (SFV): an in-person visit expected within two calendar days when pain or non-pain symptom impact is rated moderate or severe at Admission or an HUV. The SFV is a separate visit, documented in connection with the Admission or HUV that triggered it.

Each record then has its own submission deadline. CMS requires that all HOPE records be submitted to iQIES and accepted no later than 30 calendar days after the Admission Date (A0220), the HUV completion date (Z0350), or the Discharge Date (A0270), with submission times measured in Eastern time.

Our point of view: In data terms, every admission spawns a small dependency graph: up to three assessments and any triggered follow-up visits inside the first 30 days, plus a discharge record at an unknown future date, each with a clinical due date and a regulatory due date running in parallel. Under HIS, a hospice tracked two events per patient. Under HOPE it can be tracking four records and several visit windows at once. Spreadsheets and end-of-month exports do not scale to that; event-driven pipelines do.

Submission itself runs through iQIES. Before any record can move, a hospice needs at least one staff member registered as a Provider Security Official (PSO), who approves every other iQIES user. CMS strongly recommends more than one PSO and notes that failure to obtain iQIES access will affect the ability to submit HOPE records. A single PSO who leaves the organization is a single point of failure for an entire year’s compliance.

HQRP Compliance in 2026: The 90% Threshold and the 4-Point Penalty

The Hospice Quality Reporting Program (HQRP) is where HOPE stops being a clinical workflow question and becomes a financial one. HOPE compliance is based on the timeliness of data submission: hospices must submit and have accepted at least 90% of their HOPE records within the 30-day deadline. Compliance is assessed on records with a target date in the calendar year, so HOPE records with target dates from January 1 to December 31, 2026 determine the FY 2028 Annual Payment Update (APU), and the cycle repeats each year.

Two details matter for system design. First, the requirement is submitted and accepted: CMS states that providers must verify submitted records were accepted. A record rejected at validation and corrected after day 30 is a late record. Second, the deadline is per record, so the threshold is a ratio across the whole year’s volume, which under HOPE is materially larger than under HIS.

The consequence of missing the threshold is set by statute. The Consolidated Appropriations Act, 2021 raised the reduction from 2 to 4 percentage points beginning with FY 2024. CMS applies the reduction only to the fiscal year involved, not cumulatively, but it can reduce the update below zero, meaning payment rates lower than the prior year’s. For a hospice operating on tight margins, one missed reporting year can turn an expected payment increase into a payment cut across the entire Medicare census for that year.

HQRP has two other components. Hospices must contract with a CMS-approved vendor for the CAHPS® Hospice Survey, with quarterly vendor submissions (newness and size exemptions are available), and administrative claims data is drawn automatically from Medicare billing, so hospices are automatically considered compliant for that component. HOPE is the component most exposed to a hospice’s own data infrastructure, because it depends on internal systems moving information correctly and on time.

Where Hospice Data Infrastructure Comes Under Pressure

Because HOPE compliance is defined by timeliness, threshold risk is fundamentally a data-operations risk. The patterns we see most often are consistent:

• No single timeline per patient. Election and admission dates live in the EHR, visit scheduling in a separate tool, discharge events in another workflow. No system holds the complete, authoritative list of which HOPE records are due, and when.
• Lagging, not leading, indicators. The iQIES timeliness report shows what has already happened. Teams that rely on it alone discover a shortfall only after the 30-day windows have closed.
• Open rejection loops. Records rejected at validation sit unworked because rejection feedback never returns to the clinician or coder who can fix it.
• Manual handoffs to the encoding vendor. Exports, re-keying, and file transfers add days to every record and introduce errors that surface only as rejections.
• No lineage. When a record is late, nobody can quickly trace which system, interface, or handoff introduced the delay, so the same failure repeats next month.
• Access and continuity gaps. A single PSO, informal iQIES role management, or undocumented interface ownership turns ordinary staff turnover into a compliance event.

None of these require more clinical training to fix. They require a healthcare data platform designed with governance, integration, and lineage as first-class requirements.

How to Evaluate Hospice Software and Data Partners for HOPE

Vendor selection is where this is either solved or quietly deferred. Leadership evaluating hospice data collection software and integration partners should ask for demonstrated capability, not a HOPE form:

• Current CMS specification alignment. Conformance with the latest HOPE data submission specifications and testing against CMS’s HOPE Validation Utility Tool (VUT) before records reach iQIES.
• Version agility. CMS has already published several revisions of the HOPE guidance manual and item sets since launch (through v1.03 on the CMS HOPE page). Ask how quickly specification changes reach production and how they are regression-tested.
• Closed-loop submission. Encoding and iQIES submission without manual re-keying, plus automated capture of accepted and rejected outcomes back into the operational workflow.
• Standards-based integration with existing EHR, billing, scheduling, and referral intake systems, so HOPE compliance does not require replacing tools clinicians already rely on.
• Deadline intelligence. Forward-looking visibility into records due, at risk, and rejected, not just a historical compliance percentage.
• Lineage and auditability. The ability to show, for any record, its source events, transformations, submission timestamp, and acceptance status. Learn more about audit-ready data lineage here,

A point solution that satisfies today’s item set but is not built for interoperability will need rework every time CMS revises HOPE, and CMS has stated that additional measures may follow.

Building an Interoperable Data Foundation for Hospice Quality Reporting

A CMS-ready foundation is not a new EHR module or a HOPE-specific workaround. It is three disciplines working together as one healthcare data integration platform. Skip any one and the other two stay exposed.

Data Governance: The Compliance Backbone

Data governance in healthcare turns “we have the data somewhere” into “we can show where it came from, who changed it, and when it moved.” For HOPE, that means named ownership of each item section across clinical, quality, and operations teams; documented data quality rules that run before submission, such as an HUV completion date falling outside its window, an admission date inconsistent with the election date, or a moderate or severe symptom impact with no follow-up visit recorded; role-based, minimum-necessary access to PHI consistent with HIPAA; and an audit trail that answers a reviewer’s question in minutes. Our Data Quality, Governance and Compliance services build this layer. We can explore this in a deeper manner as outlined in Data Governance and CMS Compliance Frameworks for Hospice Organizations.

Data Engineering and Integration: One Timeline Instead of Many Systems

Governance defines the rules; integration makes the data move. Our Data Engineering and Integration services connect EHR, scheduling, billing, and intake systems into a single governed pipeline built around four capabilities:

• Event-driven ingestion of elections, admissions, visits, and discharges as they occur, rather than in periodic batch exports.
• A HOPE timeline engine that derives each patient’s clinical windows (Admission, HUV1, HUV2, SFV) and each record’s 30-day submission deadline in Eastern time from source dates.
• Pre-submission validation against CMS specifications, so errors are fixed while the clock still allows it.
• Closed-loop reconciliation of submitted versus accepted records, feeding rejections back to the people who can correct them.

Underneath, data is organized in distinct raw, cleansed, and reporting-ready layers rather than one undifferentiated store, an approach we explain in Medallion Architecture Explained: Bronze, Silver, and Gold Layers for Healthcare Data. That layering is what makes lineage possible: once each record has a defined path from source event to iQIES acceptance, audit-ready data lineage that survives a CMS review becomes something a compliance officer can produce on request.

What good looks like: a daily operational view showing records due in the next seven days, records past day 20 and not yet submitted, rejections awaiting correction, follow-up visits due within 48 hours, and a rolling on-time rate against the 90% threshold. These are leading indicators; the iQIES report confirms the outcome.

Data Strategy: Sequencing the Foundation for What Comes Next

Governance and integration solve today’s HOPE problem. Strategy makes sure the same foundation supports what comes next: length-of-stay and census forecasting, staffing models that anticipate HUV and follow-up visit demand, and AI agents for intake, documentation support, and patient engagement. Our Data Strategy services sequence that roadmap so the foundation is engineered once, for CMS reporting now and for analytics and AI later. It is the same principle behind the Caregence™ platform: governed, healthcare-native data first, intelligence on top.

What New Quality Measures Will HOPE Data Support?

HOPE already carries HQRP measurement: CMS continues to collect the data for the Comprehensive Assessment at Admission measure (CBE #3235) through HOPE. Beyond that, CMS has finalized two HOPE-based quality measures: Timely Follow-up for Pain Impact and Timely Follow-up for Non-Pain Symptom Impact. Each captures the percentage of assessments with a symptom follow-up visit within two days after impact was assessed as moderate or severe. CMS states that two new process measures will be added to the HQRP using HOPE data in fall 2027, the start of FY 2028, and it already describes both measures in its iQIES quality measure report materials.

Two implications follow. First, these are measures of care timeliness, so the same timeline engine that protects submission deadlines should also track follow-up visit deadlines; one foundation serves both. Second, CMS has said patients and families will be better informed about the hospice they choose through public reporting of HOPE assessment-based measures. The data a hospice generates today is the dataset its referral partners and families will eventually see.

Why This Is a Foundation, Not a Fix

Hospice executives evaluating this space often ask whether it is a compliance project or an operational one. It is both. Treating it only as the former is how organizations end up building 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 what hospice leadership wants next: forecasts of length of stay and staffing needs that hold up in a board discussion, and AI agents that support clinical and administrative teams without adding compliance risk. Neither works on fragmented, ungoverned data. The foundation comes first because no other order holds up.

Frequently Asked Questions