The Standard

The Official Blog of Health Level Seven® International

visit HL7.org 

HL7® FHIR® Connectathon 16: Patient Consent Forms: Redundant in the World of OAuth2? Part 1 of 2

[fa icon="calendar"] Sep 29, 2017 11:56:45 AM / by Sandeep Giri


 FHIR Connectathon 16 Patient Consent OAuth2

 The HL7® FHIR® Connectathon Consumer Centered Data Exchange Track

The HL7 FHIR Connectathon 16 in San Diego hosted a Consumer Centered Data Exchange track, focusing on scenarios 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. However, before such pulling or sharing can begin, one needs to consider that a provider may require an explicit patient consent or authorization form (often paper-based) signed by the patient

Today, a patient would typically do this by signing a paper form and the provider would hand over a DVD containing scanned PDF copies of the patient’s health records. Now, imagine using a consumer health app on your phone, and every time you request your provider to share your records, the app asks you to first download a consent form that you then need to print, sign and fax to your provider. That would be a cumbersome and undesirable patient experience. Instead, digitally embedding patient consent during the electronic pulling or sharing of patient records itself can make this experience much smoother.

OAuth2 Authorization Challenge or Patient Consent Form?

John Moehrke, the track co-chair, initially suggested this track to review a sample paper consent form from AHIMA, and implement similar functionality to capture consent digitally by using HL7 FHIR resources like Consent and CommunicationRequest. During the first track meeting, several track participants raised the question as to why a separate patient consent form is needed when in fact the OAuth2 authorization challenge asks a user exactly the same questions as asked by a consent form.

For example, consider the following sequence an app goes through when accessing patient data from a Cerner EHR using FHIR:

  • User instructs their app (pre-registered with Cerner) to get patient data from the EHR server using OAuth2.
  • OAuth2 requires server to redirect the user to a log-in screen to authenticate themselves.
  • Upon successful login, server then presents the user with an authorization screen to specify which health records in Cerner EHR the app should be able to access (see screenshot below, courtesy of Dennis Patterson from Cerner)

figure-1-Cerner Patient Authorization FHIR SMART.png

 

Here, the user (Nancy Smart) is instructing the Cerner EHR (FHIR Play Millennium) the specific health record categories (not just for Nancy, but also for her dependents) the EHR should share with the client application (Dennis’ SMART Tutorial App - Patient Access).

Now, consider the similarities between this OAuth2 challenge and a paper patient consent form that looks like:

 

Figure-2-AHIMA-patient-consent-form-snippet.jpg

(note: this is a partial screenshot of the AHIMA consent form)

If the categories of health records presented in the Cerner’s OAuth2 challenge (personal information, allergies, etc.) are customized to match the categories in AHIMA’s consent form (discharge summary, emergency room records, etc.), then the act of a patient like Nancy making her selections in the OAuth2 challenge should be the same as her signing a patient consent form.

 

Can We Use OAuth2 Authorization Challenge to Capture Patient Consent?

So , why don’t we just use the OAuth2 challenge to capture patient consent? Clearly, OAuth can capture the essential information to represent patient consent, but can it replace the current practice of patients signing consent forms?

To drive adoption, we need to examine the needs of both providers as well as of the patients, and also the underlying policy requirements.

Technically, a provider can capture a patient's response to OAuth2 challenge as a Consent FHIR resource, which can then replace paper/PDF forms as the legal record of patient consent. Also, the Consent resource can be shared with patient apps so they can keep track of a patient’s consent preferences across multiple providers (and avoid duplicate data entry in future).

 However, the use of the FHIR Consent resource or the OAuth2 authorization challenge are NOT about meeting the exact legal definition of "consent", "authorization", "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 friction-less while still meeting legal/policy requirements.

 

Conclusion

So if we want to enable consumer health app developers to pull patient health records from a provider, or instruct a provider to share patient health records with another provider, we can greatly benefit by first enabling providers to design their OAuth2 authorization challenge as a patient consent form. This way, patient consent can be digitally recorded during the OAuth dance, and providers can share patient health records with the patient health apps much more efficiently, while still meeting the policy and regulatory requirements.


Resources/References

Related HL7 FHIR Blog posts: 

Topics: HL7, health IT, HL7 community, FHIR, Connectathon, Patient Consent, Patient Experience, Operational Efficiency, OAuth2

Sandeep Giri

Written by Sandeep Giri

Sandeep is a Technical Product Manager at UCSF (University of California at San Francisco) Center for Digital Health Innovation (CDHI). He is working on an interoperability project based on a federated model of FHIR services. Sandeep has held several CTO, Product Manager, and Software Architect roles since the late ‘90s. You can reach Sandeep at sandeep-dot-giri-at-ucsf-dot-edu or @sandeep_giri on Twitter.