Patient Engagement On FHIR® in 7 Steps
In a previous blog and the recent webinar, we discussed how CMS has redefined the Patient Engagement requirements under MIPS in 2019. In the proposed rule announced during HIMSS, ONC proposed a new certification criterion targeted towards those objectives that EHRs will need to support going forward. Many of our clients (both providers and EHR vendors) have reached out to us for clarification of these requirements. There is a lot of concern (and confusion) specially regarding the security requirements related to “enabling access for patients to their medical records”. This blog aims at providing clarification regarding these requirements and the associated security concerns.
HL7® and FHIR® are registered trademarks of Health Level Seven International.
Let’s first review the proposed changes. All 2015 Certified EHRs are required to support an “API functionality” if they are certified to what is commonly called as the G8 criterion. This functionality allows patients to get a copy of their health records in an electronic format from any provider using that EHR. It is important to understand that this is not the same as the patient portal. A patient portal allows the patient to view their data in an application supported by their provider and/or the EHR. Whereas, the API functionality allows the patient to get a copy of their data through any application that may or may not be supported by the provider or their EHR vendor. The goal of the APIs is to allow independent app developers to create new and innovative apps for the patient. The app developers should be able to do that by following the documentation made available by the EHR vendor for connecting to the EHR’s API.
If you are using an EHR certified to G8 criterion, this functionality should be available to you TODAY. The list of the EHR vendors certified for the G8 criterion with link to the requisite documentation is available on the CHPL website. Unfortunately, this criterion did not really yield the intended results due to various issues. Therefore, ONC is replacing this G8 criterion with a brand new criterion called G10 to address these issues. The new G10 criterion will:
Define particular standards and implementation specifications based on HL7 FHIR® (The current G8 criterion doesn’t include standard API requirements.)
Define specific business and technical documentation required to be published by the EHR vendor
Define boundaries for the fees that can be charged by an EHR vendor for these APIs
Define requirements for the EHR vendor to maintain the certification
The above changes combined with other set of requirements defined in the rule would promote an open and competitive marketplace. The ultimate goal of this criterion is to accelerate development of independent 3rd party SMART On FHIR “Apps” that patients can choose from, to aggregate and manage their healthcare data. You can read more about the SMART On FHIR framework in our previous blog.
So what is the confusion and concern about? Well, it is the 5 letter word – HIPAA. “How can we allow the patient using a third party app to access our EHR? What if they hack it? Who is responsible? ” is the kind of the reaction that most providers have when they hear about this requirement.
Before I address the HIPAA concerns, let’s understand at a non-technical level how this is supposed to work. Below is a 7-step process of the overall workflow.
The provider completes a note in the EHR.
After the notes is finalized, the EHR creates a copy of the patient record to be shared with the patient and posts it to the API. There are a lot of ways this can be done but lets keep it simple for now that it creates a copy to be shared.
The provider’s office staff registers the patient in some kind of an identity system and provide the patient with a set of credentials (username and password) in a secure way.
The patient downloads a third party app that is approved by the EHR to connect to the API.
When the patient tries to login to the app, the app will redirect the user to the identity system defined in step 3. The patient enters the credentials provided to them.
If the credentials are correct, the app is provided with a security token.
The app then uses that security token to connect to the API on behalf of the patient.
It may seem that the above process is really complicated. However, this kind of a security infrastructure is pretty common and is referred to as OAuth (Open Authorization) standard. Chances are you have used an app that supports a similar architecture. If you watched Game of Thrones using Roku or an Amazon Fire device, you had to go through the same process. If you used TurboTax to import your data from different financial institutions, it is the same process again. Many common apps allow you to use your Google or Facebook account to log into the app. That is again the same process. So, this security setup is pretty common. What makes it different for healthcare? It is the confusion around HIPAA.
The requirement is to provide read-only access to the data. As outlined in step 2, there should be a process to create a separate copy of the record so there is never a direct access to the EHR. This can eliminate the risk to the data in the EHR.
Step 5 in the above process ensures that the third party app developer never gets access to the patient’s credentials. The OAuth specifications ensure that this rule is followed. This can be further tightened through an approval process for the apps. This approval process is has been defined in the new proposed rule. That being said, there is an increased security risk. There are ways an app developer could get access to the patient’s credentials and use that data without patient’s knowledge. However, it is important to understand that HIPAA is really not applicable in this scenario. Steve Posnack, Executive Director, Office of Technology, ONC explained this really well in a webinar and is nicely summarized in the following slide:
WEBINAR: API Conditions of Certification (and more!) by Steve Posnack, Executive Director, Office of Technology, ONC
Again, all this is defined in the new rule. Kudos to the ONC team for a comprehensive overhaul of this criterion. Consumerism in healthcare is finally here and you can’t hide behind HIPAA to avoid it.
Contact us if you have other questions/concerns about the new rule and would like to discuss. Our BlueButtonPRO solution has been developed from ground up to support these requirements and much more.