Public Benefits Eligibility Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why do projects scope a rules engine that cannot explain itself?

Because the requirement is stated as accuracy and delivered as an answer. Everybody agrees the determination must be correct. Almost nobody writes down that it must also emit a structured trace naming each rule applied, the values it consumed and the source of every value, and if that is not a written requirement it will not be built.

The second cause is architectural drift. Policy logic ends up spread across configuration screens, application code and interface behaviour, so no single artefact represents what the rule was on a Tuesday in March. Each individual placement was reasonable at the time. The sum is a system with no authoritative statement of its own policy.

The third is that rules get stored as configuration fields that are overwritten on update. A legislature raises an asset limit, a federal adjustment moves a standard deduction, a waiver expires, a disaster declaration triggers temporary rules for one region. Each has an effective date, and a system that overwrites loses its own history. A redetermination for a past period then computes with current numbers, which produces overpayment findings that are not real and appeal losses that are.

The fix is to hold every rule as a versioned artefact with effective dates, evaluate against the period under determination rather than the present, and emit the trace alongside the result. That has an unglamorous benefit directors care about more than hearings: when policy changes you change one versioned artefact, and you can replay a sample of real cases against both versions before it goes live.

What goes wrong with case conversion and the household model?

The defining conversion mistake is forcing one household model. 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, 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 programme and two in another, with different countable income in each.

Systems that maintain a shared countable income field and adjust it per programme are where the subtle errors found in quality control samples come from. They are also close to impossible to unwind later, because every downstream calculation inherits the shared field.

Model the person and the relationships once, then let each programme construct its own household view from that graph under its own rules. Store income as evidence rather than as a computed number: a pay stub with an amount, a date, a frequency and a source, converted by each programme under its own methodology at determination time. It is more work to build and it is the only design that survives a quality control review.

Conversion has its own version of the same trap. Legacy case data will carry a household structure that reflects whatever the old system needed, and importing that structure directly imports the defect. Profile it first, reconstruct people and relationships from what the data actually supports, and mark anything you had to infer, because a worker at a hearing needs to know which facts came from the household and which came from a conversion assumption.

Why do data source interfaces break after launch?

Because the engineering was never the hard part. Consuming a wage interface is a small piece of work. Obtaining the agreement, the test environment and the production credentials is not, and it is rarely shown on a developer's critical path chart. Interfaces then break for institutional reasons rather than technical ones: an agreement lapses at renewal, a partner agency reorganises and the contact who approved the connection has gone, credentials rotate on a schedule nobody communicated.

The technical breakages are ordinary. A source changes a field layout. A batch window moves. A partner starts returning a new status code for a case type that used to return nothing. None of these announce themselves.

What survives is monitoring built for silence rather than error. A wage source that stops responding looks exactly like a month where nobody had wages, and that misreading directly causes wrongful terminations. Instrument every source with a per source success and volume expectation, alert when the volume drops out of band, and record for every individual which sources were checked and what each returned. That record has a second use: when a determination is challenged, it shows the agency attempted verification properly.

Start the agreement work in week one of the project, not at integration time. It is the most common schedule risk in this domain and it is almost never on the engineering plan.

What happens when notice and language obligations are not covered?

The call centre absorbs it, and then the hearing officer does. Adequate and timely notice is a due process requirement, and the notice is also the first artefact a hearing officer reads. Most agency notices cite a regulation, state a conclusion, and leave the recipient unable to tell what to do about it.

The failure that costs most is a notice generated separately from the determination. If the letter is assembled from its own template logic rather than from the determination trace, the reasons in the letter and the reasons in the system will diverge, and the one that diverges is the one the hearing officer reads aloud.

Generate notices from the same trace that produced the decision. Template by notice type in plain language, translate into the languages your population actually speaks rather than the two you have always used, and produce accessible formats. Archive every notice 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.

Renewals sit in the same territory. Federal rules require states to attempt a Medicaid renewal using information already available before asking the enrollee for anything. When that 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 procedurally. The 2023 unwinding of the continuous enrolment condition made the mechanism visible nationally, with CMS identifying states running the ex parte attempt at household level rather than individual level, requiring pauses in procedural terminations and reinstatements. That was a data model defect, not a policy misunderstanding, and any build should run the attempt per individual, per source, with the result logged.

Should you build custom or configure what you already own?

Do not replace the integrated eligibility system with a custom build. The programme risk is enormous, the funding process alone runs longer than most software projects, and the states that have tried have made national news for the wrong reasons. Any firm quoting you one should be declined on that basis.

Configure the incumbent where the incumbent can genuinely reach. Merative Curam, Conduent and Deloitte implementations all have configuration surface, and Salesforce Public Sector Solutions is a reasonable platform for worker facing workflow if your agency already runs on it. If your problem is queueing, assignment or a screen layout, that is a configuration conversation and possibly a two week engagement rather than a two year one. Some of the offices we have assessed did not need software at all, they needed workload distribution changed.

Build modules, because that is now the sanctioned architecture. The components with the clearest return are the ones where the incumbent's roadmap is slow and the policy is yours: the versioned rules and explanation service, ex parte renewal, notice generation, and document intake with verification matching. Treat the rules engine as something you own regardless of platform, because that is where policy lives. Build nothing that quietly reimplements policy the incumbent already applies, because two engines applying the same rule will disagree eventually and you will not know which is right.

How do hidden costs get into the quote?

• Programme count. Medicaid alone is one shape. Add food assistance, cash assistance and child care and you have four rule sets and four household constructions, not one system with four flags.
• Federal tax information. If the component touches data covered by IRS Publication 1075, the environment, staffing and logging controls become a security programme with its own review cycle.
• Data source agreements. Quoted as integration days, delivered as months of interagency negotiation.
• Certification. Work inside a Medicaid eligibility programme sits under CMS streamlined modular certification, which shapes what you build rather than only what you document.
• Language and accessibility. Broader here than for a typical government portal, and far cheaper designed in than retrofitted.
• Policy staff time. Extracting rules and validating replays needs your policy analysts, and their hours are almost never in the plan.

What separates a build that works from one that fails here?

The builds that work drive the worker screen, the notice and the hearing packet from one determination trace. If those are three outputs assembled separately they will disagree, and the disagreement will surface in the worst room. Ask any developer what they intend to do with the trace, and treat a vague answer as disqualifying.

They measure the right number. For renewal work that is the share of renewals completed without contacting the household, per individual, tracked weekly. For document work it is the share of verification requirements cleared electronically before anyone asks the household. Neither is a vanity metric and both drive design decisions that a feature list will not.

They use automation where it removes clerical load rather than where it makes decisions. Classifying an incoming pay stub, matching it to the right case and the right open verification requirement, and extracting the gross amounts for a worker to confirm is a genuinely appropriate use of document models in a benefits agency. The determination stays with the versioned rules service, because a determination that cannot cite the rule it applied is not defensible however it was produced.

They replay before they release. A sample of real cases run against both the current and proposed rule versions, with every difference explained, is the only credible way to ship a policy change into a system that decides eligibility.

And they settle ownership before kickoff, in writing: the repository, the rules artefacts and the environments, with the right to move the work to another firm. At Digital Heroes the agency owns the code from the first commit. Eligibility rules are public policy, and locking them inside a vendor's proprietary configuration is how agencies end up waiting two quarters to implement a change the legislature made in an afternoon.