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.
• Patient notifications are not included in this page.

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 be included in our data collection.
6. role could be useful if it can help determine what data should be forwarded. Unfortunately the choices given are not helpful for that purpose.

• Data collected from the user needs to always be in two waves.

1. The user receives evidence that a website is HIPAA compliant and agrees to create a record at the website, which requires some sort of {subjectID, notification address} just to comply with the terms of privacy regulations.
   1. At this time it would be convenient to also supply sufficient information for the site to know that the user had been identity proofed to IAL2 and the the user device is capable of AAL2 authentication protections.
2. Only after such a relationship has been establish the website can ask the user for access to healthcare data. (n.b. These could be combined in one operation if the circumstances warranted.)

• At this point the user needs to be give a list of healthcare data that they are willing to supply. It would be helpful if the website presented the user with the data categories desired along with indication if the fields were "essential" so that the user could know which could be removed.
• It would be a UX consideration to think that the data categories that were "essential" could not be unchecked to avoid the problem of the user supplying data to the site that was not sufficient to continue the relationship.
• Before the website created data on its own about the user (lab tests, etc.) the user would be allowed to delete the record. After that time the user would be allowed to "deactivate" the record, whatever that might mean.
• Here is a start at creating a list of categories that the user might be able to choose from.

1. gender identification
2. sexually transmitted diseases

• One alternate might be to list the role of the requestor and a list of the data they need to perform their function.

References

• Health_IT_Record_Location_Service_(Data_Aggregation)#Use_Case_Details
• IHE Basic Patient Privacy Consents (BPPC)
• High Assurance ID Token shows a possible format to convey this data from the user (or information endpoint) to the website.