Patient Consent

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.

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

• Where the patient consent is requested, the choices must be simple an transparent. The exist FHIR consent spec may, or may not, be appropriate, but it could be a beginning point.
• To meet the needs for a FHIR consent record the following items are required (note that patient empowerment does not seem to have been considered, so modification is a distinct possibility):

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. One option is to expand this to meet the patient's needs.
   1. For now assume the code 1 will always be HOPERAT = To perform one or more operations on information used for conducting administrative and contractual activities related to the provision of health care.
   2. Second level - PATSFTY = patient safety; HRESCH = research; PATREQ = patient request (there are subcategories for Guardian etc, not clear if that is useful); DISASTER = break the glass; TREAT = normal; ETREAT = EMT/ER
   3. Unfortunately, none of this is helpful for the patient, so we may need extension that relate to the scope of data required (as opposed to requested) like: SCRIPT = requester needs meds, allergies etc.
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.

Patient Data Categories

• Here is a start at creating a list of categories that the user might be able to choose from.

1. Allergies
2. Medications
3. Immunizations
4. Procedures/operations
5. Medical Devices
6. Medical Implants
7. Patient Medical History
8. Patient Goals and concerns
9. Patient assessment/Treatment plan
10. Primary Physician
11. Family Medical History
12. gender identification
13. sexually transmitted diseases
14. Physical threat
15. Mental Health

• One alternate might be to list the role of the requestor and a list of the data they need to perform their function. - see the SCRIPT above - others could be THERAPY, EYE, DENTIST, etc.
• Other data that might be in the EHR

1. Care Coordination Team
2. Current/Most Recent visit (with details?)
3. Directives Wills
4. Exclusiions - physicians to be avoided

Notifications

Users have the right to be notified whenever:

1. Emergency access is granted to their data.
2. When another covered entity starts to store or access any PHI. (The assumption is that the patient approved updates.)
3. When a breach occurs that allows unauthorized access to their PHI.

References

• Wiki page Health_IT_Record_Location_Service_(Data_Aggregation)#Use_Case_Details
• Wiki page Patient Choice.
• 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.
• User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization provides consent to the Authorization Server to release user PHII.
• Health Relationship Trust Profile for User-Managed Access 2.0 addresses specific health related issues