RFI 269888 · Medicaid Enterprise Systems (MES) IT Standards
CMS wants your inputHave your voice heard
CMS is seeking specific, actionable information about the most significant barriers to MES transformation.
We’ve created a starting point to build upon.
Start with our take. Challenge it. Build on it. Make it Yours.
The bottom line
Quickly understand the problem and proposed direction in plain language.
Shape our response
Share your feedback to help refine and strengthen our recommendations.
Sign-in requiredSubmit your own
Build on these ideas by amplifying, revising, rewriting, or adding recommendations, then submit your own response to CMS.
Sign-in required
Why this response takes a different approach
The perspective
Written from three vantage points inside Medicaid Enterprise System modernization: delivery practitioner on MES implementations, strategy consultant developing modernization strategies with state Medicaid agencies, and advisor embedded inside them, working daily alongside program staff, state IT, counties, and vendors.
That means requirements documents, APDs, go-live support, and certification reviews. Procurements that succeeded and procurements that failed. Twenty-five years of watching the same constraints produce the same results from every seat in the room.
Decades of supporting research, insights, and proposed solutions informed by this learning is published and linked throughout.
Read the introductionThe premise
Across this experience, states have not been constrained by a lack of technology or standards. FHIR, X12, NIST frameworks, cloud architectures, API patterns, and modern data platforms are mature and have been available for years. The binding constraints are institutional: how government learns, makes decisions, procures solutions, and translates established frameworks into effective implementation.
- Lead timeYears from idea to proven outcome, when the work demands weeks.
- Decision distanceChoices made many layers removed from the point of service delivery.
- Procurement structureUpfront certainty required in conditions where certainty is impossible.
- Misapplied frameworksConstructs that describe systems without changing how they get built.
What should CMS start, continue, and stop?
These recommendations work together as one connected approach, not as isolated question-by-question answers.
11Start
actions CMS can take to remove transformation barriers and better support states
- START 1Addresses SA-7, SA-8, SE-4
Start: Classifying work with a horizons model, and creating a new CMS support capability for Horizon 3 (actual ecosystem transformation)
States must run aging systems today while building toward a future state, and most treat this as one undifferentiated portfolio, which guarantees the urgent crowds out the important. Most states cannot keep pace with legislative change as it is, and prioritization collapses into whatever is loudest. Some modernization efforts have attempted to solve this by organizing large vendor contracts around modules or systems, occasionally producing local optimizations within those system boundaries, but this work rarely spans an outcome that a person would experience.
Read the detail - START 2Addresses SA-5, SA-10, V-10
Start: Focusing intently on reducing the lead time to learn
A high-leverage metric CMS could adopt for its Horizon 3 initiatives is lead time to learn: the elapsed time from a state deciding to try something, to a running experiment, to proven or disproven outcomes, to a decision about what to do next. Today that cycle is measured in years. APD approval, procurement, contracting, and certification each add months before learning is achieved. By the time we gain actual experience with a proposed solution, the policy context has changed, the people have changed, and the learning is stale.
Read the detail - START 3Addresses SE-2, SA-6, SE-7
Start: Pushing decision authority to the people closest to the work
A reliable predictor of modernization failure we have observed is decision distance: the number of organizational layers between the people doing and receiving the work and the people deciding how the work will be done. Every layer adds delay, subtracts context, and increases the chance that the decision optimizes for something other than the outcome.
Read the detail - START 4Addresses V-9, SE-1, SE-8
Start: Preparing for AI-built software as a transformation driver
This recommendation may be more contested than the others, so we will state it as a testable prediction rather than an argument: within a short number of years, a small team, and eventually a single experienced practitioner, using AI-assisted development will be able to build a working system covering the core capabilities of a Medicaid Enterprise System in a timeframe and at a cost that today’s market would consider impossible. The ability to deliver software is improving at an exponential pace, and nothing about Medicaid’s functional requirements exempts them from that curve. The prediction is testable through exactly the demonstration mechanisms recommended elsewhere in this response, and CMS should want it tested: if it is wrong, the cost of testing was small; if it is right, every current assumption about vendors, products, and procurement changes.
Read the detail - START 5Addresses SA-10, V-2, V-4
Start: Making procurement reform a first-class element of the standards program
Procurement is where every other constraint compounds. Current models require lengthy cycles, lock in a single vendor before learning has occurred, and measure success at the end when it is too late to act on what was measured. No technical standard survives contact with a procurement model that prevents learning.
Read the detail - START 6Addresses V-3, V-5, V-9
Start: Filtering vendors on demonstrated performance, not proposals
AI has made polished proposals a worthless signal. Any vendor can now generate a compelling response, complete documentation, and a convincing demo environment with a fraction of the effort previously required. The gap between what a vendor can present and what a vendor can deliver is widening, and evaluation methods built on proposal scoring, oral presentations, and reference checks are increasingly poor predictors of performance.
Read the detail - START 7Addresses SA-4, V-3, SA-9
Start: Making production-like testability a definition of done
Vendors building for Medicaid contexts rarely get to build and test against anything real until far too late, which means solutions are designed against assumptions rather than actual conditions. The conventional fix is to prescribe test infrastructure upfront, which replaces one guess with another. The better fix is a definition-of-done criterion applied to the work itself.
Read the detail - START 8Addresses SA-5, SA-10
Start: Funding small and deciding often
Funding processes currently generate more money than most transformation efforts need, delivered in exactly the wrong shape: large, multiyear, tied to activities and deliverables defined before learning has occurred, and nearly impossible to course-correct. In our experience, by the time an approved funding request becomes running work, nearly everything about the original request has changed.
Read the detail - START 9Addresses SE-9, SA-9
Start: Providing the central infrastructure only the federal government can provide
Identity is the domain where genuine national standardization is both achievable and transformative, and it is infrastructure only the federal government can build. The recommendation has three parts.
Read the detail - START 10Addresses SE-3, SE-4, SA-6, V-10, SA-8
Start: Running end-to-end slices in protected environments, and letting standards emerge from what they teach
Every recommendation above assumes a place where Horizon 3 work can actually live. Section S1 described why that place does not exist by default: the current environment absorbs whatever is dropped into it. Drop a cucumber into brine and you get a pickle, every time, and the procurement rules, decision chains, capacity constraints, and incentives of the current environment pickle transformation initiatives just as reliably, regardless of technical merit.
Read the detail - START 11Addresses SE-4, SA-3, SA-6
Start: Putting policy change on the table as part of Horizon 3 transformation
Every state diagnosis we have participated in eventually arrives at the same finding: the primary barrier to improvement is often not the system but the policy encoded in it. Statutes and rules written for paper processes decades ago, verification requirements that cost more to administer than they protect, timelines that made sense in a mainframe batch cycle, categories that force people to be sorted before they can be served. Technology-only modernization treats all of this as fixed. That is not transformation; it is preservation with better tooling.
Read the detail
3Continue
reforms already underway that deserve defense and extension
- CONTINUE 1Addresses V-3, SE-5
Continue: Supporting outcome-based certification, extended further
The shift from checklist certification to Streamlined Modular Certification with outcomes and metrics is an important reform, and it should be defended and extended rather than diluted. The direction of travel is right: certify investments against corresponding improvements in outcomes.
Read the detail - CONTINUE 2Addresses SA-3, SA-6, SE-2
Continue: Supporting state flexibility and novel approaches
CMS deserves credit that this RFI’s framing does not fully capture: when a state brings forward a genuinely different approach, CMS has shown it can engage with it seriously, fund its planning through the APD process, and give it room to develop. Minnesota’s MES Modernization Strategy is a direct example: an approach that departed substantially from conventional patterns, which CMS engaged with and supported through planning and funding authorization. CMS has also shown it can convert pilots into policy: the outcome-based certification approach that became Streamlined Modular Certification grew out of exactly this pattern of testing an alternative before generalizing it. That flexibility is value-add, and the standards program should be designed to preserve and extend it.
Read the detail - CONTINUE 3Addresses V-6
Continue: Enforcing the CMS intellectual property model
The IP approach CMS applies today is a reasonable model and should continue: anything built as part of a paid contract is government property, as is any data generated or collected through that work, while genuinely pre-built commercial products that require no customization appropriately remain vendor IP. If the government pays for code to be written, the government owns that code. There is no reasonable basis for a vendor to retain rights over work the public funded.
Read the detail
7Stop
practices that actively prevent states from innovating, modernizing and achieving outcomes
- STOP 1Addresses SE-4, SE-2
Stop: Forcing solution and execution decisions to come from people far from the work
Across every large-scale standardization effort we have observed, the most common pitfall is the one S3 exists to correct: solution and execution decisions made by people dozens of layers removed from the point of actual service delivery, with limited context, limited relevant experience, or both, substituting proxy concerns (compliance posture, political optics, budget optics) for the outcome itself. The result is technically defensible decisions that are operationally wrong.
Read the detail - STOP 2Addresses SE-4, SE-5
Stop: Calling systems products
The MES ecosystem has adopted product language while remaining organized around specific systems or solutions. Modules are called products. Platforms are called products. Certification tracks product lifecycles. But the product of a Medicaid enterprise is not software. The product is the service a person receives: preventative medical care, transportation to receive that care, life-saving medication provided consistently on schedule. Systems and capabilities are inventory in service of that product, and inventory is a cost to minimize, not an asset to accumulate.
Read the detail - STOP 3Addresses SA-2, SA-3, SE-8
Stop: Using enterprise architecture frameworks and MITA as the definitional frame for transformation work
MITA has been the definitional frame for MES modernization for two decades. In that time it has produced enormous quantities of maturity assessments, capability matrices, and architecture documentation, and approximately zero transformed Medicaid enterprises. The framework describes; it does not deliver. Worse, it consumes the scarce attention of exactly the people who could deliver, redirecting them into documentation exercises whose primary consumer is the compliance process itself.
Read the detail - STOP 4Addresses SA-1, V-6
Stop: Misusing modularity
This RFI defines modularity as a design approach in which functionality is divided into independent, interchangeable modules that can be individually developed, procured, and implemented. We support that definition without reservation.
Read the detail - STOP 5Addresses SE-4, V-10, V-1
Stop: Building procurement on the assumption of upfront correctness
Every traditional procurement embeds the same assumption: that the state correctly identified the problem and the solution before the contract was signed. Timelines, budgets, requirements, and evaluation all hinge on that assumption holding. But Horizon 3 MES transformation is VUCA work (volatile, uncertain, complex, ambiguous), and in VUCA work the optimal approach only becomes visible in hindsight, after iterating. A predictive model applied to adaptive work fails predictably, and the implementation complexity, schedule delays, and cost growth the RFI asks about in V-10 are largely this single mismatch expressing itself.
Read the detail - STOP 6Addresses V-1, SE-1, SE-4
Stop: Treating standardization and COTS adoption as the transformation lever
The RFI’s premise is that movement toward standards-based COTS modular solutions will fix fragmentation, variability, and lock-in. Our experience says the causality mostly runs the other way: fragmentation, variability, and lock-in are produced by the conditions under which states buy and build, and COTS purchased under those same conditions reproduces the same results with a different logo. The most damaging pattern is buying COTS as a forcing function to standardize business processes around vendor constraints rather than mission requirements. It consistently produces poor outcomes and governments locked into costly solutions, which is a condition the RFI seeks to avoid.
Read the detail - STOP 7Addresses V-7, SA-5, SE-8
Stop: Using standards compliance as a barrier to entry
Security and compliance standards are currently positioned as gates vendors must pass before work begins: FedRAMP authorization, NIST attestations, state-specific overlays, each documented before a line of production code runs. This structure keeps capable builders out, keeps compliance-document specialists in, and provides less actual security than it appears to, because point-in-time paperwork assessments are weak predictors of operational security. The standards themselves can be out of date the moment they are written.
Read the detail
Your Voice Matters
Start with SI's response. Keep what works, make changes where you see it differently, and build a response that reflects your perspective.
A living response
This is a working draft. We'll continue refining our response as we receive feedback and develop our thinking.