What you need to know about the new ONC and CMS healthcare interoperability and information blocking rules

Hotly debated rulemaking from ONC has officially been finalized. 

For those of you new to healthcare regulations, the ONC (Office of the National Coordinator) is responsible for creating policy that governs national health IT adoption and interoperability. 

Their latest rulemaking efforts are part of the 21st Century Cures Act, an enormous piece of legislation passed in 2016. 

At their core, the latest rules aim to enable people to use applications to retrieve their health records directly from their medical providers and put the patient at the center of the interoperability solution.

In doing so, the latest rules make sweeping changes to the way that EHR vendors, payers, providers, and interoperability networks do business. 

In this post, we go into detail about what the new rules actually do. 

United States Core Data for Interoperability (USCDI) selected as the national standard for health data that needs to be exposed via APIs.

A mental model I use for USCDI is “what data would be necessary to exchange information with a new doctor?”. 

USCDI outlines the specific pieces of information that must be included. Real-world things like patient name, current address, allergies, care team members, laboratory tests/ results, etc. View the full set of data classes and constituent elements here. 

By selecting USCDI as its own national standard, it de-couples USCDI from a given implementation standard like FHIR and allows the two to move independently. USCDI will continue to define what information an EHR must share while FHIR will continue to define how the data should be structured and made available. 

A notable inclusion in the final standard for USCDI is “Provenance” - in other words, the metadata associated with the who, when, and where a given data point was created. 

The overall impact of adopting USCDI doesn’t change much. Project Argonaut adopters have essentially already had APIs for this data set for five years. The bigger story here is the adoption of a national standard. USCDI is meant to evolve over time, and as it does the EHR vendors will have 24 months to expose new data. 

Requirements for Certified EHR Technology (CEHRT) have become more strict.

The CEHRT program was developed for Meaningful Use as a way for providers to show that they were using EHR technology that met certain minimum requirements. Ten years after the creation of the program, EHR vendors are being asked to raise the minimum bar for what functionality their software must provide. 

A few of the notable line item changes are as follows:

1. APIs for patients that conform to FHIR R4 and SMART on FHIR

2. U.S. Core Data for Interoperability (USCDI) is adopted as a set of data that EHRs need to make available via the aforementioned APIs 

3. A new requirement to export all Electronic Health Information (EHI) for both a patient and for providers to change systems. 

4. A new requirement for Bulk Data export is also included in the CEHRT program

In addition to new requirements, A new framework called “Conditions of Certification” is imposed that allows certification to be revoked for bad behavior. Such behavior includes:

• “Gag clauses” around sharing screenshots

• Inability to demonstrate real-world interoperability

• Practicing “information blocking” (see below) 

Penalties for not meeting these conditions of certification include probation/suspension of certification in addition to data blocking fines. If an EHR vendor were to lose certification, providers and hospitals using that software could be hit with penalties under Meaningful Use. Essentially, an already arduous set of requirements gets more arduous and the hard-won certification can now be terminated more readily. 

One of the more hotly contested issues in the proposed rules was around how applications can use patient-authorized data exchange. Epic specifically fought hard to the last minute for more protections for patient privacy. Much of the specific language around access for developers has not changed. An information blocking exception was added allowing EHR vendors to prompt more warnings to patients to address privacy concerns, but applications can still expect a 10 business day approval process and a 5 business day activation period. 

“Information Blocking” (and approved exceptions) is officially defined.

Information blocking is more than just a nebulous condition of certification, it’s now a well-defined practice with penalties and exceptions. When 21st Century Cures was signed into law in 2016 many around the healthcare IT industry pondered, memed, and otherwise dreaded what “information blocking” would actually mean in practice.

Information blocking was officially defined by congress in the 21st Century Cures Act, and they delegated outlining things that don’t constitute data blocking to the ONC. There are now 8 exceptions as follows: 

1. Preventing Harm - you can block information if you have reason to believe sharing information will cause harm. 

2. Privacy - HIPAA is still the law of the land

3. Security - If you have an organizational security policy that impedes access to data that might be OK

4. Infeasibility - some protections for edge cases where it’s virtually impossible to retrieve data

5. Performance - If an app is hammering the database otherwise disrupting others it’s ok to deny them access, it’s also ok to take scheduled downtimes. 

6. Content and Manner (new) 

   1. Content: USCDI for 24 months, then anything after that

   2. Manner: You can fulfill requests in the manner different from what was requested provided proper documentation

7. Fees - You can charge reasonable fees with the expectation that you can make a profit as long as it’s transparent and applied consistently across the board

8. Licensing - An API provider can require licensing of API elements provided it is done in a reasonable and non-discriminatory way. 

The most notable change here from the proposed rules is the Content exception. Many commenters expressed concern that any and all information would have to be made available to authorized parties under information blocking. What the rules say is that for the next 24 months, information blocking is limited in scope to USCDI data, but after that, it’s any information that relates to the individual. This will be an interesting part of the rule to watch unfold. 

CMS rules that Claims data needs to be exposed via FHIR and pushes for improved payer-to-payer information sharing.

CMS also released new rules pertaining to patient access of their Claims data, payer to payer sharing of data, and payer to network sharing of information. CMS is able to use federally-funded insurance plans as a lever for this kind of work. These types of plans must meet the requirements in the new rules, but we may see payers extend functionality to all members regardless of whether or not they actually have a federally-sponsored plan: 

• MA Plan– MA stands for Medicare Advantage. Essentially, instead of the government paying for your services, they pay the plan to pay for you. An example is Kaiser Permanente, their profit goes up if you stay healthy and use fewer services.

• Medicaid Managed Care– Similar to the MA plans above, managed care plans pay a set fee to an organization to provide all the care a patient needs. Medicaid targets a different population. Here is a great overview.

• CHIP Managed Care Entities– CHIP stands for Children’s health insurance program. Again, the rule covers managed care providers, much like above. There are differences in how states administer Medicaid and CHIP so they are functionally separate.

• QHPs in the FFEs– Remember healthcare.gov? It still exists and is what is called a federally-facilitated exchange. QHPs are “qualified health plans”, essentially it means that you’re allowed to list on healthcare.gov. Here’s an overview of the states that apply and don’t apply.  

• SADP– Stand-alone dental plans, these are special.

The first big piece of the CMS rule is the patient-authorized exchange of data. Like the ONC rules, patient access to data through APIs is at the core of the new rules. Specifically, claims data needs to be exposed via FHIR. January 1, 2021 is the deadline given to implement the APIs. 

Next, these plans need to participate in payer to payer exchange using Claims and USCDI. The idea here is that if a patient switches health plans, they should be able to move data between the payers to better support care. If you had an MRI in December, and switch to a new plan during open enrollment, your new plan should know about that MRI and ideally know how to access it so you don’t get another one. January 1, 2022 is the date given to start participating in this kind of exchange. 

The final rule notably removes a proposed requirement for payers to participate in trust networks like those expected to bloom in the wake of TEFCA. The rule doesn’t prevent payers from participating, and they may well do so for their own benefit. Most of the comments were around the relative immaturity of TEFCA, as well as the aggressive timelines proposed, so we may well see this effort be picked up again in the coming years. 

Provider directories are another area of the CMS rules that don’t bring a lot of controversy. Essentially the plans covered in the rules need to expose their providers via an API, specifically FHIR in this case. This is a very clear cut scenario where standardization is/was needed and where can expect tools to be built that more effectively help consumers shop for plans. 

Public shaming of providers without digital contact information - CMS will report providers who don’t update their NPPES database listing with digital contact information like a Direct address and FHIR server. 

Finally, the rules for electronic notifications made it through. The idea is that sending notifications when patients are seen across different care settings can lead to better coordination. There are two notable takeaways from this rule: 

1. It uses the conditions of participation as the lever for the rules. While the conditions of participation have historically been used for quality programs, it may be an exciting new way to directly impact healthcare IT usage.

2. It uses HL7v2 - specifically ADT. In all the headlines about FHIR R4 being the law of the land, it’s important not to forget that trusty v2 remains the most widely deployed interoperability standard. 

The facilities affected by these updates have 6 months to comply. 

One small step or one giant leap for healthcare interoperability?

If you’ve been keeping up with the proposed rules, nothing here should come as a surprise. That being said, this is a big day for healthcare. These rules make official tangible things that will fundamentally change the way that EHR vendors, payers, providers, and interoperability networks do business. These rules open the door for a new world of patient-authorized interoperability and make a great deal of progress defining exactly what pieces of information must be made available. They push for more transparency among payers and introduce mechanisms for punishing bad actors. 

We believe that, as a whole, these rules are the result of a process that took the time to uncover the primary blockers of effective health information exchange. The solutions proposed are the result of extensive conversations with thought leaders and subject matter experts. While not perfect they push us forward and continue the evolution of our industry. We commend everyone who contributed to this process and look forward to helping organizations make use of this new reality. 

***