Standards Version Advancement Process

View / Comment Current Standard / Implementation Specification listing in IBR (170.299) Regulatory Text Citation for Standard / Implementation Specification Adopted Sort descending Certification Criteria(on) References Standard / Implementation Specification View / Comment
§ 170.202(a)(2)


§ 170.202(b)
§ 170.202(d)

§ 170.202(e)(1)

§ 170.204(a)(1)
§ 170.204(a)(2)
§ 170.205(a)(3)

§ 170.205(a)(4)






§ 170.205(a)(4)






§ 170.205(a)(5)






§ 170.205(a)(6)






§ 170.205(b)(1)
§ 170.205(d)(4)
§ 170.205(d)(4)
§ 170.205(e)(4)
§ 170.205(e)(4)
§ 170.205(g)
§ 170.205(g)
§ 170.205(h)(2)

§ 170.205(h)(3)
§ 170.205(i)(2)
§ 170.205(i)(2)
§ 170.205(k)(3)
§ 170.205(o)(1)

§ 170.205(p)(1)
§ 170.205(r)(1)
§ 170.205(s)(1)
§ 170.205(s)(1)
§ 170.213





§ 170.213






§ 170.215(a)(1)
§ 170.215(a)(3)
§ 170.215(a)(3)
§ 170.215(a)(4)
§ 170.215(b)
§ 170.215(b)(1)
§ 170.215(b)(1)
§ 170.215(j)(1)
§ 170.215(j)(2)
§ 170.215(j)(3)

1SVAP is permitted in ONC’s 21st Century Cures Act Final Rule in the Real World Testing CoC/MoC: § 170.405(b)(7) and (8) and ONC-ACB PoPC  §170.523(t)

Add a New Comment

Review comment and Submit

Edit
Comment #1
doc, docx, pdf
Max Size : 10 MB

Comment

CDC Comments on SVAP 2026

Please consider the following for SVAP 2026:  HL7 International. Health Care Surveys Reporting FHIR Implementation Guide, v2.0.0 – STU 2.

a.       Package: hl7.fhir.us.health-care-surveys-reporting#2.0.0

b.       Comment: CDC/NCHS is establishing its internal infrastructure to receive FHIR data and is also conducting pilot testing with providers.

 

CDC Comments on USCDI version 3.1 in SVAP 2026

Please see attachment with a comment on page 15. 

We request the Occupational Data for Health version be updated to 20260427 for both Occupation and Occupation Industry data elements.

USCDI-Version-3-1_2025_508_SVAP update_CDC_NIOSH_1.pdf

Epic 2026 SVAP Comments

Please see the attached for feedback from Epic on 2026 SVAP proposals.

2026 SVAP Comments.pdf

AMA comments on SVAP 2026

AMA’s overarching recommendations for the 2026 SVAP

The AMA recommends that ONC apply the following principles before approving any standard or implementation specification for SVAP advancement:

First, ONC should evaluate operational readiness, not only technical maturity. A standard should be considered “ready” only when it is final or otherwise stable, publicly available, supported by conformance resources, accompanied by test data and test tools, and demonstrated in real-world implementations that include ambulatory physician practice workflows.

Second, ONC should require clear backward compatibility and version transition expectations. A certified module’s adoption of a newer version should not break exchange with physicians, hospitals, laboratories, pharmacies, payers, public health agencies, or patient-facing applications that have not yet upgraded. Where multiple versions will coexist, ONC should require clear version negotiation, transition guidance, and transparent documentation of known incompatibilities.

Third, SVAP should not shift new work to physicians. A standard should not be considered successful merely because a message can be generated or an API endpoint can return technically conformant data. ONC should test whether the implementation reduces manual entry, reduces portal switching, improves reconciliation, and returns information in a form that physicians and care teams can use without rework. Furthermore, the Health IT End-Users Alliance, a member organization including the AMA and nine additional medical professional entities, supports this approach. We urge ONC to consider our consensus statement, outlining how and why real-world testing is needed to ensure technology works for patients and providers.  

Fourth, ONC should require meaningful client notice. Developer notice to clients should include the specific version adopted, affected certification criteria, expected user-visible workflow changes, backwards compatibility limitations, implementation timelines, support resources, and any fees or contract changes associated with the upgrade. Physicians should not have to discover after implementation that an SVAP-enabled upgrade affects prior authorization, clinical documentation, API access, quality reporting, or public health reporting workflows.

Fifth, ONC should coordinate SVAP with CMS, public health agencies, and HHS-aligned programs. ONC’s own standards bulletins note that USCDI is referenced across HHS programs, including CMS’s Interoperability and Prior Authorization Final Rule and TEFCA. SVAP approvals should therefore be coordinated with CMS reporting timelines, payer API readiness, public health receiver readiness, and the certification test method so that physicians are not penalized for trading partner delays.

USCDI, US Core, SMART App Launch, and standardized APIs

The AMA supports the continued evolution of USCDI and FHIR-based APIs but urges ONC to proceed carefully. USCDI and US Core increasingly serve as the foundation for patient access, provider access, payer data exchange, prior authorization, public health reporting, quality measurement, and TEFCA-aligned exchange. ONC approved USCDI v3.1 and USCDI v5 through the 2025 SVAP cycle and also approved US Core STU 8. USCDI v6 adds data elements such as Facility Address, Unique Device Identifier, Portable Medical Order, Family Health History, Care Plan, and Date of Onset. HL7’s US Core STU 9 is the current published US Core version, is based on FHIR R4, and is identified as version 9.0.0 / STU 9. 

The AMA supports ONC consideration of USCDI v6 and US Core STU 9 for SVAP only with guardrails. US Core STU 9 includes changes aligned to USCDI v6, but HL7’s change log also reflects that the update includes non-compatible changes, value set updates, and other substantive changes. ONC should not approve a newer US Core version through SVAP unless it also updates certification test data, Inferno or equivalent test tooling, implementation guidance, and migration resources.

The AMA recommends that ONC condition any USCDI v6 / US Core STU 9 advancement on the following:

  1. No new clinical documentation mandate by implication. USCDI identifies data for exchange; it should not be interpreted by developers, payers, or regulators as requiring physicians to newly document every USCDI element in structured fields during each encounter.
  2. Clear data provenance. APIs should distinguish patient-generated, clinician-authored, payer-supplied, device-generated, and externally sourced data. Without provenance and source metadata, expanded data exchange can increase clinical risk and reconciliation burden.
  3. Clear “data absent” and “reason not performed” handling. For data elements used in quality measurement, prior authorization, care gaps, and public health reporting, ONC should require guidance that prevents missing data from being treated as clinician non-performance or non-compliance.
  4. Alignment across US Core, C-CDA, QRDA, and public health IGs. As USCDI expands, downstream implementation guides must be updated in a coordinated manner. Physicians should not have to support inconsistent representations of the same data element across FHIR APIs, C-CDA documents, quality reports, public health messages, and payer transactions.
  5. Value set transparency. Although minimum vocabulary standards are not the focus of this SVAP cycle, implementation specifications frequently incorporate terminology bindings and value sets. ONC should require version transparency and accessible value set packages so developers and physicians can understand what is being tested and exchanged.

The AMA does not recommend that ONC approve Draft USCDI v7 through the 2026 SVAP cycle. ONC’s Draft USCDI v7 includes 30 proposed additions or revisions across multiple domains, including adverse events, referral notes, appointment data, insurance information, nutrition, immunization status and record source, device type, medication administration, medication dispense quantity, orders, accommodations, patient identifiers, and condition and procedure status. Many of these data elements are clinically valuable, but the AMA urges ONC to wait until USCDI v7 is finalized and until downstream IGs, test tools, and burden assessments are available.

Prior authorization APIs: CRD, DTR, PAS, CDS Hooks, and Subscriptions

The AMA views prior authorization automation as one of the most important near-term uses of interoperability standards. The promise of electronic prior authorization will be realized only if standards reduce friction in the physician’s EHR workflow, automate the gathering of necessary information, return timely determinations, and eliminate duplicative payer portal use.

HTI-4 adopted new provider prior authorization API criteria that reference HL7 Da Vinci Coverage Requirements Discovery (CRD) 2.0.1, Documentation Templates and Rules (DTR) 2.0.1, Prior Authorization Support (PAS) 2.0.1, SMART App Launch, CDS Hooks 2.0.1, and Subscriptions R5 Backport 1.1.0. HTI-4 also added these new API-related criteria to Real World Testing requirements. 

The AMA recommends that ONC clarify how these newly adopted criteria will be treated for SVAP purposes. If ONC considers successor versions of CRD, DTR, PAS, CDS Hooks, or Subscriptions for SVAP advancement, ONC should approve newer versions only when they demonstrably improve physician workflow and remain aligned with CMS payer API requirements.

The AMA recommends the following guardrails:

  1. No payer portal substitution. A certified EHR should be able to conduct the prior authorization workflow inside the physician’s workflow. A payer should not satisfy standards-based prior authorization by redirecting physicians to proprietary portals or requiring duplicative manual entry.
  2. Clinical data should auto-populate where available. DTR and PAS workflows should reuse data already in the EHR, including diagnoses, procedures, medications, labs, imaging, notes, orders, prior therapy, and relevant attachments. Manual re-entry should be the exception, not the operating model.
  3. Responses must be actionable. Prior authorization responses should return clear status, decision, reason, documentation deficiency, next step, appeal pathway, and expiration or authorization period information in computable form.
  4. Standards should support both medication and medical benefit workflows. ONC should coordinate NCPDP, HL7 Da Vinci, CMS payer APIs, and EHR certification so physicians do not face separate, inconsistent prior authorization workflows depending on benefit category.
  5. Real World-Testing should measure workflow outcomes. Testing should evaluate whether the standards reduce clicks, duplicate documentation, portal use, time to submission, time to determination, and avoidable denials—not merely whether messages validate.

C-CDA 4.0 and clinical documentation exchange

The AMA supports C-CDA 4.0 as a practical and important transition standard for clinical document exchange. C-CDA remains central to transitions of care, reconciliation, VDT, and all-data access. ONC’s current SVAP table includes C-CDA 4.0 as a 2025 SVAP-approved standard for multiple criteria. HL7 describes C-CDA 4.0 as the current published version and explains that it consolidates prior C-CDA guidance, includes common clinical document types, and adds guidance aligned with current USCDI versions. 

The AMA recommends that ONC maintain C-CDA 4.0 as an approved advancement while avoiding premature approval of any successor that lacks stable publication, validation tooling, implementation examples, and backward compatibility guidance.

The AMA further recommends that ONC use SVAP to improve the quality of exchanged clinical documents. Physicians need concise, relevant, trustworthy information—not longer documents filled with duplicative or low-value data. C-CDA advancement should emphasize:

  • preservation of narrative context where clinically important;
  • computable entries where they reduce burden and improve reconciliation;
  • provenance and author/source clarity;
  • better handling of externally sourced data;
  • support for unstructured documents when appropriate;
  • improved alignment between C-CDA and US Core FHIR representations.

QRDA, eCQMs, and digital quality measurement

The AMA supports quality measurement standards that reduce reporting burden, improve measure validity, and avoid duplicative manual abstraction. ONC’s current SVAP table includes QRDA I STU Release 5.3 with errata for CQM record/export and import/calculate and 2025 CMS QRDA I and QRDA III implementation guides for CQM reporting. 

The AMA recommends that ONC approve QRDA updates through SVAP only when they are synchronized with CMS reporting years, eCQM specifications, measure logic, value sets, and certification test tools. ONC should avoid mid-year changes that require practices to upgrade certified health IT or modify reporting workflows after a performance period has begun.

The AMA also encourages ONC to use SVAP and certification policy to support the transition toward digital quality measurement, but only where data are reliable, attributable, and already captured in care delivery. Physicians should not be held accountable for measures that rely on data outside their control, payer-supplied data that are not reconciled, or patient-generated data without clear provenance.

Public health reporting standards

The AMA supports public health interoperability that reduces manual reporting and improves timely, accurate reporting to public health agencies. ONC’s approved SVAP table includes immunization messaging, syndromic surveillance, electronic case reporting USCDI updates, antimicrobial use and resistance reporting, and National Health Care Surveys reporting. 

However, physician practices should not bear the burden of inconsistent public health agency readiness. Before approving newer versions of public health standards for SVAP, ONC should work with CDC, state and local public health agencies, and developers to ensure that receiving systems can test, validate, and accept the same versions.

The AMA recommends that ONC:

  1. publish or coordinate public health receiver readiness information;
  2. support end-to-end testing between certified health IT and public health agencies;
  3. avoid physician penalties where a receiving public health agency cannot accept a newer version;
  4. reduce duplicative reporting across eCR, immunization, syndromic surveillance, laboratory reporting, and registry reporting;
  5. ensure that public health reporting standards do not create new manual documentation expectations in routine clinical encounters.

Standards Version Advancement Process 2025

Thank you for the opportunity to provide feedback on the 2025 cycle of ASTP/ONC’s Standards Version Advancement Process (SVAP). Epic, as a developer of health IT, values ASTP/ONC’s collaborative feedback process when evaluating new standards and implementation specifications for industry adoption. 

We request that NCPDP SCRIPT Standard Version 2023011 be allowed under SVAP for the (b)(3) Electronic Prescribing criterion. CMS Part D already allows this updated standard (CFR 423.160(b)(1)) and so ASTP/ONC should align with CMS’s requirement. Additionally, the electronic prescribing testing tool is currently in beta testing for this standard, so it is logical to add this to the list of eligible SVAP standards.

Regarding the (f)(7) Transmission to public health agencies – health care surveys criterion, we request the inclusion of Release 1.2 of the Implementation Guide as an allowed version for SVAP. Release 1.2 facilitates the collection of inpatient data, which is essential for this criterion. Previously, Release 1.2 was an allowed version per the Certification Companion Guide, and we updated our software accordingly. Although the certification companion guide indicates that Health IT modules certified using Release 1.2 may retain their certified status, developers who frequently release new versions face challenges in re-certifying using the base standard (Release 1) or the SVAP standards (Release 3 or 3.1). Few healthcare organizations use this interface, so support for Release 3 or 3.1 has not been prioritized. Without inclusion of 1.2 in SVAP, it seems that our only option is to revert to Release 1, which lacks inpatient data. We suggest that ONC maintain previous versions until a new “floor” version is required by the rule-making process. 

For the (c)(3) Clinical Quality Measures – Report criterion, please include the CMS Implementation Guide for QRDA I and III for 2025. Currently, the Implementation Guides listed as eligible for SVAP are for 2023 and 2024, which are now outdated. Health IT developers update their systems annually to align with the latest implementation guide.

We are happy to answer any questions regarding our feedback and look forward to collaborating with ASTP/ONC to enhance standards-based health information exchange nationwide. Thank you for your consideration.

Recommendation to Include Draft USCDI v6 Elements in SVAP

As a developer of a consumer-facing digital health platform powered by wearable devices, I strongly recommend that ONC consider including select data elements from Draft USCDI v6 in the Standards Version Advancement Process (SVAP) as early as possible.

Specifically, we urge the early inclusion of:

  • Care Plan
  • Unique Device Identifier (UDI) (expanded to non-implantable devices)
  • Date of Onset

These elements are already supported by our platform and reflect real-world use cases across preventive health, chronic condition tracking, and patient-generated data feedback loops. While USCDI v4 is a strong foundation, it lacks semantic structures necessary to support key functionalities of modern wearable technologies—such as goal tracking, device-linked interventions, and early symptom pattern recognition.

Enabling these elements via SVAP will accelerate adoption, reduce reliance on custom interfaces, and promote interoperable patient data exchange across care settings. These v6 elements are technically mature and can meaningfully support public health goals today.

We appreciate the opportunity to provide this feedback and support ONC’s continued leadership in expanding data standards to reflect evolving patient needs and technology capabilities.

Sincerely,
Wearable Health Platform Developer

This is a great resource!!

 The Standards Version Advancement Process (SVAP) is a crucial step in improving healthcare IT systems and ensuring they meet the latest standards. It's exciting to see such a structured approach to enhancing interoperability and advancing technology for better patient care. Kudos to the team for providing this clear and informative guide!