On July 10, the Office of the National Coordinator for Health Information Technology (ONC)[1] released the Health Data, Technology, and Interoperability: Patient Engagement, Information Sharing, and Public Health Interoperability (HTI-2) proposed rule, which would implements provisions of the 21st Century Cures Act. This proposed rule was then released by the US Department of Health and Human Services (HHS) on the Federal Register on July 24. ONC and HHS also released an overview of the proposed rule, a fact sheet and an official press release. This proposed rule follows the HTI-1 final rule, which was effective on February 8, 2024, and continues the work that HHS has done to improve information sharing and interoperability across the healthcare system.
Among other things, this proposed rule seeks to:
- Enhance information blocking regulations, including the addition of a new exception designed to protect actors from legal action against lawfully provided reproductive healthcare,
- Tie certification requirements to United States Core Data for Interoperability Version 4 (USCDI v4), which includes new data elements to better capture patient characteristics,
- Modernize public health information technology (IT),
- Adopt newer versions of the following minimum code sets: Laboratory tests, Problems, Medications, Immunizations, Race and Ethnicity, Sex, Sexual orientation and gender information, and Social, psychological, and behavioral data, and
- Improve existing APIs through new certification requirements, which would improve patient’s access to information and help streamline the electronic prior authorization process.
Interested parties have until October 4, 2024, to submit comments.
PROPOSED KEY REVISIONS AND NEW EXCEPTIONS TO INFORMATION BLOCKING REGULATION
Under the Cures Act, healthcare providers, health Information networks/health information exchanges, and health IT developers of certified health IT face penalties for information blocking, which is defined under the Cures Act as a practice that “is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information”[2]. Currently, there are nine information blocking exceptions that, if met, prevent covered actors’ actions from being considered information blocking. For example, the Preventing Harm Exception protects covered actors from being considered to be engaging in information blocking if their actions “are reasonable and necessary to prevent harm to a patient or another person.”[3] This proposed rule would modify existing exceptions and introduce two new exceptions.
The rule would also introduce revisions to the defined terms in the information blocking regulations, include definitions relevant to the Trusted Exchange Framework and Common Agreement (TEFCA), and include with descriptions of practices that constitute interference with electronic health information (EHI).
New Proposed Information Blocking Exceptions
ONC proposes a new Protecting Care Access Exception to protect patients, providers, and facilitators from legal risks associated with sharing reproductive healthcare EHI. Under this exception, covered actors would be able to decline to share information about reproductive healthcare that was lawfully provided if sharing said information would cause risk of legal action. This exception would require actors to meet a threshold condition and either a patient protection condition or a care access condition. This proposal has been lauded by the AMA, as it would create clarity for providers.[4] ONC also proposes a new Requestor Preferences Exception to allow actors to honor requestor preferences for limitations on the scope, conditions, and timing of EHI availability without being considered information blocking.
Revisions to Existing Information Blocking Exceptions
The proposed rule includes revision to the Infeasibility and Privacy exceptions. Revisions to the Infeasibility Exception aim to enhance clarity and applicability, including adjustments to conditions related to third-party modification use and establishing different timeframes for responding to infeasibility requests. Revisions to the Privacy exception would broaden the applicability of the Interfering with Individual Access Based on Unreviewable Grounds sub-exception and broaden the availability of the Individual’s Request Not to Share EHI sub-exception.
ONC SEEKS TO REQUIRE USE OF USCDI V4 FOR HEALTH IT
The United States Core Data for Interoperability (USCDI) is a standardized set of data elements and data classes, which aggregate data elements by use case or theme. For example, the Health Status Assessments data class includes the following data elements: health concerns, functional status, disability status, mental/cognitive status, pregnancy status, alcohol use, substance use, physical activity, SDOH assessment, and smoking status. These data classes and elements represent the data points that certified health IT are expected to be able to support. By requiring that health IT maintains this standard for certification, ONC aims to promote interoperability between payers, providers, patients, and hospitals.
The USCDI was established by the ONC Cures Act Final Rule in 2020[5]. It has been updated four times since, with each update adding new data elements and/or data classes. In the Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing final rule[6], HHS, finalized the adoption of USCDI v3. In this rule, HHS proposes that, by January 1, 2028, all Health IT Modules certifications based on USCDI will require the use of USCDI v4. USCDI v4 adds 20 new data elements, including alcohol use, substance use, smoking status, and average blood pressure, and one new data class, facility information. HHS believes that increasing the demographic information available will advance health equity by painting a better picture of each patient’s unique characteristics, allowing for data analysis that better captures disparities.
ONC PUSHES TO MODERNIZE HEALTH IT FOR PUBLIC HEALTH
ONC notes that despite recent improvements to interoperability in healthcare, public health authorities (PHAs) often lack access to data that would help them better address public health needs and often use outdated technology, issues that were exposed during the Covid-19 pandemic. To address this problem, ONC proposes a variety of provisions aimed at increasing interoperability in the public health sector and ensuring that public health IT modernizes on the same timeline as IT in the rest of the healthcare industry. These provisions include revisions to certification criteria and the addition of new certification criteria supporting public health data exchange, and the addition of a new standardized Application Programming Interfaces (API) for public health data exchange.
ONC Proposes Revisions to Certification Criteria Supporting Public Health Data Exchange
The proposed rule includes a variety of provisions aimed at updating existing certification criteria for reporting public health data.
ONC certification criteria for health IT transmitting data to immunization registries have not been updated since 2015. ONC proposes a number of changes to modernize these criteria including, updating the Immunization Messaging Implementation Guide (IG) referenced in these criteria to the latest standard and adding a new functional requirement to improve querying of patient-level immunization data. Certification criteria for health IT transmitting data to public health agencies with respect to syndromic surveillance have similarly not been updated since 2015. To help PHAs better identify public health threats, ONC proposes to update certification criteria to reference a more modern standard that would require new and updated data elements. This new data includes diagnosis code, reason for admission, and service location. These updates would go into effect on January 1, 2027.
The proposed rule would also update the certification criteria for health IT transmitting to PHAs with respect to reportable laboratory tests, adding a new requirement to receive, validate, parse, and filter laboratory orders, and changes that would increase demographic information. These updates would go into effect on January 1, 2028.
ONC proposes a number of revisions to the health IT certification criteria for reporting to cancer registries, which collect state-level cancer data to inform public health interventions. To ensure that health IT keep up with the most recent standards on generating cancer registry reports, ONC proposes adoption of either the Fast Health Interoperability Resources (FHIR) Standard Implementation Guide (IG) or the HL7 Clinical Document Architecture (CDA) Release 2 IG. ONC requests comment on whether health IT modules should be required to meet both standards, as opposed to only having to meet one of the standards. ONC also proposes to adopt the standard HL7 FHIR Cancer Pathology Data Sharing, 1.0.0 – STU1. HHS believes that standardized electronic reporting on cancer pathology will facilitate more accurate understanding of diagnosis and better assessments of cancer stage at diagnosis. These proposals would go into effect January 1, 2028. In addition to these proposed changes to the certification criteria for reporting to cancer registries, ONC proposes an accompanying certification criterion “Cancer pathology reporting – Receive, validate, parse, and filter,” that would support cancer registries in accepting and validating cancer pathology reports.
The proposed rule would also update requirements for certification around the transmission of electronic case reporting, antimicrobial use and resistance reporting, and healthcare surveys to public health agencies. The electronic case reporting certification updates would go into effect on January 1, 2028, while the other updates would go into effect on January 1, 2027.
ONC Proposes New Certification Criteria Supporting Public Health Data Exchange
In addition to revising existing certification criteria, the proposed rule would add new criteria around the transmission of birth reporting to PHAs and criteria to enable health IT modules to interact with Prescription Drug Monitoring Program (PDMP) databases. The birth reporting certification would address a lack of interoperability in birth reporting, such as duplicative processes data entry for state web-based Electronic Birth Registration Systems (EBRS) and EHRs. The PDMP certification requirements would create consistent standards supporting the querying of PDMP data.
ONC Proposes New Standardized API for Public Health Data Exchange
To expand PHA’s access to data and create consistent, modern standards for public health data exchange, ONC proposes to establish requirements for a new API for public health data exchange.
MINIMUM STANDARDS CODE SETS UPDATES
In the 2015 Edition Final Rule ONC established standards for frequently updated minimum standards code sets to improve interoperability and the implementation of health IT with minimal additional burden. As stated in the HTI-1 final rule, when proposing newer versions of these code sets, ONC considers their impact on interoperability and the effort required for developers of certified health IT to implement them. If adopted, these updated code sets would become the baseline for certification, allowing developers to use them voluntarily. Despite frequent updates, these changes are limited to the concepts within the code system rather than the standards themselves.
In this proposed rule, ONC proposes that a Health IT Module must use at least one version of the standard that is adopted or approved by the Standards Version Assessment Process (SVAP) and not expired at the time of use. Health IT developers must update modules to a new version of the standard, or a subsequent version approved by SVAP before the current version expires to maintain certification and provide updated modules to customers by the expiration date.
Specifically, ONC proposes to adopt newer versions of the following minimum code sets: Laboratory tests, Problems, Medications, Immunizations, Race and Ethnicity, Sex, Sexual orientation and gender information, and Social, psychological, and behavioral data.
PATIENT, PROVIDER, AND PAYER API
The CMS Interoperability and Patient Access[7] final rule and Interoperability and Prior Authorization[8] final rule increased interoperability in the healthcare sector by instituting requirements for new APIs to allow healthcare software programs to communicate with one another. The former required the use of a Patient Access API and Provider Directory API. The latter required the use of a Provider Access API, a Payer-to-Payer API, and a Prior Authorization API. Building on these rules, ONC proposes to adopt new certification requirements for all of these APIs.If finalized, these requirements would improve patient’s access to information, allowing them to make more informed decisions about their care, and reduce administrative burden on providers, particularly in regard to prior authorizations.
ONC is seeking feedback on all proposed certification criteria.
Patient Access API
ONC proposes criteria that patients are able to access their health information using an application of their choice. Specifically, Health IT Modules would enable patient access to payer drug formulary, patient clinical, coverage, and claims information.
Having access to payer drug formulary allows patients to understand the costs of their current prescription and potential alternatives. Patients can then compare their insurance plans with others to make more informed healthcare decisions.
Prior authorization API
In January 2021, ONC published a request for information on electronic prior authorization standards, implementation specifications, and certification criteria. Following the RFI, ONC directed the Health Information Technology Advisory Committee (HITAC) to create a Task Force to give input and provide recommendations in response to the RFI. The proposals in this proposed rule would implement several of HITAC’s recommendations.
ONC proposes to establish requirements for Health IT Modules to facilitate a provider’s request for a prior authorization decision as well as requirements that payers can accept prior authorization requests from a provider and send requested coverage information and prior authorization decisions. These requirements would help support real-time access to data necessary for requesting and receiving authorization, reducing administrative burden.
Payer-to-payer API
ONC proposes to specify requirements for Health IT Modules to allow electronic exchange between payer systems, allowing health data and information to follow the patient when they switch payers. If finalized, this proposal would reduce administrative burden, improve care coordination, and make it easier for patients to take ownership of their care.
Provider access API
ONC proposes to adopt “provider access API – client” and “provider access API – server” certification criteria that would enable a provider to access information on patients’ claims as well as clinical information from sources other than claims. These proposals would inform better coordination between the provider and patient and help produce a higher quality of care.
Provider directory API
ONC proposes to adopt requirements that would allow payers to publish information on providers that participate in their network. This proposal would allow patients to understand which providers, facilities, and pharmacies are covered by their current plan, and would allow them to compare plans.
*********
This Applied Policy® Summary was prepared by Will Henkes with support from the Applied Policy team of health policy experts. If you have any questions or need more information, please contact him at whenkes@appliedpolicy.com or at (608) 722-9413.
[1] As of 7/25, the ONC is know as the Assistant Secretary for Technology Policy and Office of the National Coordinator for Health Information Technology (ASTP/ONC)
[2] 21st Century Cures Act, Pub L. 114-255
[3] Cures Act Final Rule: Information Blocking Exceptions (healthit.gov)
[4] AMA statement on ONC exception to protect reproductive health privacy | American Medical Association (ama-assn.org)
[5] 85 FR 25642
[6] 89 FR 1192
[7] 85 FR 25510
[8] 89 FR 8758