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 21st Century Cures Act. In this series, we will explore the 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. You can find Part 1 of the series here.
____________
In 2016, Congress enacted the 21st Century Cures Act with specific goals to “advance interoperability and support the access, exchange and use of electronic health information.” The purpose was to spur innovation and competition in health IT while ensuring patients and providers have ready access to the information and applications they need.
The free flow of data and the ability for applications to connect and exchange it “without special effort” are central to and supported by a combination of rules proposed by ONC and CMS. These rules address both technical requirements and expected behaviors. In this article, we look at specific technical and behavioral requirements for interoperability. Future articles will examine data blocking and other behavioral issues.
Compatible “Plugs and Sockets”
The proposed rules explicitly mandate the adoption and use of application programming interface (API) technology (or a successor) for a simple reason: APIs have achieved powerful, scalable and efficient interoperability across much of the digital economy. Put simply, APIs provide compatible “plugs and sockets” that make it easy for different applications to connect, exchange data and collaborate. They are an essential foundation for building the next generation of health IT applications. (Note: readers who want to go deeper into APIs can do so at the API Learning Center).
APIs are versatile and flexible. This makes them powerful but can also lead to wide variations in how they work. Therefore, ONC is proposing that certified health IT applications use a specific API based on the Fast Healthcare Interoperability Resources (FHIR) specification. FHIR is a consensus standard developed and maintained by the standards development organization (SDO) Health Level–7 (HL7). Mandating the use of the FHIR standard API helps to ensure a foundational compatibility and basic interoperability. This gives API technology suppliers (like EHR vendors) a clear set of standards to follow in order to fulfill the API requirement. It also ensures “consumers” of that API (like hospitals and health IT developers), have consistency when integrating applications.
Data for Interoperability
Using APIs to connect applications removes many hurdles to achieving interoperability by making it easy to connect applications. But “plugging in” is of little value if the data needed is not available. That’s why ONC has also proposed, “Adoption of the United States Core Data for Interoperability (USCDI) as a standard [that] would establish a set of data classes and constituent data elements that would be required to be exchanged in support of interoperability nationwide.”
The mandated combination of FHIR APIs and USCDI provides a solid technical underpinning for the next generation of interoperability by efficiently supporting the exchange of a standard data set. This will be a huge improvement over the hodge-podge of current legacy integration technology which is expensive, brittle, difficult to scale and suffers from a lack of enforced standards.
Interoperability for Innovation
Congress and ONC wisely recognized that today’s challenges with interoperability are due to a combination of technical barriers and behaviors. Adoption of APIs and standards, like FHIR and USCDI, solve many technical challenges but do not address behaviors which may be counter-productive. In response, ONC and CMS have crafted interlocking rules to promote a level playing field and regulate stakeholder behaviors believed to inhibit the free flow of data, innovation and competition.
Much of this is addressed in the proposed rules on information blocking, a subject we will explore in a future article. But, ONC also proposes rules related to the access and use of API technology. These API Conditions of Certification address transparency, permitted fees, and openness and pro-competitive conditions. For example, API technology suppliers must treat all API “consumers” (like hospitals and health IT developers) the same. They can’t limit access or charge differently for competitors. Documentation must be readily available, and fees must be published and based on recovery of reasonable costs.
These particular rules are intended to keep API tech suppliers from abusing market power by monetizing access to data or limiting the entry of competing products. And they come with enforcement “teeth.” Failure to comply may lead ONC to “ban a health IT developer from the program or terminate the certification of one or more of its health IT modules.” Suspected information blocking violations may be referred to the Office of the Inspector General and can result in hefty fines.
The adoption of a FHIR standard API that delivers the USCDI provides a powerful, technical solution. The proposed ONC rules build on this by encouraging behaviors that promote competition on a level playing field. This powerful combination of technical and behavioral requirements will play a key role in advancing interoperability in health care for the benefit of patients and care-givers 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.
from The Health Care Blog https://thehealthcareblog.com/blog/2019/03/15/onc-cms-proposed-rules-part-2-interoperability/