Epic's Letter To HHS: Facts vs Fiction
Last year at HIMSS, ONC announced a proposed rule pertaining to some provisions of the 21st Century Cure’s Act, which included some new certification criteria that all EHR vendors will need to support going forward. Yesterday evening, CNBC released an article sharing that Epic’s CEO, Judy Faulkner is urging hospital executives to oppose this rule. Epic has confirmed this and that they have sent an email to HHS Secretary Alex Azar, which has been signed by other “healthcare CEOs.” This is a very disappointing action by Epic, trying to misrepresent the proposed rule. Let’s winnow the fiction from the facts to understand what is going on here.
The Proposed Rule: Cures Criterion
Let’s first understand the proposed rule. All EHRs certified to the current 2015 Edition are required to support an “API functionality.” It is commonly called the G7, G8, and G9 criteria. 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 a patient portal. A patient portal allows the patient to view their data in an application supported by their provider and/or the EHR. In contrast, 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 your organization’s EHR is a 2015 Edition EHR certified to G7, G8, and G9 criteria, this functionality should be available today. The list of the EHR vendors certified for the G7, G8, and G9 criteria with a link to the requisite documentation is available on the CHPL website. Unfortunately, these criteria did not really yield the intended results due to various issues. Therefore, ONC is replacing the G8 criterion with a brand new 2015 Edition “Cures Criterion” called G10 in this proposed rule to address these issues. The new G10 criterion will:
Define particular standards and implementation specifications based on HL7 FHIR® (The current G8 criterion does not 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 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 by accelerating the development of independent third-party SMART On FHIR “Apps” that 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.
Come see a demo at HIMSS!
Find us at the Microsoft booth #2300, March 10th - 12th, 2020
Epic’s Argument
So what is Epic’s argument? Epic’s CEO Judy Faulkner believes this rule will result in app developers having access to patient data without their consent. Nothing could be further from the truth. Let us 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 note 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 many ways this can be done but let’s keep it simple for now that it creates a copy to be shared.
The provider’s office staff registers the patient in an identity system and provides the patient with a set of credentials (username and password) in a very secure way.
The patient downloads a third-party app that is approved by the EHR to connect to the API.
When the patient logs into the app, the app will redirect the user to the identity system defined in step 3. The patient then enters the credentials provided.
If the credentials are correct, the app is provided with a security token. The app developer never gets access to the patient’s credentials (username and password).
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 the 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 an app to aggregate your data from all your bank accounts to see your net worth, you have used this architecture. 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. Healthcare is slowly catching up to the consumer marketplace.
If the above architecture can be implemented with financial data, why can’t it be implemented with healthcare data? 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 has been defined in the new proposed rule.
What About HIPAA?
There is one argument that can be made here- HIPAA. However, it is important to understand that HIPAA is not applicable in this scenario. Steve Posnack, Executive Director, Office of Technology, ONC explained this really well in a webinar and we have discussed this in a previous blog.
Let’s make sure everyone understands the proposed rule. Kudos to the ONC team for a comprehensive well thought overhaul of the G8 criterion coupled with the elimination of Information Blocking. Consumerism in healthcare is finally here and EHR vendors should not be allowed to hide behind claims of false security risks to avoid it.