2020 Medicare Interoperability Rule in Healthcare: OpenID Connect, Identity and Consent

The Interoperability Rule is driving transformation in healthcare. In an earlier post, we discussed some of the drivers and goals of the Interoperability Rule and discussed how the OAuth 2.0 requirement helps ease the integration challenges and simplifies securing connections.

Today, we focus on another security requirement of the Interoperability Rule: the use of OpenID Connect Core 1.0.

What is OpenID Connect?

OAuth and OpenID Connect sound similar but they do have separate roles. For this post, I will shorten the name to OpenID, a standard that provides a standardized method to verify the identity of a user. You can think of OpenID as an integration standard adopted by most identity providers that enable applications to use a common method to verify credentials.

OpenID delivers a token representing the user’s credentials from the identity provider to the requesting party also known as the relying party. This makes it easier for every device, browser, and user to connect while standardizing the actual identity management process.

OpenID helps to protect User ID and passwords, is a key component of single sign-on, and was built for use with RESTful APIs. 

Here is a simple metaphor to help explain it. You can think of OpenID as the visitor’s badge that a security guard gives you when you are visiting a secure building. It’s not your driver’s license, but the security guard (the identity provider) verified your driver’s license before he handed the visitor’s badge (the token) to you.

Now you can enter the building, and everyone knows that you are an approved visitor, not a roaming stranger. They don’t need to ask for your driver’s license, they use the visitor badge to grant you access. Because this is now just a visitor’s badge, you cannot go into secure areas. You are locked out. If you wanted to go into a secure area, then you would need authorization and OAuth can provide that to you.

Preparing for OpenID Connect and OAuth

Healthcare organizations should take an inventory of the identity management systems in place especially those used to authenticate patients, members, and partners. Verify that your proposed identity provider and important systems such as consent management support OpenID Connect and OAuth 2.0.

You might find that SAML is supported by the earlier version of your identity management system and that you need to upgrade to a version that supports OpenID Connect. Since the Interoperability Rule specifies these technical requirements, work with vendors and technology teams to be sure that your foundational systems are ready.

Additionally, think about use cases that are associated with consent and even future visionary requirements.

Now may be the time to adopt some newer capabilities in OpenID such as using the access token to provide important user information to your FHIR® server, your consent management service, etc. Also, there are dynamic discovery features that might also be of use that were not available in prior implementations. OpenID offers new capabilities that should be explored.

Consent management

Consent management is a key part of finalizing the authorization of data exchange as defined by the Interoperability Rule. If the patient or member gives consent to a third party, the healthcare organization must provide data when the third party requests on behalf of the patient.

This requirement should also trigger an inventory of consent solutions at your organization. Consent management in the past was more siloed and might not have the APIs and parameterization for consumer consent decisions (consent might have been represented as rules such as don’t share patient X’s mental health data instead of patient X approves sharing claims data with Y external application).

Additionally, many health plans offer multiple plans: commercial employer-based insurance, public exchange insurance, as well as Medicare and/or Medicaid. Inventory consent solutions for all offered plans as well as PBMs (pharmacy benefit managers) and outsourced providers.

Managing and correlating multiple consent management systems could add an extra layer of complexity to your implementation or even require caching consent decisions in a centralized store.

Here is a short list of questions that could help avoid pitfalls and unexpected issues:

• Is each component (security module, consent module, etc.) API-enabled?
• Is there a common identity management system for your enterprise or will credentialling decisions be made at a plan level (by type of business)?
• Will the end-to-end response time from a consumer portal be acceptable if the solution requires navigating across multiple identity management, consent, and partner systems to collect data before responding?

Planning the consumer experience across all these components can help ensure that all the source systems can properly collaborate using the foundational APIs of identity, authorization, and consent before data is exchanged.

Recommendations

While many healthcare organizations have piloted or used FHIR® servers and may feel confident implementing the data exchange requirements of the Interoperability Rule, it is equally important to be confident in implementing the security and authorization requirements.

The systems that provide the foundational services of identity management, authorization, and consent need just as much attention as the FHIR® server.

It’s possible that systems need to be upgraded and tested in a sandbox to deliver the experience that consumers and third-party application developers expect.

Here are some points that can help guide your team as they ready your Interoperability Rule solution:

1. Readiness check on Foundational Systems.
   1. Verify Identity Providers across all service plans and third parties meet OpenID and OAuth requirements.
2. Partner Readiness.
   1. Verify that pharmacy benefit managers (PBMs), outsourced technology providers, etc. are aligned on credentials to be used and have the capability to authenticate and manage consent through APIs.
3. Engage the Experts.
   1. Educate your own teams and consult security, network, and technical business partners.
   2. Ensure Provider Network managers, call centers, and front-line staff are aware of processes and potential impacts such as service calls from third parties.
4. Pilot solutions.
   1. Verify end-to-end processes work as planned.
   2. Test edge cases, not just normal processing.
   3. Enlist security teams to test and assess solution strength.
   4. Stand up with new test environments as needed to provide stable testing environments for you and your partners.
5. Confirm the Experience
   1. Use the pilot environment to assess the consumer and third-party experience.
   2. Is the solution responsive, coherent, complete, and consistent?
   3. Is the experience a positive reflection on your brand?

The Interoperability Rule is opening healthcare. As we take the first steps to enable a new consumer experience, let’s make sure that our foundational systems are ready, performant, and deliver the experience our consumers expect and deserve.