The Open API economy is enjoying a great deal of success in health data democratization. The government declared that we should enable Open APIs, so we built them. Then, lo and behold, several developers (most noteworthy Apple) built client applications and—just like that—accessing your health data suddenly became cool! Still, this is only just the beginning and the industry has a way to go toward making client-app-to-API conversations more fluid and more secure. Such “market making” work will help us have even richer interactions using Open APIs over time. We brought to this past weekend's HL7 FHIR connectathon in San Antonio a few tools that help achieve this, for continued testing and socialization of the ideas. I'll just jump to what's newest, because I have written about a few of these previously.

Just what is needed? Since Open APIs create new data access paradigms, new authorization models are also needed because for Open APIs in healthcare, the entity securing health data is often someone other than the client application developer. In existing API workflows, identity information about a user goes from the identity provider to the client app in OAuth/OpenID, and the app can even retrieve additional user attributes from the identity provider with the user’s permission--like getting my first and last name or Facebook profile photo.

But a third party data holder is left somewhat out of the picture in this model, especially when you start to think about reusing credentials from foreign systems (when the identity platform and the data resource security are run by different organizations). Creating a reliable way for a data holder at organization A to get more information about an external user authenticated by organization B would allow A to make informed decisions about access (beyond simply choosing which Authorization Servers it trusts), and would enable reuse of credentials when possible, helping to scale the use of FHIR (Fast Healthcare Interoperability Resources—arguably, the most commonly-available open API for health data). Especially in the case of healthcare professionals, it is burdensome to maintain many different access credentials—each with a strong password—and is even more arduous to attain them in the first place. A method to securely communicate the verified attributes behind a provider's digital credentials directly to another party securing resources would therefore prove useful to the community.

One main way OAuth can be enhanced in order to make the most out of third party identity services is to enable this attribute expression by making the information exchange between the authenticating system (identity provider) and the data holder more equitable.

But OAuth was designed for a world in which there are commonly two parties of concern—the OAuth server doing the authentication and the client relying on this server. In this case, the client is typically tightly bound to data resources—as when an app launches from within an EMR. Using OAuth in this way, a user can authenticate to other apps using something akin to Facebook’s or Google’s authorization server—and save users from having to memorize a different credential for every new site we visit. Many such "third party" sites are interested only in keeping track of me as the same user over time. They don’t need very much metadata about me, and they don’t really care if any metadata they do obtain from my identity provider has been verified or not. (To date, such apps do not have an identity focus, which is OK for many non-healthcare use cases.) In fact, in an increasingly privacy-aware environment, apps (and their users!) probably want to have the responsibility for managing as little additional information about users as necessary. Otherwise, that data is put at increased risk and it becomes burdensome for an application to secure.

Going beyond that nominal example of signing in with Facebook or Google, there is demand for digital credentials that bear more meaningful assertions about identity, whether for cross-organizational data exchange, for multi-factor authentication, or in other situations where it increases confidence and security for consumer and business use cases alike.

Logging in to a new site with an OpenID from a different identity provider is just the beginning of how digital identities may come to be used in the next few years. As Open APIs proliferate, so too will the number of parties participating in each transaction, beyond the traditional two (client and server). The demand for cross-organizational data query isn’t unique to healthcare, but health data can benefit a great deal from better scalability, since it's an industry in which data privacy laws legitimately allow for professionals to exchange information about consumers. However, consider when one company requests data about a patient from another company—say an insurance company making a request of a health system—the healthcare organization can increase their confidence in exchange when they know more about the user than the name of the organization that issued their credential. Knowing the individual’s name and email address helps to some extent. The data holder might prefer to also obtain personally identifiable information (PII) such as other identifiers that both parties would need to secure. This goes beyond what could be done with the OpenID Userinfo Endpoint, because the data holder also wants to query for this information directly from the identity provider, rather than via the client application.

Secondary is the matter of sharing PII relating to who a query is about, which again needs to be secured and integrity-protected.

So, we now enter a realm in which both parties have data they need to protect, to make the transaction work. The healthcare organization is protecting patient health data secured with OAuth and OpenID. The insurance company is protecting information about the identity of the human making the request or about whom the request is being made, which can be secured in the same way as health data and now shared securely with the data holder using Unified Data Access Profiles (UDAP) Tiered OAuth. What's tiered about this? In the process of authorizing the health data transaction, the healthcare system's authorization server can initiate a secondary query of its own to the insurance company’s identity provider, obtain identity information and other assertions, and can then proceed to make an informed decision about releasing data about a patient to the ultimate end user (who has authenticated only to their own organization’s OAuth server). The healthcare organization simply needs to know to trust the insurance company’s OAuth server, and that additional resources can be obtained from that server when needed to make an authorization decision. This is what's possible when OAuth servers can talk.

Tiered OAuth provides a secure way for data holders to increase their confidence about who is on the other side of a FHIR transaction—and for these use cases, that has to go beyond a person’s name, email address, and profile photo as are used today when a consumer signs in with Facebook or Google to a third party app. This personally identifiable information definitely has to be secured, though. Done properly, managing credentials for cross-organizational queries thus becomes a much more scalable endeavor—third party OAuth servers can provide (with the user's permission) information about what organization a user is working for, what they intend to do with data they’re requesting, where they’re accessing data from, what their verified personal and organizational identity attributes are, and whether their system credentials—and all their user attributes—are still valid. Those resources can even offer information to help match the identity the query is about to a unique person (patient) on the other system, with a high degree of confidence.

Even in cases where robust identity information does not need to be shared, this model allows the direct transfer of purpose of use, verified person's name, and requesting party organization directly to the authorization server at the data source, rather than by passing the information through a client application.

If we take a step back and look at permissions more holistically, considering identity as a stronger and more data-rich component of the entire authorization decision, we can do something more informative. If we can build systems capable of making authorization decisions without managing access at the individual user level to an individual patient record, APIs will scale better. If we have options that don't require every healthcare industry participant to have a different credential for every system they need to access, we will save time and money, and above all frustration, for these end users.

To find out more about scaling the use of Open APIs with Tiered OAuth, check out the Unified Data Access Profiles, contact collab@udap.org, or join our Google group to get involved in the conversation. Additional profiles are also available for trusted client and user authentication and for trusted dynamic client registration.