Patient Consent - Revision history

Tomjones: /* Problems */

2021-03-20T22:38:39Z

Problems

← Older revision		Revision as of 22:38, 20 March 2021
Line 15:		Line 15:
	*Consent management - particularly privacy consent - is complicated by the fact that consent to share is often itself necessary to protect. The need to protect the privacy of the privacy statement itself competes with the execution of the consent statement. For this reason, it is common to deal with 'consent statements' that are only partial representations of the full consent statement that the patient provided. For this reason, the consent resource contains two elements that refer back to the source: a master identifier, and a direct reference to content from which this Consent Statement was derived.		*Consent management - particularly privacy consent - is complicated by the fact that consent to share is often itself necessary to protect. The need to protect the privacy of the privacy statement itself competes with the execution of the consent statement. For this reason, it is common to deal with 'consent statements' that are only partial representations of the full consent statement that the patient provided. For this reason, the consent resource contains two elements that refer back to the source: a master identifier, and a direct reference to content from which this Consent Statement was derived.
	* An example of a FHIR consent scope is patient/immunizatin.read which breaks down as the subject, the FHIR resource and the type of access. Examples show that this can get really complex.:		* An example of a FHIR consent scope is patient/immunizatin.read which breaks down as the subject, the FHIR resource and the type of access. Examples show that this can get really complex.:
	# Simple app: patient/Patient.read, patient/Observation.read		# Simple app: patient/Patient.read, patient/Observation.read (There are LOTS of observable in the patient record. )
	# Complex app:patient/*.read. { This just provides access to ALL DATA, which should not be needed in all cases. Note that patient's do not actually have access to ALL DATA. Expemptions do exist.)		# Complex app:patient/*.read. { This just provides access to ALL DATA, which should not be needed in all cases. Note that patient's do not actually have access to ALL DATA. Expemptions do exist.)
	# ePrescribing app: patient/MedicationOrder.write (note that a pre step would be needed to read patient history and allergies.)		# ePrescribing app: patient/MedicationOrder.write (note that a pre step would be needed to read patient history and allergies.)

Tomjones: /* Problems */

2021-03-20T22:37:47Z

Problems

← Older revision		Revision as of 22:37, 20 March 2021
Line 16:		Line 16:
	* An example of a FHIR consent scope is patient/immunizatin.read which breaks down as the subject, the FHIR resource and the type of access. Examples show that this can get really complex.:		* An example of a FHIR consent scope is patient/immunizatin.read which breaks down as the subject, the FHIR resource and the type of access. Examples show that this can get really complex.:
	# Simple app: patient/Patient.read, patient/Observation.read		# Simple app: patient/Patient.read, patient/Observation.read
	# Complex app:patient/*.read		# Complex app:patient/*.read. { This just provides access to ALL DATA, which should not be needed in all cases. Note that patient's do not actually have access to ALL DATA. Expemptions do exist.)
	# ePrescribing app: patient/MedicationOrder.write (note that a pre step would be needed to read patient history and allergies.)		# ePrescribing app: patient/MedicationOrder.write (note that a pre step would be needed to read patient history and allergies.)
	# Population health app: user/*.read. (this one is particularly interesting in that the "user" could be defined to be a role like: prescriber, eye doctor, physical therapist, that would have a list of data expected to be available.		# Population health app: user/*.read. (this one is particularly interesting in that the "user" could be defined to be a role like: prescriber, eye doctor, physical therapist, that would have a list of data expected to be available.

Tomjones: /* Problems */

2021-03-20T22:36:05Z

Problems

← Older revision		Revision as of 22:36, 20 March 2021
Line 18:		Line 18:
	# Complex app:patient/*.read		# Complex app:patient/*.read
	# ePrescribing app: patient/MedicationOrder.write (note that a pre step would be needed to read patient history and allergies.)		# ePrescribing app: patient/MedicationOrder.write (note that a pre step would be needed to read patient history and allergies.)
	# Population health app: user/*.read		# Population health app: user/*.read. (this one is particularly interesting in that the "user" could be defined to be a role like: prescriber, eye doctor, physical therapist, that would have a list of data expected to be available.
	* There has been no research on the user experience about patient consent that we have been able to discover, but it is certain that very few patients could understand most FHIR resources.		* There has been no research on the user experience about patient consent that we have been able to discover, but it is certain that very few patients could understand most FHIR resources.

Tomjones: /* Problems */

2021-03-20T20:34:34Z

Problems

← Older revision		Revision as of 20:34, 20 March 2021
Line 17:		Line 17:
	# Simple app: patient/Patient.read, patient/Observation.read		# Simple app: patient/Patient.read, patient/Observation.read
	# Complex app:patient/*.read		# Complex app:patient/*.read
	# ePrescribing app: patient/MedicationOrder.write (~~not~~ that a pre step would be needed to read patient history and allergies.)		# ePrescribing app: patient/MedicationOrder.write (note that a pre step would be needed to read patient history and allergies.)
	# Population health app: user/*.read		# Population health app: user/*.read
	* There has been no research on the user experience about patient consent that we have been able to discover, but it is certain that very few patients could understand most FHIR resources.		* There has been no research on the user experience about patient consent that we have been able to discover, but it is certain that very few patients could understand most FHIR resources.

Tomjones: /* Problems */

2021-03-20T20:33:42Z

Problems

← Older revision		Revision as of 20:33, 20 March 2021
Line 14:		Line 14:
	* [https://hl7.org/fhir/2018Jan/consent.html FHIR addresses Resource Consent] which includes the following on [https://hl7.org/fhir/2018Jan/consent.html#PCD Privacy Consent Directive (PCD)]. <blockquote>Privacy policies define how Individually Identifiable Health Information (IIHI) is to be collected, accessed, used and disclosed. A Privacy Consent Directive as a legal record of a patient's (e.g. a healthcare consumer) agreement with a party responsible for enforcing the patient's choices, which permits or denies identified actors or roles to perform actions affecting the patient within a given context for specific purposes and periods of time. All consent directives have a policy context, which is any set of organizational or jurisdictional policies which may limit the consumer’s policy choices, and which include a named range of actions allowed. In addition, Privacy Consent Directives provide the ability for a healthcare consumer to delegate authority to a Substitute Decision Maker who may act on behalf of that individual. Alternatively, a consumer may author/publish their privacy preferences as a self-declared Privacy Consent Directive.</blockquote>		* [https://hl7.org/fhir/2018Jan/consent.html FHIR addresses Resource Consent] which includes the following on [https://hl7.org/fhir/2018Jan/consent.html#PCD Privacy Consent Directive (PCD)]. <blockquote>Privacy policies define how Individually Identifiable Health Information (IIHI) is to be collected, accessed, used and disclosed. A Privacy Consent Directive as a legal record of a patient's (e.g. a healthcare consumer) agreement with a party responsible for enforcing the patient's choices, which permits or denies identified actors or roles to perform actions affecting the patient within a given context for specific purposes and periods of time. All consent directives have a policy context, which is any set of organizational or jurisdictional policies which may limit the consumer’s policy choices, and which include a named range of actions allowed. In addition, Privacy Consent Directives provide the ability for a healthcare consumer to delegate authority to a Substitute Decision Maker who may act on behalf of that individual. Alternatively, a consumer may author/publish their privacy preferences as a self-declared Privacy Consent Directive.</blockquote>
	*Consent management - particularly privacy consent - is complicated by the fact that consent to share is often itself necessary to protect. The need to protect the privacy of the privacy statement itself competes with the execution of the consent statement. For this reason, it is common to deal with 'consent statements' that are only partial representations of the full consent statement that the patient provided. For this reason, the consent resource contains two elements that refer back to the source: a master identifier, and a direct reference to content from which this Consent Statement was derived.		*Consent management - particularly privacy consent - is complicated by the fact that consent to share is often itself necessary to protect. The need to protect the privacy of the privacy statement itself competes with the execution of the consent statement. For this reason, it is common to deal with 'consent statements' that are only partial representations of the full consent statement that the patient provided. For this reason, the consent resource contains two elements that refer back to the source: a master identifier, and a direct reference to content from which this Consent Statement was derived.
			* An example of a FHIR consent scope is patient/immunizatin.read which breaks down as the subject, the FHIR resource and the type of access. Examples show that this can get really complex.:
			# Simple app: patient/Patient.read, patient/Observation.read
			# Complex app:patient/*.read
			# ePrescribing app: patient/MedicationOrder.write (not that a pre step would be needed to read patient history and allergies.)
			# Population health app: user/*.read
			* There has been no research on the user experience about patient consent that we have been able to discover, but it is certain that very few patients could understand most FHIR resources.

	==Solutions==		==Solutions==
	* Where the patient consent is requested, the choices must be simple and transparent. The exist FHIR consent spec may, or may not, be appropriate, but it could be a beginning point.		* Where the patient consent is requested, the choices must be simple and transparent. The exist FHIR consent spec may, or may not, be appropriate, but it could be a beginning point.

Tomjones at 22:06, 25 October 2020

2020-10-25T22:06:36Z

← Older revision		Revision as of 22:06, 25 October 2020
Line 1:		Line 1:
	==Full Title==		==Full Title==
	[[Patient Consent]] is a special case of [[User Consent]] that for [[IDEF Glossary DIGITAL IDENTITY MANAGEMENT FUNCTIONS\|Identity Management]] applies to release of health care information and notifications of changes to the information and access privileges.		[[Patient Consent]] is a special case of [[User Consent]] that for [[IDEF Glossary DIGITAL IDENTITY MANAGEMENT FUNCTIONS\|Identity Management]] applies to release of health care information and notifications of changes to the information and access privileges.

	Note that for the broader concept of [[Patient Consent]] as [https://hl7.org/fhir/consent.html described by FHIR as Resource Consent] applies to a broader range of Healthcare Options which might be processed together with PII consent, or not.

	==Context==		==Context==
			* Note that for the broader concept of [[Patient Consent]] as [https://hl7.org/fhir/consent.html described by FHIR as Resource Consent] applies to a broader range of Healthcare Options which might be processed together with PII consent, or not.
	* Most of the context from the [[User Consent]] is applicable here.		* Most of the context from the [[User Consent]] is applicable here.
	* In this page we address the special problem with healthcare as well as the problem of building the data taxonomy in such a manner that the user can actually understand the questions asked of them.		* In this page we address the special problem with healthcare as well as the problem of building the data taxonomy in such a manner that the user can actually understand the questions asked of them.

Tomjones: /* Full Title */

2020-10-25T22:05:43Z

Full Title

← Older revision		Revision as of 22:05, 25 October 2020
Line 2:		Line 2:
	[[Patient Consent]] is a special case of [[User Consent]] that for [[IDEF Glossary DIGITAL IDENTITY MANAGEMENT FUNCTIONS\|Identity Management]] applies to release of health care information and notifications of changes to the information and access privileges.		[[Patient Consent]] is a special case of [[User Consent]] that for [[IDEF Glossary DIGITAL IDENTITY MANAGEMENT FUNCTIONS\|Identity Management]] applies to release of health care information and notifications of changes to the information and access privileges.

	Note that for the broader concept of [[Patient Consent]] as [https://hl7.org/fhir/consent.html described by FHIR as Resource Consent] ~~applied~~ to a broader range of Healthcare Options.		Note that for the broader concept of [[Patient Consent]] as [https://hl7.org/fhir/consent.html described by FHIR as Resource Consent] applies to a broader range of Healthcare Options which might be processed together with PII consent, or not.

	==Context==		==Context==

Tomjones: /* Full Title */

2020-10-25T21:55:11Z

Full Title

← Older revision		Revision as of 21:55, 25 October 2020
Line 1:		Line 1:
	==Full Title==		==Full Title==
	[[Patient Consent]] is a special case of [[User Consent]] that for [[Identity Management]] applies to release of health care information and notifications of changes to the information and access privileges.		[[Patient Consent]] is a special case of [[User Consent]] that for [[IDEF Glossary DIGITAL IDENTITY MANAGEMENT FUNCTIONS\|Identity Management]] applies to release of health care information and notifications of changes to the information and access privileges.

	Note that for the broader concept of [[Patient Consent]] as [https://hl7.org/fhir/consent.html described by FHIR as Resource Consent] applied to a broader range of Healthcare Options.		Note that for the broader concept of [[Patient Consent]] as [https://hl7.org/fhir/consent.html described by FHIR as Resource Consent] applied to a broader range of Healthcare Options.

Tomjones: /* Full Title */

2020-10-25T18:03:12Z

Full Title

← Older revision		Revision as of 18:03, 25 October 2020
Line 1:		Line 1:
	==Full Title==		==Full Title==
	[[Patient Consent]] is a special case of [[User Consent]] that applies to release of health care information and notifications of changes to the information and access privileges.		[[Patient Consent]] is a special case of [[User Consent]] that for [[Identity Management]] applies to release of health care information and notifications of changes to the information and access privileges.

			Note that for the broader concept of [[Patient Consent]] as [https://hl7.org/fhir/consent.html described by FHIR as Resource Consent] applied to a broader range of Healthcare Options.

	==Context==		==Context==

Tomjones: /* Patient Data Categories */

2020-04-23T21:32:54Z

Patient Data Categories

← Older revision		Revision as of 21:32, 23 April 2020
Line 47:		Line 47:
	# Primary Physician (if known)		# Primary Physician (if known)
	#Family Medical History		#Family Medical History
			*The following elements, also included in the EHR, are not often released, but seem to be covered by the requirement to let patients see their own data.
	# gender identification		# gender identification
	# sexually transmitted diseases		# sexually transmitted diseases