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.
The criterion: no new Horizon 3 experiment, module, or funded increment is done until there is a way to test against non-sensitive production-like data, and that capability remains available to any other vendor engaging in the environment. A team delivering an eligibility slice leaves behind the de-identified or synthesized data and working interfaces needed to test that slice. The next team, whether a partner or a competitor, starts by building against what the last team left. Test capability accumulates as a byproduct of delivery rather than as an infrastructure project someone must scope, fund, and maintain on faith, and it grows in exactly the places where work is actually happening.
This criterion addresses several of the RFI’s stated problems. It makes vendor transitions real rather than theoretical, because a replacement vendor can prove capability against the incumbent’s environment before award. It makes claimed module boundaries testable, because interchangeability can be demonstrated rather than asserted. And the same standard should bind CMS’s own interfaces: any requirement that must be met at the federal level, from T-MSIS submission to hub integration, is not done until it can be tested against, continuously, by anyone building toward it. Funding follows naturally through the APD process: testability as a condition of payment for each increment, not a separate line item.