Patient Consent

From IDESG Wiki
Jump to navigation Jump to search

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.

Context

  • Note that for the broader concept of Patient Consent as 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.
  • 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.
  • 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.:
  1. Simple app: patient/Patient.read, patient/Observation.read (There are LOTS of observable in the patient record. )
  2. 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.)
  3. ePrescribing app: patient/MedicationOrder.write (note that a pre step would be needed to read patient history and allergies.)
  4. 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.

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.
  • 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 when providing data to some other provider.
  • This list applies exclusively to the list of options that the patient is given when information is to be transferred from one EHR to another.
  • Note that some items may be removed from the list of data to be transferred, but others may be required based on the purpose of the request for information.
  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 (if known)
  11. 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.
  1. gender identification
  2. sexually transmitted diseases
  3. Physical threat
  4. 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, PHARMACIST etc.
  • Other data that might be in the EHR but might not be part of a routine request for patient consent.
  1. Care Coordination Team
  2. Current/Most Recent visit (with details?)
  3. Patient demographics
  4. Directives Wills
  5. Exclusiions - physicians to be avoided

Notifications

Users have the right to be notified whenever:

  1. Emergency access is granted to their data. ( Both ETREAT = EMT/ER and DISASTER = break the glass;)
  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

Retrieved from "https://wiki.idesg.org/index.php?title=Patient_Consent&oldid=15801"