Response to Request for Information
Medicaid Enterprise Systems (MES) IT Standards
RFI 269888
This response is organized as a set of Start, Stop, and Continue recommendations rather than question-by-question answers, because the recommendations are interdependent and the format makes the underlying theory of change visible.
Submitted by Kevin Sutherland · kjsuther@si-delivery.com
Contents
Start
Ten things CMS should begin doing to make MES transformation possible.
- S1StartAddresses SA-7, SA-8, SE-4
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 - S2StartAddresses SA-5, SA-10, V-10
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 - S3StartAddresses SE-2, SA-6, SE-7
Pushing decision authority to the people closest to the work
A reliable predictor of modernization failure I 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 - S4StartAddresses V-9, SE-1, SE-8
Preparing for AI-built software as a transformation driver
This recommendation may be more contested than the others, so I 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 - S5StartAddresses SA-10, V-2, V-4
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 - S6StartAddresses V-3, V-5, V-9
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 - S7StartAddresses SA-4, V-3, SA-9
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 - S8StartAddresses SA-5, SA-10
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 my experience, by the time an approved funding request becomes running work, nearly everything about the original request has changed.
Read the detail - S9StartAddresses SE-9, SA-9
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 - S10StartAddresses SE-3, SE-4, SA-6, V-10, SA-8
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
Continue
Three reforms already underway that deserve defense and extension.
- C1ContinueAddresses V-3, SE-5
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 - C2ContinueAddresses SA-3, SA-6, SE-2
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 - C3ContinueAddresses V-6
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
Stop
Seven practices that consume the capacity transformation requires.
- X1StopAddresses SE-4, SE-2
Forcing solution and execution decisions to come from people far from the work
Across every large-scale standardization effort I 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 - X2StopAddresses SE-4, SE-5
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 - X3StopAddresses SA-2, SA-3, SE-8
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 - X4StopAddresses SA-1, V-6
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. I support that definition without reservation.
Read the detail - X5StopAddresses SE-4, V-10, V-1
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 - X6StopAddresses V-1, SE-1, SE-4
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. My 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 - X7StopAddresses V-7, SA-5, SE-8
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