On Monday, February 11, the Office of the National Coordinator for Health Information Technology (ONC) continued its implementation of the 21st Century Cures Act with the publication of its proposed regulation designed to advance interoperability, support the access, exchange and use of electronic health information, and address occurrences of information blocking.
ONC is also implementing Conditions and Maintenance of Certification requirements for health IT developers and supporting patient access to their electronic health information (EHI), such as making a patient’s EHI more electronically accessible through the adoption of standards and certification criteria and the implementation of information blocking policies that support patient electronic access to their health information at no cost. In addition, the proposed rule would modify the 2015 Edition health IT certification criteria and ONC Health IT Certification Program in other ways to advance interoperability, enhance health IT certification, as well as reduce burden and costs.
Moreover, the proposed rule focuses on establishing application programming interfaces (APIs) for several interoperability purposes, including patient access to their health information without special effort. The API approach also supports health care providers having the sole authority and autonomy to unilaterally permit connections to their health IT through certified API technology that health care providers have acquired.
Through this regulatory policymaking, ONC is trying to ensure coordination with the proposed regulation from the Centers for Medicare & Medicaid Services (CMS) to advance interoperability and facilitate greater patient engagement with and control over their healthcare data. Overall, the Department of Health and Human Services (HHS) is attempting to create opportunities for new market entrants and remove barriers to interoperability and EHI exchange, which would greatly benefit health care providers and patients.
The key provisions of ONC’s proposed regulation include the following.
Health IT Certification Program to Focus on More than Just Technical and Functional Requirements
ONC is proposing an approach where the Conditions and Maintenance of Certification express the initial and ongoing requirements for health IT developers and their certified Health IT Modules as part of the Health IT Certification Program. However, ONC is taking certification to a higher level beyond the technical and functional requirements to also include the conditions or requirements that health IT developers should also be held to, including:
- Information Blocking
Must not take any action that constitutes information blocking. - Assurances
Must make certain assurances to not take any action that may inhibit the appropriate exchange, access and use of electronic health information as well as assurances regarding retaining records that demonstrate initial and ongoing compliance with the requirements of the Certification Program. - Communications
Expressed colloquially as “gag clauses,” a developer must not prohibit or restrict communications regarding the usability, interoperability, or security of its health IT, including relevant information regarding users' experiences when using its health IT or the manner in which a user of the health IT has used such technology. - APIs
An API Technology Supplier must publish APIs and must 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. In addition, any and all fees charged by an API Technology Supplier for the use of its API technology must be described in detailed, plain language. - Real World Testing of Certified Health IT
A health IT developer with Health IT Modules to be certified to any one or more 2015 Edition certification criteria must successfully test the real world use of those Health IT Modules for interoperability in the type of setting in which such Health IT Modules would be/are marketed. A developer must submit an annual real world testing plan no later than December 15 of each calendar year. - Attestations
A health IT developer must provide an attestation of compliance with the Conditions and Maintenance of Certification requirements, including specifically attesting to not taking any action that constitutes information blocking or any of the other previously discussed requirements.
ONC is also planning to implement an additional future condition and maintenance of certification requirement that is focused on an electronic health record (EHR) reporting criteria submission. In the fall of 2018, ONC released a Request for Information for the EHR Reporting Program, and is waiting to take further regulatory action until it evaluates all the public comments that it received.
United States Core Data for Interoperability is Adopted as a Standard
In order to advance interoperability by ensuring compliance with new structured data and code sets that support the data, ONC is proposing to remove the Common Clinical Data Set (CCDS) definition and its references from the 2015 Edition and replacing it with the United States Core Data for Interoperability (USCDI) standard. USCDI v1 establishes a minimum set of data classes (including structured data) that are required for health IT to be interoperable nationwide and is designed to be expanded in an iterative and predictable way over time. USCDI v1 adds two new data classes, Clinical Notes and Provenance that were not defined in CCDS, which will require updates to the Consolidated Clinical Document Architecture (C-CDA) standard.
Overall, USCDI v1 is a modest expansion of CCDS, which ONC believes most health IT developers already support, were already working toward, or should be capable of updating their health IT to support in a timely manner.
Removal of the ONC-Approved Accreditor from the ONC Health IT Certification Program
The ONC-Approved Accreditor’s (ONC-AA’s) role is to accredit certification bodies for the Program and to oversee the ONC-Authorized Certification Bodies (ONC-ACBs). ONC is proposing to remove the ONC-AA from the Program. Years of experience and changes with the Program have led ONC to conclude that, in many respects, the role of the ONC-AA to oversee ONC-ACBs is now duplicative of ONC’s oversight. More specifically, ONC’s experience with administering the Principles of Proper Conduct for ONC-ACBs as well as issuing necessary regulatory changes (e.g., ONC-ACB surveillance and reporting requirements in the 2015 Edition final rule) has demonstrated that ONC on its own has the capacity to provide the appropriate oversight of ONC-ACBs.
Definitions Matter
ONC is introducing several new terms in this proposed rule and it is critical that the community understands and conveys these labels appropriately. These terms include:
- API Technology Supplier refers to a health IT developer that creates the API technology that is presented for testing and certification to any of the certification criteria adopted or proposed for adoption.
- API Data Provider refers to the organization that deploys the API technology created by the API Technology Supplier and provides access via the API technology to data it produces and electronically manages. In some cases, the API Data Provider may contract with the API Technology Supplier to perform the API deployment service on its behalf. However, in such circumstances, the API Data Provider retains control of what and how information is disclosed and so for the purposes of this definition is considered to be the entity that deploys the API technology.
- API User refers to persons and entities that use or create software applications that interact with the APIs developed by the API Technology Supplier and deployed by the API Data Provider. An API User includes, but is not limited to, third-party software developers, developers of software applications used by API Data Providers, and patients and health care providers that use apps that connect to API technology on their behalf.
- Electronic Health Information (EHI) is defined as electronic protected health information that identifies the individual, or there is a reasonable basis to believe the information can be used to identify the individual and is transmitted by or maintained in electronic media, that relates to the past, present, or future health or condition of an individual.
ONC Proposes Seven Exceptions to the Information Blocking Definition
ONC identifies proposals for several reasonable and necessary activities as exceptions to the information blocking definition, each of which would be considered to not constitute information blocking. The exceptions would extend to certain activities that interfere with the access, exchange, or use of EHI but that may be reasonable and necessary if certain conditions are met. To qualify for any of these exceptions, ONC is proposing that an individual or entity would, for each relevant practice and at all relevant times, have to satisfy all of the applicable conditions of that specific exception.
In developing the proposed exceptions, ONC was guided by overarching policy considerations focused on ensuring that the exceptions would be limited to certain activities that clearly advance the aims of the information blocking provision, such as promoting public confidence in health IT infrastructure by supporting the privacy and security of EHI, protecting patient safety, and promoting competition and innovation in health IT and its use to provide health care services to consumers.
In addition, each exception is intended to address a significant risk that regulated individuals and entities (i.e., the actors defined in this part of the regulation, specifically health care providers, health IT developers of certified health IT, health information networks, and health information exchanges) will not engage in these reasonable and necessary activities because of potential uncertainty regarding whether they would be considered information blocking. Moreover, each exception is intended to be tailored, through appropriate conditions, so that it is limited to the reasonable and necessary activities that it is designed to exempt.
Of the seven proposed exceptions, the first three address activities that are reasonable and necessary to promote public confidence in the use of health IT and the exchange of EHI. These exceptions are intended to protect patient safety; promote the privacy of EHI; and promote the security of EHI. The next three exceptions address activities that are reasonable and necessary to promote competition and consumer welfare. These exceptions would allow for the recovery of costs reasonably incurred; excuse an actor from responding to requests that are infeasible; and permit the licensing of interoperability elements on reasonable and non-discriminatory terms. The final exception addresses activities that are reasonable and necessary to promote the performance of health IT. This proposed exception recognizes that actors may make health IT temporarily unavailable for maintenance or improvements that benefit the overall performance and usability of health IT.
The exceptions for reasonable and necessary activities that do not constitute information blocking include:
- Preventing Harm
The actor must have a reasonable belief that the practice of not sharing EHI will directly and substantially reduce the likelihood of harm to a patient or another person arising from corrupt or inaccurate data being recorded or incorporated in a patient’s EHR or misidentification of a patient or patient’s electronic health information. - Promoting the Privacy of Electronic Health Information
An actor may engage in practices that protect the privacy of EHI. To meet this standard, the actor must satisfy at least one of four discrete sub-exceptions that address scenarios that recognize existing privacy laws and privacy-protective practices: practices that satisfy preconditions prescribed by privacy laws; certain practices not regulated by the Health Insurance Portability and Accountability Act of 1996 (HIPAA) but which implement documented and transparent privacy policies; denial of access practices that are specifically permitted under HIPAA; or, practices that give effect to an individual's privacy preferences. - Promoting the Security of Electronic Health Information
The practice must be directly related to safeguarding the confidentiality, integrity, and availability of EHI. - Recovering Costs Reasonably Incurred
An actor may recover costs that it reasonably incurs, in providing access, exchange, or use of EHI. Fees must be: charged on the basis of objective and verifiable criteria uniformly applied to all similarly situated persons and requests; related to the costs of providing access, exchange, or use; and, reasonably allocated among all customers that use the product/service. Fees must not be based on anti-competitive or other impermissible criteria. - Responding to Requests that are Infeasible
An actor may decline to provide access, exchange, or use of EHI in a manner that is infeasible. Complying with the request must impose a substantial burden on the actor that is unreasonable under the circumstances (accounting for cost as well as available resources, etc.). The actor must respond in a timely manner to infeasible requests and work with requestors to provide a reasonable alternative means of accessing the EHI. - Licensing of Interoperability Elements on Reasonable and Non-discriminatory Terms
An actor that controls technologies or other interoperability elements that are necessary to enable access to EHI will not be information blocking so long as it licenses such elements on reasonable and non-discriminatory terms. Such a license can impose a reasonable royalty but must include appropriate rights so that the licensee can develop, market, and/or enable the use of interoperable products and services. - Maintaining and Improving Health IT Performance
An actor may make health IT under its control temporarily unavailable in order to perform maintenance or improvements to the health IT. In such instances, an actor must ensure that the health IT is unavailable for no longer than necessary to achieve the maintenance or improvements.
ONC Includes Significant Detail on the API Conditions and Maintenance of Certification Requirements and Applicable Fees
The proposed regulation states that an API Technology Supplier must publish APIs and 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, including providing access to all data elements of a patient’s electronic health record to the extent permissible under applicable privacy laws. ONC wants this process to be very transparent and is only permitting certain types of fees to apply here, where an API Technology Supplier must have objective and verifiable criteria and keep detailed records of fees.
Ultimately, ONC wants to ensure that all terms and conditions for a Technology Supplier’s API technology, including any fees, restrictions, limitations, obligations, registration process requirements, or other similar requirements is published in a public manner and are uniformly applied for all substantially similar or similarly situated classes of persons and requests.
Any and all fees charged by an API Technology Supplier for the use of its API technology must be described in detailed as well as plain language. The description of the fees must include all material information, including but not limited to: the persons or classes of persons to whom the fee applies; the circumstances in which the fee applies; and, the amount of the fee, which for variable fees must include the specific variable(s) and methodology(ies) that will be used to calculate the fee.
Several Requests for Information are Embedded in the ONC Regulation
ONC is asking for comments around several additional issues in this proposed regulation, and each provides an opportunity to help guide the agency forward on crucial policy topics. ONC is seeking comment in this proposed rule on a series of questions related to health IT functionalities and standards to support the effective prevention and treatment of opioid use disorder (OUD) across patient populations and care settings.
The proposed rule also raises the idea of whether ONC should consider whether certain health IT developers should be required to participate in the Trusted Exchange Framework and adhere to the Common Agreement that the agency is still working to finalize. Such an exception may support adoption of the Common Agreement and encourage other entities to participate in trusted exchange through health information networks that enter into the Common Agreement. It could potentially provide protection if there are practices that are expressly required by the Common Agreement, or that are necessary to implement such requirements, that might implicate the information blocking provision and would not qualify for another exception.
An additional RFI is focused on whether ONC should establish new regulatory processes tailored towards recognizing the unique characteristics of health IT (e.g., EHR software) by looking first at the health IT developer, rather than primarily at the health IT presented for certification, as is currently done under the Program. Such an effort could be modeled after the Food and Drug Administration Digital Health Software Pre-Certification Program. For example, ONC could possibly establish Conditions and Maintenance of Certification requirements, through rulemaking, that facilitate the deeming of all of a health IT developer’s health IT as “certified” under the Program for certification criteria identified by ONC as solely “functionally-based” criteria.
The idea of disincentives for health care providers is the subject of another RFI. Any health care provider determined by the Office of Inspector General (OIG) to have committed information blocking shall be referred to the appropriate agency to be subject to appropriate disincentives using authorities under applicable federal law, although these disincentives may not cover the full range of applicable conduct. ONC is requesting information on disincentives or if modifying disincentives already available under existing HHS programs and regulations would provide for more effective deterrents.
ONC is also exploring multiple approaches to advancing health IT interoperability for bidirectional exchange with registries in order to mitigate risks based on factors like feasibility and readiness, potential unintended burden on health care providers, and the need to focus on priority clinical use cases. As ONC is in the process of conducting research and analysis to determine what evidence-based use cases should be supported and what standards are available to support such use cases, comments on opportunities for bidirectional exchange with registries will be timely.
In addition, ONC is looking for comment on additional opportunities that may exist in the patient matching space and ways that the agency can lead and contribute to coordination efforts with respect to patient matching.
More information about the ONC Proposed Rule is available online. Look to HIMSS for further details about the regulatory process and how members can get involved in helping to devise our public comment response letter.