Healthcare OpenID: Difference between revisions
Jump to navigation
Jump to search
| Line 19: | Line 19: | ||
* Adopt a paradigm shift to documents that are problem oriented rather than solution oriented. For example the [https://openid.net/specs/openid-financial-api-part-2.html FAPI specifications] of the OpenID foundation is oriented to solutions for financial payments from users. | * Adopt a paradigm shift to documents that are problem oriented rather than solution oriented. For example the [https://openid.net/specs/openid-financial-api-part-2.html FAPI specifications] of the OpenID foundation is oriented to solutions for financial payments from users. | ||
* Focus only on new specifications that feature the goals of the Cares Act, such as giving [[Patient Choice]] in how their information is accessed, | * Focus only on new specifications that feature the goals of the Cares Act, such as giving [[Patient Choice]] in how their information is accessed, | ||
* 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 [https://openid.net/specs/openid-connect-federation-1_0.html OpenID federation specification. | * 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 [https://openid.net/specs/openid-connect-federation-1_0.html OpenID federation specification]. | ||
* Bring up a GitHub repository and deprecate the bitbucket repository. | * Bring up a GitHub repository and deprecate the bitbucket repository. | ||
==References== | ==References== | ||
[[Category:Health]] | [[Category:Health]] | ||
Revision as of 17:37, 14 March 2020
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:
- [ http://openid.net/specs/openid-heart-oauth2-1_0.htmlHealth 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.
Problems
- The documents are written in the language of OpenID rather than in the terms of the US Healthcare ecosystem.
- The paradigm for the existing specifications is the documents from the corresponding standards committees rather than the need of the Healthcare ecosystem.
- Bit Bucket has entered end-of-life and is not viable for future development.
Solutions
- 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.
- Focus only on new specifications that feature the goals of the Cares Act, such as giving Patient Choice in how their information is accessed,
- 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.
- Bring up a GitHub repository and deprecate the bitbucket repository.