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.
The problem is that I 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. I recommend CMS make replaceability the certification test for any claimed module boundary, and stop certifying category compliance. Standard data schemas and exportable-by-default data (question V-6) follow naturally, because they are the prerequisites for passing the replaceability test.