Integrated Eligibility Systems for Medicaid and SNAP: Why a Determination You Cannot Explain Is a Determination You Will Lose

The hearing where the system cannot explain itself

A hearing officer, a claimant, and an eligibility worker with a printout. The household was found ineligible for food assistance. The claimant says her hours were cut in March and she reported it. The worker's screen shows a countable income figure. Nobody in the room can say how that figure was constructed: which pay stubs were counted, over what period, with what conversion factor, against which deduction set, under the rules in force on the date of the determination rather than the rules in force today.

That gap is the central defect in most eligibility systems, and it is not a reporting gap. It is an architectural one. The system was built to produce an answer, not to produce an explanation, and the explanation is the legal product. Every determination in this domain is appealable, the burden of showing the calculation sits with the agency, and the rules changed at least twice since the determination was made.

The incumbents in this market, Merative Curam, Conduent, Deloitte and increasingly Salesforce Public Sector Solutions, all know this. The reason it stays unsolved is that policy logic in these systems tends to be spread across configuration, code and interface behavior, so no single artifact represents what the rule was on a Tuesday in March.

Problem 1: rules have to be versioned by effective date and replayable

Eligibility policy changes mid year. A legislature raises an asset limit, a federal adjustment moves the standard deduction, a waiver expires, a disaster declaration triggers temporary rules for one region. Each of those has an effective date, and the system has to apply the rule in force for the period being determined, not the current one.

Systems that store rules as configuration fields overwritten on update lose their own history. A redetermination for a past period then computes with today's numbers, which produces overpayment findings that are not real and appeal losses that are.

What a properly built rules service does: hold every rule as a versioned artifact with effective dates, evaluate against the period under determination, and emit a structured trace alongside the result. The trace names each rule applied, the values it consumed and the source of every value, so the worker screen and the hearing packet are generated from the same evidence. This also has an unglamorous benefit that agency directors care about more: when policy changes, you change one versioned artifact and you can prove what the change did by replaying a sample of real cases against both versions before it goes live.

Problem 2: one household, four programs, four definitions of household

A single application can touch Medicaid, food assistance, cash assistance and child care subsidy. Medicaid for most adults and children uses a tax based household construction with its own income methodology, while food assistance uses who purchases and prepares food together, and child care subsidy uses its own definition again. The same three people can be one household in one program and two in another, with different countable income in each.

Workers resolve this by knowing it, which means the knowledge lives in tenured staff and evaporates when they retire. Systems resolve it badly by forcing one household model and applying adjustments, which is where the subtle errors that show up in quality control samples come from.

What a custom build does: model the person and the relationships once, then let each program construct its own household view from that graph according to its own rules. Income is stored as evidence, meaning a pay stub with an amount, a date, a frequency and a source, and each program converts it under its own methodology rather than sharing a single countable income field. It is more work to build and it is the only design that survives a quality control review.

Problem 3: renewals are where coverage is lost for procedural reasons

Federal rules require states to attempt a Medicaid renewal using information already available before asking the enrollee for anything. When ex parte renewal works, the household never sees a form. When it does not, a packet goes out, it is missed, and a person who is still eligible loses coverage for a procedural reason. The 2023 unwinding of the continuous enrollment condition made this visible at national scale: CMS identified states running ex parte renewals at the household level rather than the individual level, which required pauses in procedural terminations and reinstatements of people who should never have been disenrolled.

That failure was not a policy misunderstanding. It was a data model that treated the case as the unit when the rule operates on the individual.

What a build worth funding does: run the ex parte attempt as an automated batch against every data source you have agreements for, per individual, and record for each person which sources were checked, what they returned and why the attempt succeeded or failed. Where it fails, the request that goes to the household asks only for what is missing rather than restarting the whole application. Where it succeeds, the renewal completes without human touch. The measurable outcome is the share of renewals completed ex parte, and it is the single number worth designing this component around.

Problem 4: the notice is the legal product, and most notices are unreadable

Adequate and timely notice is a due process requirement, and the notice is also the artifact a hearing officer reads first. Most agency notices fail on both counts: they cite a regulation, state a conclusion, and leave the recipient unable to tell what to do about it. Then the call center absorbs the confusion.

What a custom notice engine does: generate from the same determination trace that produced the decision, so the reasons in the letter are the reasons in the system. Content is templated by notice type with plain language, translated into the languages your population actually speaks rather than the two you have always used, and produced in accessible formats. Every notice generated is archived exactly as sent, with its delivery record, because the question at hearing is frequently not what you decided but whether the person was told properly and when. Correspondence quality is one of the cheapest interventions available and it reduces both hearings and calls.

Problem 5: verification and documents drown the office

Processing standards are real and short. Expedited food assistance runs on a seven day clock, normal applications on thirty days, and every day spent waiting for a pay stub is a day off that clock. Meanwhile paper arrives by mail, by fax, by drop box, by phone photo and through a portal, and matching a document to the right case and the right requirement is manual work performed by people who could be determining eligibility.

What a custom build does: verify electronically first, from the federal data services hub, state wage records, and whatever employment verification agreements exist, so most requirements clear before anyone asks the household. For what remains, classify the incoming document, extract the values, match it to the open verification requirement and route the exceptions. This is one of the genuinely appropriate uses of document extraction models in government: not to make a decision, but to file a pay stub against the right case and read the gross amounts so a human confirms rather than keys. The determination stays with the worker and with the rules service.

What this costs and how long it takes

Across Digital Heroes delivery experience, a modular component in this domain runs $200,000 to $600,000 over 6 to 12 months. That covers a versioned rules and determination trace service, or ex parte renewal automation with source by source logging, or a notice generation and archive engine, or document intake with verification matching, integrated against the system of record you already run.

What drives the number:

• Program count. Medicaid alone is one shape. Medicaid plus food assistance plus cash plus child care is four rule sets and four household constructions.
• Federal tax information. If the component touches data covered by IRS Publication 1075, the environment, staffing and logging controls become a security program with its own timeline.
• Data source agreements. The engineering to consume a wage interface is small. Getting the agreement, the test environment and the production credentials is not, and it is rarely on the developer's critical path chart.
• Certification. If the work sits inside a Medicaid eligibility program, CMS streamlined modular certification shapes the outcomes you have to evidence, and that changes what you build, not just what you document.
• Language and accessibility obligations, which for public benefits are broader than a typical government portal and should be scoped from the first screen.

Build versus buy

Do not replace the integrated eligibility system with a custom build. The program risk is enormous, the funding process alone runs longer than most software projects, and states that have tried it have made the national press for the wrong reasons.

Do build modules, because that is now the sanctioned architecture. The components with the best return are the ones where the incumbent's roadmap is slow and the policy is yours: the rules and explanation service, ex parte renewal, notices, and document handling. Salesforce Public Sector Solutions is a reasonable platform choice for worker facing workflow if your agency already runs on it, but treat the rules engine as a thing you own regardless of the platform, because that is where policy lives.

Buy nothing at all if your problem is workload distribution rather than software. Some of the offices we have assessed did not need a system, they needed the queueing and assignment logic changed, and that is a two week engagement rather than a two year one.

How to choose a developer for eligibility work

Ask them to explain how a determination made in March would be reproduced in October after the rules changed twice. If the answer does not involve effective dated rule versions and replay, they will build you a system that loses hearings.

Ask how they would model a household. The correct answer is that they would not: they would model people and relationships, then construct household views per program. Anyone who proposes one household record is about to recreate the ex parte failure that CMS flagged nationally.

Ask what they will do with the determination trace. It should drive the worker screen, the notice and the hearing packet from one source. If those are three separate outputs assembled separately, they will disagree, and the one that disagrees is the one a hearing officer will read.

Ask who owns the code, the rules artifacts and the environments, in writing before kickoff. Policy logic is public property and should never be locked inside a vendor's configuration. At Digital Heroes the agency owns the repository from the first commit, and on this kind of program we would tell you to walk away from anyone who treats that as negotiable.