What HEDIS is, and why the patient-level file is where submissions break

HEDIS, the Healthcare Effectiveness Data and Information Set, is the set of quality measures that health plans in the United States use to report how well their members are cared for. The National Committee for Quality Assurance (NCQA) develops and maintains it [1]. A measure asks a concrete question: of the women in the right age range, how many had a breast cancer screening; of the members with hypertension, how many have it under control; of the members discharged from a psychiatric hospitalization, how many had a follow-up visit within seven or thirty days.

CMS has required Medicare Advantage organizations to collect and report HEDIS measures since 1998 [2]. Several of them feed the Medicare Part C Star Ratings [3], and Star Ratings feed quality bonus payments, so for a Medicare Advantage plan HEDIS is not just a compliance exercise. (How Stars move a plan's margin is covered in Why insurers are leaving Medicare Advantage; what happens inside a plan once it leaves a market is in Exiting a Medicare Advantage market is a transition project, and the MA County Viability Check screens whether a county still holds up.)

Two submissions, one set of numbers

A plan reports HEDIS twice. The summary-level results, the numerator and denominator of each measure, go to NCQA through its Interactive Data Submission System (IDSS). Behind those summaries, CMS collects the patient-level detail (PLD): one row per member that shows which measures that member counted toward [2].

The two have to agree. The CMS specification is explicit that the sum of each PLD field should equal the numerator or denominator entered in IDSS for that measure [4]. The PLD file is the evidence behind the summary.

For measurement year (MY) 2025, reported in 2026, there are two files [2][4]:

• File 1 covers every enrollee in the contract. Each row is exactly 482 characters long and holds 193 fields: identity and demographics (MBI, name, city, state, ZIP, sex, birth date, plan ID, SNP type, member months), then a denominator and one or more numerators for each measure, such as COL-E, BCS-E, CBP, FUH, TRC and KED.
• File 2 covers only Plan All-Cause Readmissions (PCR). Each row is 245 characters and describes an index hospital stay: admission and discharge dates, age, whether there was a readmission, and the risk-adjustment weights.

Both files open with a header row: a tilde, the CMS contract number, the organization name and the NCQA submission ID.

A format with no room for error

These are fixed-width text files. There are no delimiters; a field is defined only by its column positions. That makes the rules mechanical and unforgiving [4]:

• Numeric fields are right-justified and blank-filled on the left. " 3" is valid, "3 " is not.
• Text fields are left-justified and blank-filled on the right. As of MY 2025, double quotes are no longer allowed in last name, first name or city [4].
• Logical fields accept only 0 or 1. A 2 in a column that only takes 0 or 1 is an error, even if the member really did qualify twice.
• The MBI must follow the Medicare Beneficiary Identifier format: 11 upper-case characters, no dashes or spaces, no letters S, L, O, I, B or Z.
• Weights in File 2 fill all 12 columns as a decimal, padded with zeros: 0.1234500000.
• Every row must be exactly the specified length. One extra space at the end of a line rejects the file.

The layout also changes every year. For MY 2025, CMS removed nine measures from File 1, among them AMM, FUA, HDO and SNS-E, and changed age bands in BCS-E and AIS-E [4]. A pipeline that produced a valid file last year can be off by a few columns this year without anyone touching it.

How CMS validates the files

Plans send the files through CMS's file transfer channels (Gentran, MFT Internet or Connect:Direct), not through a web upload [2]. Every file then goes through two tiers of validation [2]:

1. Tier 1 checks the file name against the naming convention. A file that fails is not processed at all.
2. Tier 2 checks every character of every row against the layout. If any check fails, the file is marked "Failed" and an error report is emailed to the plan's point of contact.

There is no partial acceptance. All errors must be fixed and the full file resubmitted, as many times as needed [2]. CMS also rejects files whose contract number does not match between the file name and the header, or whose submission ID does not match its list.

The windows are short. For MY 2025, the dry run ran from April 1 to April 21, 2026, and the annual submission from May 22 to June 15, 2026 [2]. Each correction is one more round trip in that window: generate the file, transfer it, wait for the email, read the error log, fix, regenerate.

Why Nimbotools built a validator

Most of what Tier 2 rejects is mechanical: a misaligned column, a left-justified number, a 2 where only 0 or 1 is allowed, a row one character short. None of that needs CMS to find it. It can be checked against the published layout before the file leaves the building.

The obstacle is that the file is protected health information. It carries names, MBIs and birth dates for every member, so pasting it into an online tool is not an option, and a quick script tends to cover the fields someone remembered to check rather than all 193.

So the HEDIS PLD Validator runs entirely in the browser. The file is read locally and never uploaded. It checks:

• the header: tilde, contract number, organization name (with the (PCR prefix in File 2) and submission ID justification;
• the length of every row, 482 or 245;
• every field of File 1 and File 2 against the MY 2025 layout, with the column range and line number of each error, in the same structure as the CMS error log;
• warnings CMS does not raise but that point to a logic problem: a numerator larger than its denominator, a duplicate MBI, an admission after its discharge, a discharge outside the measurement year;
• the file name against the Gentran/MFT and Connect:Direct conventions (Tier 1);
• the totals of every measure field, to compare against what was entered in IDSS.

What it does not do: it cannot confirm that your submission ID or contract is on the CMS submission list, and it does not know whether the clinical logic behind each 0 or 1 is right. It checks that the file is well formed, not that the measures were calculated correctly.

We checked the tool's layout field by field against the official MY 2025 specifications (version 2.0, November 2025). The MY 2025 window closed in June 2026; the tool is useful now for testing pipelines and reviewing past files, and will be updated when CMS publishes the MY 2026 layout.

Sources

1. NCQA, "HEDIS and Performance Measurement." https://www.ncqa.org/hedis/
2. CMS, "HEDIS MY 2025 Patient-Level Data File Submission Instructions," version 2.0. Published under "HEDIS Patient Level Data Submission Instructions" on the Medicare Advantage/Part D Contract and Enrollment Data page. https://www.cms.gov/data-research/statistics-trends-and-reports/medicare-advantagepart-d-contract-and-enrollment-data
3. CMS, "Part C and D Performance Data" (Star Ratings and technical notes). https://www.cms.gov/medicare/health-drug-plans/part-c-d-performance-data
4. CMS, "HEDIS MY 2025 Patient-Level Data File Specifications, File 1 of 2" and "File 2 of 2," version 2.0, November 24, 2025, with the File 1 and File 2 layouts. Same CMS page as [2].

HEDIS® is a registered trademark of the National Committee for Quality Assurance (NCQA). Nimbotools is not affiliated with CMS or NCQA.