Build, Integrate, or Reuse? An Architecture for HR1 Verification

HR1's work and community engagement requirements do not simply add a new eligibility condition to Medicaid. They require states to verify facts that live across a fragmented institutional landscape: employer payroll systems, self-employment records, educational institutions, volunteer organizations, workforce agencies, and caregiving arrangements. No single authoritative database resolves all of them. That means states have to make an architectural choice, and the choice they make now will define their maintenance burden, their exposure to vendor lock-in, and the experience residents have navigating the system for years.

Three models exist for handling this verification. They are not mutually exclusive, and in practice a mature state implementation will use all three. But the critical question is which model becomes the default for which type of evidence, because that decision sets the cost structure, the privacy footprint, and the resilience of the whole system.

Model One: Direct Data Matching Against Authoritative Sources

The first model connects state eligibility systems directly to authoritative data sources through bilateral integrations. The state sends a query; the source returns a match or a non-match. No document changes hands. When a match is returned, the case is resolved without requiring any action from the resident.

This is the most defensible model when it can be done. States already have data-sharing agreements with state wage records, the federal State Wage Interchange System (SWIS) [VERIFY: confirm current SWIS operational status under HR1 guidance], and in many cases workforce and unemployment agencies. When a resident's employer reports wages through the state's quarterly wage system, the eligibility worker does not need to ask for a pay stub. The record already exists in a trusted, government-maintained registry.

The limitations are real, though. Direct integration requires a bilateral agreement, a maintained API or file exchange, appropriate data use governance, and ongoing operations support on both ends. Integrating a single major employment data source might take six to eighteen months when procurement, legal review, and technical implementation are factored in. [VERIFY: typical state data integration timelines from implementation experience] Every new category of qualifying activity, whether it is volunteer work at a nonprofit, enrollment at a community college, or participation in a job training program, requires a new or extended integration. States with well-funded IT agencies can maintain a portfolio of these integrations. Many cannot, which creates coverage gaps that get filled by the second model.

Model Two: Document Submission and Manual or AI-Assisted Review

When a direct match cannot be established, the standard fallback is to ask the resident to submit documentation. A pay stub, a letter from an employer, enrollment verification from a school, or a written attestation of caregiving hours. The state reviews the document, makes a determination, and processes the case.

This model is universal. It handles cases that no automated integration can resolve, and it has been the backbone of Medicaid eligibility for decades. But it carries costs that compound as volume increases.

Document submission puts the burden entirely on the resident. Obtaining the right document, understanding what format the agency accepts, submitting it through a portal that may or may not work on a mobile phone, and then waiting for someone to review it are each a potential drop-off point. For residents who lack stable employment or who earn income through informal arrangements, the documentation itself may not exist in the form the agency expects.

On the agency side, document review creates a processing backlog. Manual review is slow and prone to inconsistency. AI-assisted document processing can reduce some of the burden by automating document classification, data extraction, and validity checking, but it introduces its own governance questions. [VERIFY: whether any states have deployed AI document processing for Medicaid work requirement verification specifically] Automated systems trained on document images can misread faded text, reject non-standard formats, or fail on documents from less common employers or institutions. Oversight requirements and error rates need to be defined before an automated process is used for eligibility decisions.

The deeper problem is data retention. Once a resident submits a pay stub, an enrollment letter, or a signed attestation, the agency has to store it, protect it, and eventually purge it according to records retention rules. Each document is a liability. A verification system that defaults to document submission as the primary pathway creates a growing repository of sensitive personal records that, in most cases, were collected only because the state lacked a better way to resolve the case.

Storing documents to verify eligibility is not a requirement of verification itself; it is a consequence of using documents as the primary evidence format when structured alternatives are available.

Model Three: Layered Interoperable Evidence

The third model uses a structured intermediate layer between direct database integration and unstructured document submission. Instead of asking the resident to submit a pay stub, the state (or the resident, depending on the program design) requests a verifiable credential from the authoritative source: a machine-readable, cryptographically signed assertion that the resident meets a specific condition as of a specific date.

This model depends on the issuing institution being able to generate such a credential. That capacity does not yet exist universally, but it is expanding. Federal agencies, state workforce systems, educational institutions participating in standards-based transcript exchange, and some large employers are increasingly capable of issuing structured electronic records. Where that capacity exists, verifiable credentials offer several advantages over both direct integration and document submission.

Unlike a bilateral API integration, a verifiable credential can be issued once and reused across multiple programs. A resident who obtains an employment verification credential from their employer's HR system can present it for Medicaid work requirement verification, for SNAP, for housing assistance, and for any other program that accepts the same credential format. The state does not need to build a new integration for each program. The issuer does not need to respond to queries from multiple agencies. And the resident does not have to request documentation multiple times for the same underlying fact.

Credential reuse across government services changes the economics of verification at scale, but it requires issuing institutions to adopt standards that most have not yet implemented. That is a governance and adoption challenge, not a technical one.

The privacy properties are also materially different. A verifiable credential can be designed to reveal only the fact that is needed for the specific determination, rather than the full document that contains it. An employment verification does not need to include the resident's salary, supervisor's name, or job classification to establish that they worked twenty hours in a given week. Selective disclosure allows the credential to be scoped to the specific claim the program needs, reducing the data the agency collects to what is proportionate to the determination.

Comparing the Models Across What Actually Matters

The three models do not sort neatly by quality. They sort by what they are suited for.

Direct integration wins when the authoritative source is a government system with existing data-sharing authority, when the match rate is high, and when the integration can be maintained without constant renegotiation. Quarterly wage records are a good candidate. A federal employment database with a stable API and a broad coverage population is a good candidate. A nonprofit volunteer program's internal spreadsheet is not.

Document submission remains necessary for anything that cannot be resolved by matching or by a structured credential. A resident who works informally, who cares for a disabled family member, or who participates in a religious organization's community service program has limited options for producing a machine-verifiable record. Document review is the right fallback for these cases. The goal is to make it the fallback, not the default.

Interoperable verifiable evidence makes the most sense where a credentialing institution already exists (an employer with an HR platform, a school with a student information system, a workforce agency with an electronic records infrastructure) but where building a direct state-to-institution API integration is disproportionate to the scale. Instead of asking a state IT team to maintain separate integrations with a hundred community colleges and fifty major employers, the state can publish a policy that it accepts credentials in a given format from any institution that chooses to issue them. The issuer set grows without requiring a new integration for each one.

The comparison across dimensions the brief specifies is worth making explicit:

Time to onboard a new data source. Direct integration requires bilateral agreement, procurement, and technical implementation. That timeline commonly runs to twelve months or more for a new source. A verifiable credential model requires the issuer to implement a standards-compliant credential issuer; if they already have infrastructure for it, onboarding can be days. Document submission requires no technical onboarding but creates manual processing volume instead.

Verification confidence. Direct integration against a government wage system is high confidence by design, assuming the integration is current and the data is accurate. A cryptographically signed verifiable credential provides strong integrity guarantees, the assurance depends on the issuing institution's own identity proofing and record accuracy. Document submission confidence depends on fraud controls and reviewer judgment.

User burden. Residents experience the least friction in the direct matching model, where the case may be resolved without any interaction on their part. Verifiable credentials require the resident to request and present the credential, which is more involved than passive matching but substantially less burdensome than locating, obtaining, and submitting a physical or scanned document. Document submission places the highest burden on the resident and has the most failure points.

Data retention. Direct integration retains a match record but not a copy of the underlying data. Verifiable credentials, when implemented well, allow the state to retain a cryptographic proof of the verification event without retaining the credential itself. Document submission generates a persistent copy of the submitted document that must be stored, secured, and eventually purged. The data liability accumulates over time.

Cross-program reuse. Direct integrations are typically built for a specific program and require renegotiation for each new use. A verifiable credential presented by the resident can, in principle, be reused across programs without the issuer being involved in each transaction. Document copies are typically scoped to the submission context and may be unusable in another program without resubmission.

Long-term maintenance. Direct integrations break when source systems change, when data-sharing agreements expire, or when source institutions modify their APIs or file formats. Each integration is a dependency. A credential format approach standardizes the contract between issuer and verifier, which means the state's verification system does not depend on the specific technical implementation of each issuing institution. Document review workflows require staff, training, and quality controls that scale with volume.

The Architectural Question Is About Defaults

States implementing HR1 verification will use all three models. The policy context requires it: some evidence will be in government databases, some will come from institutions capable of issuing structured credentials, and some will only be available as documents.

The architectural decision that matters is where each type of evidence sits in the priority order. A state that defaults to document submission for all unresolved cases, and treats direct integration and structured credentials as specialized supplements, will end up with high staff costs, significant data retention liability, and a resident experience defined by friction. A state that inverts that hierarchy, using direct matching first, structured credentials second, and document submission as the genuine last resort, builds a system that scales and that does not accumulate unnecessary data.

Getting to that inverted hierarchy requires decisions at each layer: which sources warrant direct integration, which credentialing institutions to encourage or require to participate in a standards-based credential ecosystem, and what the fallback review process looks like for cases that cannot be resolved by either. It also requires governance: who decides which credential formats are accepted, what assurance level is required for which evidence type, and how the trust model is maintained as issuers change.

Interoperability in government digital services is not primarily a technical question at this stage; it is a governance question about which institutions participate in a shared trust model and under what rules.

Where SpruceID Fits

SpruceID builds verification infrastructure for exactly this architecture. Our work spans direct credential verification, standards-based credential issuance and verification, and document intake processing with structured data extraction. We have worked with state and federal agencies on the governance questions, the standards choices, and the trust framework design that an interoperable evidence model requires.

In active conversations with states approaching HR1 implementation, the question we hear most often is not which technology to buy but how to sequence the work: what to prioritize in the first phase, what to design for extensibility, and how to avoid building point-to-point integrations that will create maintenance liability before the credential ecosystem matures. Those are architecture questions, and they are worth working through before procurement decisions lock in a model that is hard to change.

The verification infrastructure challenge underlying Medicaid work requirements is not solved by any single integration or product. It is solved by an architecture that sequences evidence sources correctly and preserves the ability to add new ones without rebuilding the core system.

If your agency or integration team is working through the architecture decisions for HR1 verification, SpruceID offers a structured session to map the evidence landscape, evaluate the three models against your specific state context, and identify the sequencing that makes the most sense. Contact us to request an HR1 verification architecture session.

Medicaid and SNAP verification can share evidence infrastructure even when their eligibility rules differ, which means the architecture decisions made for HR1 compliance have implications beyond a single program. That is worth factoring in when the foundation is being designed.

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.