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.
The problem is that we have never observed a module in the MES ecosystem that actually has those properties. Module categories inherited from MITA business areas produced procurements that are neither independent (they share entangled data and infrastructure), nor interchangeable (no state can swap one vendor’s module for another’s without a multiyear project), nor individually implementable (every integration is bespoke).
The category confusion runs deeper than system boundaries. Some states now procure IV&V, quality assurance, or even the systems integrator itself as modules. Whatever those engagements are, they are not independent, interchangeable units of functionality that can be individually developed, procured, and implemented; they are professional services wearing the label. When the same word describes a claims engine and an oversight contract, the word has stopped meaning anything, and it becomes clear that funding categories, not architecture, are doing the defining.
The result is the worst of both worlds: monolith-scale integration risk distributed across more contracts. Real modularity is a property you can test: can this component be replaced by a competitor's in weeks, with data intact, without renegotiating every interface? Until the answer is yes, the module boundary is fiction. We recommend CMS make replaceability the certification test for any claimed module boundary, and stop certifying category compliance.
CMS should not attempt to support this with pre-published schemas or reference architectures; no one has yet built a module that passes this test, which means no one yet knows what the supporting standards should say. Instead, make replaceability a definition of done for anything newly created: certification is the demonstration itself, a successful swap performed in a test environment with data intact. Apply it to new boundaries, not retroactively to entangled legacy systems. When the first implementations pass, publish what they did, and let the schemas and interfaces that emerge from working swaps become the reference for everyone else.
Standard data schemas and exportable-by-default data (question V-6) follow naturally, because they are the prerequisites for passing the replaceability test. Or the demonstrations may teach us something else: that in some situations replaceability is better achieved through flexibility and federation than through standardization, particularly as AI-assisted adaptation makes translating between interfaces cheaper than agreeing on them. A definition of done leaves room for that discovery. A predefined standard forecloses it.