Technical Implementation of the Cures Act

On December 13, 2016, the 114th United State Congress passed the 21st Century Cures Act with an intention to make it big in the face of U.S Healthcare. While it is designed to accelerate preventive care, health IT development and clinical research, it also intends to encourage data fluidity in the healthcare ecosystem. Recently, through the Cures Act Final Rule, released on May1, 2020, it brought with itself the Information Blocking & Interoperability and Patient Access rules. Although new to the family, their collective aim is to propel US healthcare to the patients’ courtyard. 

If you take a step closer, the first thing that’d stand out is the precise amalgamation of “Information blocking” & “Interoperability”. The Cures Act Final Rule strengthens the guidelines that prevent information blocking by any of the involved actors to facilitate interoperability and reinforce seamless exchange & use of Electronic Health Information. The rule outlines provisions that allow patients to access their Electronic Health Information (EHI) whenever, wherever and however they need. This serves the dual purpose of making the continuum of care, patient centric as well as promoting the modern app economy. 

Now as utopian as it may sound, it brings its own share of complexities. For a gear shift like this to be effective, the existing administration needs to undergo metamorphosis, a progressive one. The following are the policies that’ve been finalized to facilitate the implementation: 

• Patient Access API (applicable January 1, 2021) 
• Provider Directory API (applicable January 1, 2021) 
• Payer-to-Payer Data Exchange (applicable January 1, 2022) 
• Improving the Dually Eligible Experience by Increasing the Frequency of Federal-State Data Exchanges (applicable April 1, 2022) 
• Public Reporting and Information Blocking (applicable late 2020) 
• Digital Contact Information (applicable late 2020)Admission, Discharge, and Transfer Event Notifications (applicable spring 2021) 

If you think accomplishing this is going to be duck soup then let us do some digging, shall we? 

 

The Stated Pre-requisites

• FHIR R4: The APIs to be exposed by provider and payer organizations need to be FHIR V4 compliant. 
• USCDI Transition: USCDI to replace the Common Clinical Data Set that was previously required as part of a number of 2015 Edition health IT certification criteria. 
• SMART on FHIR Setup: Deployment of patient authorization mechanisms to access patient health information through mobile apps  
• Identity Assertion: As multiple patients/members attempt to access their information via these APIs, the assertion of user identity becomes a necessity. 
• While on paper this may seem like a simple list of four essential requirements, the practical implementation would have a different tale to narrate. And to top it up, we have the repercussions of information blocking that have the potential to cause a paradigm shift across the elements of interoperability. 

Now that you’re primed for what you may expect in the process, let us dissect the possibilities brewing under the surface. Below, we have listed down some of the expected scenarios that you may face in the process. 

• Capturing Consent  
• Policy Control 
• Exception Management 
• Value set synchronization 

With probable obstacles in sight, payer and provider organizations must scramble to cushion the blow of the 21st Century Cures Act mandates, or even better, buffer it all. Here are some scenarios of how you may want to get to the bottom of this: 

PROVIDERS: 

• Those with a single EHR: If the EHR vendor already uses FHIR V4 resources, then the supporting APIs should handle the requirements of the Cures Act Final Rule adequately. 
• Those with multiple EHRs: A solution needs to be put in place that consolidates the information packets in individual EHRs and deliver it via one endpoint. 

PAYERS: 

• Transactional systems as the source: The information to be delivered to members is generally all over the place due to disparate databases, so hooking them up with the new FHIR system might be daunting. 
• New data store for FHIR: Replicating voluminous patient data will not only drill a hole in the budget but will also would render the strenuous task of synchronizing the transaction systems with it. 
• EDW as the source: Having Enterprise Data Warehouses (EDW) to source data could simplify data aggregation and may be a feasible source to hook up the FHIR servers to. 

A Glimpse of the “Ideal Final Solution”

While there’s no definitive answer to it, we have rolled out the blueprint of what the ideal solution may look like.  

In a condensed form, we may rightly say that the bigger picture of FHIR enablement is an issue that requires expertise with the healthcare standards and calculative measures to develop patient data exchange mechanisms. With turbulent dynamics, a myriad of bullets to dodge in the form of regulatory compliance, the payer and provider organizations will have to invest a major chunk of their round table chats to it. 

The choice you make today holds the potential to cause tremendous after effects, be it uphill or downhill. But the good part is you are in charge of the direction of this current. And that is why it is essentially important to place your trust in the right hands. 

If you want to dive deeper into a wide spread and detailed explanation speak to one of our healthcare experts now or reach out to us at info@nalashaa.com