Remember these key dates for info sharing compliance.
The 21st Century Cures Act is gradually making patient data more accessible. Healthcare providers, health information exchanges and many developers of health IT are subject to Cures Act information sharing rules.
Simply put, this law requires medical information to be shared in an easy and standardized way. Since it’s a law - not just a policy - health data interoperability is written on our calendars in permanent ink.
Healthcare requires carefully thought-out plans, so the Cures Act is moving slowly. Major parts of the Cures Act began taking effect in 2021, and we’re watching closely as the rules continue to phase in. If you’d like to get up to speed as well, start by taking a look at this key date cheatsheet!
The aim of the Cures Act is summed up in one of its subtitles, “Empowering Patients and Improving Patient Access to Their Electronic Health Information” (Section 4006). When Congress passes a law with plain English in it, you know it’s important!
Among other things, the Cures Act championed the bipartisan patient access philosophy. Patient access encompasses information sharing and pushes all players in the healthcare ecosystem to share health data.
The Cures Act Final Rule, which sets out how providers will implement the Cures Act, is published. Some people call this the Information Sharing Rule, or (incorrectly) the Open Notes Rule. Due to COVID-19 disruption, over a year of delays pass by before the Final Rule takes effect.
The Cures Act Final Rule, and some of its major conditions, take effect. From now on, your basic electronic health information must be accessible on request. For example:
1. Major categories of electronic health information must be made available.
2. Anti-information blocking provisions are now binding.
3. Condition of Certification (CoC) compliance requirements begin.
4. Health IT developers now prohibited from restricting certain communications.
Some parts of the rule are still rolling out (more on that below).
By December 2021, it’s time for developers to show the world how far they’ve come on interoperability.
Before this date, “developers of certified health IT” need to submit real world testing plans to the Certified Health IT Product List. This requires a plan certified by ONC-ACBs (Authorized Certification Bodies).
Depending on the ACB, a plan may be needed as early as August 31! This is enforced by the ONC Health IT Certification Program.
ONC releases the final Trusted Exchange Framework and Common Agreement (TEFCA), a non-binding policy framework that standardizes the process for Health Information Networks to share data. TEFCA will also make it easier for other networks to connect with each other by transforming into a new type of entity, Qualified Health Information Networks (QHINs). Cures Act Section 4003 directed ONC to oversee this public-private partnership.
If you’ve started complying with information sharing rules, now is the time to prove it.
There’s more work to be done for development teams that want to meet the important Conditions and Maintenance of Health Certification for Health IT.
To be a part of Cures Act-compliant networks, developers must submit an attestation to their ONC-ACB that conditions like API availability and info blocking best practices are followed.
If the CoC seems new, that's because it's also a part of the Cures Act (Section 4002). Developers must check in with ONC every six months to recertify their software.
After this date, any electronic health information on a patient must be made shareable - not just USCDI v1 elements.
This expansive rule includes billing records and claims information.
The Cures Act’s eight sharing exceptions for privacy and security will remain in place.
If you thought FHIR was for someone else to figure out, think again. The Conditions of Certification will require FHIR compliance in health apps from this day forth.
Per the final rule, services must “respond to requests for a single patient’s data, including the mandatory capabilities described in ‘US Core Server CapabilityStatement’”.
According to ONC, this delayed timeline strikes a balance between incentivizing developers and promoting the public good of interoperability. In the final rule, ONC was concerned that “If ONC does not grant an appropriate extension for developers to comply with the 2015 Edition Cures Update, some health IT developers may decide not to seek re-certification ... if they determine they do not have the resources required to meet tight deadlines.”
It actually takes over a year before last year’s results are made publicly available.
Ever ported your phone number from one carrier to another? EHI export capability means that the health data ecosystem will support that equivalent for your personal health data. If you’re a healthcare provider, the same goes for your EHR.
ONC certification will require two comprehensive export features from this date on. What’s really interesting is how the final rule requires two types of exports.
The first type of export is simple - “timely [creation of] export file(s) with all of a single patient’s electronic health information ... a user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate.”
The second type of export - and this is where we really unlock insights - is the ability to do a bulk EHI record export. This enables patient population insights, or easier EHR switching.
Broadly speaking, information blocking refers to the widespread if unintentional practice of not allowing patient data exports (in industry lingo, these are negatively referred to as “data silos”). The Cures Act seeks to end info blocking for good.
Particle Health’s partners are ahead of schedule when it comes to health data interoperability. When the Cures Act was passed in 2016, it didn’t immediately ban info blocking. Instead, it directed the Department of Health and Human Services to create rules that would stop info blocking. Organizations like Particle Health started building the infrastructure to make data sharing possible.
In a few years, all potential “information blocking actors” will have to proactively comply with FHIR data exports, the most modern interoperability standard. They’ll also have to export EHI, including billing data, with few exceptions.
But as of writing, actors simply must not take any action that constitutes information blocking; must share information that is included in the USCDI standard; and must share it in the manner initially requested, if possible.
What makes this complicated? Undefined gaps between the date of the law and the enforcement date are confusing. Vague definitions of info blocking during the transition period are a hassle (you can’t block an API, but your API doesn’t have to be operational). A lack of end user tools is another problem that’s changing fast.
There are good reasons for this gradual approach, but it can be confusing in the meantime. Particle’s recommendation is to reach full info sharing compliance as soon as possible. Try our free developer portal or reach out to us for help!