Get Ready for Cures Act With Azure API For FHIR®

In our recent blog, I outlined some of ongoing discussions in the healthcare industry about patients’ right to access their own data under the Cures Act. Based on the overwhelming feedback we received from the blog, it seems there is much confusion around the proposed rule. In this blog, I wanted to take a step back to explain the core idea behind this law and share how we are working with our clients to get prepared to meet these requirements by leveraging Azure API for FHIR®.

 
HL7® and FHIR® are registered trademarks of Health Level Seven International.

HL7® and FHIR® are registered trademarks of Health Level Seven International.

 

What is 21st Century Cures Act?

The 21st Century Cures Act (commonly known as Cures Act) was signed into law on December 13th, 2016. It is vital to understand that the goal of this law was to help accelerate medical product development and bring new innovations and advances to patients faster and more efficiently. The law was designed to facilitate incorporating the patient’s perspectives into the development of drugs, biological products, and devices in the FDA's decision-making process. As outlined on the FDA website“Cures enhances our ability to modernize clinical trial designs, including the use of real-world evidence, and clinical outcome assessments, which will speed the development and review of novel medical products, including medical countermeasures”.

This basically requires patients to have the ability to gain access to their data. The law targeted improved EHR use to support this health data interoperability. Specifically, it called on the ONC to establish better requirements for health IT interoperability to enable data transfer between disparate systems. Last year at HIMSS, ONC announced a proposed rule pertaining to those provisions of the 21st Century Cures Act. This included some new certification criteria that all EHR vendors will need to support going forward. One of these newly proposed criteria is referred to as the “2015 EHR Certification G10 API” or the “Cures Criterion.” This new G10 API criterion: 

  • Mandates HL7 FHIR® as the API standard

  • Defines specific business and technical documentation required to be published by the EHR vendor

  • Defines boundaries for the fees that can be charged by an EHR vendor for these APIs

  • Defines more stringent requirements for the EHR vendor to maintain the certification

The above changes combined with another set of requirements defined in the rule would promote an open and competitive marketplace. The ultimate goal of this criterion is to promote patient engagement and their involvement by accelerating the development of independent third-party SMART On FHIR “Apps” patients can choose from, to aggregate and manage their provider-validated healthcare data. You can read more about the SMART On FHIR framework in our previous blog.

As part of compliance solutions offerings, we have been working to develop a solution to support the Cures Act requirements. As we had discussed in one of our blogs, we have been working with Azure API for FHIR since it’s early release last year. It still amazes me how we can get a “HIPAA ready” FHIR server provisioned in minutes. This allows organizations like ours to focus on developing innovative applications to meet our customer needs without worrying about security and scalability. Last year, we announced a partnership to develop a FHIR based clinical registry based on Azure API for FHIR. We have been working on many other similar solutions with our clients. As we explored options to implement a solution for Cures Act, Azure API for FHIR was obviously our first choice. Today, we are excited to announce that we will be releasing our “Cures Act Connector for Azure API for FHIR” at HIMSS20 this year.

The Cures Act Connector is built on top of Azure API for FHIR as a plug-and-play solution and would allow organizations to meet and even exceed Cures Act requirements. If you have ever been through the ONC certification process for any criterion, you will know this is not a trivial task. In order to develop this, we had to make sure we are able to meet all the “regulatory requirements” for the proposed rule. This requires passing all the steps of the technical scripts and testing tools designed to meet those requirements. It makes it even more challenging as we only have access to draft scripts at this time. We would like to thank the Azure API for FHIR team for all their continued support to help us understand and implement Azure API for FHIR. Our ability to rapidly deliver this connector is attributed to the access to the Azure API for FHIR source code and the support provided by Microsoft.

If you planned to attend HIMSS, please contact us to schedule a live demo. In addition to the Cures Act Connector, we can also show you our other solutions based on Azure API For FHIR:

  • BlueButtonPRO™: A complete end to end solution to implement seamless two way exchange of data between healthcare entities and patients

  • BlueButtonPRO™ Care Insights: A Microsoft Azure API for FHIR connector to identify and stratify patients using an evidenced based algorithm used across the globe by health systems, health plans, government organizations and individual researchers

  • CMS BlueButton and Data At Point of Care Connector: A plug-and-play solution based on Azure API for FHIR to implement CMS Blue Button and CMS Data at the Point of Care


RELATED POSTS