The Standard | The Official Blog of HL7

What Can Apple Learn from the CCDE Track at the HL7® FHIR®  Connectathon 17

Written by Sandeep Giri | Feb 5, 2018 6:41:34 PM

 

 The HL7® FHIR® Connectathon Consumer Centered Data Exchange Track

Covered entities face an ever-growing demand to enable digital health apps to access Protected Health Information (PHI). The technical and legal requirements to enable this are the focus areas for the Consumer Centered Data Exchange (CCDE) track at the HL7 FHIR Connectathon. This track initiated at the San Diego Connectathon (September 2017), and it made more progress recently (January 27-28) at the New Orleans Connectathon. Track participation may have been piqued by Apple’s recent announcement that it will provide patients an “effortless solution bringing health records to iPhone”, and that Apple will use FHIR services to enable this.

Caption: Participants at the HL7 FHIR Connectathon 17 in New Orleans, LA. Image credit: Kai Heitmann.

Apple’s announcement couldn’t be more closely tied to the work of the enthusiastic CCDE track participants, representing the entire healthcare industry including providers, payers, government, academia and app developers. Apple could benefit a lot from this track’s work if iPhone users are to access PHI from covered entities beyond the initial 12 participants of the iOS 11.3 beta.

Why? Mainly because the CCDE track focuses on 3 key requirements:

  1. It should be technically simple for a covered entity to verify that an app requesting access to a patient’s PHI is indeed controlled by that particular patient;
  2. The way an app accesses PHI should be compliant with data governance and privacy policies of the covered entity, as well as HIPAA guidelines, and;
  3. The experience of an app user should be simple enough so that they clearly understand and acknowledge what they are sharing with the app. 

Technical Simplicity of OAuth

OAuth is a simple, versatile and widely adopted standard that can enable a covered entity to verify that an app requesting access to PHI is indeed controlled by a trusted patient (documented in a prior blog post Patient Consent Forms: Redundant in the World of OAuth2?). Once a covered entity can securely link an app to a trusted/verified patient of theirs, the entity can then trust the app in order to send the patient’s PHI. Also, as a part of OAuth, a patient can restrict how much of their PHI to share with the app. They may choose to share all PHI, only a specific set, or not share anything at all (remember the U2 album that automatically showed up in everyone’s iTunes account whether they wanted it or not?).

 

HL7 FHIR Resources Representing Patient Authorization/Consent

A covered entity may want to record a patient’s authorization to share PHI with an app. This provides an audit trail and can help meet legal requirements. It also provides a FHIR resource server (RS) with an efficient way to check whether a patient has authorized sharing PHI with an app. At the CCDE track, I observed two main options being used for recording a patient’s preferences for sharing PHI:

  1. Record preferences in the OAuth authorization server (AS) so that the AS can direct the RS to either permit or deny any resource request;
  2. Make use of FHIR resources like consent or contract so that patient preferences can be shared more easily (for example, with the contract resource, a covered entity can represent patient authorization as a legal document signed by the patient). 

 

Simplified User Experience

UX is the crux of the matter for widespread adoption. Thus, it should be easy for a patient to understand and acknowledge what they are sharing. One way to simplify is as follows:

Imagine you have a new iPhone app that can pull your PHI from any hospital of your choice. You fire up the app, search for your hospital X, and upon finding it, you click on a link that says “download my health records from hospital X”. Hospital X wants to verify that it is indeed you making this request, so it asks you to log into its online patient portal (using OAuth). By logging into the portal, you make a secure link between your patient account at Hospital X and your iPhone app — a link that Hospital X can now trust.

Next, Hospital X requests you to specify how much of your PHI you want to share with this iPhone app.

How about providing the following three choices to the patient? 

  1. Share Nothing (or Opt-Out);
    This is the default -- security folks are conservative, so we always assume the worst -- that you as a patient may have been just playing around with the app, and didn’t really want to download all your PHI on your cousin’s new iPhone X which he was showing off at the Thanksgiving dinner).
  2. Share All PHI (or Opt-in)
  3. Share PHI Not Marked “Restricted”
    “Restricted” is a FHIR security label indicates “highly sensitive, potentially stigmatizing information, which presents a high risk to the information subject if disclosed without authorization.” Examples: sensitive conditions, mental health, HIV, substance abuse, domestic violence, child abuse, genetic disease and reproductive health.

The good news is that FHIR as a community has formal processes to take discussions like these and turn them into implementation guides (IG) — clear technical specifications which illustrate how to use FHIR’s open standards and enable practitioners to make the standards work for specific use cases and workflows in healthcare.


Caption: Apple HealthKit app (Image credit: Apple)

 

Conclusion

In promising patients an “effortless solution bringing health records to iPhone”, and adopting HL7 FHIR, Apple has embarked on a worthy cause where they can help immensely by promoting widespread adoption of open standards and best practices to achieve interoperability. I hope Apple, and other app developers, can leverage the IG’s coming out of FHIR Connectathon tracks like CCDE, and also make their own contributions to improve the process.


Resources/References

Related HL7 FHIR Blog posts: 
View full post