On March 9, 2020, the United States Department of Health and Human Services (HHS) Office of the National Coordinator for Health Information Technology (ONC) released a final rule implementing provisions of the 21st Century Cures Act (Cures Act). The rule covers Conditions and Maintenance of Certification requirements for health information technology (health IT) developers, the voluntary certification of health IT for use by pediatric health providers, and reasonable and necessary activities that do not constitute information blocking. The Rule also implements portions of the Cures Act to support patients’ access to the electronic health information (EHI) in a form convenient for patients (i.e., making a patient’s EHI more electronically accessible by adopting standards and certification criteria) and implementing information blocking policies that support patient electronic access to their health information at no cost to them.
Deregulatory Actions
In this final rule, ONC finalized new deregulatory actions with the intent to reduce burdens on health IT developers, providers, and other stakeholders. The five actions are: (1) removal of a requirement to conduct randomized surveillance on a set percentage of certified products, allowing ONC-Authorized Certification Bodies (ONC-ACBs) more flexibility to identify the right approach for surveillance actions; (2) removal of the 2014 Edition from the Code of Federal Regulations (CFR); (3) removal of the ONC-Approved Accreditor (ONC-AA) from the Program; (4) removal of certain 2015 Edition certification criteria; and (5) removal of certain Program requirements.
Modifications to the ONC Health IT Certification Program
The rule also finalized corrections to the 2015 Edition privacy and security certification framework (80 FR 62705) and relevant regulatory provisions. Additionally, the rule clarifies that the records retention provision includes the “life of the edition” as well as three years after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules.
Conditions and Maintenance of Certification Requirements
The Program’s Conditions and Maintenance of Certification requirements express initial requirements for health IT developers and their certified Health IT Module(s) as well as ongoing requirements that must be met by both health IT developers and their certified Health IT Module(s) under the Program. In this regard, we have implemented the Cures Act Conditions of Certification requirements with further specificity as it applies to the Program and implemented any accompanying Maintenance of Certification requirements as standalone requirements to ensure that the Conditions of Certification requirements are not only met but continually being met through the Maintenance of Certification requirements.
Information Blocking
Section 4002 of the Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification requirement under the Program, not take any action that constitutes information blocking as defined in section 3022(a) of the Public Health Service Act (PHSA). As finalized, the Condition of Certification requirement prohibits any health IT developer under the Program from taking any action that constitutes information blocking as defined by section 3022(a) of the PHSA.
Assurances
Section 4002 of the Cures Act also requires that a health IT developer, as a Condition of Certification requirement under the Program, provide assurances to the Secretary that, unless for legitimate purpose(s) as specified by the Secretary, the developer will not take any action that constitutes information blocking as defined in section 3022(a) of the PHSA or any other action that may inhibit the appropriate exchange, access, and use of EHI.
Application Programming Interfaces (APIs)
As a Condition of Certification requirement in section 4002 of the Cures Act requires health IT developers to publish APIs that allow “health information from such technology to be accessed, exchanged, and used without special effort through the use of APIs or successor technology or standards, as provided for under applicable law.” The Cures Act’s API Condition of Certification requirement also states that a developer must, through an API, “provide access to all data elements of a patient’s electronic health record to the extent permissible under applicable privacy laws.” The Cures Act’s API Condition of Certification requirement in section 4002 includes several key phrases and requirements for health IT developers that go beyond the technical functionality of the Health IT Modules they present for certification. This final rule adopts new standards, new implementation specifications, a new certification criterion, and a modified Base EHR definition.
Information Blocking
The Cures Act defines “information blocking” as a practice that health care providers or HIT developers, exchanges, or networks engage in that “is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information.”
In the final rule, ONC identifies eight exceptions to the information blocking prohibition. The exceptions generally address activities that are reasonable and necessary under certain circumstances, despite being likely to interfere with, prevent, or materially discourage access to, or the exchange or use of, EHI.
The exceptions are:
- Practices that are reasonable and necessary to prevent harm to a patient or another person;
- Practices that are reasonable and necessary to protect the privacy of an individual’s EHI;
- Practices that are reasonable and necessary to promote the security of EHI;
- Practices where a person declines to provide access to EHI because doing so is infeasible; and
- Practices that are reasonable and necessary to maintain and improve the overall performance of HIT.
- Practices where an actor reasonably limits the content of its response to, or the manner in which it fulfills, a request to access, exchange, or use EHI;
- Practices where an actor is permitted to recover certain costs reasonably incurred in connection with accessing, exchanging, or using EHI; and
- Practices where an actor licenses interoperability elements on reasonable and non-discriminatory terms.