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.
This is not a distant critique. We participate in MITA workgroups and discussions. For years, we have asked vendors and state leaders a simple question: what do you value about MITA? We have never once received an outcome-oriented answer. Vendors value it as dependable, low-risk revenue: structured work that must be done, regardless of whether it changes anything. State leaders value it as a funding pathway: boxes checked, compliance satisfied, dollars unlocked. Some have gone further, describing the appeal of paying a vendor to complete MITA work precisely so their own teams do not have to think about it. Every one of these answers describes MITA’s value as the avoidance of work that matters. None connects it to a resident served, a caseworker’s day improved, or a dollar better spent. Two decades in, that silence is the evaluation.
CMS has already taken good steps to create flexibility around MITA's more prescriptive elements, yet many states still treat the framework as gospel for how Medicaid Enterprise Systems must be organized, creating confusion about what is required versus what is inherited habit. Where we do see potential value for a framework like MITA is in documenting the current state: what systems are in use, what integrations connect them, how business processes traverse them end to end, and where the handoffs between business users sit. But that value holds only under one condition: the documentation must be kept current as part of every change to the environment. Most legacy environments cannot support this, so architecture documentation arrives as a one-time deliverable that is out of date on delivery. A current-state map that lives is an asset for Horizon 1 and 2 work. A map that ages is another artifact for the shelf.
The RFI asks which standards are underutilized. The honest answer is that the industry standards that matter (FHIR, X12, NIST) are underutilized not because states lack a framework that mentions them but because very little in the delivery environment rewards using them. A standards lifecycle that prevents technical debt accumulation (question SE-8) is one where standards are small, running, testable, and retired when the running evidence stops supporting them. Frameworks maintained as documents accumulate debt by design.
None of this means walking away from 42 CFR 433.112(b)(11)'s requirement that states "align to, and advance increasingly, in MITA maturity for business, architecture, and data" as a condition of the 90 percent enhanced match. It means measuring that maturity differently for Horizon 3 work: by outcomes and working software rather than architecture documents. A definition built that way satisfies the letter of (b)(11) and does a better job of what MITA maturity is supposed to measure in the first place, an enterprise that is actually more capable, not just more thoroughly mapped.
We recommend a single maturity indicator to anchor this new pathway: on average, how long does it take a state to make a change in its environment in response to an emerging business need or major policy change? A change in one week or less reflects level 5 maturity. One month reflects level 4. Six months reflects level 3. One year reflects level 2. Two years or more reflects level 1.
This measure could be applied against any existing capability matrix and used here as a recommended Horizon 3 version of MITA maturity, complementing the lead time to learn measure introduced in Start 2. An enterprise that cannot operate at level 4 or better has reached a point at which transformation may be needed before improved maturity in other areas is beneficial, because it takes too long to do anything.
We participate in the MITA 4.0 workgroups, which have been meeting for roughly two years and are producing a genuine improvement over the current framework for Horizon 1 and 2 work. But 4.0 is built for exactly that: well suited to swapping one module for another that works about the same, and not suited to transformation work bigger than that.
Define the Horizon 3 program around outcomes and working software, reference industry standards where they serve, and give Horizon 3 its own MITA maturity pathway rather than the one built for Horizon 1 and 2.