Human-Centered Principles for States Evaluating Vendor Solutions to Implement H.R.1 Work Reporting Requirements

Jamila McLean, State Health and Value Strategies

With the passage of H.R.1, states face the most extensive transformation of eligibility and enrollment policies and operations since the enactment of the Affordable Care Act (ACA) in 2010. The law’s provisions require fundamental updates to how states administer the Medicaid program. One of the most significant changes is the requirement for states to establish work reporting requirements for Medicaid enrollees in the expansion population both prior to enrollment and at renewal. This represents an unprecedented departure from prior entitlement-based Medicaid eligibility and requires states to develop new eligibility policy and build or significantly modify eligibility systems to collect new data to verify compliance with that policy. Medicaid work reporting requirements are a significant operational and policy shift as states must begin to examine how to collect and verify information about work, school, or community service participation, while applying exemptions for certain groups such as individuals who are pregnant and postpartum, caregivers, and those who are medically frail.

Data and technology will be critical to implementing work reporting requirements, and states are being approached by many vendors offering data and technology solutions ranging from full system platforms to new data sources for verifying compliance. Given the volume and diversity of proposals, state procurement rules, and an aggressive timeline, states are struggling to assess which options best meet the needs of applicants, enrollees, staff and the program writ large.

The opportunity to mitigate coverage losses for eligible Medicaid enrollees requires technology and data solutions that are well-designed for both enrollees and agency staff, affordable, and integrated with existing systems. Poorly designed systems will lead to coverage losses for eligible individuals—creating new structural barriers to coverage, increasing churn, generating additional workload for already burdened state staff, and risking waste or misuse of taxpayer funds. This expert perspective examines key principles states should consider as they evaluate vendor solutions to support work reporting requirements implementation.

State Considerations for Reviewing Vendor Solutions

Does the Solution Take a Human-Centered Approach?

A human-centered approach ensures that systems and processes are designed around the real experiences and needs of the individuals who use them. States should consider whether the proposed vendor solutions have been designed and tested with meaningful input from Medicaid enrollees and the state staff who support them. Systems that reflect how people realistically navigate programs create efficiencies for the state and lead to better trust, satisfaction, and continuity of coverage for enrollees.

Example questions states should ask:

1. How have Medicaid enrollees, case managers, community partners, and agency staff been involved in co-design and user testing of the system?
2. How will the solution collect and analyze feedback from users such as enrollees, navigators, and state staff to drive continuous improvement?
3. What pathways exist for enrollees to access help if needed (e.g., chatbots, multilingual helplines, FAQs)?
4. Can the system proactively generate outreach such as automatic reminders (“nudges”) via text, email, or automated voice to prevent reporting gaps?
5. Is the platform able to support document uploads in multiple formats (e.g., PDF, JPEG, PNG)?

Has the Solution Been Developed to Mitigate Embedded Bias?

Technology solutions that are built around biased algorithms or data practices can disproportionately impact populations at higher risk of coverage losses and result in inequities. Vendor technology development and testing practices like “red teaming”^[1] can help identify and correct hidden biases by simulating real-world scenarios and stress-testing system logic, data flows, and decision-making algorithms. By requiring vendors to incorporate red teaming and bias audits into their development lifecycle, states can better safeguard fairness, transparency, accuracy, and trust in technology solutions that support Medicaid eligibility determinations.

Example questions states should ask:

1. How do you evaluate your solution for potential bias across race, ethnicity, language, disability status, and other protected classes?
2. Can you provide documentation of fairness testing or audits conducted on your eligibility logic or decision-making models?
3. Do you deploy red teaming or adversarial testing to identify and mitigate bias in your system? If so, how frequently and by whom?
4. What steps do you take to ensure training data used in your system does not reinforce historical inequities or discriminatory patterns?
5. How do you handle missing or incomplete data for under-resourced communities to avoid exclusion or misclassification?

Does the Solution Prioritize Accessibility?

It is essential that eligibility systems are designed to work for all people, not just most people. While current policies prioritize preventing ineligible individuals from receiving coverage, an equally if not more meaningful indicator of system failure is how many eligible people lose or can’t access coverage because they cannot navigate complex systems. By designing for the populations most likely to experience barriers to coverage—such as individuals with disabilities, people in rural areas, those without consistent internet access, and people with limited English proficiency—states can build systems that work for everyone. States should consider how the proposed solutions will meet the unique needs of their Medicaid population, especially communities that may require higher levels of support.

Example questions states should ask:

1. Can your system provide clear, understandable reasons for eligibility determinations to applicants, enrollees and caseworkers?
2. Can members report their work or exemptions through all modalities (e.g., web, mobile app, text, phone, mail, and in-person)?
3. Which languages is the solution offered in “off the shelf”? Are all solution interfaces and communications offered in those languages?
4. Can the solution be adapted to be offered in additional languages that respond to the diversity of the state’s Medicaid population?
5. Does the solution and all interfaces and communications use plain language written at the appropriate reading level (between 6^th and 8^th grade level)?
6. How will the system identify and support enrollees with higher or unique needs, such as people experiencing homelessness or those in rural areas without stable internet access?
7. Do you offer tools or dashboards that allow state staff to monitor disparate impacts in real time?

Does the Solution Emphasize Data Protection, Availability, and Interoperability?

All Medicaid applicants and enrollees deserve, and are entitled to, transparency about how their data are collected, used, and protected. States should consider how solutions meet strict federal and state data privacy and security standards, collect only the information necessary to determine eligibility or exemptions, and communicate clearly with enrollees about data use and consent.

Many eligibility systems are integrated with other social safety net programs, such as the Supplemental Nutrition Assistance Program (SNAP), so interoperability is crucial to prevent duplication of effort, gaps in coverage and administrative errors. SHVS has published a toolkit for states outlining where exemptions from Medicaid’s new work reporting requirements may overlap or relate to exemptions in SNAP to help states identify people who should not be subject to work reporting requirements in Medicaid.

Additionally, states are required to use the ex parte process whenever possible, making access to high-quality, reliable data sources essential. When evaluating vendors, states should prioritize their ability to access and leverage robust available data sources. Lastly, given the constantly evolving policy landscape, platforms should be flexible enough to adapt to state or federal changes without disrupting users, allowing features to be turned on or off as needed.

Example questions states should ask:

1. What safeguards are in place to ensure data privacy, that only necessary data are collected, and that these safeguards are communicated to applicants and enrollees?
2. Does the solution pre-populate or auto-verify hours using existing data [unemployment insurance wage files, SNAP/Temporary Assistance for Needy Families (TANF), new-hire registries]? If so, from which sources?
3. How will the system integrate with the state’s existing eligibility system and other safety-net programs (e.g., SNAP and TANF) to avoid data silos and duplicative reporting?
4. What data sources can the system access to verify compliance or exemptions?
5. How easily can the system adapt to changes in state or federal policy without disrupting data flows or eligibility determinations?

[1] Red teaming is a structured, adversarial testing approach used to identify vulnerabilities, biases, and unintended consequences in systems—especially those involving automation, algorithms, or decision-making logic. It helps ensure that technology solutions are resilient, fair, and inclusive by proactively challenging assumptions and exposing hidden biases before they affect real users.