A Punchlist for Consumer Directed Exchange Success

Health data fluidity in the United States still has a way to go to get to an ideal state.  Federal efforts, such as Meaningful Use, have improved the situation somewhat, but people still struggle to access their own health information.  An effort to empower patients by giving them the power to move data around on their own is gaining momentum and attention. Although it can go by many names, its often referred to as "Consumer Directed Exchange".

To clear up some ambiguity, "Directed Exchange" in US health care most often refers to the Direct Project. Direct is an encrypted email-based point-to-point exchange mechanism that is required to meet Meaningful Use criteria. Direct is often used for provider-to-provider and system-to-system communication. Direct has seen little adoption by consumers (i.e. patients).  

 The term "Consumer Directed Exchange", on the other hand, is a technology agnostic term that can refer to many things. Consumer Directed Exchange can include a patient's ability to log onto a health provider's patient portal to view, download, and transmit information.   The ability to "download" one's own patient data is often referred to as "Blue Button".   More recently it is often used to refer to patient-facing application programming interfaces (APIs) as defined by Meaningful Use Stage 3. An API is what helps computers and systems talk to each other. While Meaningful Use 3, patient-facing API requirement. does not prescribe the use of any particular technology it appears that OAuth2 and FHIR are the clear front-running technologies for how the industry as a whole is addressing the challenge.  CMS is implementing the Blue Button API to allow Medicare beneficiaries to access their health information within 3rd party applications of their choosing. The CARIN Alliance is convening stakeholders to collectively tackle these issues.

Consumer Directed Exchange can refer to many technologies, techniques, and policy. This punch list focuses on technical considerations and assumes OAuth2 and FHIR as key enabling technologies.  While not an exhaustive list, it highlights some key items that will be necessary for widespread success.

• Implement the Argonaut FHIR Profile - As an international standard with many different code-sets, the industry needs to narrow things down with a common profile such as the Argonaut FHIR profile.  Argonaut should consider an STU 3 version.  Implementers should consider supporting both STU2 and STU3.
• Implement the SMART on FHIR Authorization - The SMART on FHIR Authorization flow defines how the patient's ID is passed to the application along with an OAuth2 access token. The SMART on FHIR Authorization flow defines how the patient's ID is passed to the application along with an OAuth2 access token.
• Extend or Define FHIR Profiles  - Define US-specific FHIR profiles where current profiles either are incomplete or don't already exist or are incomplete for ideal data exchange. Key FHIR resources include Laboratory, Pathology, Imaging Investigations, and other diagnostics.
• Standardize User Info API - Even if a data provider is not implementing OpenID Connect (OIDC), data providers should still implement the UserInfo Endpoint in accordance with OIDC. Include the patient field in the UserInfo endpoint response.
• Implement OAuth2 Discoverability  -   Even if a data provider is not implementing OpenID Connect (OIDC), data providers should implement  OIDC Discovery (i.e the /.well-known/openid-configuration endpoint).  Include the FHIR Metadata endpoint in the OIDC Discovery response so the FHIR server details are more easily discovered.  (e.g. add "fhir_metadata_endpoint" : "https://example.com/fhir/metadata").
• Create a National Authentication Service and Voluntary Unique Patient Identifier -  Encourage all data providers to join forces to create a universal authentication service.
• Allow Social Logins -  For consumer convenience  allow patient's to attach social logins, such as Google and Facebook. This will make logging into patient portals and approving applications is that much easier.
• Proliferate Application Registries -  Find many channels to support application discovery.  These can include the Apple App store, Google Play, or other application registries. Registries could meld with the DCRP and application endorsement.
• Adopt FIDO - FIDO is becoming the industry standard for authentication. FIDO allows users to authenticate without passwords.  For example a device or a biometric reader can be used instead.  Both iPhone and Android's internal  Trusted Platform Module (TPM) chips support FIDO.  The health care industry should adopt this important standard to the extent possible so that end users can more easily and securely access data.  FIDO can improve both security and convenience.
• Standardize an Approach for In-Person Identification - Create a simple process for identity proofing and account creation.  For example, when a patient arrives at a health provider's office and their government issued ID checked, the patient signs her name, and the account and social login binding is completed on the spot.

I considered adding remote identity proofing to the list, but  remote identity proofing is a tough nut to crack.  Its a widespread problem that extends well beyond the health care industry.  Finding one way to do it is unlikely.  Instead, remote identity proofing solutions may be a patchwork of technologies and will be use case specific.

While there is still work to do, I'm optimistic about the future of health data fluidity. Putting patient's in the driver seat to share their data is finally on the horizon.

We should consider a data sharing landscape that extends beyond health data.  For example, we should extend to community-based and faith-based organizations such as homeless shelters.

Transparent Health is an emerging open source software foundation focused on the United States healthcare industry. Our GitHub page is https://github.com/TransparentHealth. If you have an open source health project needing a home, please reach out!

Opinions in this article are my own and do not reflect those of clients, government entities, business partners, Transparent Health directors, or staff.