As states move from debating Medicaid work and community engagement requirements to actually implementing them, one question keeps coming up in CIO and Medicaid Director conversations:
“Should we build this directly into our integrated eligibility system (IES), or treat it as a separate, modular component?”
On the surface, putting everything inside the IES can sound cleaner. One system, one rules engine, one place to manage eligibility. But when you look at the policy risk, technical complexity, and implementation timeline for community engagement (CE) and work requirements, a different conclusion emerges:
Hardcoding CE into your IES is the most expensive, least agile, and highest‑risk path you can choose.
A modular, decoupled approach is far more aligned with what CMS is signaling, what states say they are worried about, and what recent history has already taught us.
What we have learned from the first round of work requirements
We are not starting from a blank slate. Prior to the new federal mandate, 13 states received approval under section 1115 waivers to impose Medicaid work or community engagement requirements. Most never fully implemented them. Courts blocked several waivers, and states suspended others after legal challenges and operational issues. Arkansas was the only state to actually disenroll people for failing to meet or report work requirements before its waiver was invalidated.
Independent evaluations of Arkansas’ experience found that thousands of people lost coverage, most of whom were already working or met an exemption but could not navigate the reporting system. There was no evidence of increased employment. Kentucky’s waiver was struck down in federal court. Indiana’s Gateway to Work program was suspended after litigation and later formally ended by the federal government.
The policy debate will continue, but the operational lesson is already clear: these programs are complex, politically volatile, and likely to change. That alone should give states pause before embedding CE logic into the heart of their IES.
What states themselves say they are worried about
A recent KFF survey of state Medicaid agencies asked how they are preparing for the new national work requirement and what they see as the biggest challenges. The top concerns included:
- The scale and complexity of system changes needed
- The difficulty of matching and integrating data across programs and data sources
- Tight federal timelines leading up to late‑2026 and 2027 implementation
- Limited IT and vendor capacity to take on new work while managing other priorities
KFF’s broader work requirements tracker reinforces that nearly all expansion states will be affected and that most are working under significant time and staffing constraints.
In that context, “just put it in the IES” stops sounding simple and starts sounding risky.
Why the IES is the wrong place to embed community engagement
There are several reasons not to make CE a permanent resident of your IES codebase.
1. Cost and timeline: IES changes are slow and expensive
Your IES is one of the largest, most tightly controlled systems in your environment that touches:
- Core eligibility rules
- Case workflows
- Determination and redetermination logic
- Notice generation
Each of these components require careful design, testing, and, often, CMS review as part of APD and certification processes.
Now layer on CE:
- Monthly or rolling compliance checks
- New exemption categories and hardship rules
- Cross‑program data matching
- New notifications and appeal pathways
Implementing all of that inside the IES will be a multi‑year effort for most states. The federal clock does not care. It is counting down to January 1, 2027.
A modular CE component can sit alongside the IES, consuming existing data and sending back determinations or decision support. That approach dramatically reduces the scope of core IES changes and makes it far more realistic to hit federal timelines.
2. Guidance is still evolving and will continue to change
CMS has begun releasing guidance on who is exempt, how hardship should work, how many months of community engagement must be demonstrated, and what notice and outreach timelines look like. That guidance will continue to evolve as CMS issues additional sub‑regulatory updates and states submit questions.
If you hardcode CE into the IES, every change becomes an IES change request with all of the associated cost and risk. This includes:
- Federal hardship categories
- Lookback windows
- Acceptable data sources
- Exception handling
A modular CE engine can implement most of this logic in configuration and rules, not custom code. When CMS clarifies or revises a rule, you change a configuration, not your IES.
3. Legal and political volatility
The last decade has shown that Medicaid work requirements are politically contested. Courts have already struck down multiple waivers. Prior programs were halted or reversed when administrations changed.
Under the new national mandate, work requirements are on firmer statutory ground, but they remain deeply political. A future Congress or administration may narrow them, modify them, or even repeal them.
If you have embedded CE logic deep in your IES, you will be left with:
- Stranded investment in rules that no longer apply
- Complex code to unwind under tight timeframes
- Testing cycles to ensure that rolling back CE does not break core eligibility
A decoupled component gives you insulation. If policy changes, you can scale back or turn off CE features without rewriting your IES.
4. Community engagement looks more like an overlay than a core rule
CE compliance is not a single yes/no question evaluated once a year. It is:
- Ongoing
- Month‑by‑month
- Dependent on multiple data sources (wage, employment, education, programs like SNAP and TANF, and sometimes self‑attestation)
Conceptually, it is closer to a continuous monitoring overlay than a traditional one‑time eligibility rule. That is exactly the kind of thing that fits better in a dedicated component designed for:
- Data ingestion and matching
- Business rules that evolve over time
- Caseworker decision support
- Member notifications and self‑service tools
It is not what your IES was originally built to do.
5. CMS is pushing modularity, not monoliths
CMS’s own IT guidance has been moving toward modular Medicaid Enterprise Systems rather than single, monolithic platforms. The Streamlined Modular Certification and related guidance emphasize modular components, clear interfaces, and incremental certification, rather than one big system that does everything.
Treating CE as a module that fits the modular vision to:
- Consumes data from the IES and other sources
- Returns determinations, risk scores, or recommendations
- Integrates with notices and portals
Trying to fold CE fully into the IES pushes you in the opposite direction.
The case for a modular community engagement solution
If “not in the IES” is the conclusion, what does a better approach look like?
At a high level, a modular CE solution should:
- Integrate with, but not depend on, the IES
Use existing eligibility data, but keep CE logic and workflows separate so that you can change one without destabilizing the other. - Use data first, member contact second
Prioritize automated data‑driven verification through wage files, public program data, and other sources before asking members to attest or submit documents. This is consistent with CMS’s “data first” philosophy and helps avoid unnecessary coverage loss. - Support federal exemption and hardship rules out of the box
Represent statutory exemptions and optional hardship categories in configuration, not hard‑coded logic, so states can align exactly with CMS guidance and adjust as it evolves. - Provide a continuous compliance view
Offer dashboards and work queues for CE compliance that show which members are:- Fully compliant
- Exempt
- At risk due to missing data or activity
- Approaching notice and termination timelines
- Minimize member abrasion
Integrate member‑facing channels (portal, mobile, call center scripts, notices) so that individuals understand what is required and what they have already satisfied, instead of navigating multiple disconnected systems. - Be reversible and adaptable
If policy changes, the state should be able to scale back or reconfigure CE without a multi‑year IES retrofit.
But isn’t one system simpler?
It can feel intuitive to say, “we want one eligibility system, so everything should go there.” In practice, that simplicity is mostly illusory. The reality looks more like:
- Long queues of change requests against IES vendors
- Difficult tradeoffs between CE work and other statutory updates
- Long testing cycles to ensure nothing breaks in eligibility
- Delays that push states closer to federal deadlines with less time to adjust
A modular CE component does not create “another system” in the negative sense. Done correctly, it becomes:
- An extension of your eligibility ecosystem
- A specialized engine for a specialized problem
- A way to move faster without touching every part of the core stack
You still present a unified experience to members and workers. You simply stop asking your IES to do something it is not well designed to do.
Lessons from Arkansas, Kentucky, Indiana: design for uncertainty
The early work requirement states offer a simple lesson: design for uncertainty. Arkansas’ first implementation generated significant coverage losses and was ultimately halted. Georgia and Arkansas have already scaled back prior proposals in light of those experiences. Kentucky’s initial effort was blocked in federal court. Indiana suspended its program amid litigation before the federal government formally ended it.
Today’s national work requirement is different in structure, but none of that volatility has gone away. If anything, stakes are higher because implementation will be national rather than limited to a few waiver states.
Designing CE as a modular overlay acknowledges that:
- Policy details will evolve
- Data availability will vary
- Hardship and exemption rules may be tweaked
- Future administrations may rethink the entire construct
Your technology should give you the ability to respond without tearing down core systems each time.
Questions every state should ask before touching the IES
If you are in a planning meeting and someone says, “let’s just add this into the IES,” here are a few questions worth asking:
- How many major eligibility changes are already in the IES backlog, and what will adding CE do to that schedule?
- If CMS modifies hardship rules, acceptable data sources, or review periods in 2027 or 2028, how quickly can we adapt IES logic and testing?
- What happens to our IES if a future Congress repeals or narrows CE requirements?
- Can we get enhanced federal funding and streamlined certification more easily for a modular CE component than for a big IES retrofit?
- Are we designing something that protects eligible people from losing coverage due to system complexity, or something that adds another layer of administrative burden?
If you are not comfortable with the answers, then the case for keeping CE out of the IES and in a modular solution practically makes itself.
Conclusion
Community engagement and work requirements are not just another eligibility rule to bolt onto your existing system. They are a new layer of continuous, data‑driven monitoring that is:
- Policy‑volatile
- Operationally complex
- Time‑sensitive
- Politically visible
Embedding that directly into your IES will be costly, slow, and difficult to unwind. A modular CE approach gives you flexibility, protects your core systems, and aligns with where CMS and the broader Medicaid IT ecosystem are already heading.
For states, the strategic question is not just “How do we comply by 2027?” It is:
“How do we build something that can adapt when the policy, the data, or the politics inevitably change?”
Designing CE as its own component, rather than hard‑coding it into your IES, is the strongest answer to that question.
