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.
The extension worth making as part of the standards program: pair government ownership with open publication as the default, and let publication do the assurance work that standards checklists currently pretend to do. In the mechanism we have drafted as proposed legislation, every delivered solution, including source code, frameworks, and documentation, is published quarterly to a public repository under an OSI-approved open source license, with personally identifiable and health information removed or synthesized.
This isn't a new idea for HHS. ACF's CCWIS rule already requires title IV-E agencies to hand agency-owned software built with federal funds to a designated federal repository on request, citing the same authority, 45 CFR 95.617, that governs Medicaid systems. What we are asking CMS to do here has already been operationalized elsewhere in the department. CMS's own Reuse Repository, established under SMD #18-005, shows the appetite already exists: it just stops at procurement and design documents behind a state-only login, rather than the code itself. Publication closes that gap.
Publication should be layered, because transparency serves different readers at different levels of abstraction. Code turns over too fast, especially in the agentic age, to be the primary carrier of public trust. What changes slowest and explains most is intent: what outcome each system is responsible for, and the process by which that intent is currently fulfilled. The published record should therefore run from intent, to process, to architecture and interfaces, down to code and data schemas, with the layers that humans rely on for trust kept deliberately current and readable, and the fast-churning code layer increasingly reviewed by automated means.
Each published solution is then open to comment and review by any person in the country across four dimensions: accessibility, privacy, security vulnerabilities, and whether existing solutions better achieve the same outcome. Each dimension reads a different layer: better existing alternatives are surfaced at the intent level, privacy concerns at the process level, vulnerabilities at the code level, and accessibility against the running solution itself, which is why publishing code alone was never enough. Findings are collected, triaged, and reported publicly. This is not publication after a security review; the publication is the review, and it is more rigorous than any checklist because the reviewers are unlimited, motivated, and uninvited. The fourth review dimension deserves particular attention: a standing public mechanism for surfacing better existing alternatives is the cheapest duplicate-spend prevention the ecosystem could have, and it directly serves the reuse goals this RFI describes. It is also the dimension anyone can participate in without reading a line of code, because it reads the layer that changes slowest.