Healthcare OpenID

Full Title

The OpenID Foundation has a working group, HEART, which is creating specifications for the use of OpenID and related specifications within the US Healthcare ecosystem.

Context

The following Implementer’s Drafts of Four HEART Specifications have been approved as of March 12, 2019. The four specifications that were approved are:

• Relationship Trust Profile for OAuth 2.0
• Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes
• Health Relationship Trust Profile for User-Managed Access 2.0 Health Relationship Trust Profile for User-Managed Access 2.0
• Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) UMA 2 Resources
• A complete list of HEART specifications produced (including previous Implementer’s Drafts) can be found in the group’s BitBucket repository.

The first meeting of the reorganized effort mention the topic of dynamic registration. It is likely that HIPAA compliant entities are NOT dynamically created, but need to go through a rigorous testing procedure and are statically registered.

Problems

• The above 4 documents are written in the language of OpenID rather than in the terms of the US Healthcare ecosystem. In other words, they attempt to impose solutions from other groups rather than focus on the problems that need to be solved.
• The paradigm for the existing specifications is the documents from the corresponding standards committees rather than the need of the Healthcare ecosystem.
• The need for patient consent is not mentioned anywhere in the specs. Not even in the one on UMA. Somehow that seems core the intent of the Cares Act.
• The hyperledger/aries effort include a program to provide patient healthcare data into the research programs. This is an effort to take patient supplied and clinical data into wide scale research programs. Some interface to us FHIR efforts could help both teams.
• Limitations of the existing OpenID connect approach to supplying call claims in a single id token from a single source are currently being addressed by a wide range of solutions. It is unclear which proposals will survive the tumulate of change in identifier provisioning.
• Bit Bucket has entered end-of-life and is not viable for future development.

Solutions

Two areas are addressed in the documents that can be found at the highlighted links in the following. The third is just a mechanical change mandated by circumstances.

1. Adopt a paradigm shift to documents that are problem oriented rather than solution oriented. For example the FAPI specifications of the OpenID foundation is oriented to solutions for financial payments from users.
   1. In particular look at the information that is created in a High Assurance ID Token that would address the needs of both the TEFCA requirement for high-assurance as well as the needs for self-sovereign identifiers.
2. Focus only on new specifications that feature the goals of the Cares Act, such as giving the Patient Choice in how their information is accessed,
   1. In particular focus on how the patient can know that any given web site can be trusted with their protected health information (PHI). A good approach might be to enable the Entity Statement of the OpenID federation specification.
   2. From the user perspective dynamic registration of HIPAA compliant web sites should not be allowed as a web site either has a current certificate or it does not,
3. Bring up a GitHub repository and deprecate the bitbucket repository .
4. Kantara Federated Identifiers work group has agreed to establish a formal liaison with OpenID HEART work group to share the load, so to speak, if that is acceptable to the OpenID teams.