HR1 Verification Readiness Checklist for State Medicaid Agencies

Pillar: Document Intake | Type: Canonical | Audience: Program Manager, Medicaid Implementation Leads, CIO Offices, Procurement Teams

Before a state can evaluate whether a given verification system is adequate for the One Big Beautiful Bill Act (HR1) community engagement requirements, it needs to map what it can already resolve, where the evidence gaps are, and what operational capabilities it lacks. The questions below are a diagnostic, not a prescription. Working through them in order gives implementation teams a clear picture of the problem they are actually trying to solve.

Start with what you can already verify

The first question is not "how do we verify work requirements?" but "how much of the population can we resolve without asking them to do anything?"

States should inventory every data source they can access automatically: the state wage record system, state unemployment insurance database, data available through the Public Assistance Reporting Information System (PARIS), employer payroll data available through the Work Number or similar services, and any state-level data-sharing agreements with workforce agencies, educational institutions, or vocational programs.

For each source, the key questions are:

• What is the freshness of the data? State quarterly wage records typically lag by one to two quarters, and the National Directory of New Hires (NDNH) can have up to a six-month lag. This creates a structural problem for monthly verification requirements.
• What percentage of the active Medicaid population appears in each source?
• What activities or exemptions does each source cover?

Running this inventory against a sample of the enrolled population before procurement begins will tell you more about your actual gap than any vendor demonstration.

Identify the population that will remain unresolved

No combination of automated data sources will resolve every case. Some beneficiaries work in industries with limited employer reporting. Others are exempt due to medical conditions, caregiving responsibilities, age, or geographic barriers, and the evidence supporting those exemptions often exists outside any government database. Gig workers, self-employed individuals, and students in non-traditional programs are systematically underrepresented in standard wage and employment records.

Estimating the unresolved population determines the operational scale of the fallback process. CMS's June 2026 interim final rule establishes that states must first attempt verification through available data sources, and permits self-attestation for activity compliance through 2027; beginning January 1, 2028, states must generally require documentation when reliable data is not available. The higher the residual percentage, the more significant the document intake workload becomes.

A verification gap is not the same as a verification failure. Someone who cannot be confirmed through an automated check may be fully compliant; the evidence simply is not in a connected system. The implementation architecture has to distinguish between "we have not found the evidence yet" and "the evidence does not exist."

Map the evidence, not just the data sources

Once you know which activities and exemptions cannot be resolved ex parte, map where the relevant evidence actually exists. For employment, the employer holds the authoritative record. For education, the institution. For medical exemptions, the treating provider. For caregiving, the evidence may be informal or institutional depending on the circumstances.

This mapping matters because the evidence type determines how it can be collected and what trust level it carries. A structured, signed record from an employer payroll system is different from a PDF pay stub, which is different from a photograph of a pay stub. A clinical summary from an EHR system is different from a letter on clinic letterhead. All may be acceptable under program rules, but they carry different fraud risk, different processing requirements, and different implications for document review staffing.

When verification operates on a monthly cycle rather than an annual one, the volume of documentation flowing through a state Medicaid agency increases by an order of magnitude. The document intake processes adequate for annual renewal cannot simply be scaled up.

Determine which sources can provide structured or signed data

Not all evidence has to arrive as a PDF. Increasingly, employers, institutions, and health systems can provide structured data or digitally signed records that a receiving system can verify cryptographically rather than through human review.

The relevant questions for each evidence source:

• Does the employer or institution have an API or data-sharing agreement that could provide structured records directly?
• Can they issue a digitally signed credential or attestation rather than an unstructured document?
• If digital issuance is possible, what standard does it use, and is there an interoperability framework for accepting credentials from multiple issuers?
• What governance or legal agreements are needed to receive data directly from employers or institutions?

Document intake automation is most valuable when the incoming data carries structural integrity. Verifiable digital credentials, formatted to open standards such as the W3C Verifiable Credentials Data Model 2.0, allow a state to confirm the issuer's identity cryptographically and verify that the record has not been altered since it was signed, without building a point-to-point integration with every employer or institution in the state.

Establish how issuer trust will work

Structured and signed data only helps if the receiving system can evaluate whether the signer is a trustworthy source. For employment evidence, the question is whether a given employer's payroll records are authoritative. For educational records, whether the issuing institution is accredited. For medical exemptions, whether the certifying provider is licensed.

A cryptographic signature ties a record to a specific key held by a specific issuer. But the technical verification of a signature is not the same as a policy determination that the signer is an authorized source for the claim. A state needs to define, before the verification system goes live, what categories of issuers it will recognize for each evidence type and how it will maintain that list as institutions change.

This is a governance question, not only a technical one. States that treat it purely as a technology procurement decision tend to build systems that can cryptographically verify records but cannot reliably determine which records should be accepted as authoritative.

Define the fallback process for electronic verification failures

Every verification system will fail for some percentage of cases. The key architecture questions for the fallback:

• What channel does the beneficiary use to submit documentation?
• What document types are acceptable, and how will that list be communicated?
• What is the review queue process and staffing model?
• What is the timeline between submission and decision, and how does that interact with the monthly cycle?
• What happens if documentation is submitted but review is not complete before the coverage termination date?

The resident experience at the point of document submission matters considerably here. If the submission process is cumbersome or the status of a submission is opaque, the most significant cause of coverage loss may not be non-compliance but rather a process that beneficiaries cannot navigate successfully.

Determine whether evidence can be reused across cycles and programs

Can evidence verified in one month carry forward to subsequent months? Can evidence verified for Medicaid be reused for SNAP or CHIP?

For renewal cycles, the question is whether evidence with a known validity window, such as a full-time student enrollment record, can satisfy requirements for the enrollment period without being re-obtained monthly. Under the CMS interim final rule, HR1 requires eligibility redeterminations every six months for individuals subject to community engagement requirements, and states may verify compliance more frequently if they choose.

For cross-program reuse, the question is both technical and legal. Medicaid and SNAP operate under different statutory authority, but that does not mean the evidence itself must be obtained separately. A single employment record can be evaluated under each program's own rules. The architecture question is whether the state's system is built to reuse trusted evidence across program evaluations or whether it requires redundant documentation collection.

Building reuse capability into the initial architecture is considerably less expensive than retrofitting it later.

Address identity assurance early

Verifying an activity requires knowing whose activity is being verified. The person submitting or authorizing access to evidence needs to be the person the agency has on record.

For most HR1 verification scenarios, identity assurance at IAL2, as defined in NIST SP 800-63, is a reasonable baseline for remote digital interactions: identity proofing has confirmed the person's identity against an authoritative source, and subsequent authentication provides reasonable confidence that the same person is presenting. CMS has not specified a particular identity assurance level for HR1 electronic verification pathways in its interim final rule, but IAL2 aligns with broader federal practice for remote identity proofing in benefits contexts.

The identity infrastructure question also affects the fallback process. If a beneficiary calls a caseworker to resolve a verification failure, the caseworker needs to confirm identity before discussing account details. Ensuring that digital and phone-based pathways share a common identity foundation reduces both fraud risk and the likelihood that legitimate beneficiaries are turned away.

Plan the integration with your eligibility and enrollment platform

Verification results need to flow into the state's eligibility and enrollment (E&E) platform in a form it can act on. This frequently becomes a bottleneck when the verification system and the E&E platform use different data models, case identifiers, or concepts of what constitutes a resolved case.

Before procurement, document the specific integration points: how a verification result will be recorded in the case management system, what triggers a coverage action, what the audit trail looks like for each decision, and how caseworkers can review the evidence that supported an automated determination.

Verification systems can be procured and configured relatively quickly; changes to a legacy E&E platform typically cannot. If the E&E platform cannot accept structured verification results, the operational benefit of a sophisticated verification system is limited. States may need to sequence implementation to account for platform modernization timelines.

Define the metrics before implementation begins

Without pre-defined success metrics, it is impossible to distinguish between a system correctly identifying non-compliant beneficiaries and one incorrectly disenrolling compliant beneficiaries at high rates.

The metrics that matter:

• Ex parte resolution rate by activity and exemption category
• Percentage of cases resolved without beneficiary contact
• Documentation submission rate and completion rate for the fallback pathway
• Average time from documentation submission to case resolution
• Rate of coverage actions reversed through fair hearings or appeals
• Coverage termination rate attributable to process failure rather than non-compliance

The last metric is particularly important. A high appeal reversal rate signals that the system is generating erroneous decisions. States should establish a baseline methodology for measuring this before the system processes its first case.

From checklist to architecture

The questions above are sequenced to surface what a state actually needs before it can evaluate technology options. States that have worked through them are in a position to write a meaningful procurement scope. States that begin with technology selection and work backward tend to acquire capabilities that do not match their actual gaps.

SpruceID works with agencies building verification infrastructure that can handle both automated and document-based pathways, with support for structured evidence formats, issuer trust frameworks, and integration with existing eligibility systems. If your team is working through the architecture questions above, we are glad to compare notes.

About SpruceID: SpruceID builds digital trust infrastructure for government. We help states and cities modernize identity, security, and service delivery — from digital wallets and SSO to fraud prevention and workflow optimization. Our standards-based technology and public-sector expertise ensure every project advances a more secure, interoperable, and citizen-centric digital future.