A Technical Guide for States to Reduce Procedural Terminations from Medicaid’s Work Reporting Requirements

States face a very challenging mission to implement work reporting requirements from the so-called One Big Beautiful Bill Act (OBBBA) before the new eligibility rules go into effect in January 2027. At baseline, millions of people who need health insurance are likely to lose coverage due to these work reporting requirements. Depending on how states implement the law, millions more are at risk of losing health care coverage due to red tape or administrative errors. States that want to mitigate some of the potentially catastrophic harms of this policy must implement it carefully, minimizing administrative burdens and effectively applying exemptions to work reporting requirements.

Despite this significant time pressure, now is an opportune time to reevaluate which approaches and vendors will lead states toward better administrative technology and which will simply compound existing problems and increase liability. Unfortunately, many states’ Medicaid eligibility and enrollment systems already fail to consistently apply eligibility rules, keep track of case data, and send legally compliant and clear notices. Building on top of these brittle systems with the vendors that made them, using tried-and-failed approaches, is not necessarily the best option for states.

This guide reviews specific policy and technical implementation choices to reduce procedural terminations within work requirement exemptions and reporting. It is created by advocates and technologists experienced with state Medicaid systems and software generally. Topics covered in this guide include reducing complexity and administrative burdens of the verification process, mitigating risks from automation, navigating vendors and accountability mechanisms, and testing, reporting, and monitoring considerations to help avoid issues upon roll-out of work requirements. The Centers for Medicare and Medicaid Services is required to issue additional guidance for implementing the law on or before June 2026, and our specific recommendations may change depending on that guidance.

It is worth emphasizing that OBBBA will do nothing more than penalize people who are already struggling. It cannot be perfectly implemented—especially within such a limited timeline. That is why states must do all in their power to minimize failure points, divest from unaccountable vendors, and record evidence of the law’s consequences.

States are in a very difficult position to change their Medicaid administration systems to implement OBBBA work reporting requirements, and millions of Americans are at risk of losing health coverage, despite the fact that the vast majority of them are working or are exempt from work requirements. This guide offers ways to minimize procedural terminations through decreasing policy and technical complexity, better aligning design choices to recipients’ needs, and creating vendor accountability mechanisms.

Reflected throughout our specific recommendations are these key principles:

• Technology is not a silver bullet. While narrowly defined uses of automation can greatly reduce administrative burdens, technology comes with its own limitations and risks. The reality is that not all the data necessary to automate compliance exists, not all enrollees and applicants are able to use digital tools, and not all technological approaches are the best way to solve the problem to which they claim an answer. Further, technology can introduce new problems through glitches, subtle mistranslations of policy, privacy violations, and inaccessibility.
• Applicants and enrollees are the highest priority. The ultimate system evaluation metric is whether eligible people obtain and maintain Medicaid coverage. While this does substantially depend on whether agency workers can also successfully operate the system, applicant and enrollee testing is too often left to the end, if it happens at all. Applicants and enrollees, especially those with disabilities or limited English proficiency, need to be consulted as early as possible to ensure the system design plans match their needs and that design choices do not create additional barriers.

Below is a list of our recommendations at a high level. The rest of this guide discusses them in further detail.

Minimize burdens by simplifying compliance review. Make policy and design choices to minimize administrative burden on applicants and agency employees by using the simplest possible verification methods, including accepting self-reports wherever possible (e.g., of medical frailty), under the principle that each required interaction increases the likelihood of procedural terminations.

1. Use the lowest frequency of redetermining eligibility (every 6 months) and shortest lookback period (1 month). This is a win-win-win: It minimizes use of agency resources, minimizes technical complexity and implementation costs, and minimizes procedural terminations.
2. Prioritize robust off-ramps that catch everyone who should be exempt or excluded due to hardship or due to qualifying for different eligibility categories. This will minimize the number of people for whom the state must spend recurring resources to verify participation.
3. Minimize administrative burdens by automating compliance with ex parte data and other data directly accessible by the agency. Only add new data sources that are accountable (i.e., in which inaccuracies are extremely uncommon and can be easily corrected without extra burden on the subject) when there is evidence of their benefit.
4. Where gaps exist in data to automate exemptions, simplify verification by accepting applicant or enrollee statements, as there are major barriers to obtaining proof of many exemptions, such as medical frailty or caregiver status.
5. Use best practices and lessons learned from the unwinding of the COVID-19 Public Health Emergency to fix existing system deficiencies such as notices.
6. Ensure notices contain information on data sources to comply with due process requirements.
7. Avoid risky technology, such as AI for decision-making or apps that overcollect sensitive data. Instead, consider the simplest and most transparent way to solve the problem that AI is pitched to help accomplish.

Use testing to reduce system harms. Perform proactive system testing with a wide range of Medicaid recipients and advocates to ensure that design choices comply with legal requirements, meet people’s needs, and that the system is robust.

1. Engage Medicaid recipients and advocates before the system design is finalized, so that plans can be changed without incurring significant further costs.
2. Test language and interfaces before implementation (e.g., by using mock-ups such as wireframes) to ensure that design and language choices are accessible to people with disabilities and limited English proficiency and do not create barriers for the user to accomplish the objective with the system. This is especially important for catching exemptions.
3. Conduct projected-impact testing on the system and associated functions, such as phone lines and office visits, so that states can respond to people’s actual needs (e.g., if a state’s population is mostly rural and lacks an internet connection, more resources should go to phone lines).
4. Measure metrics, such as completion rates from text message or email outreach, portal logins, document-upload success rates, and ability to navigate websites and find answers to questions, in a pilot phase before roll-out.

Maximize vendor accountability. Require accountability mechanisms in vendor contracts so that the system can be effectively monitored for issues and fixed when they occur.

1. Prioritize nonprofit or B Corp. vendors that are willing to create open-source software that can be used by any state, as opposed to vendors that charge each state separately for fixing errors that are likely common across states. When working with these vendors, states may find it is easier to accomplish the accountability mechanisms in this section.
2. Specify broad contract language defining programming errors or system defects, so that vendors are not incentivized to request additional payment to fix errors they created.
3. Ensure testing plans from Section 2 of this guide are included in contract language and project timelines.
4. Build an off switch to pause terminations or processing for particular groups or the entire population, to be used if major errors occur.
5. Publish on agency websites and proactively communicate about errors that have potential consequences for applicants/enrollees once they have been identified, along with steps they can take to rectify issues.
6. Create detailed, public-facing reports on rates of procedural terminations, broken down by demographics, county, and specific reason for termination (e.g., recipient was not able to be contacted, recipient was not successful in logging into reporting portal, recipient logged in but attempts to upload documents failed, etc.), at minimum.
7. Continue to monitor other important system metrics established during the pilot phase.
8. Make changes less burdensome to implement by following best programming practices and getting direct access to nontechnical elements of the system, such as notice template language or diagnosis code lists.
9. Generate human-readable audit logs for system errors that show the path taken by an individual or agency worker.

The policy options that minimize administrative burdens on Medicaid applicants and enrollees can also minimize technical complexity, cost to states, and error rates—which, if they raise Payment Error Rate Measurement (PERM), also cost states federal matching funds. Simplifying compliance review minimizes challenges for states for three main reasons:

1. Every interaction with the system, or “touch,” can add to churn by creating a potential drop-off point for applicants and enrollees.
2. It costs states resources every time the system or a caseworker has to process an application.
3. Adding unnecessary complexity to technical features increases the risk of errors, which leads to both churn and liability for states.

Churn places significant administrative and financial burden on states. When enrollees lose Medicaid eligibility for procedural reasons, for instance, eligibility workers end up processing multiple applications for individuals who were eligible the entire time but still lost their eligibility and cycled off coverage.

States can save considerable money, time, and effort when they simplify their Medicaid eligibility processes. To be sure, OBBBA will significantly reduce costs by simply ending health insurance coverage for millions of people who need it but cannot meet the reporting requirements. Yet states that try to enforce complicated eligibility processes are likely to end up overpaying private vendors and increasing their administrative costs, with little benefit to the public.

The U.S. Government Accountability Office found, for example, that “administrative spending has outpaced spending for medical assistance” in Georgia’s Pathways to Coverage program. From the beginning of fiscal year 2021 to the end of March 2025, more than $54 million, or 67.5 percent of the state’s total program expenditures, had gone to administrative tasks to support Pathways’ community engagement requirement, including $45.1 million paid to contractors for the eligibility and enrollment system. Despite this considerable spending, Pathways has enrolled only 11,600 people as of November 2025, since it began in July 2023—a fraction of eligible Georgians.

In contrast, several months after Pathways opened up in Georgia, North Carolina—which has very similar population and income levels as Georgia—implemented a straightforward Medicaid expansion without work reporting requirements. This expansion has enrolled more than 687,000 people in North Carolina.

States should not underestimate the costs of creating extra hoops that people have to jump through, especially when the money largely goes to private vendors and administrative costs instead of benefiting the public. The following policy and technical recommendations can help states decrease the complexity of their verification systems.

Minimize reverification frequency and lookback periods

States should review beneficiary compliance only once every 6 months, unless a change of status is reported. States should also implement the shortest available lookback period option at application or renewal, which is 1 month under statute. More frequent compliance checks and longer lookback periods will create significantly more work for states in the form of running additional queries, verifying additional documents, aligning compliance checks with other eligibility renewal factors, and modifying rules engines to account for more complicated scenarios. They also multiply the risk of procedural disenrollments, adding to churn.

Prioritize off-ramps to minimize burdens

Reporting requirements are the most burdensome and resource-intensive part of this policy for applicants and enrollees, as well as for the agency, as they create additional recurring administrative costs to check compliance. States should therefore prioritize identifying as early as possible everyone who ought to qualify for exemptions or temporary hardships or who could be in a non-expansion eligibility category.

Considerations for exemptions

States should screen for exemptions as early as possible in the application and renewal processes and prioritize checking for exemptions with longer or permanent terms. For exemptions such as medical frailty or caregiver status, states must make sure their interpretation is not overly restrictive in terms of who qualifies under statutory and regulatory language. The written criteria shown to applicants and enrollees must be easy to understand and must match the criteria used to automate exemptions. As described in the section on system and user testing, screening language can lead to exemption failures because many applicants will not identify with or understand certain policy terms.

For a more detailed discussion on exemptions for parents and other caregivers, see the Center on Budget and Policy Priorities’ “Guide to Reducing Coverage Losses Through Effective Implementation of Medicaid’s New Work Requirement” (hereafter referred to as the CBPP guide).

Implement optional hardship exceptions

A major contributor to churn will be the lack of employment opportunities due to high unemployment rates, disaster, or emergency. States should therefore implement the OBBBA’s optional hardship exceptions for individuals in counties facing these circumstances. One analysis determined that 158 counties in Medicaid expansion states could qualify for the high unemployment hardship exception, meaning that as many as 1.4 million enrollees could be exempt from work requirements under this provision.

In terms of implementation, this would require that states create additional automatic hardship pathways in rules engines. Yet each type of hardship will require the same basic technical infrastructure, which will also be similar to exemptions that states must build anyway. States should still check for exemptions for individuals applying during a hardship, as those exemptions may be long term or permanent, in order to minimize the likelihood that they will be procedurally terminated when the hardship is over.

Consider alternative eligibility pathways

Medicaid enrollees who are eligible through non-expansion eligibility pathways can sometimes be placed into Medicaid expansion in cases where the state did not check for all eligibility pathways at the time of their application. States are already required to consider all bases of eligibility before terminating Medicaid coverage, and recent guidance reaffirms this requirement.

This strategy would likely work best in states that have extended eligibility for “traditional Medicaid” to the expansion group, rather than creating a new/different program to serve expansion enrollees. If moving people to another eligibility group might disrupt their access to care (e.g., they would be forced to move to a new network), then this should be weighed against potential disruptions to care caused by remaining in expansion and being subject to work requirements.

Automation to minimize administrative burdens

Carefully designed automation is one of the major ways that states can reduce administrative burdens and procedural denials. Further, OBBBA mandates that states use “reliable information” that they already have available to verify compliance with or exemption from work requirements, without requiring the individual to submit additional information. States should prioritize using the large number of data sources already available to them and carefully consider whether and how to use new data sources.

At best, automation can proactively identify information so that individuals have fewer hurdles to pass through. States should understand where automation has significant limits, however, and not assume that it can remove all burdens from what is a fundamentally burdensome policy.

Automating verification of work or community engagement

States have access to a number of options to determine income, which is one option for individuals to show compliance with work reporting requirements. These include State Wage Information Collection Agencies, state unemployment compensation agencies, and Social Security Administration databases.

For determining hours worked, the main option is Equifax’s The Work Number database, but it is costly to query and has known accuracy issues that are difficult for individuals to contest. While other wage and income databases have not faced the same criticisms as The Work Number, they are not designed to provide on-demand, real-time reporting, meaning that there will still be gaps in the information available. For this reason, states should prioritize income data in what the CBPP guide describes as a “waterfall” approach.

A major limitation to automating work verification is around “nonstandard” workers, such as gig workers or other contractors, whose jobs tend to have limited formal payment documentation, and are more likely to be missing from employment databases. While reporting apps attempt to mitigate this, it remains to be seen how easy they are to use or whether people will feel comfortable using them.

Automating exemptions

Exemptions are either straightforward and highly likely to be represented in available agency data or are more complicated and less likely to have documentation at all. Automation therefore has an important but limited role in proactively identifying exemptions.

Exemptions due to demographic information, such as age or whether someone is American Indian or Alaskan Native, can be directly identified with ex parte data or from the application. For other straightforward exemptions, such as enrollment in Medicare Parts A or B or existing compliance with work requirements for the Temporary Assistance for Needy Families program or Supplemental Nutrition Assistance Program, data is also easily accessible via those programs’ databases.

It will be less straightforward for states to automatically identify people exempt for medical frailty or being a caregiver to a person with a disability. These circumstances are often not formally documented, and other similar designations that are documented do not fully overlap with what OBBBA considers. That said, there are some data sources that can be used to automatically identify subsets of those who qualify for the medically frail exemption, such as Medicaid home- and community-based services (HCBS) enrollment data or referencing medical claims data against a list of diagnosis codes associated with medical frailty (such as Michigan’s list, which is not necessarily complete).

Yet states should avoid creating algorithms to “flag” medical frailty. While the idea is well-intentioned, doing so would add complexity and opacity, and does nothing for the significant group of people for whom medical data is nonexistent. It would also risk applying different criteria to people automatically identified versus manually claiming the exemption. Crucially, it does not have clear benefits in filling automation gaps over self-reporting, especially considering that states do not have to require verification of this exemption.

If states are concerned that medical frailty or caretaker exemption implementation will not catch people who qualify, as happened in Arkansas, they should allow people with disabilities and advocates to guide the language used to ask about these exemptions and to recommend additional relevant diagnosis codes for the list used in medical claims data matching.

Other automation considerations

States must consider the accuracy and shortcomings of data sources, precisely how they will interpret data, resolve data source conflicts, and give recourse to people for incorrect data. To make this possible, eligibility notices should include (in addition to all legally required information) the information used in automatic verification, such as the data itself, the data source, and how that data was specifically used.

A major part of ensuring reliability of data sources is the ability of states to resolve data errors on behalf of individuals. For example, if an applicant or enrollee sees that data used to automatically check for income or employment was incorrect and tells the agency, the state should fix the data and propagate that correction to anywhere else the data appears. This is especially important for privately operating databases such as The Work Number, so that individuals are not burdened with correcting their information multiple times.

Further, states should never try to use data or the lack of it to prove someone is failing to meet requirements. Databases are a floor, not a ceiling, and can contain a subset of existing records. In other words, if a database shows that someone’s income is less than the $580 per month requirement or that they worked fewer than the 80 hours per month requirement, it could just be missing information or out of date. All this means is that states do not have enough information to identify compliance on behalf of an individual.

Accept applicant and enrollee-reported information where possible

States need to account for the significant limitations of automation in a way that still minimizes burden on applicants and enrollees, as well as on state resources. Where states have the option to do so, simply accepting the statement of an applicant or enrollee as proof is the cheapest and simplest verification method by far and imposes minimal additional process on applicants and enrollees who are not automatically identified as exempt or compliant with reporting.

Compared to requiring additional documents, accepting self-reported information where permitted reduces procedural terminations and churn, and minimizes the agency staff time required to process documentation. Requiring additional documentation from applicants and enrollees is extremely resource-intensive with a risk for high procedural errors and contributes to states wasting money on administrative costs for a program that does not serve people.

For exemptions in particular, requiring additional documentation will lead to significant churn and higher error rates. Documentation is either redundant for easily automatable exemptions or unduly burdensome for others where documentation is less likely to exist.

Leveraging self-reporting, where permitted, to confirm Medicaid eligibility factors is not novel. States may accept applicants’ and enrollees’ statements as proof that they meet most Medicaid eligibility factors, except where they are explicitly prohibited by law from doing so (i.e., states cannot accept self-reported information as proof of citizenship or immigration status). Generally, states must accept self-reported statements as proof of pregnancy status. It is worth emphasizing that Medicaid fraud on the part of applicants and enrollees has been found to be “negligible” based on data from the U.S. Department of Health and Human Services Office of the Inspector General.

The Centers for Medicare and Medicaid Services is required to issue additional guidance about compliance verification on or before June 2026, and our recommendations may change depending on that guidance. The most recent guidance, released on December 8, 2025 and November 18, 2025, do not provide details on this.

Existing best practices and lessons from unwinding

Although OBBBA blocks implementation of many of the streamlining provisions of the 2024 Eligibility & Enrollment Final Rule, states are still free to adopt most of the Final Rule’s strategies for improving eligibility and enrollment processes. States should implement these strategies to the maximum extent possible.

States should also provide the maximum possible amount of time for responding to any requests for information prompted by the system and, relatedly, should build into their systems time for processing returned paperwork before initiating a termination. An enrollee who returns their paperwork on time should not be penalized because the state’s system does not process or review it in a timely manner.

States should prioritize individuals obtaining and keeping coverage, even if applications are backlogged or there are other discrepancies that the state can resolve in the background. States have numerous options to preserve program integrity in the unlikely event that an ineligible person is incorrectly determined eligible for Medicaid. Yet the harm to individual applicants and enrollees of these eligibility changes, when not implemented properly, is great and often irreversible.

For most Medicaid-eligible adults, the program is their only source of health insurance. Many Medicaid enrollees who are disenrolled for procedural reasons do not reenroll. Indeed, 70 percent of adults who were disenrolled during Medicaid unwinding became uninsured. Moreover, OBBBA provisions prohibit people who are disenrolled from Medicaid for noncompliance with work requirements from accessing tax credits to offset the cost of Affordable Care Act Marketplace coverage, making it a much less accessible fallback option.

Finally, states should update their notices to fix any problems and ensure legal compliance, as well as readability.

Avoid risky uses of technology

Given the significant administrative costs of implementing these policies, there may be pressure for states to adopt “time-saving” AI features. Yet states should be aware that adopting AI tools can significantly increase errors and liability to states and may not be worthwhile compared to simpler options. Vendors may over-promise on the capabilities of AI systems, especially if state agencies do not have the expertise on hand to be able to verify the claims.

Simple automation can be helpful if it is appropriately scoped to a reasonably narrow task and if it includes safeguards, such that it accomplishes its stated purpose and failures do not frustrate users or contribute to procedural terminations. While eligibility rules are straightforward enough that it would make little sense to do so, it is still worth mentioning that AI should not be used in decision-making for compliance with reporting requirements due to the consequences of erroneous decisions.

If an AI solution is proposed but seems risky, states can think about other ways to accomplish the desired task or goals without AI. Vendors may suggest, for example, using generative AI in a chatbot to answer general questions so as to free up caseworker capacity for more complicated calls. Yet there may be issues with the quality and accessibility of the state’s online resources, which, if addressed, could help relieve this issue—without adding additional risk from generative AI’s tendency to fabricate inaccurate but convincing statements. Further, states could offer the same accessibility benefits of real-time text-based communication by staffing a chat line with trained human workers.

States should include Medicaid recipients, state advocates, and other impacted stakeholders as early as possible in the procurement and design process. Advocates, including legal services organizations and others who interface daily with Medicaid recipients, can be helpful proxies for getting input and for connecting with Medicaid enrollees. Including enrollees and advocates early helps build trust and creates the relationships necessary for testing throughout development and for continued feedback about performance of the system once it is rolled out. This is the most effective way to ensure the system’s design or features are maximally responsive to the needs of applicants and enrollees.

Build channels to engage applicants and enrollees early and often

States should create opportunities and actively recruit for regular meetings with Medicaid applicants, enrollees, and advocates. Medicaid Advisory Committees and Beneficiary Advisory Councils (MACs and BACs) provide a ready-made infrastructure for such public engagement.

Outside of regular meetings, states should develop and adequately staff additional formal channels for advocates and members of the public to raise issues. Such channels could include a website, a central email address, a telephone hotline, user testing sessions, and/or standing public meetings. It could also include establishing a dedicated stakeholder working group.

States must prioritize accessibility so that individuals can actually participate. That means following best practices—including live ASL interpreters and transcription services, using inclusive language, and ensuring virtual meeting platforms are accessible, among others—and scheduling meetings when people can attend in modalities that allow persons with accessibility needs to participate (such as hybrid attendance) and in languages and accessible formats they understand.

Test assumptions and accessibility with diverse groups before implementation

Translating policy into code requires making many choices about how the system should operate. Before significant time is invested in implementing a certain back-end or user-facing design, states need to check their assumptions on exactly how the system will operate. Two equally important ways to do this are by facilitating direct feedback (qualitative evidence) and by collecting data to estimate impact (quantitative evidence).

A major priority for designing and testing systems must be to ensure accessibility. States have an obligation to prevent their systems from discriminating against people with disabilities and those with limited English proficiency, which means doing comprehensive planning, testing, and monitoring to ensure accommodations provide access. The National Health Law Program has more detailed guidance on accessibility for Medicaid systems to protect these groups.

States must also make sure not only that their digital tools are as accessible as possible for people with disabilities, but also that they invest resources to properly train staff and fund in-person offices and call centers. States must also take special care around the implementation of exemptions, which advocates have pointed out may fail to identify people with complex or episodic medical conditions, mental health conditions, and substance-use disorders, or the caretakers of people with disabilities.

Direct feedback

In order to surface as many perspectives as possible, states need to work with a variety of stakeholders, including people with disabilities, older adults, people whose primary language is not English, advocates, and others. MACs and BACs will be important places to start assembling these test groups.

First, states need to learn about people’s experiences in order to avoid making incorrect assumptions in policy implementation. Individuals might have overlapping reasons for exemptions, for example, or different individuals might qualify for the same exemption but for different lengths of time. If exemptions were programmed to be mutually exclusive, then someone might not be able to report the exemption that is most impactful for their coverage. Or if all medical frailty exemptions were assumed to need renewal, someone with a permanent disability could be more likely to lose coverage for procedural reasons.

Before the front-end is built out, states can test how well people navigate proposed designs through mock-ups or “wireframes.” For communications such as notices, example text that the state plans to use can also be tested. User interface testing will be crucial, especially for catching exemptions, and some groups have conducted research on better language and design choices for OBBBA implementation.

Some specific questions states need to ask are:

• Do people actually understand the words and phrases that the state uses?
• Can people actually complete their application, save their progress if they need to take a break, and get confirmation that they have submitted it correctly?
• Are resources actually discoverable on the website, and/or does a chatbot actually suffice to answer questions? If so, what types of questions?
• Are users able to provide an email address to make an account and remember their chosen password?

States must also take special care to balance access needs with anti-fraud or security measures. There must be proactive consideration of how people can access their application when they do not have their own email accounts or when they rely on a support person, enrollment assister, or advocate to complete applications on their behalf. This may include giving people alternative options, including using their name and date of birth or a case number they can save or creating separate limited-information pages where people can check their application status without having to log in.

Projected impact testing

States can also use quantitative data to understand the potential impacts of choices throughout the implementation process. This includes determining which features and data sources states should prioritize, as well as how the proposed features or designs will actually affect applicants and enrollees. This can be done with existing agency data, new population studies, test data, or during a pilot phase.

While projected impact assessments may seem resource intensive, they allow states to catch issues before roll-out, which minimizes liability and associated costs. States will have to pay for errors eventually, and it is much easier to handle them before they impact people. Advocates in Missouri, along with Upturn, for example, performed an informal audit of the state’s proposed Medicaid Home- and Community-Based Services algorithm, which showed significant unintended effects of that algorithm that the state was able to lessen before roll-out.

The following questions can help guide what data sources and design choices states should prioritize:

• For what percentage of the population does the state have the necessary data to conduct ex parte renewals? What are the demographics (including disability status) of that population?
• What percentage of the population does the state predict will likely qualify for each type of exemption or will report each type of compliance activity?
• For those that the state expects to be exempt from work requirements, how many will the state have access to verification data on (broken down by exemption category and data source)? Are there specific subgroups that are underrepresented in the available data?
• For those who are not likely to be exempt from work requirements, how many will have employment or income data accessible directly by the state? And for those who do not have this data, what is the estimated time and cost associated with reviewing submitted documents?
• What percentage of enrollees currently submit their application online versus in person, by phone, fax, or by mail?
• What is the current demand for application assistance, such as navigators?
• What volume of calls can the agency currently handle, and how long are wait times? What proportion of people are calling to ask general questions versus questions about their application or to apply?
• What percentage of enrollees and applicants have home internet access? How many rely on a smartphone for internet access, and, of those people, how many have bandwidth or data limits?
• How many people without home internet live near institutions such as public libraries where they could access a computer? How many of them are available and have access to transportation during the hours the library is open?

If states planned to use certain data sources on disability status to automatically apply exemptions, for example, they must figure out how many people’s data can be successfully imported from those sources so they can choose how to account for that limitation. Or if a state determines that its residents have limited internet access, they can invest more time in improving call centers.

Once systems have been built up enough to test in a pilot phase, states should determine:

• Step completion rates, showing the percentage of users who are able to proceed to each step in the process—for example, how many people open the application, successfully log in, proceed to each page of the application, and how many complete their submission. This should include details to show rates specific to the exemption and compliance elements of the application and, ideally, would be broken down by exemption category or compliance type.
• Document upload error rates, showing how many document uploads fail and the associated failure reasons, such as too large of a file or wrong file format.
• Page loading time and data requirements, determining if people, especially those with limited internet access, can reasonably use online applications.
• Device and browser information, recording whether the user is a mobile or desktop user and what internet browser they use. This can help detect compatibility issues if some users seem to be “stuck” in parts of the online application.
• Open rates and associated action rates of notices posted in online portals, sent via text message, or other electronic methods.
• System load capacity, making sure it can handle the expected usage.

These insights are crucial for determining whether a system is doing what states intend it to and for ongoing monitoring. States may find out that a significant number of users get stuck on a certain page of the application, for example, and can reevaluate the language on that page or investigate whether technical errors are occurring.

Other outreach considerations

OBBBA only requires that states notify potentially affected enrollees at least 3 months in advance of the policy taking effect and through two modalities, including regular mail or electronically. Yet many aspects of outreach will pose major challenges, and states should plan for and fund outreach as soon as possible, as well as work with MACs and BACs to extend outreach.

Practically, states should provide information in plain language—terms such as “exemption,” “qualifying activity,” and “good cause” have all been found to confuse impacted individuals. Key information should be highlighted, including action steps and consequences. And all communications must be accessible to people with disabilities and people with limited English proficiency.

States should also be aware that electronic contact methods, such as texts and phone calls, can confuse recipients who are not accustomed to the agency contacting them this way. States also should not assume that recipients are comfortable accessing existing benefits portals, have their login information readily available, or know to check the portal for information such as this.

Attempts to introduce work reporting requirements in states such as New Hampshire or Arkansas show examples of what to avoid. These states did not allocate enough funding or time for outreach, their communication modalities did not match residents’ needs, and the language they used caused major confusion. The consequences were extremely low Medicaid enrollment and high procedural termination rates, despite most people already working or being exempt from work requirements.

The consequence of relying on vendors to build public benefits systems is that private entities can essentially prevent the state from implementing its own policies, even though states are liable for issues in their programs’ operations. Vendor failures can greatly compound the harm done to people who are subject to work reporting requirements.

Contracts need to address this by clarifying how outcomes and performance will be tested and monitored, how issues will be proactively addressed, who is responsible for fixing them, who is allowed to fix or change system components, how much system changes cost, and how long changes will take.

Choose vendors carefully

States should take seriously vendors’ track records on building public benefits systems. Larger vendors, such as Deloitte, are associated with significant issues in systems. Some of these issues are described in the recent letter from the Senate Finance Committee, and in the FTC complaint and supplement submitted by the National Health Law Program, Electronic Privacy Information Center, and Upturn. Problematic vendors may reuse code across states, building in the same deficiencies, and charging each state independently to fix its particular system. Data services vendors such as Equifax have similar profit incentives.

Given this, states should not assume that their existing Medicaid eligibility system contractor is the best choice for implementing these work reporting requirements. It may actually be more costly to continue contracting with a vendor that has known issues than to find a new vendor with more aligned accountability practices—especially if the known issues of the current vendor lead to legal liability for the state.

Existing systems’ vendors may argue that their technology is too complicated or proprietary for another vendor to build on, but this is often just a marketing tactic. Working with a different vendor would certainly still take careful planning, the relevant software expertise, and potentially extra time depending on the scope of components, but it could be the best option.

States should instead prioritize vendors that make open-source tools that can be built once and integrated into different states’ systems and that have system updates that get pushed out to each state’s copy of the tool. These vendors are often nonprofit or B corporation entities and therefore have less incentive to inflate costs and timelines or to take advantage of how states each have their own implementation processes. This approach also follows CMS requirements that Medicaid eligibility and enrollment systems “promote sharing, leverage, and reuse” of technologies across states.

To be sure, states should not automatically trust vendors just because they are small or not-for-profit. Vendors of any size and type can cause issues such as lock-in, added security risks, errors, or inflated costs.

Finally, states should also consider what capabilities they have in-house and not assume that vendors must build every part of the system. There may be less technically complex elements, such as online forms or databases, that are feasible for states to build and therefore have internal control over.

Considerations for contract requirements

States can get far along in the implementation process before realizing a component was not built as needed—and then hear from vendors that the state “did not ask for it,” and if the state wants it, it will set back the timeline and cost extra. To address this, states need to ask for the important features up front, particularly the ones that support system testing and monitoring. Getting feedback and input from applicants, enrollees, and advocates early in the process can help proactively identify some of these features.

Responsibility for fixing implementation errors

When an error occurs or the system does not behave as expected, states should have a plan in place with vendors and create a clear delineation between what constitutes a “change request” or “enhancement” (asking for a new feature) and what constitutes a system “defect” (a vendor-side error in implementing the state’s plan).

The “defect” definition should also cover choices that the vendor makes when trying to translate contract requirements into system design. Vendors should be required to dialogue with the state when requirements are “underspecified” to determine what the actual implementation should be, instead of making assumptions.

Options to pause determinations

The Centers for Medicare and Medicaid Services has called for an option to pause procedural disenrollments when automation errors are detected. Sometimes referred to as an off switch, states should make sure vendors build controls for stopping automated determinations from occurring for certain groups or the entire population.

Further, systems should make it easy to proactively reinstate coverage in batches when groups of people are identified as having been erroneously terminated or denied.

Publish known system errors and resolution timelines

Vendor contracts should allow states to publish known errors when they arise. Vendors should supply states with descriptions of the errors and the populations likely affected, and states should publish these, along with clear instructions for applicants and enrollees or advocates to take action. This will allow applicants and enrollees to find out if they need to reapply, contact the agency, or file an appeal, which will help counter erroneous terminations and application drop-offs. When vendors fix issues, they can be marked as closed but stay listed for transparency’s sake.

Plans to implement user testing and continued monitoring

Vendors have a major role in facilitating the user testing explained in the previous section. Testing with user groups must be built into development timelines, and vendors should be required to produce the mock-ups and reporting infrastructure to enable it.

Further, the same metrics collected to pilot the system, including step completion rates and document upload error rates, should continue to be monitored after roll-out to see if they are contributing to procedural terminations. States and vendors must account for the resources required to monitor the system.

Detailed public reporting on system outcomes and user experience

As required by the Centers for Medicare and Medicaid Services, state systems must produce “transaction data, reports, and performance information” to evaluate the system. States should require that vendors collect data on both eligibility outcomes, as well as user experience, and disaggregate data by demographics and compliance categories. Like known system errors, all monitoring metrics should be publicly available.

On eligibility outcomes, vendors should build in reporting for approvals, denials, terminations, and requests for information, whether they were done ex parte or manually, the type of exemption or compliance activity, and the data sources used in the process. A good list from the Center on Budget and Policy Priorities can be found here.

Further, states should get more details on procedural denials and whether they are from new work reporting requirements versus other parts of the process. Some useful metrics would be how many people:

• Claimed an exemption or reported compliance activity but failed to submit documentation, and were denied
• Claimed an exemption or reported compliance activity, submitted documentation, but were denied due to the quality of the documentation
• Were terminated or denied after not responding to a request for information that was sent because they could not be automatically verified
• Reported that data about them used to attempt automatic verification was inaccurate
• Did not renew an exemption for which they qualified in an earlier coverage cycle, broken down by type of exemption and whether they maintained coverage
• Appealed the agency decision, and on what basis

High-level metrics regarding number of terminations should also be broken down by county or ZIP code. More fine-grain metrics in the above bulleted list should be public but potentially not be broken down by county so as to preserve the privacy of individuals residing in sparsely populated areas, especially where Medicaid is administered at the county level and enrollees and applicants are in the same communities as administrators.

Making systems less burdensome to modify

Vendor choices affect how technically complex making a change to the system will be. The Centers for Medicare and Medicaid Services requires that states build flexible, modular systems where business rules are separate from “core programming.” This means vendors should follow best programming practices to not “hard code” or directly embed data into programs. This makes it significantly simpler to change the specifics of policies, such as the length of a renewal window or the list of diagnosis codes checked to identify medical frailty exemptions.

States should also require that they have direct access to nontechnical components such as the language that appears on notices or websites. For notices, which are usually automatically generated using templates, states should be allowed to directly modify the text elements of templates.

Human-readable audit logs for system errors

To enable the state agency to more quickly identify the source of errors and the affected population, the system should produce an audit trail for each decision, detailing the sequence of rules that were applied to arrive at the individual outcome. These audit trails could be useful in notices as well, to inform individuals what rules were applied to them.

There are still many details yet to be clarified by the Centers for Medicare and Medicaid Services in guidance, but states should begin planning now for the resources it will take to properly test their implementation and to handle the volume of assistance needed once the policy takes effect. Better choices now, even ones such as testing that seem costly, will save significant administrative costs in the long run and will allow the Medicaid program to actually serve people as it should.

Please reach out to the Benefits Tech Advocacy Hub through our contact form if you have questions about anything in this guide or are interested in collaborating on harm-reduction strategy in your state.

Special thanks to our additional technologist support from EEAMO Bridges in researching and drafting these recommendations.