The SNPE Universe: How CMS Tests HRA Timeliness Across Your Entire Enrollment File
Sevana Health Team
July 19, 2026
Key Takeaways
- •SNPE is the SNPCC census table, and two of the protocol's standards are tested across the full file rather than against a sample.
- •Standard 1.1 tests the initial HRA at 90 days; Standard 1.2 tests the annual reassessment at 365 days. Their populations differ on purpose.
- •The annual test has no enrollment-date limit, so it keeps surfacing members the initial test aged out of. A lower annual rate is not, by itself, a calculation error.
- •None in Column K is the failed-timeliness marker, not a blank. EXC-10 suppresses a date without suspending the reassessment obligation.
- •Most self-computed SNPE rates fail on denominators, not date math. Every row should land in exactly one bucket per test.
If your Special Needs Plan is selected for a CMS Program Audit, the SNPCC protocol is in scope, and the first thing CMS will ask for is Universe Table 1: Special Needs Plans Enrollees, or SNPE. It is the census table. Every SNP enrollee appears in it, one row per member, and two of the protocol's compliance standards are tested directly against the full file rather than against a sample. That combination, full population plus automated testing, makes SNPE the table where assessment gaps have nowhere to hide.
This post walks through what SNPE contains, exactly how the two universe-level timeliness tests work, why their populations deliberately differ, and the record layout details that decide whether a row reads as compliant, late, or invalid.
What SNPE Is
SNPE is a snapshot of your SNP enrollment as of the date the universe is pulled, laid out in columns A through N, per the record layout CMS publishes in the CMS-10717 Program Audit Protocols package (ZIP). Columns A through F carry member identity: name, Medicare Beneficiary Identifier, contract, plan benefit package, and plan type (D-SNP, C-SNP, or I-SNP). The columns that matter for timeliness are the dates:
| Column | Field | Format |
|---|---|---|
| G | Enrollment Effective Date | CCYY/MM/DD |
| I | Date of Most Recent HRA | CCYY/MM/DD or None |
| J | Date of Previous HRA | CCYY/MM/DD or None |
| K | Date Initial HRA Completed | CCYY/MM/DD, None, or EXC-10 |
| M | Date of Most Recent ICP | CCYY/MM/DD or None |
Two structural facts about this layout shape everything downstream. First, the file carries only the two most recent HRA dates plus the initial one. A member's deeper assessment history does not exist in the universe, so every judgment has to be provable from those three columns. Second, Column M holds only the most recent individualized care plan date. There is no initial-ICP column, which limits what anyone, including CMS, can conclude about care plan timing from this table alone.
The Two Tests CMS Runs Across the Whole File
The SNPCC protocol's Standard 1.1 and Standard 1.2 are timeliness tests conducted at the universe level, citing 42 CFR 422.101(f) and 422.152(g). The rest of the protocol's standards are reviewed through case-level documentation on sampled cases; those obligations remain fully in force, but they are not computed across the file. The two that are:
Standard 1.1, the Initial HRA test
The initial health risk assessment must be completed within 90 days, before or after, of the enrollee's effective date of enrollment. The test population is specific: enrollees continuously enrolled for at least 90 days, whose enrollment effective dates fall within 12 months of the audit engagement letter.
Standard 1.2, the Annual HRA test
The annual reassessment must be completed within 365 days of the prior HRA completion date, or of the date of enrollment if no initial HRA was conducted. The population: enrollees continuously enrolled for 365 days or more, plus new enrollees who missed the deadline to complete an initial HRA. Note what is absent: an enrollment-date limit.
The Two Populations Differ by Design, and the Design Is the Point
Read those two population definitions together and a deliberate mechanism appears. A member who never receives any HRA ages out of the Initial HRA test 12 months after enrollment. But the Annual HRA test picks that member up through its enrollment-date anchor and keeps holding them. Enrolled six years ago with no assessment on record? Standard 1.1 stopped looking at that member five years ago. Standard 1.2 is still looking, measuring from the enrollment date because no initial HRA was ever conducted.
The practical consequence: the two tests usually produce different rates, and that is not a data problem. The Initial HRA test measures how your intake process performed over the last year. The Annual HRA test reaches wider, covering long-tenured members alongside newer enrollees who missed an initial assessment. Plans reviewing their own universes are often surprised that the annual figure reads lower than the initial one. A lower annual rate is not, by itself, evidence of a calculation error. It is where the protocol puts the wider population.
The handoff between the tests is also precise at the boundary. "At least 90 days" is inclusive, and the universe speaks as of its pull date: if a member's 90-day window has fully elapsed within the file's coverage and Column K reads None, that is a testable miss, not an open item. The same day a member becomes measurable under Standard 1.1, a missed initial assessment makes them eligible for Standard 1.2's second population branch. The tests interlock; nobody falls between them.
The Record Layout Does the Talking
Most SNPE findings trace back to a handful of layout rules that are easy to miss on first read.
| Field | What goes wrong | Impact |
|---|---|---|
| K = None | Teams validate only populated dates and treat None as neutral. The layout instructs plans to enter None when no HRA was completed within 90 days before or after enrollment, so None is itself the failed-timeliness marker. | The actual Standard 1.1 failures pass through review untested. |
| K = EXC-10 | EXC-10 means the initial HRA was completed more than 10 years ago and the layout suppresses the date. It is defined for Column K only. Teams sometimes read it as an exclusion from HRA requirements. | The member's annual reassessment obligation is judged normally. An EXC-10 member whose Columns I and J are also empty is among the most overdue reassessments in the file, not an exempt case. |
| I and J | Only the two most recent HRA dates exist. A compliant recent pair can sit on top of a gap that occurred years earlier and is no longer visible. | The current obligation is what remains testable: a most recent HRA more than 365 days old means the next reassessment is due regardless of how clean the recorded pair looks. |
| Sentinel values | The SNPE layout permits the literal value None (plus EXC-10 in Column K). Values like NA belong to other SNPCC tables. Mixed sentinels usually mean the extract logic was shared across tables. | Invalid values in date columns read as layout errors. Under the 2026 audit framework, errors that prevent CMS from validating or testing the universe can contribute to an Invalid Data Submission determination. |
| M | Column M is the most recent ICP, not the initial one. A date that falls after a care planning window may be a later revision of a plan that was originally timely. | Care plan timing conclusions drawn from this column alone overreach what the file can prove. Honest tooling discloses these cases rather than scoring them. |
One more expectation worth knowing, and it lands after the universe is already submitted. Both timeliness tests carry an impact analysis request. For any enrollee flagged as not having a timely initial HRA, and for any enrollee found to have an untimely annual reassessment, CMS requests a row in Table 2IA, the HRA Timeliness Impact Analysis (HRAT-IA), quantifying the outreach the plan made to complete the assessment.
Three details about Table 2IA matter operationally. It belongs to the audit field work phase, not to the 15-business-day universe package, and it is due within 10 business days of the request. Its scope is bounded to enrollees who did not receive a timely initial or annual HRA within the 12-month period prior to the engagement letter date, so the annual test itself has no enrollment-date limit but the impact analysis attached to it does. And submissions that do not strictly adhere to the record layout are rejected, which means the outreach evidence has to be assembled in the layout's own terms rather than pulled ad hoc from case notes under deadline. Within the protocol's 12-month review period, your untimely SNPE population and your HRAT-IA submission should reconcile, subject to CMS validation. A material discrepancy is worth running down before submission rather than explaining during field work.
Getting the Denominators Right
When plans compute their own SNPE rates ahead of an audit, the errors are rarely in the date math. They are in the populations.
The common failure is computing one rate across every enrollee in the file. That blends members the tests would never examine (enrolled 30 days, window still open) with members the tests would examine, and it merges two tests CMS evaluates separately. A rate that cannot be reproduced from a defined population is worse than no rate, because it anchors leadership on a number the audit will contradict.
The discipline that holds up: every row in the file should land in exactly one place per test. In the test's population. Outside it, with a stated reason: enrolled too recently, enrolled outside the 12-month lookback, window still open. Or unmeasurable, because a date column holds something the layout does not permit, disclosed rather than silently dropped. If those categories sum to your row count, your number will survive scrutiny. If they do not, you have found something to run down before CMS asks about it.
This is the kind of reconciliation that is tedious in a spreadsheet and mechanical in purpose-built tooling. Sevana's CMS Universe Scrubber validates SNPE against the record layout, runs the Standard 1.1 and 1.2 populations and clocks as the protocol defines them, and accounts for every row in the file, including the ones that cannot be measured and why. It covers all five CMS audit protocols: CMS publishes the field-level record layout specs via OMB-approved form CMS-10717, and our platform translates those specs into 1,600+ discrete validation rules across them.
The Honest Summary
SNPE rewards plans that read the record layout as carefully as the regulation. The two universe-level tests are not complicated individually: 90 days for the initial assessment, 365 for the annual one. What catches plans is the machinery around them. None is a failed-timeliness marker, not a blank. EXC-10 suppresses a date without suspending an obligation. Standard 1.2 has no enrollment-date limit, so it keeps surfacing unresolved reassessment gaps that the initial test aged out of, though because SNPE carries only the most recent and previous HRA dates, it does not reconstruct every historical lapse. The file only proves what its fourteen columns can carry, which means a defensible review discloses what it cannot measure instead of guessing.
If you run SNPs and have not pulled a practice SNPE universe against the current protocol, that is the single most informative afternoon your compliance team can spend before an engagement letter arrives. For the broader protocol context, our SNPCC compliance guide covers the standards beyond the two tested at the universe level, and I-SNP compliance walks through what this looks like for institutional plans. Either way, know your annual HRA number before CMS computes it for you.
Scope note. This analysis measures protocol-aligned HRA timeliness using the fields submitted in SNPE. It does not independently validate underlying source-system documentation and does not constitute a CMS compliance determination. CMS cautions that its audit protocols and record layouts should not be used on their own to interpret policy; see the CMS Program Audits page.
Reviewed against the CMS-10717 SNPCC Program Audit Protocol and Data Request, July 2026.
Frequently Asked Questions
What is the SNPE universe?
SNPE (Special Needs Plans Enrollees) is Universe Table 1 of the CMS SNPCC audit protocol. It is a census file: one row per SNP enrollee as of the universe pull date, laid out in columns A through N, carrying member identity, contract and plan benefit package, plan type, and the health risk assessment and individualized care plan dates that the protocol tests against.
Why do the Standard 1.1 and Standard 1.2 populations differ?
Standard 1.1 (initial HRA) is limited to enrollees whose enrollment effective dates fall within 12 months of the audit engagement letter, so a member who never received an assessment ages out of it after a year. Standard 1.2 (annual HRA) has no enrollment-date limit and measures from the enrollment date when no initial HRA was conducted, so it continues to hold that member indefinitely. The initial test measures the last year of intake performance; the annual test carries the accumulated backlog.
What does EXC-10 mean in the SNPE universe?
EXC-10 is a sentinel value defined for Column K only. It indicates that the initial HRA was completed more than 10 years ago and the record layout suppresses the actual date. It is not an exclusion from HRA requirements. An EXC-10 member is still subject to annual reassessment, and if Columns I and J are also empty, that member is among the most overdue reassessments in the file.
Can care plan timeliness be judged from the SNPE universe alone?
Only partially. Column M holds the date of the most recent individualized care plan, and the layout carries no initial-ICP column. A date that falls after a care planning window may be a later revision of a plan that was originally timely. Conclusions about initial care plan timing drawn from Column M alone overreach what the file can prove, which is why a defensible review discloses those cases rather than scoring them.
Is Table 2IA (HRAT-IA) part of the SNPCC universe submission?
No. Table 2IA, the HRA Timeliness Impact Analysis, is an impact analysis record layout requested during the audit field work phase, not part of the universe package due 15 business days from the engagement letter. CMS requests it for enrollees identified as not having a timely initial or annual HRA, to quantify the outreach the plan made. Impact analyses are due within 10 business days of the request, and submissions that do not strictly adhere to the record layout are rejected.
How should a plan calculate its own SNPE compliance rates?
Separately, and from defined populations. Compute the Standard 1.1 rate over enrollees continuously enrolled at least 90 days whose enrollment effective dates fall within the 12-month lookback, and the Standard 1.2 rate over enrollees continuously enrolled 365 days or more plus new enrollees who missed the initial HRA deadline. Every row in the file should land in exactly one bucket per test: in the population, outside it with a stated reason, or unmeasurable because a date column holds a value the layout does not permit.
Know Your SNPE Numbers First
See what row-level validation catches in a SNPE file, with every row accounted for, including the ones that cannot be measured.