The Standards Version Advancement Process exists because regulation moves slower than HL7 does. Certification criteria name a specific version of a specific implementation guide; those criteria change through rulemaking, which takes years; and in the interval, the standards community ships new versions that the certified product is not allowed to use. SVAP is the release valve — a pathway for developers to certify against newer versions without waiting for the next rule.
ONC announced the 2026 approved versions on June 30, 2026. Voluntary certification against them opens August 29, 2026, alongside the versions approved in prior SVAP cycles (ONC).
The eight approved versions
- United States Core Data for Interoperability (USCDI), Version 6
- HL7 FHIR US Core Implementation Guide, STU 9.0.0 (June 2026)
- HL7 Consolidated CDA Release 5.0.0 — US Realm (June 2026)
- HL7 FHIR Da Vinci — Coverage Requirements Discovery (CRD), v2.2.1
- HL7 FHIR Da Vinci — Documentation Templates and Rules (DTR), v2.2.0
- HL7 FHIR Da Vinci — Prior Authorization Support (PAS), v2.2.1
- 2026 CMS QRDA I Implementation Guide (updated May 2025)
- 2026 CMS QRDA III Implementation Guide (updated December 2025)
Two things stand out in that list. The first is that USCDI v6 and US Core STU 9 arrive together, which is the pairing that actually determines what data a certified system can carry. The second is that the three Da Vinci prior-authorization guides appear here at exactly the versions the FY2027 IPPS final rule adopted as regulation, effective October 1, 2026 — the same CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1.
That overlap is the most useful signal in the announcement, and it is easy to miss because the two documents come from different rulemaking tracks. For the prior-authorization guides, SVAP is not offering an optional early look at a version that may or may not become required. It is offering an early on-ramp to versions that are already headed into the certification criteria. A developer certifying to those three under SVAP is doing required work early, not speculative work.
What SVAP does not do
The word doing the most work in every ONC description of this program is voluntary. SVAP creates a pathway; it does not create an obligation, and adopting an approved version does not relieve a developer of the baseline certification requirement.
This is the point most often garbled in secondary coverage, which tends to describe SVAP approvals as though they were deadlines. They are not. There is no announced developer deadline attached to the 2026 cycle, and a product that stays on the regulatory baseline version remains compliant. The pressure to advance comes from customers and trading partners, not from the certification program.
That distinction changes how the decision should be framed internally. The question is not “when must we move to USCDI v6” — the program does not answer that. It is “what do we gain, and what do we owe our customers, by moving before we are required to.”
USCDI v6 and the recurring version-skew problem
USCDI v6 expands the data classes and elements a certified system can consistently exchange. Each USCDI increment does, and each increment recreates the same operational problem: the sender and the receiver are rarely on the same version.
A system certified to USCDI v6 exchanging with a partner on v3 does not fail. It degrades — the additional elements have nowhere to land, and the exchange completes with less than the sender could have provided. Nothing errors, nothing alerts, and the data-quality loss is invisible unless someone is specifically looking for it. Organizations that track interoperability by transaction success rate will see a healthy number and a quietly diminished payload.
For developers, this argues for two things that are less obvious than “upgrade.” The first is knowing and recording which version each trading partner is actually on, rather than assuming the certified version is the operative one. The second is being honest with customers about what a USCDI v6 upgrade will and will not deliver on day one: the capability is unilateral, the benefit is bilateral.
US Core STU 9 carries the same dynamic in a more technical register. It is the FHIR profile layer that determines how USCDI data is actually represented on the wire, which is why the two move together and why upgrading one without the other produces a product that is coherent on paper and awkward in integration.
C-CDA 5.0.0 is the quieter item
Consolidated CDA Release 5.0.0 will get less attention than the FHIR entries, and for a certain class of vendor it is the more consequential one. Document-based exchange has been declared legacy for the better part of a decade and continues to carry an enormous share of real-world clinical data movement — transitions of care, referrals, and the long tail of exchange partners who are not standing up FHIR APIs on any near-term schedule.
A major C-CDA release is a meaningful maintenance event for products with a large installed base of document-exchange integrations. Treating it as a footnote because the industry’s attention is elsewhere is how organizations end up with a modern API surface and a document pipeline nobody has touched in years.
The QRDA guides and a dating oddity
The two CMS QRDA implementation guides are labelled for 2026 but carry update dates of May 2025 (QRDA I) and December 2025 (QRDA III). This is normal for quality-reporting specifications, which are published well ahead of the reporting year they govern, and it is worth flagging only because the mismatch between the guide’s name and its update date reliably confuses people encountering the naming convention for the first time. The 2026 guides govern 2026 reporting; they were finalized in 2025 so that vendors could build against them.
How to decide
For most certified developers, the 2026 cycle splits cleanly into two categories.
Advance the prior-authorization guides. CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1 are moving into the certification criteria on October 1, 2026 regardless. Certifying under SVAP now converts a future compliance event into a controlled one.
Schedule USCDI v6 and US Core STU 9 against customer demand. These are the versions that determine competitive position on data richness, and the right timing depends on whether your customers’ exchange partners can receive what you would be able to send. Ask before building.
C-CDA 5.0.0 belongs on the maintenance roadmap in proportion to how much of your traffic is still document-based — which, for most organizations that check honestly, is more than they assume.
Sources: ONC, “Advancements in Health IT: ONC’s 2026 Approved SVAP Standards” · ONC, Standards Version Advancement Process · ONC, health IT standards in the FY2027 CMS IPPS final rule