Bindinglaw

US · guidance

HOPE Guidance Manual v1.02, § 3.4

Validation of Records and Files

activein force · 2025-10-01 – presentcompiled-edition

The submission system is designed to monitor timeliness and ensure that the uploaded records conform to the

HOPE Data Submission Specifications. After uploading, the system will provide a success or failure

notification to indicate if the upload was successful. The following describes the validation, storage, and

reporting of records in a submission file.

3.4.1. Initial Submission Confirmation

After records are uploaded in a zip file, a success or failure notification will indicate if the upload was

successful. This notification only indicates if the upload was successful, not whether the patient records have

been processed. Upload failures can occur for several reasons, including an invalid zip file format, an empty zip

file, a virus found, or if the file size is over five megabytes.

3.4.2. Validation and Editing Process

After the records have been successfully uploaded, the View Report link will be enabled after the zip file has

been processed. The submitter can refresh their browser until the View Report link is enabled. The FVR is

automatically generated in the CMS system within 24 hours of the submission of a file and will verify

acceptance or rejection of records, as well as warnings and any fatal errors. Errors and warning messages

detailed in the FVR are explained further in the HOPE Error Message Reference Guide. Each time a user

submits a zip file of one or more HOPE records to CMS, three types of validation are performed:

• Fatal File Errors. The file structure is validated to ensure it follows the requirements outlined in the

HOPE Data Submission Specifications provided by CMS. The file is rejected by the system if the file

structure does not meet these requirements. Examples of fatal file errors include the following:

o The file is not a ZIP file.

o The records in the ZIP file cannot be extracted.

o The file cannot be read.

• The Submitter Final Validation Report will list any fatal file error(s). Files that are rejected must be

corrected and resubmitted.

• Fatal Record Errors. If the file structure is acceptable, then each HOPE record in the file is validated

individually for fatal record errors. These errors include, but are not limited to, the following:

o Out-of-range responses (for example, the valid responses for the item are 1, 2, and 3, and the

submitted value is 6).

o Inconsistent relationships between items, e.g., an inconsistent date pattern, such as the Patient’s

Birth Date (Item A0900) is later than the Admission Date (Item A0220).

o Duplicate records.

• Fatal record errors result in the rejection of individual records. The provider is informed of fatal record

error(s) on the FVR. Rejected records must be corrected and resubmitted, if appropriate based upon the

error displayed on the FVR (i.e., records that received the duplicate record error should not be

resubmitted to the CMS system as the record already exists in the CMS database).

• Warnings (Non-fatal Errors). The record is also validated for warnings (non-fatal errors). Warnings

include, but are not limited to, missing or questionable data of a non-critical nature or item consistency

errors of a non-critical nature. Examples of warnings include the following:

o Timing errors:

 Submission date is more than 30 days after the Admission Date (A0220) when A0250 = 1 (Admission).

o Record sequencing errors:

 An Admission record is submitted after a previous Admission record and there was no Discharge

record submitted in between.

 A record is submitted for a patient after a Discharge record with a Reason for Discharge (A2115)

equal to Expired (1) has been submitted.

 A HUV record is submitted before an Admission record.

All warnings (non-fatal errors) are reported to the provider in the FVR. The provider must evaluate each

warning to identify necessary corrective actions.

3.4.3. Record Storage

If there are any fatal record errors, the record will be rejected and will not be stored in the CMS system. If there

are no fatal record errors, the record is stored by CMS, even if the record has warnings (non-fatal errors).

History

HOPE Guidance Manual v1.02, effective October 1, 2025 (OMB control number 0938-1153).

Provenance

Source
cms.gov
Retrieved
2026-09-17
Edition
hope-v1.02
Content hash
fcb61299a811b0258a0b22b7f54378ac4b83a11680e709664819b45693941123
View the official source →

The link goes to the issuing authority’s own document — the one we read to produce this record. Where a source publishes whole titles rather than sections, your browser may need a moment to jump to the provision.

Unofficial copy of government-published law, reproduced from official sources with full provenance. Not an official publication; verify against official sources before relying on it in a filing. Records in the 'guidance' corpus, and only that corpus, are sub-regulatory (interpretive guidelines, survey procedures) and are not binding law. Validity bounds follow each jurisdiction's declared temporalBasis.

Coverage · API docs

Bindinglaw

Point-in-time US law with the receipt attached. Source URL, retrieval time, content hash, and validity dates on every answer.

curl api.binding.law/v1/law/coverage

© 2026 binding.law · a Jubal, Inc. productAttorneys and firms never pay. Ever.