Difference between revisions of "Consent Management"
(→HealthCare) |
(→HealthCare) |
||
| Line 23: | Line 23: | ||
===HealthCare=== | ===HealthCare=== | ||
There are two types of consent involved, consent to access user information and consent to preform a medical procedure. This sections is entirely about the former. | There are two types of consent involved, consent to access user information and consent to preform a medical procedure. This sections is entirely about the former. | ||
| − | * [[FHIR]] provides a [http://www.hl7.org/fhir/consent.html resource consent] which create a "record of a healthcare consumer’s choices, which permits or denies identified recipient(s) or recipient role(s) to perform one or more actions within a given policy context, for specific purposes and periods of time." | + | * [[FHIR]] provides a [http://www.hl7.org/fhir/consent.html resource consent] which create a "record of a healthcare consumer’s choices, which permits or denies identified recipient(s) or recipient role(s) to perform one or more actions within a given policy context, for specific purposes and periods of time." It appears that this was designed solely to enable access to a FHIR CURD API. |
==References== | ==References== | ||
Revision as of 15:25, 13 February 2022
Full Title or Meme
The process of acquiring, refreshing, managing and deleting User Consent to access User Private Information and other resources.
Context
The primary consideration is the collection of consent from the user, but the need for Recovery, Redress and simple maintenance by the user must be addressed as well.
The EU has already addressed the collection of consent in some guidance.[1] That guidance was based on the following paragraphs 42 and 43 of the GDPR.
Where processing is based on the data subject's consent, the controller should be able to demonstrate that the data subject has given consent to the processing operation. In particular in the context of a written declaration on another matter, safeguards should ensure that the data subject is aware of the fact that and the extent to which consent is given. In accordance with Council Directive 93/13/EEC1 a declaration of consent pre-formulated by the controller should be provided in an intelligible and easily accessible form, using clear and plain language and it should not contain unfair terms. For consent to be informed, the data subject should be aware at least of the identity of the controller and the purposes of the processing for which the personal data are intended. Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment.
In order to ensure that consent is freely given, consent should not provide a valid legal ground for the processing of personal data in a specific case where there is a clear imbalance between the data subject and the controller, in particular where the controller is a public authority and it is therefore unlikely that consent was freely given in all the circumstances of that specific situation. Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance.
The Office of the Privacy Commissioner of Canada has published Guidelines for obtaining meaningful consent[2] which "sets out practical and actionable guidance regarding what organizations should do to ensure that they obtain meaningful consent."
Problems
It's easy to say that the user should have control of their own data, it's hard to create a User Experience which enables such control in a manner that does not result in Cognitive Overload for the User.
Solutions
Just a list of some of the factors to address:
- Make sure that there is a list of the data types that can be displayed to the user when asking for consent. Too many details will not be helpful, so the categories need to be broad, yet not confusing, for example, don't ask the user for consent to have their street, then their city, then their state, etc., just ask for consent for the mailing address.
- The User Consent page should have check boxes for each data type that may be pre-filled by the Web Site, but under control of the user. Some legislation requires the Web Site to tell the user which types are mandatory, but in any case the site should be able to continue to function for the user if some types are unchecked. Clearly a mailing address will be required if the user wants to have a package mailed to them, but not if they are getting online delivery. Asking for a billing address if a credit card is used is not required, but some sites will not work if it is not provided. That behavior is now illegal in some jurisdictions.
HealthCare
There are two types of consent involved, consent to access user information and consent to preform a medical procedure. This sections is entirely about the former.
- FHIR provides a resource consent which create a "record of a healthcare consumer’s choices, which permits or denies identified recipient(s) or recipient role(s) to perform one or more actions within a given policy context, for specific purposes and periods of time." It appears that this was designed solely to enable access to a FHIR CURD API.
References
- ↑ EU Commission, How should my consent be requested? https://ec.europa.eu/info/law/law-topic/data-protection/reform/rights-citizens/how-my-personal-data-protected/how-should-my-consent-be-requested_en
- ↑ Privacy Commissioner of Canada, Guidelines for obtaining meaningful consent. https://www.priv.gc.ca/en/privacy-topics/collecting-personal-information/consent/gl_omc_201805/
