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)
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:
(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
- 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:
