2026 SVAP clears USCDI v6 for voluntary certification advancement
The approval creates a newer voluntary path for certified health IT, but it does not replace the USCDI v3 baseline required under HTI-1.
Editorial figure by Health Interoperability Review. Source context: ASTP/Office of the National Coordinator for Health IT.
Two standards baselines now need separate labels
The 2026 Standards Version Advancement Process gives certified health IT developers a route to incorporate approved newer standards without waiting for a rule to rewrite every certification criterion. That makes USCDI v6 relevant to product roadmaps and buyer diligence, but the voluntary path should not be confused with the mandatory HTI-1 baseline.
A useful provider record needs at least three fields: the version required by regulation, the newer version a developer has elected to support through SVAP, and the version actually available in a customer's production environment. A generic claim such as 'supports USCDI' does not distinguish those states.
Buyers should ask for testable version evidence
Implementation teams should ask which profiles, data classes, elements, terminology bindings, and API behaviors are included in the claimed version. They should also ask whether the capability is generally available, separately licensed, limited to a pilot, or dependent on an upstream EHR or payer connection.
The practical work is change management across data models, mappings, validation suites, downstream applications, and operational monitoring. A version badge is useful only when the organization can trace what changed and show that connected systems continue to exchange usable data.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.