States could build Medicaid work requirements from the statute before the rule arrived

The week

By mid-March 2026, state Medicaid agencies were deep in preparation for the community engagement requirements in the July 2025 reconciliation law. No single event marked the week; what marked it was a deadline drawing closer.

“Community engagement” is the official name for what most people call Medicaid work requirements. Medicaid is the joint federal and state program that pays for health coverage for people with low incomes, and each state runs its own version. A reconciliation law is a budget bill passed through a special fast-track process in Congress.

The law requires states to apply the requirements to adults in the expansion population aged 19 to 64 by January 1, 2027, with good-faith exemptions possible through 2028. The “expansion population” is the group of lower-income adults that states chose to cover when they expanded Medicaid under the Affordable Care Act. A good-faith exemption is, in effect, extra time for a state that can show it genuinely tried but could not finish.

The standard itself is simple to state. Members must show 80 hours a month of work, community service, a work program or half-time education, or equivalent income, unless exempt. Behind that simple sentence lies a large technology project: every month, for every affected person, someone or something has to decide whether the standard was met.

That job falls largely to state eligibility systems, the computer systems that decide who qualifies for Medicaid and other benefits, generate letters, and feed caseworkers’ screens. They are large, old in places, and run under long contracts with outside firms.

The rules were not finished. CMS, the federal Centers for Medicare & Medicaid Services, had to issue an interim final rule by June 2026. An interim final rule takes effect right away while public comments are still being collected, so states would have to build against it immediately. In the meantime CMS had issued sub-regulatory guidance, meaning letters and instructions that explain how the agency reads the law without being formal regulations.

On January 29 CMS announced pledges from ten eligibility system vendors of more than $600 million in free or discounted products and services. State budget proposals that spring included money for eligibility system changes.

So the picture in mid-March was this: a fixed legal deadline, an unfinished rulebook, a crowded vendor market and a great deal of work to do.

Most commentary on Medicaid work requirements argued about the policy. State Medicaid directors and eligibility CIOs (chief information officers, the executives responsible for the technology) had a narrower problem in March 2026. The deadline was fixed in statute, about nine months away. The federal rule that would settle many details was not due until June. Waiting for the rule meant starting a large system change with six months left. Starting without it meant building on assumptions that might be wrong.

The way through was to sort the work by how much the rule could change it. We see three categories that together cover the build. First, what the statute already fixed, which could be built now. Second, what the rule would decide, which should be built as configuration. Third, what had to be contracted now, because delivery capacity was finite.

This sorting is useful well beyond Medicaid. Any organization that must build a system against a deadline while the rules are still being written, whether a bank facing a new reporting regime or a hospital facing a new payment rule, faces the same dilemma. First, the machine being changed.

What an eligibility system actually does

A state eligibility system follows a fixed sequence. A person applies for coverage, online, by phone or at an office. The system gathers what it knows about them, applies the program’s rules, decides whether they qualify, records the decision, and sends a letter, called a notice, explaining it. Periodically it checks again; that check is called a redetermination or renewal.

The system rarely works alone. It connects to other state and federal databases to confirm facts without asking the applicant: wages reported by employers, enrollment in other benefit programs, and so on. Each of those connections is a data match, in which the system looks for the same person in another database and pulls back a fact. A good match spares the applicant paperwork. A poor one, matching the wrong person or missing the right one, creates errors that are hard to see from the outside.

Most states do not build or run these systems themselves. They hire a system integrator, a large technology services firm, under a long-term contract. Changes are requested through change orders, formal amendments that define the work, its cost and its schedule. The federal government pays a large share of the cost of these systems, at a higher rate for qualifying technology work, which is called enhanced federal match, but federal reviewers must approve the plans.

Work requirements add a monthly determination to this machine for millions of people: whether each person met the standard or is exempt. The answer must come from data where possible, from the person where not, and it must be right, because the consequence of a wrong answer is the loss of health coverage.

Build now: what the statute fixed

The law settled the population, the monthly standard, the qualifying activities and the list of mandatory exemptions. It also directed states to use available data to verify compliance where they could. Not one of those depended on the rule.

That made data connections the safest early investment. Linking the eligibility system to state wage records, SNAP and TANF case data, and education and workforce program enrollment would be needed under any plausible rule. (SNAP is the food assistance program once known as food stamps; TANF is cash assistance for families with children.) So would the matching logic that decides when a record is good enough to count. Each member verified from data is one fewer notice, portal visit or call. CMS later offered states an open-source income verification app through a support program it called Emmy; “open-source” means the underlying code is freely available for states to use and adapt.

Exemption identification fell in the same category. Pregnancy and postpartum status, disability and serious illness, caregiving and recent incarceration are often visible in data the state already holds. A state could build the queries and test them against current members long before the rule arrived.

It could also measure, early, the share of the affected population it could verify or exempt without asking anything of the member. That single number drives call center staffing, notice volumes and, in the end, how many eligible people lose coverage for procedural reasons. A procedural loss happens because paperwork went unanswered, even though the person may have met the rules: a letter sent to an old address, a form not returned in time. Arkansas’s 2018 experience, where research found that many people who lost coverage appeared to be eligible or exempt, showed how much that number matters.

Configure later: what the rule would decide

Several choices were left to CMS or to state options the rule would shape. How many months of past activity a state checks at application. How often it re-verifies. Whether short-term hardship exemptions are offered. How medical frailty is defined, and what evidence an exemption needs. Each of those can be hard-coded into an eligibility system, and each hard-coded assumption is a change request when the rule says something different.

The difference between “hard-coded” and “configured” is the heart of this section. Hard-coding means writing a rule directly into the software’s instructions: “check three months.” Changing it means programmers rewriting, retesting and redeploying code. Configuring means the software reads the rule from a table: “check the number of months in cell B4.” Changing it means a policy analyst edits the table, tests the result and releases it. Hard-coding is like a thermostat wired permanently to a single temperature; configuration gives it a dial.

The defensive pattern was to build them as parameters. Look-back periods, verification frequency and exemption evidence rules should sit in tables that policy staff can change and test, not in application code. Notice templates should draw from the same parameters, so a change in rule text does not require a separate rewrite of every letter. This costs more up front. It turns a late rule from a rebuild into a configuration release, and it leaves room for later federal changes or a state’s own policy choices.

There is a governance side as well. Parameter tables need an owner who can approve changes, a test process that checks downstream effects, and an audit trail. Without them, configurability becomes a way to change eligibility policy without anyone noticing, which is its own risk under federal oversight.

Contract now: delivery capacity

Most states run eligibility systems through long-term contracts with a small number of system integrators. Every expansion state faced the same deadline in the same months, alongside other changes in the same law, such as more frequent redeterminations. Integrator teams, test environments and federal reviews of system changes were all finite. A test environment is a copy of the system where changes can be tried safely before they touch real people; there are only so many, and only so many skilled testers to run them.

That made spring the time to secure capacity, even with the requirements incomplete. Practical steps included change orders scoped to the statute-fixed work, named staffing commitments for the second half of the year, and early requests for enhanced federal match on the system changes.

The vendor pledges announced in January needed the same scrutiny as any discount. A state needed to know what was free, for how long, what it would cost to maintain, and whether accepting it deepened dependence on an incumbent. CMS itself said its list of vendor offerings was not an endorsement and not a determination that any product met federal requirements. A free tool that locks a state more tightly to one vendor can turn out to be expensive over the following decade.

States also needed a credible plan for what would happen if the build slipped. The good-faith exemption gave the federal government a way to allow more time. A state that wanted one would need evidence of effort: dated contracts, test results and a realistic schedule. The same documents serve the state’s own legislature and auditors.

Sorting the work this way did not remove risk. It placed the risk where it was cheapest. Statute-fixed work went ahead, rule-dependent work waited as configuration, and the scarce resource, delivery capacity, was reserved before other states claimed it.

How the monthly check works in practice

Following a single member through the process shows where technology choices turn into human outcomes.

First, scope. The system checks age and whether the person is in the expansion population. Most of this is already in the eligibility record.

Second, exemptions. The system runs its exemption queries, looking for another record that shows a pregnancy or recent birth, a disability or serious illness, caregiving responsibilities or recent release from incarceration. If a reliable record says yes, the person is exempt and never needs to hear about the requirement beyond a clear letter saying so.

Third, compliance from data. If the person is not exempt, the system looks for evidence that they met the standard: wages in state wage records equivalent to the required income, participation in a work program, enrollment in education. A good match settles the question silently.

Fourth, only then, ask the person. If neither an exemption nor compliance can be confirmed from data, the system must ask: a notice, a portal task, perhaps a call. This is the expensive and fragile step. Letters go astray, people move, portals confuse, and phone lines back up. Every person who reaches this step carries some risk of losing coverage for a reason that has nothing to do with whether they worked.

Finally, decide and explain. The system records the outcome and sends a notice the person can understand, with a way to respond if it is wrong.

The design goal follows directly: push as many people as possible through the first three steps, so the fourth is reserved for genuine uncertainty. That is why data connections and exemption queries sit in the “build now” column, and why the share of members resolved without contact is the number that matters most.

One state’s spring, on a single page

Take an expansion state in March. Its Medicaid director has a budget request pending, an integrator contract with two years left, and a federal rule not yet written.

In the first week, the eligibility CIO lays out the work on a single page with three columns: build now, configure later, contract now. Under build now go the data links to state wage records, SNAP and TANF, and the exemption queries. Under configure later go the look-back period, verification frequency, hardship exemptions and evidence rules, each to be built as a table with a named policy owner. Under contract now go a change order for the first column, a request for named integrator staff from July to December, and a federal funding request.

By April, the data team runs the exemption queries against current members and produces the number that matters: what share of affected adults the state can verify or exempt from data alone. Suppose it is lower than hoped. That is valuable news in April. It tells the director to invest in better matching, to plan call center staffing realistically, and to design clearer notices, while there is still time to act.

When the rule lands in June, most of its choices become edits to tables rather than new code. The state’s dated records of progress sit ready in case it needs a good-faith exemption. The approach does not guarantee a smooth launch, but it means the state spent its scarce months on work it would never have to redo.

Coverage, rework and caseloads

People. The measure of success is not whether the system went live on time, but whether eligible people kept their coverage. Every avoidable procedural loss is a person who may skip care or arrive at an emergency room later and sicker.

Money. Rework is the most expensive kind of technology spending. Hard-coded assumptions that a rule then overturns are paid for twice. Configuration costs more at first and less over time.

Regulators and oversight. Federal reviewers, state legislators and auditors all want evidence that the state acted prudently. A clear sorting of the work and dated records of progress provide it.

Staff. Caseworkers and call center staff absorb whatever the system cannot do. A high data-verification rate is, among other things, a workforce plan.

Reputation. Public programs are judged on fairness as well as cost. Arkansas’s experience showed how quickly a program can become a story about eligible people losing coverage.

The prepared state and the scrambling one

The prepared state has a one-page sorting of the work into what the law fixes, what the rule will decide and what must be contracted; early data connections and a measured verification rate; policy choices held in governed tables, not code; integrator capacity secured early; vendor offers examined with care; and a dated record of progress.

The scrambling state tends to make the same errors:

• Waiting for certainty. Holding all work until the rule arrives, then compressing a year’s build into six months.
• Building on guesses. Hard-coding assumptions about the rule that then have to be torn out.
• Ungoverned flexibility. Making everything configurable without an owner, tests or an audit trail.
• Taking free at face value. Accepting discounted tools without asking about duration, maintenance and lock-in.
• Measuring the wrong thing. Tracking go-live dates instead of the share of members verified without contact.

Where the deadline risk sits now

1. Which choices are we waiting on the rule for, and are we building them as adjustable settings or as code?
2. What share of affected members can we verify or exempt from data we already hold, and how do we know?
3. Do we have named integrator staff and test environments booked for the second half of the year?
4. If we needed a good-faith exemption, what evidence could we show today?
5. How will we know, month by month, whether eligible people are losing coverage for paperwork reasons?

With hindsight

CMS issued its interim final rule on June 1, 2026, with publication in the Federal Register days later and comments accepted through July 31. The January 1, 2027 deadline held. States that had waited for the rule before starting now had exactly the compressed timetable they had feared.

Many of the details landed in the categories above as state choices: how many months to look back, how often to verify, and whether to offer short-term hardship exemptions. For states that had built those as adjustable settings, the rule became largely a matter of filling in tables. For those that had hard-coded guesses, some of those guesses became change requests.

Medical frailty was not left to states: CMS defined it by the five statutory categories and did not let states add others. Configurability is a hedge, not a prediction. Some choices states expected to make were made for them.

Evidence rules tighten over time. Until January 1, 2028, states may accept other information where data fall short; from that date they must generally require documentation when it is reasonably available, a change states with configurable evidence rules could absorb more easily. The rules will change again in the middle of the program’s life, and systems designed to be adjusted will cope better than those designed to be rebuilt.

CMS said coverage effects would depend heavily on state implementation choices. That puts the measure we suggested, the share of members verified or exempted from data without contact, at the center of how the policy plays out. For a governor, a Medicaid director or a legislator, it is the single number most worth asking for, because it predicts both the administrative cost and the human cost of the policy.

The same approach serves anyone facing a deadline before the rules are final: separate what is certain from what is not, build the certain part, make the uncertain part adjustable, and secure the scarce resources early.