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 our previous blog series, we explored the ideas behind the rules, why they are necessary, and the expected impact. In this installment, we analyze the final rules affecting interoperability. Future posts will look at rules related to data blocking, innovation, and payers. A handy summary of the changes between the proposed and final rules can be found here.
Given that the rules are complex and controversial topics open to interpretation, we invite readers to respond with their own ideas, corrections, and opinions.
Digitalization of health care continues as innovators build on the foundation now in place by providing better, more diverse applications. Health care is starting to leverage existing monolithic applications like electronic health records (EHRs) to create platforms that support a robust application ecosystem. Think the App Store for healthcare and you can see where we are headed.
This is why interoperability and data blocking are two of the biggest issues in health IT today. 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 (data blocking) or integration is difficult, innovation is stifled.
Given the importance of health IT in enabling the larger transformation of our health system, the stakes are profoundly high. Congress recognized this when it passed the 21st Century Cures Act in 2016. Title IV of the Act contains specific provisions designed to, "advance interoperability and support the access, exchange, and use of electronic health information; and address occurrences of information blocking." In February 2019, ONC and CMS simultaneously published proposed rules to implement the provisions. After more than a year of collecting feedback the final rules were released in March 2020.
Competition is a key theme of the ONC and CMS final rules. They are designed to create a level playing field and foster market-driven innovation. The coordinated effort between CMS and ONC makes the most of their respective regulatory powers. ONC is defining how health IT companies, providers, and others should behave (certification and use of health IT), and CMS is tying compliance with those behaviors to payment for services. This is a powerful set of carrots and sticks that have proven effective in the past.
Broadly, the final rules address:
- Interoperability Technology. Application programming interfaces (APIs) have transformed other industries in the digital economy. The rules mandate the certification, adoption, and use of APIs as the next generation of interoperability infrastructure and a role for standards like FHIR (Fast Healthcare Interoperability Resources).
- Business Models and Intellectual Property. Select business practices inhibit competition and innovation. The rules seek to balance the need for competition with protection of legitimate intellectual property rights and reasonable profit.
- Data. A core data set for interoperability with specific data elements required.
- Health Insurance Data. There are significant requirements for health insurance providers.
- Data Blocking. The rules define and address data blocking and require "exit ramps" for patients and providers who want to switch from one application to another and/or take their data with them.
- Safety. They promote patient safety through the development of safer health IT applications and practices and by promoting transparency.
- Security and Privacy. The new rules impact patient privacy and the security of health data.
The free flow of data and the ability for applications to connect and exchange “without special effort” are central to and supported by a combination of rules that address both technical requirements and expected behaviors.
You Can't Tell the API Players Without this Score Card
- Certified API Developer: Health IT developer that creates certified API technology (ex: EHR vendor)
- API Information Source: Organization that deploys certified API technology (ex: Hospital using an EHR)
- API user: Persons and entities that use or create software applications that interact with certified API technology (ex: mobile app developer integrating with EHR)
Compatible "Plugs and Sockets"
The rules explicitly mandate the adoption and use of API technology (or a successor). APIs have achieved powerful, scalable, and efficient interoperability across much of the digital economy by providing compatible "plugs and sockets" that make it easy for different applications to connect, exchange, and collaborate data. APIs are an essential foundation for building the next generation of health IT applications.
APIs are powerful but their flexibility can also lead to wide variations in how they work. Therefore, ONC is requiring 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). The final rule specifically requires the use of FHIR release 4. 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 (i.e. hospitals and health IT developers), have consistency when integrating applications.
Data for Interoperability
Using APIs to "plug-in" is of little value if the data needed is not available. That's why ONC also requires the "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.
U.S. Core Data for Interoperability (USCDI)
The bulk of the datasets in the USCDI comes from the Common Clinical Data Set (CCDS), which was last updated in 2015. The newest USCDI adds clinical notes and provenance (metadata, or information about the data that shows who created it and when).
FHIR created standards around the APIs used to access health care data. APIs developed under the FHIR standard aligns with the USCDI to meet the certification rules.
Exhibit 1: USCDI API Endpoints
More Steps in the Right Direction
The USCDI has expanded upon the CCDS, which is a much-needed next step forward for data sharing. It also outlines an expansion process to include more data over time. In the expansion process, data is classified as USCDI based on agreement among stakeholders. The process moves the data from emerging, to candidate, to USCDI status. With the expansion plan in place for more data to be made available, there is hope that non-clinical data will eventually be shared as well.
Interoperability for Innovation
Congress and ONC wisely recognized that interoperability can be limited 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 counterproductive. In response, ONC and CMS crafted interlocking rules to promote a level playing field and regulate stakeholder behaviors believed to inhibit the free flow of data, innovation, and competition.
While much of this is addressed in the rules on information blocking, ONC also has rules on the access and use of API technology. The "API Conditions of Certification" address transparency, permitted fees, openness, and pro-competitive conditions. For example, API technology suppliers must treat all API consumers ( i.e. 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 and a reasonable profit margin.
Our next post in this series will dive deeper into the final rules on Information Blocking and explore how these provisions are intended to impact both technology and behavior.