Healthcare OpenID - Revision history

Tomjones: /* Solutions */

2020-03-19T01:02:12Z

Solutions

← Older revision		Revision as of 01:02, 19 March 2020
Line 22:		Line 22:

	==Solutions==		==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~~.		Two areas are addressed in the documents that can be found at the highlighted links in the following. The third and forth address administrative issues.
	# 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.
	## In particular look at the information that is created in a [[High Assurance ID Token]] that would address the needs of both the [https://tcwiki.azurewebsites.net/index.php?title=TEFCA TEFCA] requirement for high-assurance as well as the needs for self-sovereign identifiers.		## In particular look at the information that is created in a [[High Assurance ID Token]] that would address the needs of both the [https://tcwiki.azurewebsites.net/index.php?title=TEFCA TEFCA] requirement for high-assurance as well as the needs for self-sovereign identifiers.

Tomjones: /* Context */

2020-03-19T00:53:20Z

Context

← Older revision		Revision as of 00:53, 19 March 2020
Line 11:		Line 11:
	* A complete list of HEART specifications produced (including previous Implementer’s Drafts) can be found in the group’s [https://openid.bitbucket.io/HEART/ BitBucket repository.]		* A complete list of HEART specifications produced (including previous Implementer’s Drafts) can be found in the group’s [https://openid.bitbucket.io/HEART/ 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.		The first meeting call of the reorganized effort mentions 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==		==Problems==

Tomjones: /* Problems */

2020-03-19T00:49:30Z

Problems

← Older revision		Revision as of 00:49, 19 March 2020
Line 18:		Line 18:
	*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 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.		* 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 like that from the W3C DID group.		* 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 like that from the W3C DID group on blockchain identifiers.
	* Bit Bucket has entered end-of-life and is not viable for future development.		* Bit Bucket has entered end-of-life and is not viable for future development.

Tomjones: /* Problems */

2020-03-19T00:39:10Z

Problems

← Older revision		Revision as of 00:39, 19 March 2020
Line 18:		Line 18:
	*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 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.		* 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.		* 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 like that from the W3C DID group.
	* Bit Bucket has entered end-of-life and is not viable for future development.		* Bit Bucket has entered end-of-life and is not viable for future development.

Tomjones: /* Solutions */

2020-03-19T00:33:01Z

Solutions

← Older revision		Revision as of 00:33, 19 March 2020
Line 29:		Line 29:
	## 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,		## 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,
	# Bring up a GitHub repository and deprecate the bitbucket repository .		# Bring up a GitHub repository and deprecate the bitbucket repository .
			# 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.

	==References==		==References==
	[[Category:Health]]		[[Category:Health]]

Tomjones: /* Solutions */

2020-03-17T17:30:31Z

Solutions

← Older revision		Revision as of 17:30, 17 March 2020
Line 22:		Line 22:

	==Solutions==		==Solutions==
	Two ~~ares~~ 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.		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.
	# 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.
	## In particular look at the information that is created in a [[High Assurance ID Token]] that would address the needs of both the [https://tcwiki.azurewebsites.net/index.php?title=TEFCA TEFCA] requirement for high-assurance as well as the needs for self-sovereign identifiers.		## In particular look at the information that is created in a [[High Assurance ID Token]] that would address the needs of both the [https://tcwiki.azurewebsites.net/index.php?title=TEFCA TEFCA] requirement for high-assurance as well as the needs for self-sovereign identifiers.

Tomjones: /* Problems */

2020-03-16T15:17:32Z

Problems

← Older revision		Revision as of 15:17, 16 March 2020
Line 18:		Line 18:
	*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 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.		* 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.		* Bit Bucket has entered end-of-life and is not viable for future development.

Tomjones: /* Problems */

2020-03-16T15:14:42Z

Problems

← Older revision		Revision as of 15:14, 16 March 2020
Line 17:		Line 17:
	* The paradigm for the existing specifications is the documents from the corresponding standards committees rather than the need of the Healthcare ecosystem.		* 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 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.
	* Bit Bucket has entered end-of-life and is not viable for future development.		* Bit Bucket has entered end-of-life and is not viable for future development.

Tomjones: /* Solutions */

2020-03-15T19:08:20Z

Solutions

← Older revision		Revision as of 19:08, 15 March 2020
Line 25:		Line 25:
	# 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,		# 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,
	## 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].
	## From the user perspective dynamic registration of HIPAA compliant web sites should not be allowed as a web site has a current certificate or it does not,		## 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,
	# 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]]

Tomjones: /* Solutions */

2020-03-15T17:54:53Z

Solutions

← Older revision		Revision as of 17:54, 15 March 2020
Line 25:		Line 25:
	# 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,		# 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,
	## 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].
	## From the user perspective dynamic registration of HIPAA compliant web sites should not be allowed/as a web site has a current certificate or it does not,		## From the user perspective dynamic registration of HIPAA compliant web sites should not be allowed as a web site has a current certificate or it does not,
	# 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]]