AHA Comments on ONC Core Data for Interoperability Draft

April 13, 2026

Thomas Keane, M.D., MBA
National Coordinator for Health Information Technology
U.S. Department of Health and Human Services
330 C Street, SW, 7th Floor
Washington, DC 20024

Submitted Electronically

RE: United States Core Data for Interoperability Draft Version 7

Dear Dr. Keane:

On behalf of our nearly 5,000 member hospitals, health systems and other health care organizations, our clinician partners — including more than 270,000 affiliated physicians, 2 million nurses and other caregivers — and the 43,000 health care leaders who belong to our professional membership groups, the American Hospital Association (AHA) appreciates the opportunity to provide comment on the United States Core Data for Interoperability Draft Version 7 (USCDI v7).

The USCDI is a standardized set of data elements — grouped into data classes such as demographics, medications and vital signs — that are intended to support nationwide, interoperable electronic data exchange. They are part of the Office of the National Coordinator for Health IT’s (ONC) Health IT Certification program, and can help ensure consistent health information exchange across the various parties that engage in a patient’s health care journey. Standardization of data elements is a critical component to advance interoperability, support patient safety and improve communication across stakeholders.

In general, the AHA appreciates ONC’s thoughtful approach to evolving USCDI. The USCDI v7 proposals include 30 new and revised elements, demonstrating ONC’s commitment to continually updating elements to keep pace with clinical, technology and policy changes. While we support several of ONC’s proposals, other proposed changes lack clarity of purpose, do not align well with clinical workflows and would inadvertently run counter to the USCDI goals by increasing burden, reducing reliability and exacerbating unwarranted variation.

The AHA recommends that ONC:

Adopt proposed USCDI data elements that align with clinical workflows and are supported by certified health IT, such as device type, accommodation and deceased indicator.
Not adopt proposed USCDI data elements that conflict with existing processes and where risks outweigh benefits, such as adverse events and referral notes.
Provide clarifying guidance and vocabulary standards prior to adopting USCDI data elements such as patient identifier, diagnostic imaging reference, nutrition assessment, reason not performed and health insurance information.

Our detailed comments are below.

Proposed USCDI Elements That Align with Clinical Workflows and Are Supported by Certified Health It

Device Type

USCDI v7 includes a proposed data element for “device type” within the medical devices data class. The device type element includes the “kind of instrument,” “machine,” “appliance,” “implant,” “software,” and “similar medical device” using Systemized Nomenclature of Medicine (SNOMED) vocabulary standards. We support “device type” data attributes advancement because this element supports existing workflows. This data element also could inform hospital quality improvement activities related to device use and other internal analyses.

Accommodation

This proposed data element includes information about modifications, tools, technologies and other supports to enable access to care. This may include sign language interpreters, wheelchair accessibility or sensory accommodation. The AHA supports the adoption of this new data element. We agree that standardization of this element can ensure awareness of patient-specific access needs across care delivery settings. It is also already leveraged in clinical workflows and is supported by certified health IT.

Deceased Indicator

ONC proposes a “deceased indicator” element to specify whether a patient is known to be deceased. The element would be structured as a yes/no flag, and could be used in conjunction with elements for date or cause of death, where available. We agree with ONC that the reliable exchange of information on deceased status would support patient matching processes and may mitigate undue stress to family members caused by outreach for a deceased patient. We support the advancement of this element.

Proposed USCDI Elements That Conflict with Existing Processes and/or Where Risks Outweigh Benefits

Adverse Events

In USCDI v7, ONC proposes a new “adverse events” data class to capture unintended effects associated with clinical interventions. The data class would be comprised of “adverse event details” (a change to patient condition that could be an unintended effect of clinical interventions) and “adverse event outcomes” (the result or impact of an adverse event, such as hospitalized, recovered, recovered with sequelae and death).

Patient safety has long been a top priority for hospitals and health systems. We recognize that this proposal intends to support adverse event tracking across care settings and the identification of adverse event patterns. However, we are concerned that the proposed new “adverse events” data class does not have clear definitions, does not reflect existing clinical workflows and may be inconsistent with existing federal regulatory frameworks governing information sharing for adverse events.

In terms of existing workflows, “adverse events” are typically not known or labeled as such at the point of clinical documentation. Some clinical conditions that may be associated with an adverse event (e.g., electrolyte abnormalities, hypotension) are usually documented in the electronic health record (EHR) as a clinical finding as opposed to an adverse event. That is because adverse events generally require root cause analysis (RCA) to determine if the event was related to medical care rather than an underlying condition. RCAs include detailed multidisciplinary reviews to determine how the event occurred and if the event resulted from systemic issues. Furthermore, while certified EHRs provide data to inform adverse event analyses, RCAs and other adverse event analyses are usually performed using other platforms. In other words, EHR data can inform analyses of adverse events, but are usually not the authoritative internal repository for adverse events.

Furthermore, we are concerned that ONC’s proposal may be inconsistent with the federal privacy and confidentiality protections provided by the Patient Safety and Quality Improvement Act (PSQIA). Enacted in 2005, the PSQIA promotes voluntary activities that enable providers to learn from and prevent adverse events in a non-punitive, improvement-oriented environment. The PSQIA established three core components to support this work:

Patient safety evaluation systems (PSES) are structured processes that hospitals use to collect, manage, analyze and evaluate information related to adverse events and near misses. Typical components of a PSES include, but are not limited to, safety event reporting platforms and RCA protocols.
Patient safety work product (PSWP) is information collected and created during the internal reporting and analysis of adverse events and near misses. These could include safety event reports, the results of RCAs conducted using a PSES-specified process and trend analyses of safety events.
Patient safety organizations (PSOs) are independent, federally-listed groups that collect hospital data to find patterns and share best practices for preventing adverse events. By statute, hospital participation in PSOs is entirely optional.

The PSQIA treats both the PSWP and PSOs’ work as privileged and confidential to encourage the reporting and analysis of adverse events. Protection from disclosure fosters a culture of safety and learning, as opposed to retribution and blame.

The AHA is concerned that the vague definitions of adverse events proposed by ONC could inadvertently circumvent these protections. This is especially true of the “adverse event detail” data elements, which do not appear to distinguish between a clinical finding and an adverse event. This could lead to certain clinical parameter changes (e.g., a hypoglycemic event) being characterized as an adverse event without the benefit of hospitals’ deliberative processes to ascertain the root cause.

Given the concerns that the proposed “adverse events” data class may conflict with existing confidential reporting processes, we urge ONC not to adopt the “adverse events” data class and corresponding data elements from USCDI v7. However, we recognize the potential value of learning from broader trends in adverse events and encourage the agency to consider issuing a formal request for information regarding opportunities to better track adverse event patterns.

Referral Note

The AHA urges ONC not to adopt its proposed referral note data element. This element entails a narrative summary that may include the reason for referral, relevant patient history and requested services or questions. However, the AHA believes this data element does not reflect existing clinical workflows. Typically, referrals are initiated through an order, and documentation is completed within clinical progress notes. The addition of a referral note data element outside the progress note would introduce administrative burden and redundancies without commensurate improvement in coordination.

Provide Clarifying Guidance and Vocabulary Standards Before Formalizing

Patient Identifier

USCDI v7 includes a new data element for a “patient identifier.” The element description indicates that this includes a sequence of characters assigned by an organization to uniquely refer to a patient. USCDI v7 also includes an example (Medical Record Number, or MRN), but does not provide a list of the patient identifiers being considered.

The AHA recognizes the importance of unique patient identifiers in supporting patient matching activities and ensuring patient safety, and in concept, we support the establishment of unique patient identifier standards. However, we urge ONC to specify the types of patient identifiers that would be included in this element. For example, ONC’s guidance should address issues such as whether MRNs and/or other identifiers like regional identifiers would be required.

Diagnostic Imaging Reference

ONC proposes a computable reference that enables access to diagnostic imaging associated with a patient encounter. The goal of such a reference would be to reduce duplicative imaging and more seamlessly exchange images across networks.

As the AHA recently commented, access to secure, high-resolution images is often a critical component of diagnosis and early intervention and can improve outcomes and reduce costs.[1] However, the seamless transfer of images has historically been hampered by siloes generated from proprietary systems, inconsistent formats and the lack of exchange frameworks.

The AHA recognizes that new USCDI data elements may be an important part of improving the interoperability of diagnostic imaging. However, before finalizing new data elements, we encourage ONC to promote platform and exchange standardization through a uniform regulatory approach for imaging interoperability. We recommend this be done through formal rulemaking to gather public stakeholder feedback.

Nutrition Assessment

USCDI v7 proposes the “nutrition assessment” element to identify findings of nutritional status, needs and risks. The agency asserts that this element can support transitions of care, reduce errors in diet instructions and enable better integration of nutrition into care planning activities.

The AHA supports the concept of this proposed data element and appreciates the important role of capturing nutrition assessment data to drive health. However, we urge ONC to provide more specificity about the intended use, scope and standards for this element. This would ensure that the element is used consistently and advances the USCDI’s goal of standardizing data capture.

Reason Not Performed

The agency proposes the element “reason not performed” under a new data class for health care information attributes. The “reason not performed” element is intended to identify why an ordered test, procedure, immunization or other planned intervention did not occur, such as patient refusal, clinical contraindication or logistical constraints. ONC asserts that the intent of this proposed element is to support more accurate quality measurement.

We appreciate the intent of capturing data to support more accurate quality measure reporting, as there may be instances where data should not be included (e.g., if a patient declined an intervention). At the same time, EHRs do not always reflect the reasons that tests are not performed, which instead tend to be captured in ancillary systems (e.g., lab or imaging systems). Based on ONC’s proposed description, it is unclear what the intended scope of the element is. Before adopting this data element, we recommend that ONC develop guidance that includes illustrative examples. This could help providers know what to capture in EHRs and reduce the use of free-text entry. In addition to areas like patient refusal, clinical contraindication or logistical constraints, we would also encourage the agency to explore opportunities for reasons related to insurance coverage or insurance denials. We also recommend that ONC clarify existing workflow artifacts that should be used instead of requiring new documentation. For example, there may be existing artifacts in the order management system reason codes, clinical notes, scheduling tools, radiology systems and lab systems that support this element.

Health Insurance Information

ONC proposes four elements under the “health insurance information” data class, including “coverage period,” “payer,” “plan” and “plan identifier.” The AHA agrees that standardized exchange of payer and plan data can minimize administrative burden and improve care coordination across care settings. However, we ask ONC to provide clarifying details on the elements proposed. For example, the proposed description of “plan identifier” is a sequence of characters used to uniquely refer to an insurance plan. It would be helpful for ONC to provide examples of plan identifiers to minimize variation and prevent the use of free text or local codes. It would also be useful for ONC to provide clarifying information on why there is a need for this element now and how this proposal differs from the health plan identifier (HPID) requirements from 2012 that was rescinded after stakeholder concerns were raised regarding provider burden, implementation costs, and inefficiencies.[2] Similarly, the descriptions of “payer” and “plan” do not provide examples, which increases the likelihood of variability. We encourage ONC to provide clarifying information for these elements.

Again, we applaud ONC’s ongoing work to standardize data classes, elements and vocabulary standards to reduce variation and promote interoperability. We look forward to working with the agency to refine USCDI v7 proposals and further advance data interoperability to support patient care. Please contact me if you have questions, or feel free to have a member of your team contact Jennifer Holloman, AHA’s director of health IT policy, at jholloman@aha.org.

Sincerely,

/s/

Ashley Thompson
Senior Vice President
Public Policy Analysis and Development

Notes

Download the Letter PDF

AHA Comments on ONC Core Data for Interoperability Draft PDF

Interoperability