By DAVE LEVIN MD

The Office of the National Coordinator (ONC) and the Centers for Medicare and Medicaid (CMS) have proposed final rules on interoperability, data blocking and other activities as part of implementing the 21^st Century Cures Act. In this series, we will explore ideas behind the rules, why they are necessary and the expected impact. Given that these are complex and controversial topics open to interpretation, we invite readers to respond with their own ideas, corrections and opinions.

____________

When it comes to sharing health data, the intent of the 21^st Century Cures Act is clear: patients and clinicians should have access to data without special effort or excessive cost. To make this a reality, the act addresses three major areas: technical architecture, data sets and behaviors. Part two of our series looked at how APIs address technical issues while part three covered the new data requirements. In this article, we delve into information blocking. A companion podcast interview with ONC expert Michael Lipinski provides an even deeper dive into this complex topic.

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 information will be shared though the Act does authorize the Secretary to identify reasonable and necessary exceptions.

The proposed rules focus on “technical requirements as well as the actions and practices of health IT developers in implementing the certified API.” 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 proposed 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 examples of the proposed 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 much easier for patients or an entire health system to change from one health IT application (typically an EHR) to another. This reduction in “switching costs” should reduce barriers to innovation and competition.

Meta-Information Blocking

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 proposed 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: When is Information Blocking not Information Blocking?

The expectation is that information will readily and easily flow but the rules also identify seven common sense exceptions – situations when this is not feasible or would be counter-productive. Three overarching policy considerations guided the development of these exceptions: they should advance the overall aims of the Act, reduce uncertainty about whether specific activities would constitute information blocking, and be tailored to limit their impact to reasonable and necessary activities.

These first three exceptions “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, “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 last 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.”

Enforcement

Having rules and clarity is of limited value without enforcement. There is ample evidence that achieving robust interoperability in health care won’t be completely voluntary. Getting organizations to pay attention to and follow the rules requires meaningful enforcement. ONC’s certification authority combined with CMS’s conditions of participation provides a powerful set of carrots and sticks. When it comes to information blocking by certified health IT developers, ONC may ban a health IT developer from the program or terminate the certification. 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. CMS proposes to require providers to attest to compliance and to publicly report organizations that are not in full compliance. CMS is considering additional enforcement mechanisms as well.

Summary

Information blocking–practices that interfere with the access, exchange, or use of electronic health information–comes in many forms that can be obvious or subtle. It can occur as a result of incompatible technology, limited data sets or stakeholder behaviors. ONC and CMS have crafted an interlocking set of requirements, definitions and enforcement mechanisms to address the root causes of information blocking. The expectation is that, with a few specific exceptions, information will flow in ways that enhance patient care and promote competition and innovation. The hope is that this will result in better care at lower cost, delivered in ways that are more pleasing to patients and providers alike.

Dave Levin, MD is co-founder and Chief Medical Officer for Sansoro Health where he focuses on bringing true interoperability to health care. Dave is a nationally recognized speaker, author and the former CMIO for the Cleveland Clinic.