Key Takeaways for Health Care Providers regarding new AI Transparency Provisions, EHR Certification criteria, and Information Blocking

Most noteworthy, the HTI-1 Rule establishes groundbreaking transparency requirements for artificial intelligence (AI) and machine learning (ML) technology that supports clinical decision-making in certified health IT. Additionally, the final rule makes substantial changes to the Information Blocking Rules and ONC’s Health IT Certification Program to facilitate interoperability and improve access to, and the exchange and use of, electronic health information. The HTI-1 Rule also includes a significant number of new provisions and modifications to existing provisions across a wide range of topics, with the goal of further promoting interoperability and advancing equity.

This article provides high-level takeaways for health care providers (whether or not such providers are considered health IT developers). For more information on the broader contents of the HTI-1 Rule, as well as upcoming webinars hosted by ONC.

Decision Support Interventions

Though artificial intelligence and machine learning in health care is not new, its exponential growth in recent years has invited scrutiny and increased efforts to implement additional oversight.  The HTI-1 Rule is a significant step forward in those efforts, as ONC seeks to strike a balance between promoting innovation and safeguarding against risks.  As stated in the preamble to the HTI-1 Rule, ONC believes that “now is an opportune time to help optimize the use and improve the quality of AI and machine learning-driven decision support tools.”[1]

In particular, the HTI-1 Rule includes a new “decision support intervention,” or “DSI,” criterion at 45 CFR 170.315(b)(11) – which effectively replaces and updates the prior provision applicable to clinical decision support at 45 CFR 170.315(a)(9).  As described by ONC, this provision is intended to “reflect an array of contemporary functionalities, support data elements important to health equity, and enable the transparent use of predictive models and algorithms to aid decision-making in healthcare.”[2]  With this in mind, ONC carries over many of the concepts set forth in the CDS criterion, but also distinguishes between “evidence based DSI” and “Predictive DSI,” and imposes heightened standards for Predictive DSI.

Predictive DSI is defined as “technology that supports decision-making based on algorithms or models that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis.” The revised definition aims to align with, and place Predictive DSI within the scope of, the definition of Artificial Intelligence at 15 U.S.C. 9401(3), as used in E.O. 14110, Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence.

Notably, while most of ONC’s proposals related to the DSI criterion were finalized, the agency significantly narrowed the scope of the requirements only to Predictive DSIs supplied by a Health IT developer as part of its certified health IT module. This change was in response to the significant concern ONC received in comments about the broad scope of the proposed rule (which read that the requirements applied to all Predictive DSIs “that the certified Health IT Module enables or interfaces with”). As such, the DSI criterion requirements do not extend to Predictive DSIs developed or implemented by clients of Health IT developers that are not part of the Health IT developer’s certified health IT module.

The key requirements as finalized for Health IT developers supplying Predictive DSI focus on transparency, risk mitigation, and governance controls, as ONC seeks to promote FAVES principles, i.e., DSIs that are fair, appropriate, valid, effective, and safe, without being too prescriptive by establishing applicable baselines, measures, thresholds, or other methodologies.  The requirements include:

• Source Attributes. The regulation sets forth a list of source attributes which users must be able to access, including: (1) details and output (including the funding source); (2) purpose (e.g., intended patient population, use, and user); (3) cautioned out-of-scope uses; (4) development details and input features (including demographic representativeness); (5) process to ensure fairness (including description of approach to reduce or eliminate bias); (6) external validation process description; (7) quantitative measures of performance; (8) ongoing maintenance (e.g., the frequency by which the validity and fairness is monitored); and (9) update and continued validation or fairness assessment schedule.[3]  ONC states that access to this information “will have value both as reference information to individual users evaluating the use of DSI on an individual patient … and for the organization during procurement, implementation, and analysis.”[4]  Access could be for a limited set of identified users, as opposed to all users of the Health IT.
• Intervention Risk Management. The developer must engage in intervention risk management practices, meaning analysis of potential risks and adverse impacts associated with validity, reliability, robustness, fairness, intelligibility, safety, security, and privacy.  This is an example of flexibility allotted to developers, as ONC does not dictate a particular framework to conduct the risk analysis, though it does reference NIST’s AI Risk Management Framework and notes this provision was drafted to be consistent with such framework.[1] Once risks are identified, the developer must engage in risk mitigation practices.
• [1] 89 Fed. Reg. 1272-73.
• Governance. The developer must adopt policies and controls for governance, including with respect to data acquisition, data management, and data use.

Other safeguards to mitigate risks must also be in place. ONC notes that the Predictive DSI will also be subject to real-world testing and require Health IT developers to submit the results of such testing, as required under 45 CFR 170.405.  In addition, as part of the Predictive DSI configuration, users must be able to provide electronic feedback, and that feedback will be available for export.

Health IT developers will need to update Health IT currently certified to the CDS criterion to meet the DSI criterion requirements by December 31, 2024.

It is important to note that although it can be anticipated similar requirements could be proposed in the future for other groups of AI tools, the regulations set forth in this rulemaking do not address third-party vendors outside of this program.  Micky Tripathi, the National Coordinator for Health Information Technology, had indicated to Congress that the agency’s expectation is that as AI becomes more transparent through these Predictive DSI requirements, other developers will voluntarily begin matching similar standards.

The rule does not specifically include any standards, format or benchmarks for the disclosures and noted that certification is not an approval or guarantee from ONC. They have implemented these requirements to allow users to review and make their own judgments from the information provided.  ONC has indicated it would be premature to mandate certain measures as there has not been a consensus to this point.

Clarifications and Updates to Information Blocking Exceptions

The 21st Century Cures Act (Cures Act) prohibits “information blocking” by certain actors, including health care providers, health IT developers, and health information exchanges. Information blocking is generally defined as a practice that is likely to interfere with, prevent, or materially discourage access, exchange or use of electronic health information, except as required by law or permitted by an information blocking exception specified in ONC’s regulations.

In an effort to support information sharing and improve clarity on compliance with information blocking requirements, the HTI-1 Rule modifies and builds upon two regulatory exceptions, including the infeasibility and manner exceptions. The final rule also defines what it means to “offer health IT” for purposes of the information blocking regulations to provide clarifying guidance on when health care providers may offer certified health IT to others (as well as further defining “health IT developer” to clarify when a health care provider would or would not fall into such a category).

Streamlining Information Blocking Compliance: TEFCA Manner Exception

 Requests for health care data are a significant burden for providers due to the time and resources necessary to respond to frequent requests in different formats. In the proposed rule, ONC sought to mitigate this burden by allowing actors to fulfill certain information sharing obligations through a qualified health information network (QHIN) under the Trusted Exchange Framework and Common Agreement (TEFCA) with other QHIN participants and subparticipants. The proposed modifications were also intended to incentivize participation in TEFCA, which is a voluntary data sharing framework designed to enable nationwide exchange of electronic health information across different HINs. As finalized, the TEFCA exception only applies when the actor and requestor are both part of TEFCA as a QHIN, participant, or subparticipant, the requestor is capable of receiving the information requested specifically via TEFCA, and the request for access, exchange, or use of EHI is not via an API, essentially Fast Healthcare Interoperability Resources (FHIR)-based standard. This last condition was added in the final rule in response to public comments urging ONC to balance its dual goals of promoting TEFCA participation, on the one hand, and FHIR-based APIs, on the other.

Modifications to Infeasibility Exception

ONC recognizes several circumstances that may excuse providers from complying with requests for health information, including conditions under which it is infeasible to fulfill a request due to financial or technical barriers. Such circumstances include where a health care provider encounters an “uncontrollable event”, like a natural disaster. In the final rule, ONC finalized minor changes to the “uncontrollable events” condition to make it clear that there must be a causal relationship between the uncontrollable event and the infeasibility to fulfill the request. In other words, the provider cannot fulfill a request because of an uncontrollable event that negatively impacts the provider’s ability to exchange or provide access to electronic health information.

Additionally, ONC also finalized two new conditions under the Infeasibility Exception, referred to as the “third party seeking modification use” condition for when third parties seek greater control over data flows, and the “Manner Exception exhausted” condition, for when providers’ efforts to accommodate a request are unsuccessful.

Clarification Regarding when Health Care Providers are Health IT Developers

In the proposed rule, ONC sought to define the term “offer health IT” in an effort to delineate what technical activities or arrangements providers may undertake without being classified as a “health IT developer of certified health IT” under the Information Blocking rules. As finalized, ONC’s modified definitions intend to clarify the impact of certain subsidies (e.g., donations or subsidies of health IT acquisition) on providers’ obligations under the Information Blocking rule, promote acquisition of beneficial technology, and give providers additional certainty that certain collaborative functionalities do not constitute “offering” health IT.  In particular, the revised definitions help to expressly narrow the circumstances under which a health care provider would be considered a health IT developer:

• “Offer Health IT”: Modified to exclude activities commonly conducted by providers, including implementing APIs, extending portal access, or providing login credentials to independent practitioners under certain circumstances.
• “Health IT Developer of Certified Health IT”: Excludes providers who self-develop technology that is “not offered to others”, even when that technology is extended to other providers under certain circumstances (i.e., it does not constitute “offering” health IT under the new definition of such concept).

In light of these changes, health care providers should consider revisiting their analysis as to whether they engage in activities or arrangements that would cause them to be considered a “health IT developer” subject to the Information Blocking Rule by “offering” health IT.

Certification Program Updates

For health care providers who also develop or offer health IT and have voluntarily certified one or more health IT modules with ONC through its ONC Health IT Certification Program,[6] the HTI-1 Rule includes several updates to health IT certification criteria and implementation specifications to be aware of.  We highlight a few of these key updates below.[7]

EHR Reporting Program

The HTI-1 Rule implements the Electronic Health Record (EHR) Reporting Program, as required under the Cures Act, by establishing new Conditions of Certification for developers of certified health information technology (health IT) under the ONC Health IT Certification Program. Specifically, under the Insights Condition and Maintenance of Certification (Insights Condition), certain developers of certified health IT with at least 50 hospital sites or 500 individual clinician users for their certified health IT will be required to submit data annually to ONC regarding specified measures around interoperability, usability and user-centered design, security, conformance to certification testing, and other categories. Such reporting is intended to provide more transparency around information gaps in the health IT marketplace as well as insight into user experience with certified health IT and the use of certain health IT functionalities that will all ultimately help monitor the performance of EHR technology.

USCDI v.3 as New Standard

The HTI-1 Rule adopts the United States Core Data for Interoperability Standard Version 3 (USCDI v3) as a means of promoting the establishment and use of interoperable data sets of Electronic Health Information (EHI) for interoperable health data exchange. (Recall that in the 2020 ONC Cures Act Final Rule, ONC adopted the USCDI, Version 1, as a nationwide baseline of established data classes and elements required to support interoperability by health IT developers.) The adoption of USCDI v3 expands upon the USCDI standard to include data elements such as sexual orientation, gender identity, and certain social determinants of health. ONC believes that including these elements will help to more accurately capture diverse characteristics of patients and drive efforts toward reducing health outcome disparities, particularly in marginalized and underrepresented communities. The adoption of new elements under USCDI v3 is also intended to improve public health and emergency response (for example, a new pandemic) by facilitating the collection and exchange of key data elements related to public health. Prompting ONC’s move toward adopting of USCDI v3 is the concept of “health equity by design,” which ONC defines as occurring “where health equity considerations are identified and incorporated from the beginning and throughout the technology design, build, and implementation process, and health equity strategies, tactics, and patterns are guiding principles for developers, enforced by technical architecture, and built into the technology at every layer.” USCDI v1 may continue to be used until December 31, 2025; thereafter, only v3 may be used (note this deadline is one year later than the proposed rule in response to concerns about complying with the new baseline standard by January 1, 2025).

The HTI-1 Rule will take effect February 8, 2024. For health care providers who use Certified EHR Technology and participate in CMS’s interoperability programs, it will be critical to understand the new requirements imposed by the HTI-1 Rule to ensure that their health IT conform. Reevaluating the information blocking actor classification may also be necessary for certain health care providers, to the extent they “offer health IT”, and with it, updating information sharing practices for consistency with new provisions of the Information Blocking rules. While the final rule provides some time over the next few years for health IT developers and industry to implement the required changes, the DSI provisions have a one-year compliance mandate, given ONC’s prioritization of algorithmic transparency.

ONC has also been moving forward on its Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability proposed rule (HT-2) which is expected to be released soon.

[1] 89 Fed. Reg. 1192, 1196 (Jan. 9, 2024).

[2] 89 Fed. Reg. 1235.

[3] For more information on the source attributes and other information regarding the DSI certification criterion, see HTI-1 Decision Support Interventions (DSI) Fact Sheet: Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Final Rule (healthit.gov).

[4] 89 Fed. Reg. 1256.

[5] 89 Fed. Reg. 1272-73.

[6] See https://www.healthit.gov/topic/certification-ehrs/about-onc-health-it-certification-program.

[7] The HTI-1 Rule revises certification criteria in a range of areas that are not addressed here, including, by way of example, criteria addressing electronic case reporting and standardized application programming interfaces (APIs) for patient and population services, patient demographics and observations, and transitions of care.   The rule also introduces a new certification criterion for patient requested restrictions, which aims to further support the rights provided to patients under the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule.