On April 18, 2023, the Office of the National Coordinator for Health Information Technology (“ONC”) within the U.S. Department of Health and Human Services published a proposed rule in the Federal Register titled “Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing” (the “Proposed Rule”).1 If finalized, the Proposed Rule would introduce significant changes to the ONC Health Information Technology Certification Program (the “Certification Program”) and the Information Blocking Rule2 applicable to health care providers, developers of certified health information technology (“health IT”), and health information exchanges and networks (“HIE/HINs”). The Proposed Rule represents ONC’s latest efforts in its mission to advance health IT interoperability, improve transparency in the health care market, and support the access, exchange, and use of electronic health information (“EHI”) pursuant to the 21st Century Cures Act (the “Cures Act”). Some of the most notable proposed changes for developers of certified health IT, health care providers, and HIE/HINs are summarized below.
I. Proposed Changes to the Certification Program
Under the Certification Program, electronic health records software applications (“EHRs”) and other health IT can be certified as adhering to certification criteria and requirements specified in federal regulations. Health care providers must use certified EHR technology that satisfies the minimum Certification Program criteria specified in federal regulations to participate in the Medicare Promoting Interoperability Programs.3 Therefore, changes to the Certification Program can significantly impact both developers of certified health IT and health care providers.
The Proposed Rule includes several notable proposed changes to the Certification Program, including:
- Replacing year-specific “Editions” of health IT certification criteria with a single set of “ONC Certification Criteria for Health IT”;
- Updating several Certification Program certification criteria and standards, including revising the criteria for clinical decision support (“CDS”) and electronic case reporting, introducing a new certification criterion for patient-requested restrictions on uses and disclosures of protected health information (“PHI”), and changing the applicable version of the United States Core Data for Interoperability (“USCDI”) standard and other standards and terminology associated with the Certification Program; and
- Revising the requirements to obtain and maintain health IT certification under the Certification Program (“Conditions and Maintenance of Certification Requirements”), including introduction of the new Insights Condition and Maintenance of Certification Requirements and updates to the Assurances, Application Programming Interfaces (“APIs”), Real World Testing, and Attestations Conditions and Maintenance of Certification Requirements.
a. Single Set of ONC Certification Criteria for Health IT
The Certification Program currently consists of year-specific “Editions” for 2011, 2014, and 2015, with the 2015 Edition being updated to reflect Cures Act requirements in 2020. ONC proposes changes to the health IT certification regulations to remove references to different certification Editions and instead reference one set of ONC Certification Criteria for Health IT that will be updated in an incremental fashion in closer alignment with standards development cycles and regular health IT development timelines. These changes are intended to reduce the perception of outdated technology in the market.
b. New Decision Support Interventions (“DSI”) Certification Criterion
The Certification Program currently includes a CDS certification criterion that outlines a set of requirements for health IT developers seeking to certify health IT that supports CDS.4 Since this criterion was last revised in 2015, health IT that supports CDS has evolved rapidly, and, in particular, predictive models and other forms of artificial intelligence have been increasingly used to inform decision-making in clinical, administrative, payment, and operations contexts. ONC refers to these expanded CDS capabilities and applications as decision support interventions (“DSIs”) and proposes to replace the existing CDS certification criterion with a new DSI certification criterion5 effective January 1, 2025. The new DSI certification criterion would address both CDS covered by the current criterion and predictive decision support algorithms and models. It would require predictive DSIs enabled by or interfaced with certified health IT modules to (i) enable users to review information about additional “source attributes” for evidence-based DSIs and patient demographics and observations data elements used in the DSI, (ii) implement “intervention risk management” practices to mitigate risk involved in the use of DSIs, and (iii) make public summary information regarding their intervention risk management practices. Health IT developers may be certified under either the current CDS criterion or the new DSI criterion through December 31, 2024.
Developers seeking certification to the CDS or DSI criteria also should keep in mind that certain CDS and DSI functionality may be subject to federal Food and Drug Administration (“FDA”) regulation as a medical device. FDA has issued and revised guidance over the last several years regarding when it considers CDS functionality to be software-as-a-medical device (“SaMD”) subject to FDA regulation. ONC explains that its authority to regulate developers under the Certification Program is separate and distinct from FDA’s oversight of the safety and effectiveness of SaMD functions, including CDS or other kinds of DSIs.6 ONC reassures stakeholders that the two agencies support a harmonized and complementary approach with respect to predictive technology independent of the platform on which the technology exists, in accordance with their existing intersecting regulatory oversight.7 Nevertheless, both agencies’ regulation of similar CDS and DSI functions could present administrative burden for developers that must comply with both agencies’ requirements.
c. New Patient Requested Restrictions Certification Criterion
ONC proposes to adopt a new “Patient Requested Restrictions” certification criterion in support of the Health Insurance Portability and Accountability Act of 1996 (“HIPAA”) Privacy Rule’s “right to request a restriction” on certain uses and disclosures of PHI pursuant to 45 C.F.R. § 164.522(a). To be certified under this proposed criterion, health IT developers would be required to enable users of health IT modules to implement a process to restrict uses or disclosures of PHI in response to a patient request for such restriction if agreed to by the covered entity. This certification criterion would be standards-agnostic, allowing health IT developers flexibility in designing these capabilities as long as functional requirements under the criterion are met.
d. Electronic Case Reporting Certification Criterion
The Certification Program currently includes an electronic case reporting criterion,8 which includes functional, descriptive requirements, such as case report creation and maintaining a set of trigger codes that signal reportability to public health agencies. ONC proposes to replace these requirements by January 1, 2025 with consensus-based, industry-developed electronic standards and implementation guides. ONC explains that the standardization of electronic case reporting in this manner will help facilitate faster and more efficient case reporting and disease tracking for public health purposes.
e. USCDI V.3 and Updated Standards and Terminology to Promote Diversity, Cultural Competency, and Health Equity
In its 2020 final rule, ONC adopted the USCDI v.1 standard for certified health IT to establish a set of data classes and constituent data elements required to support interoperability nationwide. Effective January 1, 2025, ONC proposes updating the version of the USCDI standard that certified health IT must support to USCDI v.3, which ONC has developed over the last few years based on stakeholder input. ONC explains that USCDI v.3 promotes patient diversity, cultural competency, and health equity by including new data elements related to sexual orientation, gender identity, and social determinants of health. ONC also proposes changes to content, exchange, and vocabulary standards and terminology associated with certain certification criteria to advance these goals. Further, ONC notes that either USCDI v.1 or v.3 will be acceptable through December 31, 2024.
f. New Insights Condition and Maintenance of Certification Requirements
ONC proposes to introduce new Insights Condition and Maintenance of Certification Requirements (“Insights Condition”) to implement an EHR Reporting Program as required by the Cures Act. The purpose of the Insights Condition is to provide transparent reporting and insights on health IT in the categories of interoperability, usability and user-centered design, security, conformance to certification testing, and other categories, as appropriate to measure the performance of EHR technology. If adopted as proposed, the Insights Condition would require reporting on a set of four measures beginning in April 2025 and an additional five measures beginning in April 2026, as described in more detail in the table in Exhibit A. While this initial set of nine reporting measures focuses on interoperability, ONC anticipates that it will, through future rulemaking, propose additional reporting measures for the Insights Condition that focus on usability, security, and conformance to certification testing.9
g. Changes to Existing Conditions and Maintenance of Certification Requirements
ONC also proposes changes to existing Conditions and Maintenance of Certification Requirements as follows:
- Assurances: Health IT developers that participate in the Certification Program must provide a number of assurances, including that their certified health IT is in full compliance with the certification criteria for which it is certified and that they will not engage in any action that constitutes information blocking. ONC proposes to require health IT developers to provide additional assurances that they will not inhibit a customer’s timely access to interoperable health IT certified under the Certification Program and that their health IT is certified to the most recently adopted certification criteria. ONC also proposes to require developers to make health IT certified to revised certification criteria available to customers within a specified time frame.10 ONC hopes that adoption of these new requirements will support and improve interoperability by requiring certification to the most recently revised certification criteria, which have been adopted by ONC to allow for better access, exchange, and use of EHI.
- APIs: The API Condition and Maintenance of Certification Requirements establish requirements for developers to obtain and maintain certification for APIs under the certification criteria codified at 45 C.F.R. § 170.315(g)(7)–(10). ONC proposes standardizing the format and content of service base URLs that developers must publish for the (g)(10) “standardized API for patient and population services” certification criterion and requiring developers to review published information quarterly. ONC believes that these proposed changes continue its efforts to standardize APIs, foster competition among API developers, and improve access to EHI.11
- Real World Testing and Attestations: ONC proposes to add the CDS certification criterion (§ 170.315(a)(9)) to the list of criteria that must be included in a developer’s real world testing plan and for which the developer must attest to compliance with real world testing requirements.12 In addition, ONC proposes to close a loophole that currently allows health IT with “inherited” certified status to avoid real world testing.13
II. Proposed Changes to the Information Blocking Rule
ONC proposes several changes to the Information Blocking Rule, which prohibits certain “actors”—health care providers, developers of certified health IT, and HIE/HINs—from engaging in certain practices that interfere with access, exchange, or use of EHI, except as required by law or permitted by an information blocking exception specified in the regulations. Overall, the changes are intended to provide actors with additional flexibility in meeting the Information Blocking Rule requirements.
a. Technical Changes to Remove References to Limited EHI Definition
Under the previously finalized regulations, the scope of EHI subject to information blocking was temporarily limited to data elements represented in the USCDI v.1 standard until October 6, 2022. ONC initially adopted a limited definition of EHI to afford stakeholders time to adjust to the new information blocking requirements. In the Proposed Rule, ONC proposes technical revisions to the Information Blocking Rule to remove references to the narrower EHI definition given that the USCDI limitation is no longer in effect. These changes include re-naming the “Content and Manner Exception” the “Manner Exception” because there is no longer a need to specify a different rule for the content of responses to EHI requests prior to October 6, 2022.
b. Updated Definition of “Developer” to Clarify What Constitutes “Offering” Certified Health IT
The Information Blocking Rule defines a “developer” subject to information blocking requirements as including individuals or entities that develop or offer certified health IT. However, the regulations do not define what it means to “offer” certified health IT. The definition of “developer” also excludes a health care provider that self-develops health IT “for its own use.” ONC proposes to codify a definition of what it means to “offer” certified health IT under the developer definition, which would include holding out for sale, selling, reselling, licensing, or relicensing. Crucially, however, the definition of “offer” would exclude the following:
- Certain donation and subsidized supply arrangements involving funding to subsidize or fully cover the costs of a health care provider’s acquisition, augmentation, or upkeep of health IT;
- Certain implementation and use activities, including issuing user accounts and/or login credentials to employees, public health authority employees, and other health care providers, and making available production APIs or online portals to query or transmit EHI from or across HIE/HINs; and
- Certain consulting, legal, administrative, and management services arrangements.
In addition, ONC proposes revising the developer definition to exclude “a health care provider that that self-develops health IT “not offered to others,” thereby leveraging the new “offer” definition. These proposed changes provide additional clarity to which individuals and entities—especially providers—would be considered “developers” under the regulations, which is important because developers may be subject to civil monetary penalties for information blocking violations, while providers are not.
c. Updates to the Infeasibility Exception
The Infeasibility Exception outlines the conditions under which not fulfilling a request to access, exchange, or use EHI due to the “infeasibility” of the request will not be considered information blocking.14 There are three such conditions under the current Infeasibility Exception, only one of which needs to be satisfied: uncontrollable events, segmentation, and infeasibility under the circumstances.
ONC proposes to revise the “uncontrollable events” condition in order to clarify that it requires the infeasibility to be caused by the uncontrollable event. ONC explains that this causal connection has always been required but that this proposed revision would provide greater clarity regarding the requirement.
ONC also proposes to add two new conditions: “third party seeking modification use” and “Manner Exception exhausted.” The “third party seeking modification use” condition would permit not fulfilling a request to modify EHI (e.g., creating and deleting EHI), so long as the request is not from a health care provider requesting such use from a business associate. ONC proposes this new condition in order to clarify situations in which declining certain requests for third-party modification or use of EHI is excepted from information blocking, thereby reducing the burden of determining whether requests to modify EHI meet other information blocking exceptions or other conditions under the Infeasibility Exception.
The “Manner Exception exhausted” condition applies when a request cannot be fulfilled after exhausting the Manner Exception,15 including offering all alternative manners, and the actor does not provide a substantial number of individuals or entities similarly situated to the requestor with the same requested access, exchange, or use of the requested EHI. If finalized, this condition would alleviate a major point of confusion under the current regulations as to what an actor should do if it cannot fulfill a request in the manner requested and the requestor does not accept any of the alternative manners specified in the Manner Exception.
d. Addition of the New “TEFCA Manner” for Fulfilling Requests for EHI
In January 2022, ONC published the Trusted Exchange Framework and Common Agreement (“TEFCA”) to facilitate data-sharing among health information networks and support nationwide health information interoperability. While participation in TEFCA is optional, ONC now proposes to adopt a new condition under the Manner Exception that would provide TEFCA-qualified health information networks (“QHINs”), participants, and sub-participants with additional flexibility when fulfilling requests for EHI. ONC hopes that this flexibility will encourage TEFCA participation.
If finalized, these proposed changes would significantly overhaul the ONC Health IT Certification Program in ways that would address the evolving landscape of health IT and continue to promote interoperability and improved access, exchange, and use of EHI. Developers of certified health IT will face additional burden in meeting these newly proposed and complex certification requirements. In addition, the changes would require health care organizations to re-evaluate their information blocking actor classifications and information sharing practices.
Comments on the Proposed Rule may be submitted until 5:00 p.m. Eastern Time on June 20, 2023.
* * *
- 88 Fed. Reg. 23,746.
- Codified at 45 C.F.R. Part 171.
- OFFICE OF THE NATIONAL COORDINATOR FOR HEALTH INFORMATION TECHNOLOGY, “About The ONC Health IT Certification Program,” https://www.healthit.gov/topic/certification-ehrs/about-onc-health-it-certification-program; OFFICE OF THE NATIONAL COORDINATOR FOR HEALTH INFORMATION TECHNOLOGY, ONC HEALTH IT CERTIFICATION PROGRAM OVERVIEW, https://www.healthit.gov/sites/default/files/PUBLICHealthITCertificationProgramOverview.pdf.
- 45 C.F.R. § 170.315(a)(9).
- 45 C.F.R. § 170.315(b)(11).
- 88 Fed. Reg. 23,810–11.
- 45 C.F.R. § 170.315(f)(5).
- 88 Fed. Reg. 23,843–44.
- Specifically, no later than December 31 of the calendar year that falls 24 months after the effective date of the final rule adopting the revised criteria or, for a new customer, no later than 12 months after the purchasing or licensing relationship has been established, if later than the December 31 deadline described above.
- 88 Fed. Reg. 23814–15.
- 88 Fed. Reg. 23809.
- 88 Fed. Reg. 23830–31. A newer version of a previously certified health IT module may be granted “inherited” certified status if the certifying body determines that the capabilities for which certification criteria have been adopted have not been adversely affected. See https://www.healthit.gov/faq/b11-how-does-inherited-certification-status-work.
- 45 C.F.R. § 171.204.
- 45 C.F.R. § 171.301.
Stay Up To Date with Ropes & Gray
Ropes & Gray attorneys provide timely analysis on legal developments, court decisions and changes in legislation and regulations.
Stay in the loop with all things Ropes & Gray, and find out more about our people, culture, initiatives and everything that’s happening.
We regularly notify our clients and contacts of significant legal developments, news, webinars and teleconferences that affect their industries.