ASTP Standards Bulletin 2025-1
tomoe.koketsu
Thu, 01/09/2025 – 13:20
The Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology (hereafter ASTP) Standards Bulletin 2025-1 (SB25-1) describes the development of the Draft United States Core Data for Interoperability Version 6 (Draft USCDI v6), which ASTP released on January 14, 2025.
The USCDI sets the technical and policy foundation for the access, exchange, and use of electronic health information to support nationwide interoperable health information exchange and is a standard stewarded and adopted by ASTP on behalf of the U.S. Department of Health and Human Services (HHS). ASTP publishes new versions of USCDI annually, with a draft version released in January and a final version released in July to keep pace with clinical, technology, and policy changes that influence the use of clinical and related terminology. Draft USCDI v6 includes new data elements that seek to advance interoperability for patient care.
SB25-1 describes ASTP’s continued expansion of USCDI, following the same prioritization approach applied to USCDI Version 5. SB25-1 also reflects ASTP’s consideration of submissions for new data elements, comments on previously submitted data elements, and the evolving maturity of data elements through the USCDI+ Program.
Background: United States Core Data for Interoperability
In 2024, ASTP adopted USCDI version 3 (USCDI v3) as a standard (at 45 CFR 170.213) and required USCDI v3 for certain criteria within the ONC Health IT Certification Program (Certification Program) in the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Final Rule. As a baseline for exchange across care settings and use cases, USCDI provides a standardized set of data elements to drive interoperability. USCDI groups data elements into data classes that share a common theme, but that does not limit its use or exchange to the context indicated by the class name. For example, First Name and Last Name are in the Patient Demographics/Information data class and are used for patient matching, but may also be exchanged to identify a patient in a document, a laboratory result, or a diagnostic imaging report. Likewise, the data element Performance Time in the Procedures data class can describe not only when a skin biopsy is performed, but can also describe when a vaccine is administered or when an electrocardiogram (EKG) is performed.
Annual USCDI updates help drive interoperability by keeping pace with clinical, technology, and policy changes. A USCDI version can be voluntarily adopted by industry prior to the regulatory “floor” being updated through the rulemaking process when the USCDI version is approved as part of ASTP’s Standards Version Advancement Process (SVAP). SVAP enables health IT developers in the ONC Health IT Certification Program to voluntarily incorporate newer versions of specific ASTP regulated standards and implementation specifications into their products, including newer USCDI versions. ASTP included USCDI v4 in the recently published SVAP Approved Standards for 2024, which enables health IT developers to incorporate it into their certified health IT products as of August 19, 2024. In the Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (HTI-2) Proposed Rule, ASTP proposed to raise the USCDI version baseline adopted for the Certification Program from USCDI v3 to v4.
USCDI is also referenced in HHS funded programs consistent with the HHS Health IT Alignment Policy, as well as through HHS regulated programs. For example, CMS’ Interoperability and Prior Authorization Final Rule (CMS-0057-F), Health Resources and Services Administration (HRSA) Health Center Controlled Networks, SAMHSA Certified Community Behavioral Health Centers, and exchange networks such as the Trusted Exchange Framework and Common AgreementTM (TEFCATM) require the capability to exchange USCDI data elements. USCDI also serves as the foundation for datasets developed as part of the ASTP USCDI+ Program, which identifies extensions to USCDI to meet specific programmatic and/or use case requirements. One such example is the HRSA Health Center Program Uniform Data System (UDS) Modernization Initiative (UDS+), which HRSA uses to reduce health centers’ reporting burden and improve the availability of data, while aligning to federal data standards.
Feedback on USCDI+ datasets has highlighted certain data elements as broadly applicable across care settings and use cases and thus critical additions to USCDI. These include, for example, data elements Unique Device Identifier, Facility Address, Date of Onset, and Family Health History.
Draft United States Core Data for Interoperability Version 6
ASTP invited proposals for new data elements (via the ONDEC submission system) and feedback on previously submitted data elements during the Draft USCDI v6 submission cycle from July to September 2024. ASTP received over 130 comments on existing data elements and almost 80 submissions recommending new data elements. Recently, ASTP has been able to use feedback from our USCDI+ datasets to help inform the technical maturity and breadth of applicability of data elements. ASTP reviewed and considered these comments and submissions in the development of the Draft USCDI v6.
ASTP identified key policy priorities guiding our selection for this version of USCDI. These priorities include:
Implementation burden for standards development organizations, developers of certified health IT products, and healthcare entities who will integrate these changes into clinical and other workflows.
Additional factors that may impact implementation burden, such as new regulatory requirements (e.g., those included in HTI-1 final rule), are also considered.
Important additions that will broadly benefit health IT users, while emphasizing these areas:
Health data needs for improving health outcomes, public health reporting, and behavioral health integration with primary care.
Data elements demonstrated through the USCDI+ programs to be a critical addition to USCDI.
The table below lists the data elements added to Draft USCDI v6.
Facility Information
Medical Devices
Orders
Facility Address
Unique Device Identifier*
Portable Medical Order
Patient Summary and Plan
Problems
Care Plan
Date of Onset
Family Health History
* Significantly modified data element (see more info below)
What’s New in Draft USCDI v6
Unique Device Identifier
We made a significant change to the Medical Devices data element Unique Device Identifier – Implantable to broaden its scope to include all other medical devices, including non-implantable devices. The ability to collect, use, and exchange information about implantable medical devices (such as cardiac pacemakers and artificial joints) has long been a requirement for certified health IT, including earlier versions of USCDI. However, the need to exchange information extends to all devices, including non-implantable, to effectively identify and report on device-related patient safety events, to respond to device safety recalls, and to conduct post-marketing surveillance on medical devices. The standard used to identify implantable and non-implantable devices is the same, and expanding the scope of the data element to include non-implantable devices highlights the importance of being able to exchange identifying information about the device in use.
Portable Medical Orders
Orders represents provider-authored requests for the delivery of patient care services and indicates that certain aspects of care may be underway. Orders data elements support patient care, care planning, and case management. They are particularly important when several providers are coordinating different aspects of care, as in the case of management of patients with multiple chronic conditions.ASTP added Portable Medical Orders to address when a patient is near the end-of-life or has a life-threatening condition and may need certain end-of-life or life-sustaining services, like “do-not-resuscitate” or “comfort measures only.” Portable Medical Orders do not expire, and follow a patient between care settings, including admission, transfer to a different level of care or facility, or even discharge to home. This last distinction makes the access to and exchange of these orders between electronic systems even more valuable, as it is often a challenge to find these orders during the admission or transfer processes and then execute them. Without access to Portable Medical Orders, delays or errors in carrying out a patient’s predetermined wishes may occur.
Facility Address
Facility Address can be used to differentiate specific service locations, link data to track care quality and health outcomes, or monitor facility level capacity such as hospital bed and ventilator availability. It can also be used for allocation of resources across a community for natural disasters or public health emergencies, or to track patient safety events. It differs from the existing data element Encounter Location, which is linked to individual patient care episodes and specific settings of care, such as an intensive care unit.
Care Plan
A Care Plan details a patient’s care needs, goals, and strategies for meeting them. Care plans are created by patients and their care teams, which can include health providers, family members, and caregivers. Being able to share the Care Plan is essential for coordinating care, ensuring continuity of care, and preventing duplicative services, particularly in complex care settings involving multiple specialties. The content included in a care plan may vary by care setting, condition, or to meet program requirements. Care plan implementation guides, such as the Multiple Chronic Condition eCare Plan or the Electronic Long Term Services & Support Care Plan implementation guides, support the exchange of data for shared care planning activities across care teams for key care planning scenarios. Similar to the way that the USCDI Address data element includes street name, city, state, and zip code, the USCDI Care Plan data element includes prioritized problems, health concerns, assessments, goals, and interventions. It is not ASTP’s intent to require all potential components of every type of care plan, but to standardize a base set of components common across different care plans.
Date of Onset
Date of Onset is the date or estimated date when signs or symptoms of a condition began, providing more information about the course of disease or other condition that was available from the existing data elements Date of Diagnosis and Date of Resolution. Date of Onset is used to determine the duration of a condition rather than how long ago a formal diagnosis was made. This supports differential diagnosis development and research questions by helping to identify a condition that appears suddenly (such as appendicitis) versus a condition that develops and persists over time (such as irritable bowel disease). Feedback from USCDI+ Quality, Behavioral Health, and Public Health datasets regarding Date of Onset further supported this data element’s broad applicability across care settings and importance across use cases.
Family Health History
Family Health History details the health conditions of a family member that might be relevant to a patient’s care. For example, a known family history of breast cancer can change the approach to screening for a younger patient. This information is routinely collected in the course of care, widely exchanged in structured documents, and informs care across care settings.
Other Draft USCDI v6 Changes
The following updates would be made to data classes and elements:
Medication Order would include RxNorm as the applicable standard
Laboratory Order, Diagnostic Imaging Order, and Clinical Test Order would include LOINC as the applicable standard
In order to provide clarity to implementers we propose to update definitions, usage notes, or examples for the following data elements: Performance Time, SDOH Assessment, Result Unit of Measure, Coverage Type, and Reaction.
ASTP identifies, where appropriate, vocabulary standards such as SNOMED Clinical Terms® U.S. Edition, Logical Observation Identifiers Names and Codes ® (LOINC), RxNorm®, and National Drug Code to represent data elements, and as we have done in the past, we updated the applicable vocabulary to the latest versions as of the publication of Draft USCDI v6. In draft USCDI v6, we propose to add the CDCREC 1.3 consisting of American Indian and Alaskan Native concept updates; we further anticipate future updates will reflect additional CDCREC code set changes including those that support SPD15 implementation. We anticipate a future USCDI version may reflect the updated OMB SPD 15 (finalized in March 2024 with a compliance date of March 2029).
USCDI Roadmap
As we announced with the release of USCDI v5, ASTP is developing a roadmap for the collaborative advancement of USCDI. The roadmap will outline readiness considerations for future USCDI data elements, including technical maturity and broadly applicable use-cases, and how readiness is advanced through community engagement and the USCDI+ program. The roadmap will be available in a future publication on HealthIt.gov.
ASTP Requests Specific Feedback on the Following Data Elements
Unique Device Identifier
ASTP seeks feedback on whether Unique Device Identifier (UDI) should be one or two data elements (Unique Device Identifier—Implantable and Unique Device Identifier—Non-implantable). Is there an impact on standards development or information exchange to use one data element, Unique Device Identifier, to include both implantable and non-implantable devices?
Care Plan
We are seeking feedback on the scope and definition of the draft Care Plan data element for USCDI. At a minimum, this data element includes the capability to exchange prioritized problems, health concerns, assessments, goals, and interventions. Do these minimum components reflect the common elements across different care plan types? Does the USCDI data element definition provide enough information for developers to implement the capability to exchange Care Plan?
Diagnostic Imaging
ASTP has heard from a variety of interested parties, including the Healthcare Information Technology Advisory Committee (HITAC), that providing shareable links or detailed information about individual diagnostic imaging studies, series, and images offers great potential to improve access to images. Relatedly, HTI-2 Proposed Rule proposes to revise the certification criteria to include certification requirements to support capturing and documenting hyperlinks to diagnostic images. We seek feedback on what additional work is needed in this space to advance meaningful, secure, and shareable access to images across disparate networks, and we seek examples of real-world evidence of exchange.
Draft USCDI v6 Public Feedback Period
With its publication, Draft USCDI v6 is open for public comment until April 14, 2025, at 11:59 pm ET. In addition to the feedback requested above, ASTP is seeking feedback on any aspect of Draft USCDI v6 and is requesting specific input on the following areas:
Suggestions for improvement in the data classes or elements in Draft USCDI v6, including:
a. Data class and element definitions, usage notes, and examples; and
b. Examples of code systems used by health IT developers and implementers to communicate data element scope.
Should other existing Level 2 data elements be added to USCDI v6 instead of, or in addition to, those in Draft USCDI v6? If so, why?
Which additional data elements from USCDI+ domains should be added to USCDI v6?
Are there significant barriers to development, implementation, or use of any of these data elements that warrant a change in the final version of USCDI v6?
ASTP will also work with the Health Information Technology Advisory Committee (HITAC) to develop recommendations on Draft USCDI v6 during the open comment period.
ASTP continues to work with the public and federal agencies to identify areas where more work is needed to inform future versions of USCDI. ASTP recognizes there are specific but important use cases that require consistency and alignment on datasets that go beyond USCDI. ASTP continues to work with governmental and industry partners through the USCDI+ initiative to support the identification and establishment of domain or program-specific datasets that can be extensions to USCDI. Where appropriate, ASTP will consider data elements from the USCDI+ project for inclusion in USCDI.
ASTP is targeting release of the final USCDI v6 in July 2025.
ASTP Standards Bulletin 2025-1
tomoe.koketsu
Thu, 01/09/2025 – 13:20
The Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology (hereafter ASTP) Standards Bulletin 2025-1 (SB25-1) describes the development of the Draft United States Core Data for Interoperability Version 6 (Draft USCDI v6), which ASTP released on January 14, 2025.
The USCDI sets the technical and policy foundation for the access, exchange, and use of electronic health information to support nationwide interoperable health information exchange and is a standard stewarded and adopted by ASTP on behalf of the U.S. Department of Health and Human Services (HHS). ASTP publishes new versions of USCDI annually, with a draft version released in January and a final version released in July to keep pace with clinical, technology, and policy changes that influence the use of clinical and related terminology. Draft USCDI v6 includes new data elements that seek to advance interoperability for patient care.
SB25-1 describes ASTP’s continued expansion of USCDI, following the same prioritization approach applied to USCDI Version 5. SB25-1 also reflects ASTP’s consideration of submissions for new data elements, comments on previously submitted data elements, and the evolving maturity of data elements through the USCDI+ Program.
Background: United States Core Data for Interoperability
In 2024, ASTP adopted USCDI version 3 (USCDI v3) as a standard (at 45 CFR 170.213) and required USCDI v3 for certain criteria within the ONC Health IT Certification Program (Certification Program) in the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Final Rule. As a baseline for exchange across care settings and use cases, USCDI provides a standardized set of data elements to drive interoperability. USCDI groups data elements into data classes that share a common theme, but that does not limit its use or exchange to the context indicated by the class name. For example, First Name and Last Name are in the Patient Demographics/Information data class and are used for patient matching, but may also be exchanged to identify a patient in a document, a laboratory result, or a diagnostic imaging report. Likewise, the data element Performance Time in the Procedures data class can describe not only when a skin biopsy is performed, but can also describe when a vaccine is administered or when an electrocardiogram (EKG) is performed.
Annual USCDI updates help drive interoperability by keeping pace with clinical, technology, and policy changes. A USCDI version can be voluntarily adopted by industry prior to the regulatory “floor” being updated through the rulemaking process when the USCDI version is approved as part of ASTP’s Standards Version Advancement Process (SVAP). SVAP enables health IT developers in the ONC Health IT Certification Program to voluntarily incorporate newer versions of specific ASTP regulated standards and implementation specifications into their products, including newer USCDI versions. ASTP included USCDI v4 in the recently published SVAP Approved Standards for 2024, which enables health IT developers to incorporate it into their certified health IT products as of August 19, 2024. In the Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (HTI-2) Proposed Rule, ASTP proposed to raise the USCDI version baseline adopted for the Certification Program from USCDI v3 to v4.
USCDI is also referenced in HHS funded programs consistent with the HHS Health IT Alignment Policy, as well as through HHS regulated programs. For example, CMS’ Interoperability and Prior Authorization Final Rule (CMS-0057-F), Health Resources and Services Administration (HRSA) Health Center Controlled Networks, SAMHSA Certified Community Behavioral Health Centers, and exchange networks such as the Trusted Exchange Framework and Common AgreementTM (TEFCATM) require the capability to exchange USCDI data elements. USCDI also serves as the foundation for datasets developed as part of the ASTP USCDI+ Program, which identifies extensions to USCDI to meet specific programmatic and/or use case requirements. One such example is the HRSA Health Center Program Uniform Data System (UDS) Modernization Initiative (UDS+), which HRSA uses to reduce health centers’ reporting burden and improve the availability of data, while aligning to federal data standards.
Feedback on USCDI+ datasets has highlighted certain data elements as broadly applicable across care settings and use cases and thus critical additions to USCDI. These include, for example, data elements Unique Device Identifier, Facility Address, Date of Onset, and Family Health History.
Draft United States Core Data for Interoperability Version 6
ASTP invited proposals for new data elements (via the ONDEC submission system) and feedback on previously submitted data elements during the Draft USCDI v6 submission cycle from July to September 2024. ASTP received over 130 comments on existing data elements and almost 80 submissions recommending new data elements. Recently, ASTP has been able to use feedback from our USCDI+ datasets to help inform the technical maturity and breadth of applicability of data elements. ASTP reviewed and considered these comments and submissions in the development of the Draft USCDI v6.
ASTP identified key policy priorities guiding our selection for this version of USCDI. These priorities include:
Implementation burden for standards development organizations, developers of certified health IT products, and healthcare entities who will integrate these changes into clinical and other workflows.
Additional factors that may impact implementation burden, such as new regulatory requirements (e.g., those included in HTI-1 final rule), are also considered.
Important additions that will broadly benefit health IT users, while emphasizing these areas:
Health data needs for improving health outcomes, public health reporting, and behavioral health integration with primary care.
Data elements demonstrated through the USCDI+ programs to be a critical addition to USCDI.
The table below lists the data elements added to Draft USCDI v6.
Facility Information
Medical Devices
Orders
Facility Address
Unique Device Identifier*
Portable Medical Order
Patient Summary and Plan
Problems
Care Plan
Date of Onset
Family Health History
* Significantly modified data element (see more info below)
What’s New in Draft USCDI v6
Unique Device Identifier
We made a significant change to the Medical Devices data element Unique Device Identifier – Implantable to broaden its scope to include all other medical devices, including non-implantable devices. The ability to collect, use, and exchange information about implantable medical devices (such as cardiac pacemakers and artificial joints) has long been a requirement for certified health IT, including earlier versions of USCDI. However, the need to exchange information extends to all devices, including non-implantable, to effectively identify and report on device-related patient safety events, to respond to device safety recalls, and to conduct post-marketing surveillance on medical devices. The standard used to identify implantable and non-implantable devices is the same, and expanding the scope of the data element to include non-implantable devices highlights the importance of being able to exchange identifying information about the device in use.
Portable Medical Orders
Orders represents provider-authored requests for the delivery of patient care services and indicates that certain aspects of care may be underway. Orders data elements support patient care, care planning, and case management. They are particularly important when several providers are coordinating different aspects of care, as in the case of management of patients with multiple chronic conditions.ASTP added Portable Medical Orders to address when a patient is near the end-of-life or has a life-threatening condition and may need certain end-of-life or life-sustaining services, like “do-not-resuscitate” or “comfort measures only.” Portable Medical Orders do not expire, and follow a patient between care settings, including admission, transfer to a different level of care or facility, or even discharge to home. This last distinction makes the access to and exchange of these orders between electronic systems even more valuable, as it is often a challenge to find these orders during the admission or transfer processes and then execute them. Without access to Portable Medical Orders, delays or errors in carrying out a patient’s predetermined wishes may occur.
Facility Address
Facility Address can be used to differentiate specific service locations, link data to track care quality and health outcomes, or monitor facility level capacity such as hospital bed and ventilator availability. It can also be used for allocation of resources across a community for natural disasters or public health emergencies, or to track patient safety events. It differs from the existing data element Encounter Location, which is linked to individual patient care episodes and specific settings of care, such as an intensive care unit.
Care Plan
A Care Plan details a patient’s care needs, goals, and strategies for meeting them. Care plans are created by patients and their care teams, which can include health providers, family members, and caregivers. Being able to share the Care Plan is essential for coordinating care, ensuring continuity of care, and preventing duplicative services, particularly in complex care settings involving multiple specialties. The content included in a care plan may vary by care setting, condition, or to meet program requirements. Care plan implementation guides, such as the Multiple Chronic Condition eCare Plan or the Electronic Long Term Services & Support Care Plan implementation guides, support the exchange of data for shared care planning activities across care teams for key care planning scenarios. Similar to the way that the USCDI Address data element includes street name, city, state, and zip code, the USCDI Care Plan data element includes prioritized problems, health concerns, assessments, goals, and interventions. It is not ASTP’s intent to require all potential components of every type of care plan, but to standardize a base set of components common across different care plans.
Date of Onset
Date of Onset is the date or estimated date when signs or symptoms of a condition began, providing more information about the course of disease or other condition that was available from the existing data elements Date of Diagnosis and Date of Resolution. Date of Onset is used to determine the duration of a condition rather than how long ago a formal diagnosis was made. This supports differential diagnosis development and research questions by helping to identify a condition that appears suddenly (such as appendicitis) versus a condition that develops and persists over time (such as irritable bowel disease). Feedback from USCDI+ Quality, Behavioral Health, and Public Health datasets regarding Date of Onset further supported this data element’s broad applicability across care settings and importance across use cases.
Family Health History
Family Health History details the health conditions of a family member that might be relevant to a patient’s care. For example, a known family history of breast cancer can change the approach to screening for a younger patient. This information is routinely collected in the course of care, widely exchanged in structured documents, and informs care across care settings.
Other Draft USCDI v6 Changes
The following updates would be made to data classes and elements:
Medication Order would include RxNorm as the applicable standard
Laboratory Order, Diagnostic Imaging Order, and Clinical Test Order would include LOINC as the applicable standard
In order to provide clarity to implementers we propose to update definitions, usage notes, or examples for the following data elements: Performance Time, SDOH Assessment, Result Unit of Measure, Coverage Type, and Reaction.
ASTP identifies, where appropriate, vocabulary standards such as SNOMED Clinical Terms® U.S. Edition, Logical Observation Identifiers Names and Codes ® (LOINC), RxNorm®, and National Drug Code to represent data elements, and as we have done in the past, we updated the applicable vocabulary to the latest versions as of the publication of Draft USCDI v6. In draft USCDI v6, we propose to add the CDCREC 1.3 consisting of American Indian and Alaskan Native concept updates; we further anticipate future updates will reflect additional CDCREC code set changes including those that support SPD15 implementation. We anticipate a future USCDI version may reflect the updated OMB SPD 15 (finalized in March 2024 with a compliance date of March 2029).
USCDI Roadmap
As we announced with the release of USCDI v5, ASTP is developing a roadmap for the collaborative advancement of USCDI. The roadmap will outline readiness considerations for future USCDI data elements, including technical maturity and broadly applicable use-cases, and how readiness is advanced through community engagement and the USCDI+ program. The roadmap will be available in a future publication on HealthIt.gov.
ASTP Requests Specific Feedback on the Following Data Elements
Unique Device Identifier
ASTP seeks feedback on whether Unique Device Identifier (UDI) should be one or two data elements (Unique Device Identifier—Implantable and Unique Device Identifier—Non-implantable). Is there an impact on standards development or information exchange to use one data element, Unique Device Identifier, to include both implantable and non-implantable devices?
Care Plan
We are seeking feedback on the scope and definition of the draft Care Plan data element for USCDI. At a minimum, this data element includes the capability to exchange prioritized problems, health concerns, assessments, goals, and interventions. Do these minimum components reflect the common elements across different care plan types? Does the USCDI data element definition provide enough information for developers to implement the capability to exchange Care Plan?
Diagnostic Imaging
ASTP has heard from a variety of interested parties, including the Healthcare Information Technology Advisory Committee (HITAC), that providing shareable links or detailed information about individual diagnostic imaging studies, series, and images offers great potential to improve access to images. Relatedly, HTI-2 Proposed Rule proposes to revise the certification criteria to include certification requirements to support capturing and documenting hyperlinks to diagnostic images. We seek feedback on what additional work is needed in this space to advance meaningful, secure, and shareable access to images across disparate networks, and we seek examples of real-world evidence of exchange.
Draft USCDI v6 Public Feedback Period
With its publication, Draft USCDI v6 is open for public comment until April 14, 2025, at 11:59 pm ET. In addition to the feedback requested above, ASTP is seeking feedback on any aspect of Draft USCDI v6 and is requesting specific input on the following areas:
Suggestions for improvement in the data classes or elements in Draft USCDI v6, including:
a. Data class and element definitions, usage notes, and examples; and
b. Examples of code systems used by health IT developers and implementers to communicate data element scope.
Should other existing Level 2 data elements be added to USCDI v6 instead of, or in addition to, those in Draft USCDI v6? If so, why?
Which additional data elements from USCDI+ domains should be added to USCDI v6?
Are there significant barriers to development, implementation, or use of any of these data elements that warrant a change in the final version of USCDI v6?
ASTP will also work with the Health Information Technology Advisory Committee (HITAC) to develop recommendations on Draft USCDI v6 during the open comment period.
ASTP continues to work with the public and federal agencies to identify areas where more work is needed to inform future versions of USCDI. ASTP recognizes there are specific but important use cases that require consistency and alignment on datasets that go beyond USCDI. ASTP continues to work with governmental and industry partners through the USCDI+ initiative to support the identification and establishment of domain or program-specific datasets that can be extensions to USCDI. Where appropriate, ASTP will consider data elements from the USCDI+ project for inclusion in USCDI.
ASTP is targeting release of the final USCDI v6 in July 2025.
ASTP Standards Bulletin 2025-1
tomoe.koketsu
Thu, 01/09/2025 – 13:20
ASTP Standards Bulletin 2025-1
The Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology (hereafter ASTP) Standards Bulletin 2025-1 (SB25-1) describes the development of the Draft United States Core Data for Interoperability Version 6 (Draft USCDI v6), which ASTP released on January 14, 2025.
The USCDI sets the technical and policy foundation for the access, exchange, and use of electronic health information to support nationwide interoperable health information exchange and is a standard stewarded and adopted by ASTP on behalf of the U.S. Department of Health and Human Services (HHS). ASTP publishes new versions of USCDI annually, with a draft version released in January and a final version released in July to keep pace with clinical, technology, and policy changes that influence the use of clinical and related terminology. Draft USCDI v6 includes new data elements that seek to advance interoperability for patient care.
SB25-1 describes ASTP’s continued expansion of USCDI, following the same prioritization approach applied to USCDI Version 5. SB25-1 also reflects ASTP’s consideration of submissions for new data elements, comments on previously submitted data elements, and the evolving maturity of data elements through the USCDI+ Program.
Background: United States Core Data for Interoperability
In 2024, ASTP adopted USCDI version 3 (USCDI v3) as a standard (at 45 CFR 170.213) and required USCDI v3 for certain criteria within the ONC Health IT Certification Program (Certification Program) in the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Final Rule. As a baseline for exchange across care settings and use cases, USCDI provides a standardized set of data elements to drive interoperability. USCDI groups data elements into data classes that share a common theme, but that does not limit its use or exchange to the context indicated by the class name. For example, First Name and Last Name are in the Patient Demographics/Information data class and are used for patient matching, but may also be exchanged to identify a patient in a document, a laboratory result, or a diagnostic imaging report. Likewise, the data element Performance Time in the Procedures data class can describe not only when a skin biopsy is performed, but can also describe when a vaccine is administered or when an electrocardiogram (EKG) is performed.
Annual USCDI updates help drive interoperability by keeping pace with clinical, technology, and policy changes. A USCDI version can be voluntarily adopted by industry prior to the regulatory “floor” being updated through the rulemaking process when the USCDI version is approved as part of ASTP’s Standards Version Advancement Process (SVAP). SVAP enables health IT developers in the ONC Health IT Certification Program to voluntarily incorporate newer versions of specific ASTP regulated standards and implementation specifications into their products, including newer USCDI versions. ASTP included USCDI v4 in the recently published SVAP Approved Standards for 2024, which enables health IT developers to incorporate it into their certified health IT products as of August 19, 2024. In the Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (HTI-2) Proposed Rule, ASTP proposed to raise the USCDI version baseline adopted for the Certification Program from USCDI v3 to v4.
USCDI is also referenced in HHS funded programs consistent with the HHS Health IT Alignment Policy, as well as through HHS regulated programs. For example, CMS’ Interoperability and Prior Authorization Final Rule (CMS-0057-F), Health Resources and Services Administration (HRSA) Health Center Controlled Networks, SAMHSA Certified Community Behavioral Health Centers, and exchange networks such as the Trusted Exchange Framework and Common AgreementTM (TEFCATM) require the capability to exchange USCDI data elements. USCDI also serves as the foundation for datasets developed as part of the ASTP USCDI+ Program, which identifies extensions to USCDI to meet specific programmatic and/or use case requirements. One such example is the HRSA Health Center Program Uniform Data System (UDS) Modernization Initiative (UDS+), which HRSA uses to reduce health centers’ reporting burden and improve the availability of data, while aligning to federal data standards.
Feedback on USCDI+ datasets has highlighted certain data elements as broadly applicable across care settings and use cases and thus critical additions to USCDI. These include, for example, data elements Unique Device Identifier, Facility Address, Date of Onset, and Family Health History.
Draft United States Core Data for Interoperability Version 6
ASTP invited proposals for new data elements (via the ONDEC submission system) and feedback on previously submitted data elements during the Draft USCDI v6 submission cycle from July to September 2024. ASTP received over 130 comments on existing data elements and almost 80 submissions recommending new data elements. Recently, ASTP has been able to use feedback from our USCDI+ datasets to help inform the technical maturity and breadth of applicability of data elements. ASTP reviewed and considered these comments and submissions in the development of the Draft USCDI v6.
ASTP identified key policy priorities guiding our selection for this version of USCDI. These priorities include:
Implementation burden for standards development organizations, developers of certified health IT products, and healthcare entities who will integrate these changes into clinical and other workflows.
Additional factors that may impact implementation burden, such as new regulatory requirements (e.g., those included in HTI-1 final rule), are also considered.
Important additions that will broadly benefit health IT users, while emphasizing these areas:
Health data needs for improving health outcomes, public health reporting, and behavioral health integration with primary care.
Data elements demonstrated through the USCDI+ programs to be a critical addition to USCDI.
The table below lists the data elements added to Draft USCDI v6.
Facility Information
Medical Devices
Orders
Facility Address
Unique Device Identifier*
Portable Medical Order
Patient Summary and Plan
Problems
Care Plan
Date of Onset
Family Health History
* Significantly modified data element (see more info below)
What’s New in Draft USCDI v6
Unique Device Identifier
We made a significant change to the Medical Devices data element Unique Device Identifier – Implantable to broaden its scope to include all other medical devices, including non-implantable devices. The ability to collect, use, and exchange information about implantable medical devices (such as cardiac pacemakers and artificial joints) has long been a requirement for certified health IT, including earlier versions of USCDI. However, the need to exchange information extends to all devices, including non-implantable, to effectively identify and report on device-related patient safety events, to respond to device safety recalls, and to conduct post-marketing surveillance on medical devices. The standard used to identify implantable and non-implantable devices is the same, and expanding the scope of the data element to include non-implantable devices highlights the importance of being able to exchange identifying information about the device in use.
Portable Medical Orders
Orders represents provider-authored requests for the delivery of patient care services and indicates that certain aspects of care may be underway. Orders data elements support patient care, care planning, and case management. They are particularly important when several providers are coordinating different aspects of care, as in the case of management of patients with multiple chronic conditions.ASTP added Portable Medical Orders to address when a patient is near the end-of-life or has a life-threatening condition and may need certain end-of-life or life-sustaining services, like “do-not-resuscitate” or “comfort measures only.” Portable Medical Orders do not expire, and follow a patient between care settings, including admission, transfer to a different level of care or facility, or even discharge to home. This last distinction makes the access to and exchange of these orders between electronic systems even more valuable, as it is often a challenge to find these orders during the admission or transfer processes and then execute them. Without access to Portable Medical Orders, delays or errors in carrying out a patient’s predetermined wishes may occur.
Facility Address
Facility Address can be used to differentiate specific service locations, link data to track care quality and health outcomes, or monitor facility level capacity such as hospital bed and ventilator availability. It can also be used for allocation of resources across a community for natural disasters or public health emergencies, or to track patient safety events. It differs from the existing data element Encounter Location, which is linked to individual patient care episodes and specific settings of care, such as an intensive care unit.
Care Plan
A Care Plan details a patient’s care needs, goals, and strategies for meeting them. Care plans are created by patients and their care teams, which can include health providers, family members, and caregivers. Being able to share the Care Plan is essential for coordinating care, ensuring continuity of care, and preventing duplicative services, particularly in complex care settings involving multiple specialties. The content included in a care plan may vary by care setting, condition, or to meet program requirements. Care plan implementation guides, such as the Multiple Chronic Condition eCare Plan or the Electronic Long Term Services & Support Care Plan implementation guides, support the exchange of data for shared care planning activities across care teams for key care planning scenarios. Similar to the way that the USCDI Address data element includes street name, city, state, and zip code, the USCDI Care Plan data element includes prioritized problems, health concerns, assessments, goals, and interventions. It is not ASTP’s intent to require all potential components of every type of care plan, but to standardize a base set of components common across different care plans.
Date of Onset
Date of Onset is the date or estimated date when signs or symptoms of a condition began, providing more information about the course of disease or other condition that was available from the existing data elements Date of Diagnosis and Date of Resolution. Date of Onset is used to determine the duration of a condition rather than how long ago a formal diagnosis was made. This supports differential diagnosis development and research questions by helping to identify a condition that appears suddenly (such as appendicitis) versus a condition that develops and persists over time (such as irritable bowel disease). Feedback from USCDI+ Quality, Behavioral Health, and Public Health datasets regarding Date of Onset further supported this data element’s broad applicability across care settings and importance across use cases.
Family Health History
Family Health History details the health conditions of a family member that might be relevant to a patient’s care. For example, a known family history of breast cancer can change the approach to screening for a younger patient. This information is routinely collected in the course of care, widely exchanged in structured documents, and informs care across care settings.
Other Draft USCDI v6 Changes
The following updates would be made to data classes and elements:
Medication Order would include RxNorm as the applicable standard
Laboratory Order, Diagnostic Imaging Order, and Clinical Test Order would include LOINC as the applicable standard
In order to provide clarity to implementers we propose to update definitions, usage notes, or examples for the following data elements: Performance Time, SDOH Assessment, Result Unit of Measure, Coverage Type, and Reaction.
ASTP identifies, where appropriate, vocabulary standards such as SNOMED Clinical Terms® U.S. Edition, Logical Observation Identifiers Names and Codes ® (LOINC), RxNorm®, and National Drug Code to represent data elements, and as we have done in the past, we updated the applicable vocabulary to the latest versions as of the publication of Draft USCDI v6. In draft USCDI v6, we propose to add the CDCREC 1.3 consisting of American Indian and Alaskan Native concept updates; we further anticipate future updates will reflect additional CDCREC code set changes including those that support SPD15 implementation. We anticipate a future USCDI version may reflect the updated OMB SPD 15 (finalized in March 2024 with a compliance date of March 2029).
USCDI Roadmap
As we announced with the release of USCDI v5, ASTP is developing a roadmap for the collaborative advancement of USCDI. The roadmap will outline readiness considerations for future USCDI data elements, including technical maturity and broadly applicable use-cases, and how readiness is advanced through community engagement and the USCDI+ program. The roadmap will be available in a future publication on HealthIt.gov.
ASTP Requests Specific Feedback on the Following Data Elements
Unique Device Identifier
ASTP seeks feedback on whether Unique Device Identifier (UDI) should be one or two data elements (Unique Device Identifier—Implantable and Unique Device Identifier—Non-implantable). Is there an impact on standards development or information exchange to use one data element, Unique Device Identifier, to include both implantable and non-implantable devices?
Care Plan
We are seeking feedback on the scope and definition of the draft Care Plan data element for USCDI. At a minimum, this data element includes the capability to exchange prioritized problems, health concerns, assessments, goals, and interventions. Do these minimum components reflect the common elements across different care plan types? Does the USCDI data element definition provide enough information for developers to implement the capability to exchange Care Plan?
Diagnostic Imaging
ASTP has heard from a variety of interested parties, including the Healthcare Information Technology Advisory Committee (HITAC), that providing shareable links or detailed information about individual diagnostic imaging studies, series, and images offers great potential to improve access to images. Relatedly, HTI-2 Proposed Rule proposes to revise the certification criteria to include certification requirements to support capturing and documenting hyperlinks to diagnostic images. We seek feedback on what additional work is needed in this space to advance meaningful, secure, and shareable access to images across disparate networks, and we seek examples of real-world evidence of exchange.
Draft USCDI v6 Public Feedback Period
With its publication, Draft USCDI v6 is open for public comment until April 14, 2025, at 11:59 pm ET. In addition to the feedback requested above, ASTP is seeking feedback on any aspect of Draft USCDI v6 and is requesting specific input on the following areas:
Suggestions for improvement in the data classes or elements in Draft USCDI v6, including:
a. Data class and element definitions, usage notes, and examples; and
b. Examples of code systems used by health IT developers and implementers to communicate data element scope.
Should other existing Level 2 data elements be added to USCDI v6 instead of, or in addition to, those in Draft USCDI v6? If so, why?
Which additional data elements from USCDI+ domains should be added to USCDI v6?
Are there significant barriers to development, implementation, or use of any of these data elements that warrant a change in the final version of USCDI v6?
ASTP will also work with the Health Information Technology Advisory Committee (HITAC) to develop recommendations on Draft USCDI v6 during the open comment period.
ASTP continues to work with the public and federal agencies to identify areas where more work is needed to inform future versions of USCDI. ASTP recognizes there are specific but important use cases that require consistency and alignment on datasets that go beyond USCDI. ASTP continues to work with governmental and industry partners through the USCDI+ initiative to support the identification and establishment of domain or program-specific datasets that can be extensions to USCDI. Where appropriate, ASTP will consider data elements from the USCDI+ project for inclusion in USCDI.
ASTP is targeting release of the final USCDI v6 in July 2025.
Leave A Comment