Trustworthy Healthcare Ecosystem - Revision history

Tomjones: /* User Digital Devices */

2021-03-21T17:28:31Z

User Digital Devices

← Older revision		Revision as of 17:28, 21 March 2021
Line 29:		Line 29:
	* The exact nature of "secure access" to the information is not not specified.		* The exact nature of "secure access" to the information is not not specified.
	* There are multiple ways to provide the information and to secure access, none has been acceptable to all of the participants. See solutions below.		* There are multiple ways to provide the information and to secure access, none has been acceptable to all of the participants. See solutions below.
	* The Cures Act Final rule focuses on the prevention of Information Blocking by allowing user access to APIs, but does allow the EHR to validate the App developer. The companion wiki on [[Trustworthy Healthcare ~~Applications~~]] is an attempt to take the limited ONC Guidance into a set of guidelines that can be used to create a set of [[Software Assessment Criteria]] for use by an [[Accreditation Authority]] and their credentials validators in assessment of developers and applications.		* The Cures Act Final rule focuses on the prevention of Information Blocking by allowing user access to APIs, but does allow the EHR to validate the App developer. The companion wiki on [[Trustworthy Healthcare Application]]s is an attempt to take the limited ONC Guidance into a set of guidelines that can be used to create a set of [[Software Assessment Criteria]] for use by an [[Accreditation Authority]] and their credentials validators in assessment of developers and applications.

	===Digital Service Endpoints===		===Digital Service Endpoints===

Tomjones: /* User Digital Devices */

2021-03-21T17:27:59Z

User Digital Devices

← Older revision		Revision as of 17:27, 21 March 2021
Line 29:		Line 29:
	* The exact nature of "secure access" to the information is not not specified.		* The exact nature of "secure access" to the information is not not specified.
	* There are multiple ways to provide the information and to secure access, none has been acceptable to all of the participants. See solutions below.		* There are multiple ways to provide the information and to secure access, none has been acceptable to all of the participants. See solutions below.
			* The Cures Act Final rule focuses on the prevention of Information Blocking by allowing user access to APIs, but does allow the EHR to validate the App developer. The companion wiki on [[Trustworthy Healthcare Applications]] is an attempt to take the limited ONC Guidance into a set of guidelines that can be used to create a set of [[Software Assessment Criteria]] for use by an [[Accreditation Authority]] and their credentials validators in assessment of developers and applications.

	===Digital Service Endpoints===		===Digital Service Endpoints===

Tomjones: /* Use of Native Apps to hold the patient's PHI */

2020-08-13T17:33:05Z

Use of Native Apps to hold the patient's PHI

← Older revision		Revision as of 17:33, 13 August 2020
Line 111:		Line 111:
	While there may be multiple ways to protect patient's PHI while in the user's possession, this paper explores two use cases.		While there may be multiple ways to protect patient's PHI while in the user's possession, this paper explores two use cases.
	# The app is considered to be a HIPAA covered entity and will only accept and disburse patient data to other covered entities. Exfiltration of data from this [[Trustworthy Healthcare Ecosystem]] is severely restricted, but still possible. This case is explored on the wiki page [[Phone as Health Care Credential]].		# The app is considered to be a HIPAA covered entity and will only accept and disburse patient data to other covered entities. Exfiltration of data from this [[Trustworthy Healthcare Ecosystem]] is severely restricted, but still possible. This case is explored on the wiki page [[Phone as Health Care Credential]].
	# The app is not a HIPAA covered entity and is not bound by the federal regulations that apply to covered entities. Apps with little regard for the patient's information may be able to convince users to share data which is not covered. The Cures Act Final ~~rule~~ still requires such an app to be from a certified developer.		# The app is not a HIPAA covered entity and is not bound by the federal regulations that apply to covered entities. Apps with little regard for the patient's information may be able to convince users to share data which is not covered. The Cures Act Final Rule (2020-05-01) still requires such an app to be from a certified developer.
	The above addresses information that starts out covered by HIPAA. Other data that is not initially covered includes in-home telemetry data and user entered data include patient approved medical directives.		The above addresses information that starts out covered by HIPAA. Other data that is not initially covered includes in-home telemetry data and user entered data include patient approved medical directives.
	====App as HIPAA covered entity====		====App as HIPAA covered entity====

Tomjones: /* Use of Native Apps to hold the patient's PHI */

2020-08-13T17:31:17Z

Use of Native Apps to hold the patient's PHI

← Older revision		Revision as of 17:31, 13 August 2020
Line 110:		Line 110:
	===Use of [https://tcwiki.azurewebsites.net/index.php?title=Native_App Native Apps] to hold the patient's PHI===		===Use of [https://tcwiki.azurewebsites.net/index.php?title=Native_App Native Apps] to hold the patient's PHI===
	While there may be multiple ways to protect patient's PHI while in the user's possession, this paper explores two use cases.		While there may be multiple ways to protect patient's PHI while in the user's possession, this paper explores two use cases.
	#1 The app is considered to be a HIPAA covered entity and will only accept and disburse patient data to other covered entities. Exfiltration of data from this [[Trustworthy Healthcare Ecosystem]] is severely restricted, but still possible.		# The app is considered to be a HIPAA covered entity and will only accept and disburse patient data to other covered entities. Exfiltration of data from this [[Trustworthy Healthcare Ecosystem]] is severely restricted, but still possible. This case is explored on the wiki page [[Phone as Health Care Credential]].
	#2 The app is not a HIPAA covered entity and is not bound by the federal regulations that apply to covered entities. Apps with little regard for the patient's information may be able to convince users to share data which is not covered.		# The app is not a HIPAA covered entity and is not bound by the federal regulations that apply to covered entities. Apps with little regard for the patient's information may be able to convince users to share data which is not covered. The Cures Act Final rule still requires such an app to be from a certified developer.
	The above addresses information that starts out covered by HIPAA. Other data that is not initially covered includes in-home telemetry data and user entered data include patient approved medical directives.		The above addresses information that starts out covered by HIPAA. Other data that is not initially covered includes in-home telemetry data and user entered data include patient approved medical directives.
	====App as HIPAA covered entity====		====App as HIPAA covered entity====

Tomjones: /* External References */

2020-08-13T16:20:35Z

External References

← Older revision		Revision as of 16:20, 13 August 2020
Line 197:		Line 197:
	*[https://tcwiki.azurewebsites.net/index.php?title=Compliant_Implementation_of_Trust_Registry Compliant Implementation of Trust Registry]		*[https://tcwiki.azurewebsites.net/index.php?title=Compliant_Implementation_of_Trust_Registry Compliant Implementation of Trust Registry]
	*[https://tcwiki.azurewebsites.net/index.php?title=EHR Electronic Health Records - EHR]		*[https://tcwiki.azurewebsites.net/index.php?title=EHR Electronic Health Records - EHR]
	*[https://tcwiki.azurewebsites.net/index.php?title=FHIR FHIR]		*[https://tcwiki.azurewebsites.net/index.php?title=FHIR FHIR] (Fast Health Interoperability Resources) is designed to enable information exchange to support the provision of healthcare in a wide variety of settings.
	*[https://tcwiki.azurewebsites.net/index.php?title=FirstNet FirstNet]		*[https://tcwiki.azurewebsites.net/index.php?title=FirstNet FirstNet]
	*[https://tcwiki.azurewebsites.net/index.php?title=Health_Care_Digital_Identity Health Care Digital Identity]		*[https://tcwiki.azurewebsites.net/index.php?title=Health_Care_Digital_Identity Health Care Digital Identity]

Tomjones: /* App is not protected by HIPAA */

2020-03-14T16:59:33Z

App is not protected by HIPAA

← Older revision		Revision as of 16:59, 14 March 2020
Line 120:		Line 120:
	* Rules of consent to release data could be rigorously enforced and violator could be thrown out of the federation. All federation access would be verfied for every connection to any other federated entity.		* Rules of consent to release data could be rigorously enforced and violator could be thrown out of the federation. All federation access would be verfied for every connection to any other federated entity.

	====~~App is not protected by HIPAA~~====		====Smartphone Apps====
	~~Only~~ regular FTC protections for user private information apply.		Currently only regular FTC protections exists for user private information apply.
	* There is an effort to create a "Code of Conduct" for apps that can acquire PHI from an EHR that is in development by the CARIN alliance.		* There is an effort to create a "Code of Conduct" for apps that can acquire PHI from an EHR that is in development by the CARIN alliance.
	* It is not clear that if a large company, like Apple, created a Health app, would then decide not to agree to the code of conduct. Could they be excluded from access PHI given the access rules of the ONC?		* It is not clear that if a large company, like Apple, created a Health app, would then decide not to agree to the code of conduct. Could they be excluded from access PHI given the access rules of the ONC?
			* While there is a code of conduct proposed by the CARIN alliance, it has not yet been declared mandatory.
			* The solution for good, trustworthy [[Patient Choice]] is to bring the Smartphone apps into compliance with HIPAA if we really want patient data to be protected.

	===Recovery and Redress===		===Recovery and Redress===

Tomjones: /* Use of Native Apps to hold the patient's PHI */

2020-03-14T16:56:14Z

Use of Native Apps to hold the patient's PHI

← Older revision		Revision as of 16:56, 14 March 2020
Line 110:		Line 110:
	===Use of [https://tcwiki.azurewebsites.net/index.php?title=Native_App Native Apps] to hold the patient's PHI===		===Use of [https://tcwiki.azurewebsites.net/index.php?title=Native_App Native Apps] to hold the patient's PHI===
	While there may be multiple ways to protect patient's PHI while in the user's possession, this paper explores two use cases.		While there may be multiple ways to protect patient's PHI while in the user's possession, this paper explores two use cases.
	#1 The app is considered to be a HIPAA covered entity and will only accept and disburse patient data to other covered entities. Exfiltration of data from this [~~Trusted Federation~~] is severely restricted, but still possible.		#1 The app is considered to be a HIPAA covered entity and will only accept and disburse patient data to other covered entities. Exfiltration of data from this [[Trustworthy Healthcare Ecosystem]] is severely restricted, but still possible.
	#2 The app is not a HIPAA covered entity and is not bound by the federal regulations that apply to covered entities. Apps with little regard for the patient's information may be able to convince users to share data which is not covered.		#2 The app is not a HIPAA covered entity and is not bound by the federal regulations that apply to covered entities. Apps with little regard for the patient's information may be able to convince users to share data which is not covered.
	The above addresses information that starts out covered by HIPAA. Other data that is not initially covered includes in-home telemetry data and user entered data include patient approved medical directives.		The above addresses information that starts out covered by HIPAA. Other data that is not initially covered includes in-home telemetry data and user entered data include patient approved medical directives.

Tomjones: /* Digital Service Endpoints */

2020-03-14T16:54:12Z

Digital Service Endpoints

← Older revision		Revision as of 16:54, 14 March 2020
Line 34:		Line 34:
	* While there may be distinct services that are available at each endpoint, there will (nearly) always be multiple endpoint at one particular domain named service. The domain named service is most often available as a result of a [https://tcwiki.azurewebsites.net/index.php?title=DNS DNS] entry for the host name such as https://example.com. Which must responds to requests for metadata that describes it in well-known protocols and semantics.		* While there may be distinct services that are available at each endpoint, there will (nearly) always be multiple endpoint at one particular domain named service. The domain named service is most often available as a result of a [https://tcwiki.azurewebsites.net/index.php?title=DNS DNS] entry for the host name such as https://example.com. Which must responds to requests for metadata that describes it in well-known protocols and semantics.
	* These domain names and endpoints all belong to a single legal entity which is a member of the appropriate federation where the metadata may be examined.		* These domain names and endpoints all belong to a single legal entity which is a member of the appropriate federation where the metadata may be examined.
	* The issue of [[Trustworthy Healthcare Provider]]s is important for flows not only among members of the federation, but also among also flows to and from the patients and their ~~guardian.~~. Please see that wiki page for more details about the identification of [[Trustworthy Healthcare Provider]]s.		* The issue of [[Trustworthy Healthcare Provider]]s is important for flows not only among members of the federation, but also among also flows to and from the patients and their guardians. Please see that wiki page for more details about the identification of [[Trustworthy Healthcare Provider]]s.
	# Trust Registry - is an online Trust Anchor for information about medical providers that have met the appropriate operational criteria. All of the following endpoints will have trust certificates from a trust registry.		# Trust Registry - is an online Trust Anchor for information about medical providers that have met the appropriate operational criteria. All of the following endpoints will have trust certificates from a trust registry.
	# Credential Service Provider - is the glue between the user devices and the [[Covered Entities]] that perform identity proofing. It provides IAL2/AAL2 evidence that an App can act as the agent for the patient.		# Credential Service Provider - is the glue between the user devices and the [[Covered Entities]] that perform identity proofing. It provides IAL2/AAL2 evidence that an App can act as the agent for the patient.

Tomjones: /* Digital Service Endpoints */

2020-03-14T16:53:23Z

Digital Service Endpoints

← Older revision		Revision as of 16:53, 14 March 2020
Line 34:		Line 34:
	* While there may be distinct services that are available at each endpoint, there will (nearly) always be multiple endpoint at one particular domain named service. The domain named service is most often available as a result of a [https://tcwiki.azurewebsites.net/index.php?title=DNS DNS] entry for the host name such as https://example.com. Which must responds to requests for metadata that describes it in well-known protocols and semantics.		* While there may be distinct services that are available at each endpoint, there will (nearly) always be multiple endpoint at one particular domain named service. The domain named service is most often available as a result of a [https://tcwiki.azurewebsites.net/index.php?title=DNS DNS] entry for the host name such as https://example.com. Which must responds to requests for metadata that describes it in well-known protocols and semantics.
	* These domain names and endpoints all belong to a single legal entity which is a member of the appropriate federation where the metadata may be examined.		* These domain names and endpoints all belong to a single legal entity which is a member of the appropriate federation where the metadata may be examined.
	* The issue of [[Trustworthy Healthcare Provider]]s is important for flows not only among members of the federation, but also among their ~~will participants~~. Please see that wiki page for more ~~detains~~ about the identification of [[Trustworthy Healthcare Provider]]s.		* The issue of [[Trustworthy Healthcare Provider]]s is important for flows not only among members of the federation, but also among also flows to and from the patients and their guardian.. Please see that wiki page for more details about the identification of [[Trustworthy Healthcare Provider]]s.
	# Trust Registry - is an online Trust Anchor for information about medical providers that have met the appropriate operational criteria. All of the following endpoints will have trust certificates from a trust registry.		# Trust Registry - is an online Trust Anchor for information about medical providers that have met the appropriate operational criteria. All of the following endpoints will have trust certificates from a trust registry.
	# Credential Service Provider - is the glue between the user devices and the [[Covered Entities]] that perform identity proofing. It provides IAL2/AAL2 evidence that an App can act as the agent for the patient.		# Credential Service Provider - is the glue between the user devices and the [[Covered Entities]] that perform identity proofing. It provides IAL2/AAL2 evidence that an App can act as the agent for the patient.
Line 41:		Line 41:
	# Payment Provider - can a part of both the patient proofing and patient authentication processes in most practices. At least one service will list covered solutions and indicate if the patient has co-pays that they need to make. This class of service endpoint also includes payment sources, like credit cards.		# Payment Provider - can a part of both the patient proofing and patient authentication processes in most practices. At least one service will list covered solutions and indicate if the patient has co-pays that they need to make. This class of service endpoint also includes payment sources, like credit cards.
	# Medical Record Locator Service - is a source for the patient or trusted providers to search for records about the patient. It has yet to be fully specified, but is assumed to exist.		# Medical Record Locator Service - is a source for the patient or trusted providers to search for records about the patient. It has yet to be fully specified, but is assumed to exist.

	===Legally Mandated Access===		===Legally Mandated Access===
	US Federal Regulations (CFRs) place burdens on the covered medical entities to provided PHI to the patient (or legal guardian). [https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html Individuals’ Right under HIPAA to Access their Health Information 45 CFR § 164.524] are filled with dense descriptions that are meant to clarify the obligations of the medical entity, but do not mention trust in any form. They do describe verification in these terms: <blockquote>The Privacy Rule requires a covered entity to take reasonable steps to verify the identity of an individual making a request for access. See 45 CFR 164.514(h). The Rule does not mandate any particular form of verification (such as obtaining a copy of a driver’s license), but rather generally leaves the type and manner of the verification to the discretion and professional judgment of the covered entity, provided the verification processes and measures do not create barriers to or unreasonably delay the individual from obtaining access to her PHI, as described below. Verification may be done orally or in writing and, in many cases, the type of verification may depend on how the individual is requesting and/or receiving access – whether in person, by phone (if permitted by the covered entity), by faxing or e-mailing the request on the covered entity’s supplied form, by secure web portal, or by other means. For example, if the covered entity requires that access requests be made on its own supplied form, the form could ask for basic information about the individual that would enable the covered entity to verify that the person requesting access is the subject of the information requested or is the individual’s personal representative. For those covered entities providing individuals with access to their PHI through web portals, those portals should already be set up with appropriate authentication controls, as required by [https://www.law.cornell.edu/cfr/text/45/164.312 45 CFR 164.312(d) of the HIPAA Security Rule], to ensure that the person seeking access is the individual or the individual’s personal representative.</blockquote>		US Federal Regulations (CFRs) place burdens on the covered medical entities to provided PHI to the patient (or legal guardian). [https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html Individuals’ Right under HIPAA to Access their Health Information 45 CFR § 164.524] are filled with dense descriptions that are meant to clarify the obligations of the medical entity, but do not mention trust in any form. They do describe verification in these terms: <blockquote>The Privacy Rule requires a covered entity to take reasonable steps to verify the identity of an individual making a request for access. See 45 CFR 164.514(h). The Rule does not mandate any particular form of verification (such as obtaining a copy of a driver’s license), but rather generally leaves the type and manner of the verification to the discretion and professional judgment of the covered entity, provided the verification processes and measures do not create barriers to or unreasonably delay the individual from obtaining access to her PHI, as described below. Verification may be done orally or in writing and, in many cases, the type of verification may depend on how the individual is requesting and/or receiving access – whether in person, by phone (if permitted by the covered entity), by faxing or e-mailing the request on the covered entity’s supplied form, by secure web portal, or by other means. For example, if the covered entity requires that access requests be made on its own supplied form, the form could ask for basic information about the individual that would enable the covered entity to verify that the person requesting access is the subject of the information requested or is the individual’s personal representative. For those covered entities providing individuals with access to their PHI through web portals, those portals should already be set up with appropriate authentication controls, as required by [https://www.law.cornell.edu/cfr/text/45/164.312 45 CFR 164.312(d) of the HIPAA Security Rule], to ensure that the person seeking access is the individual or the individual’s personal representative.</blockquote>

Tomjones: /* Next Steps */

2019-10-01T15:36:32Z

Next Steps

← Older revision		Revision as of 15:36, 1 October 2019
Line 157:		Line 157:
	==Next Steps==		==Next Steps==
	The order and extent of these items is currently arbitrary and pending review by industry experts.		The order and extent of these items is currently arbitrary and pending review by industry experts.
	# Approve broad plan for proceeding.		# Approve broad plan for proceeding including sources of funding.
	# Create a Patient experience set of use cases to be tested (as a part of a broader conformance verification)		# Create a Patient experience set of use cases to be tested (as a part of a broader conformance verification)
	# Establish a specific plan for the sand box. (roughly to build components that correspond to the labels in the diagram above.)		# Establish a specific plan for the sand box. (roughly to build components that correspond to the labels in the diagram above.)