EHI export for certified health modules: (b)(10) deadline is on the horizon  

No sooner has (g)(10) been put to bed, than there’s another mandatory Final Rule criterion to worry about: in this case the ONC requirement to export all Electronic Health Information (EHI), for individuals or entire groups of patients.  

But once again, Firely has already done the heavy lifting, positioning our software to reduce the burden on your resources and smooth the path toward the next step in ONC Cures Act, Final Rule compliance.  

What’s on the §170.315(b)(10) agenda? 

Under ONC Cures Act, Final Rule criterion §170.315(b)(10), certified health IT modules must be able to electronically export all the EHI stored by the module itself, or by non-certified capabilities of the same health IT product. These new export capabilities must be ready on or before December 31, 2023.   

While no standard format is specified, export files must be electronic and in a computable format that’s accessible via a public hyperlink, so that authorized users can obtain the information without further conditions or extra steps. So far so simple. Now let’s take a look at the details. 

Electronic protected health information (ePHI)

EHI in this context is the same ePHI that patients have the right to request under the HIPAA Privacy Rule: information that relates to someone’s health conditions, or to providing or paying for their health care. Certified electronic health record technology (CEHRT) or modules must be able to export this data for two stated purposes: 

1. The timely availability of the full set of EHI for a single patient: on demand and without the need for developer assistance. This can be for an individual, a specific set of users, or a system administrative function. 
2. Exporting patient population EHI so that patients can be switched to another EHR or between health IT systems.

Didn’t we cover this already?

§170.315(b)(6) Data Export mandated for Certified EHR Technology (CEHRT) to be capable of exporting continuity of care documents (CCDs) so that users can access the data at any time, without the help of a developer.  

§170.315(b)(10) takes this one step further, replacing proctor testing with self-declaration, and expanding on the previous standards-based (CCDA) regime so that virtually all EHI becomes eligible for export. Images, imaging information, and image elements can be exported as files or links, depending on what the product stores. Psychotherapy notes and information intended for legal proceedings remain mostly excluded. 

Anything else to consider?

Exporting data and making it more accessible to users doesn’t alter any of your data protection responsibilities. You still need to safeguard the security and privacy of individuals’ EHI according to relevant laws and regulations: but Firely Server has SMART on FHIR built-in, so it comes with all the protections you need.  

How urgent is the (b)(10) deadline? 

If your certified EHR technology (CEHRT) currently stores EHI, you must have a process for the two export scenarios in place by the end of this year: but to create documentation for a proprietary format would be a huge task in itself. As the interoperability and EHI storage standard in the US, FHIR already satisfies the ONC Cures Act, Final Rule requirement for a publicly-available schema, with a well-documented format that’s ready to use.

How can Firely help? 

Firely Server gives you all the capabilities you need to link, consume, and export the EHI data required for (b)(10) without expending time and effort on technical and functional software requirements. It provides the API for receiving and executing the (b)(10) request, so you can focus on mapping and linking EHR data to FHIR right off the bat. Unstructured data can be exported inside a FHIR resource “wrapper”, as long as the schema is defined at the same time. 

Our solution is designed as a plug-and-play component that re-uses our tried-and-tested technologies – such as SMART on FHIR – to provide a UI for practitioners and patients to define information requests and trigger data exports. It can be deployed within the EHR ecosystem without creating dependencies and compensates for the absence of a required standard via the bulk data export features we developed for the (g)(10) criterion.  

Take the next step

§ 170.315(b)(10) might not look demanding at first glance, but (g)(10) taught us how easily new criteria can throw up unforeseen issues, drain developer resources, and catch everyone unawares. Start investigating your options now to fully understand how (b)(10) will affect your product and your business, create a strong foundation for future implementations, and get the support you need when you need it. 

The best plans are the earliest plans, so get in touch with us today!