The HL7® FHIR® Connectathon Consumer Centered Data Exchange Track
In my previous article, Patient Consent Forms: Redundant in the World of OAuth, Part 1, I suggested providers to design their OAuth2 authorization challenge as a patient consent form so that patient consent can be digitally recorded during the OAuth dance. This would allow providers to share patient health records with the patient health apps much more efficiently without requiring separate paper/PDF consent forms, while still meeting the policy and regulatory requirements.
In this post, I will walk through a specific example of how to do this, and also discuss the differences in providers and patients’ perspectives on consent.
OAuth2 Authorization Challenge as a Patient Consent Form
First, let’s consider the scenarios from the Consumer Centered Data Exchange track at the FHIR Connectathon 16 in San Diego where a patient app can pull their health records from all of their providers in one place, or cause their EMR data to be sent from provider A to provider B. In both these scenarios, the provider may need an explicit patient consent or authorization form (often paper-based) signed by patient. So, how can we use OAuth2 challenge instead to capture patient consent?
CMS Blue Button FHIR Server Interface
I discussed this with track participants Mark Scrimshire and Alan Viars (from the CMS Blue Button project). In their HL7 FHIR server interface, a user’s response to the OAuth2 authorization challenge is indeed recorded on the backend, and it can be made available as a FHIR Consent resource. Here’s what the OAuth2 authorization challenge response provided by a user looks like on their FHIR server end (screenshot courtesy of Mark Scrimshire and Alan Viars):
First, here is the authorization challenge as viewed by the patient:
Next, the patient’s response tracked as a JSON resource on their backend (which can be made available as a FHIR Consent resource):
This way, providers can capture a patient’s response to the challenge as a Consent FHIR resource and presumably replace paper/PDF forms as the legal record of patient consent.
Mainly, providers want to verify the identity of the patient requesting health records. They may require the patient to fill out a separate consent form, which they use as an audit record for releasing the patient’s health records. Consent is also transactional for the providers since they require a separate form for each request to release/share records. So, over time, the patients may end up filling out many such forms.
From a patient’s perspective, it would be more desirable to think of consent as their global preferences for sharing their health records with various parties. That way, the patient has one place to keep track of all consent instructions to share records across multiple care providers. In this model, every time the patient interacts with one of these providers, the app should be able to present consent preferences to that provider, instead of having the patient fill out a separate consent form each time.
FHIR Consent Resource
It is important not to confuse the FHIR Consent resource with the legal definition of the words consent or authorization in a given country or state (In this post, I have taken the liberty to use consent to represent both these terms, sticking to their literal meaning). A request to share patient’s health records can be initiated either by the patient or one of their care providers. If it is initiated by the patient, HIPAA (in the US) does NOT require an explicit patient consent form signed by the patient (specific state laws about particularly sensitive information, such as HIV/AIDs tests, might). However, a provider may still require their own separate form to be filled out by the patient to officially record the patient’s request to share his or her health records.
If the request to share records is initiated by a provider, then again, patient consent is not required if the records are shared for TPO (treatment, payment, or operations). However, if it is not for TPO, then the provider must obtain signed patient consent.
Conclusion
As I stated in the last post, the use of the FHIR Consent resource or the OAuth2 authorization challenge are NOT about meeting the exact legal definition of consent, authorization or directive in a given country or state. Rather, they provide a MEANS to meet the legal/policy requirements of electronically sharing patient data (in any given locale) WITHOUT requiring the patient to sign paper (or even PDF) forms. They are about making sharing information frictionless while still meeting legal/policy requirements
As shown by the CMS Blue Button example, HL7 FHIR and OAuth2 present the technology option to make the consent process frictionless. It is up to us as implementers to ensure it meets the security and policy requirements.
Resources/References
- HL7® FHIR® Connectathon 16: Patient Consent Forms: Redundant in the World of OAuth2? Part 2 of 2
- FHIR Connectathon 16 in San Diego, September 9-10, 2017
- Consumer Centered Data Exchange track
- AHIMA consent form
- Turning your iPhone into the one-stop shop for all your medical info
- Thanks to track participants for helping review this post: John Moehrke, the track co-chair; Aaron Seib, track co-chair, from National Association of Trusted Exchange, Luis Maas and Julie Maas from EMR Direct, Mark Scrimshire and Alan Viars from Blue Button, and Dennis Patterson from Cerner
- Difference between HIPAA Authorization and Patient’s Right of Access (courtesy: Kathleen Conner, one of the track participants)
- Smart-on-FHIR Application Authorization using OAuth2 Standard
Related HL7 FHIR Blog posts:
