The Office of the National Coordinator (ONC) and the Centers for Medicare and Medicaid (CMS) have released final rules on interoperability, information blocking, and other activities as part of implementing the 21st Century Cures Act. In part one of this series, we explored the rules on interoperability, why they are necessary, and the expected impact. In this post, we delve into the provisions that address information blocking. Future posts will look at the rules related to innovation and payers. A handy summary of the changes between the proposed and final rules can be found here.
Given that the final rules are complex and controversial topics open to interpretation, we invite readers to respond with their own ideas, corrections, and opinions.
Interoperability – the ability of applications to freely connect, exchange, and collaborate health data within the health IT ecosystem– is a key driver of the pace and breadth of innovation. Free flowing, rich clinical data sets are essential to building powerful, user-friendly applications. Making it easy to install or switch applications reduces the cost of deployment and fosters healthy competition. Conversely, when data exchange is restricted (info blocking) or integration is difficult, innovation is stifled.
The 21st Century Cures Act passed by Congress in 2016 contains specific provisions designed to, “advance interoperability and support the access, exchange, and use of electronic health information; and address occurrences of information blocking.” After more than a year of collecting feedback, the final rules to implement some of these provisions were released in March 2020.
Part one of the series looked at the overall impact of the final rules and the intent of provisions related to technical aspects such as interoperability technology and the required data sets. The rules wisely recognize that the flow of information is limited by both technical barriers and behaviors. The technical provisions address the former while those regarding information blocking are designed to impact the latter.
Information Blocking Comes in Many Forms
The Public Health Services Act (PHSA) broadly defines information blocking as a practice that is “likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information.” The overarching assumption is that information will be shared, though the Act does authorize the Secretary of Health and Human Services to identify reasonable and necessary exceptions.
Information blocking can come in a variety of forms. It can be direct and obvious (“No you can’t have this data ever!”) or indirect and subtle (“Sure, you can have the data, but it will cost you $$$ and we won’t be able to get to your request for at least 12 months”). The rules are designed to address both. This passage illustrates some of the concerns:
Health IT developers are in a unique position to block the export and portability of data for use in competing systems or applications, or to charge rents for access to the basic technical information needed to facilitate the conversion or migration of data for these purposes.
It’s worth looking at example remedies. Here is an example that addresses anti-competitive behavior:
Developers of health IT certified to this criterion would be required to provide the assurances proposed in § 170.402, which include providing reasonable cooperation and assistance to other persons (including customers, users and third-party developers) to enable the use of interoperable products and services.
Another example is the Electronic Health Information (EHI) Export requirements intended to:
…provide patients and health IT users, including providers, a means to efficiently export the entire electronic health record for a single patient or all patients in a computable, electronic format.
These remedies provide an “exit ramp” designed to make it easier for patients or an entire health system to change from one health IT application (typically an EHR) to another. This reduction in application switching costs should reduce barriers to innovation and competition.
While we tend to think of information blocking as solely affecting the exchange of data, open discussion and sharing of information about performance is a cornerstone of performance improvement and safety. Contractual “gag” clauses, IP concerns, and other legal issues have led to meta-information blocking by limiting information exchange about system performance. As the rules note, “These practices result in a lack of transparency around health IT that can contribute to and exacerbate patient safety risks, system security vulnerabilities, and product performance issues.”
These concerns are addressed directly by the Cures Act requirements, stating that:
…a health IT developer, as a Condition and Maintenance of Certification under the Program, does not prohibit or restrict communication regarding the following subjects:
- The usability of the health information technology
- The interoperability of the health information technology
- The security of the health information technology
- Relevant information regarding users’ experiences when using the health information technology
- The business practices of developers of health information technology related to exchanging electronic health information and
- The manner in which a user of the health information technology has used such technology.
Exceptions to Information Blocking
The expectation with respect to information blocking is that information will readily and easily flow but the rules also identify eight common sense exceptions – situations when this is not feasible or would be counter-productive. Three overarching policy considerations guided the development of these exceptions. Stating that it should:
- advance the overall aims of the Act
- reduce uncertainty about whether specific activities would constitute information blocking, and
- be tailored to limit impact to reasonable and necessary activities.
Five exceptions involve not fulfilling requests to access, exchange, or use EHI. These exceptions are intended to prevent harm and protect patient safety, promote the privacy and security of EHI, excuse an actor from responding to requests that are infeasible, and address activities that are reasonable and necessary to promote the performance of health IT.
Three additional exceptions involve procedures for fulfilling requests to access, exchange, or use EHI. These exceptions are:
- when an actor’s practice of limiting the content of its response or the way it responds to a request to access, exchange, or uses EHI.
- when an actor’s practice of charging fees, including fees that result in a reasonable profit margin, for accessing, exchanging, or using EHI.
- and when an actor’s practice to license interoperability elements for EHI to be accessed, exchanged.
There is ample evidence that achieving robust interoperability in health care won’t be completely voluntary. Getting organizations to follow the rules requires meaningful enforcement. ONC’s certification authority combined with CMS’s conditions of participation provides powerful incentives. If information blocking occurs, ONC may ban a health IT developer from the certification program or terminate their certification. While the law also authorizes the Inspector General of the Department of Health and Human Services (DHS) to investigate any claim and impose fines of up to $1,000,000 per occurrence, compliance is not required until at least six months after publication of the final rules. Dates for enforcement have yet to be determined by ONC and OIG (Office of Inspector General). CMS plans require providers to attest to compliance and publicly report organizations that are not in full compliance.
In part three of the series, we will dive deeper into final rules intended to promote competition as a means to drive innovation.