Patient Consent

Full Title

Patient Consent is a special case of User Consent that applies to health care.

Context

• 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.
• Any solution must address the needs the the whole of the affect population. In this page we assume the population that are asked for consent speaks and reads English and has at least an 8th grade education.
• Accessibility by any member of the population addressed is to be accommodated.

Problems

• Most of the developers dealing with User Consent heretofore have focused on the problem of satisfying the legal challenges faced by the Enterprise that is asking for consent.
• FHIR addresses Resource Consent which includes the following on Privacy Consent Directive (PCD).

  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.

• 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.

Solutions

• To meet the needs for a FHIR consent record the following items are required:

1. status {draft | proposed | active | rejected | inactive | entered-in-error} --> this page will assume that rejected covers the case of the user later changing their consent to none.
2. scope {ADR | research | privacy | treatment}. --> this page will focus on exclusively on privacy although some consideration of research might be considered. (In any case we should avoid any alternate use of the term "scope"
3. consent-action {Collect | Access | Use | Disclose | Correct}. --> this page will assume the join Collect + Access + Use + Disclose as the only case to address
4. purpose is a wide ranging list that is not germain to this page. We should probably avoid use the the term "purpose" for other fields. We may be able to assume the code will alway be HOPERAT = To perform one or more operations on information used for conducting administrative and contractual activities related to the provision of health care.
5. dataPeriod may by include in our data collection.

References

• Health_IT_Record_Location_Service_(Data_Aggregation)#Use_Case_Details
• IHE Basic Patient Privacy Consents (BPPC)