ONC HTI-1 Proposed Rule – Key Takeaways for Health Care Providers

This article summarizes a few key takeaways of note 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 Proposed Rule, as well as upcoming webinars hosted by ONC, see Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI-1) Proposed Rule | HealthIT.gov.

Clarifications and Updates to Information Blocking Exceptions

Briefly for context, the 21st Century Cures Act (the “Cures Act”) amended the Public Health Service Act (“PHSA”) in December 2016 to prohibit “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. The PHSA also required HHS to identify reasonable and necessary activities that do not constitute information blocking and in March 2020, ONC released final rules governing information blocking and setting forth eight exceptions to the information blocking prohibition, each with detailed requirements that an actor must meet to avail itself of the exception.

The HTI-1 Proposed Rule modifies and builds upon two of these exceptions, including the infeasibility and manner exceptions. The proposed rule also proposes to define 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. The proposed rule would mitigate this burden by allowing providers to fulfill information sharing obligations through participation in the Trusted Exchange Framework and Common Agreement (TEFCA).[1] Under TEFCA, providers who connect to a Qualified Health Information Network (QHIN) may rely on that connection as a substitute for fulfillment of tailored requests for electronic health information.[2] In short, a provider’s response to a request for information could appropriately redirect the requestor to the QHIN.

Modifications to Infeasibility Exception

In addition, the proposed rule would recognize several circumstances that may excuse providers from complying with requests for health information. These circumstances include when a provider encounters “uncontrollable events” like a natural disaster, for when third parties seek greater control over data flows, and for when providers’ efforts to accommodate a request are unsuccessful.[3]

Generally, the infeasibility exception applies where sharing health information is not possible “under the circumstances” due to financial or technical barriers. This exception allows providers to uphold their information sharing obligations by documenting hardships that prevent the free flow of health information for appropriate purposes. The new “uncontrollable events” exception is a natural outgrowth of these principles—applying the same principle to acute disruptions to the flow of health information.

 Clarification Regarding when Health Care Providers are Health IT Developers

The proposed rule modifies several definitions to delineate what technical activities providers may undertake without being classified as health IT developers. 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 would help to expressly narrow the circumstances under which a health care provider would be considered a health IT developer:[4]

• “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).

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,[5] the HTI-1 Proposed Rule also includes several updates to health IT certification criteria and implementation specifications to be aware of.  We highlight a few of these key updates below.[6]

 EHR Reporting Program

The HTI-1 Proposed Rule, if finalized, would implement 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, certain developers of certified health IT will be required to submit to ONC every six months data 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.

Interoperability Updates, USCDI v.3

The HTI-1 Proposed Rule proposes to adopt 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.) If finalized, the adoption of USCDI v3 would expand upon the USCDI standard to include data elements such as sexual orientation, gender identity, and certain social determinants of health. ONC believes that including such elements would help to more accurately capture characteristics of patients that reflect patient diversity and drive efforts toward reducing health outcome disparities, particularly by patients who may be marginalized and underrepresented. 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.” If finalized, both USCDI v1 and v3 would be acceptable for use until December 31, 2024. However, only v3 could be used after December 31, 2024.

Clinical Decision Support and Predictive Decision Support Interventions

Given the immense potential of artificial intelligence and machine learning in healthcare, industry stakeholders should particularly note the provisions addressing clinical decision support (CDS) and decision support interventions (DSIs).  While many of the proposed rule’s provisions are incremental in nature, the CDS and DSI proposals are a significant evolution in the ONC’s HIT Certification regulations.  While the proposed regulations stop short of directly regulating developers of artificial intelligence (AI) and machine learning (ML), they do so indirectly by imposing requirements on developers of Certified Health IT.  The proposals around AI in particular reflect collaboration among several agencies including the Federal Trade Commission (FTC) and the HHS Office of Inspector General (OIG).

The proposed rule describes predictive decision support interventions, or predictive “DSIs,” as the “implementation of models to support or inform decision-making across the health industry.”[7]  The full definition is “technology intended to support decision-making based on algorithms or models that derive relationships from training or example data and then are used to produce an output or outputs related to, but not limited to, prediction, classification, recommendation, evaluation, or analysis.” Under the proposed rule, the current criterion for CDS would be renamed as the “Decision Support Interventions” certification criterion to more accurately reflect the nature of predictive models used in healthcare today.

The Proposed Rule would implement requirements for 1) health IT modules that enable or interface with predictive DSIs to provide information to users regarding technical specifications and performance; 2) requirements for certified developers of health IT regarding risk management practices related to predictive DSIs (including risks presented by bias and discrimination in AI); and 3) requirements for certified developers of health IT modules involving predictive DSIs to participate in certain types of testing.

The ONC’s proposals involving DSI seek to increase the transparency and trustworthiness of predictive algorithms with the ultimate goal of supporting their widespread use in healthcare. ONC describes its efforts involving DSIs with the term FAVES, i.e., DSIs that are fair, appropriate, valid, effective, and safe, and as such are considered by ONC to be “high-quality”. ONC intends to make information consistently available to enable providers to decide whether (and, if so, to what extent) to trust predictive DSIs and determine their appropriate role in patient care.  That information is key to enabling practitioners to use predictive DSIs in ways that create better outcomes for patients and to avoid the potential pitfalls of harmful or unhelpful models.

***

ONC is encouraging stakeholders to submit comments through regulations.gov, which are due by June 20, 2023.

ONC is also developing two other proposed rules, “Establishment of Disincentives for Health Care Providers who Have Committed Information Blocking” and “Patient Engagement, Information Sharing, and Public Health Interoperability.”[8]

[1] Following designation of the first QHINs earlier this year, TEFCA is poised to become a network-of-networks for health information sharing. Providers should be aware that participation in TEFCA may reduce administrative burdens when fulfilling or initiating requests for health information, while the terms of participation impose contractual information sharing duties that flow-down to providers from the QHIN.

[2] 88 Fed. Reg. 23746, 23873, 23917 (April 18, 2023).

[3] 88 Fed. Reg. 23746 at 23754, 23916.

[4] 88 Fed. Reg. 23746, 23857-23772, 23915.

[5] See here.

[6] The HTI-1 Proposed 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 proposed 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.

[7] 88 Fed. Reg. 23746, 23776.

[8] See here and here.