Submitted by CDC_DSMH_WG on
CDC's comment for inclusion in USCDI v7
CDC recommends renaming “Immunizations” to “Vaccine Administered Code.” The inclusion of a coded data element representing the administered vaccine is essential for accurate and interoperable exchange within USCDI v7. The current “Immunizations” data element captures this information using CVX or NDC as part of the HL7 v2.7 RXA-5; however, the label is ambiguous and may be misinterpreted as referring to an immunization event rather than a coded attribute.
To improve clarity, CDC proposes renaming this data element to “Vaccine Administered Code.” This change does not modify the definition, datatype, or value set—it remains a coded representation of the administered vaccine—but instead clarifies the element’s purpose.
This revision also resolves confusion within USCDI, where “Immunizations” refers to both a data class and a data element. In addition, this terminology aligns with the FHIR Immunization resource, which defines a vaccineCode element to represent the coded identity of the administered vaccine, supporting standardized and unambiguous data exchange.
In summary, this terminology update improves clarity and alignment without altering the underlying data structure, supporting more accurate data exchange and public health outcomes.







Submitted by CDC_DSMH_WG on
CDC comments for draft USCDI v8
Renaming "Immunizations" to "Vaccine Administered Code"
CDC recognizes that a similar comment was previously submitted for USCDI v7, and that other USCDI data elements carry required terminology codes without "Code" appended to their name. We appreciate this point and want to clarify where the confusion occurs and revise our recommendation accordingly.
The issue is not that the element lacks a code — it already requires one (CVX or NDC) — but that "Immunizations" is the name of both the USCDI data class and this specific data element within it. This creates ambiguity for implementers and public health partners reading USCDI documentation: a reference to "the immunizations data element" can be misread as the class, an immunization event, or the coded attribute itself. This is a naming collision specific to this element, not a general naming pattern issue, and does not apply to elements like Problems or Medications.
Given this, we withdraw the proposed name "Vaccine Administered Code" and instead recommend ONC resolve the class/element naming collision directly — for example, by renaming the data element (not the data class) to something that avoids duplicating the class name, using a naming convention consistent with other USCDI elements (e.g., "Vaccine Type" or "Vaccine Administered"), while leaving the data class named "Immunizations" unchanged. No change to the element's definition, datatype, or value set is proposed.
Supporting links:
- US Core Immunization Profile (US Core IG v9.0.0): https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-immunization.html
- HL7 v2.5.1 Implementation Guide for Immunization Messaging (RXA-5 field): https://www.cdc.gov/vaccines/programs/iis/technical-guidance/downloads/hl7guide-1-5-2014-11.pdf
- HL7 FHIR Immunization resource — vaccineCode element: https://hl7.org/fhir/immunization.html
Level 2: Captured/stored/accessed in multiple production EHRs or other HIT modules from more than one developer.
Use Case: The coded vaccine identity element (currently named "Immunizations" in USCDI, using CVX or NDC codes) is essential for accurate, interoperable public health data exchange — supporting immunization reporting, vaccine inventory management, coverage assessment, and outbreak/exposure investigation across IIS, EHRs, and public health agencies. However, the current element name is ambiguous: "Immunizations" is easily misread as referring to an immunization event rather than a coded attribute, and it duplicates the name of the "Immunizations" data class itself, creating confusion for implementers and reviewers working across USCDI documentation.
Renaming this element to "Vaccine Administered Code" — with no change to its definition, datatype, or value set — resolves this ambiguity and aligns USCDI terminology with the existing FHIR Immunization resource's vaccineCode element. This improves clarity for implementers building to both USCDI and FHIR/US Core simultaneously, reducing the risk of misinterpretation in public health data exchange, without introducing any new technical or implementation burden.
US Core Immunization Profile (US Core Implementation Guide v9.0.0): https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-immunization.html
HL7 Version 2.5.1 Implementation Guide for Immunization Messaging (Release 1.5) — RXA-5 field: https://www.cdc.gov/vaccines/programs/iis/technical-guidance/downloads/hl7guide-1-5-2014-11.pdfHL7
FHIR Immunization resource — vaccineCode element definition: https://hl7.org/fhir/immunization.html
Additional information-Supporting links:
- US Core Immunization Profile (US Core IG v9.0.0): https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-immunization.html
- HL7 v2.5.1 Implementation Guide for Immunization Messaging (RXA-5 field): https://www.cdc.gov/vaccines/programs/iis/technical-guidance/downloads/hl7guide-1-5-2014-11.pdf
- HL7 FHIR Immunization resource — vaccineCode element: https://hl7.org/fhir/immunization.html
U.S. Core inclusion- Yes.
U.S.Core details- The U.S. Core Implementation Guide v9.0.0 Immunization Profile lists "a vaccine code that identifies the kind of vaccine administered" as one of four elements every Immunization instance must have (Mandatory), corresponding to Immunization.vaccineCode. This is the same underlying FHIR element currently captured by the USCDI "Immunizations" data element, using CVX or NDC codes. The proposed change renames this data element to "Vaccine Administered Code" to align USCDI terminology with the existing FHIR element name (vaccineCode) and to eliminate confusion between the "Immunizations" data class and the "Immunizations" data element name. This is a terminology-only change; the definition, datatype, and value set remain unchanged, and no new Mandatory or Must Support designation is being introduced — the element is already Mandatory in US Core today.