Potential Consent Solution to Some Permission Use Cases

[sherryyuan-gcp]

To better understand the benefit of having permission (and whether we should support certain use cases?), this issue try to list of some Consent solution to Permission use cases. Some of them are questions on alternatives and purposes.

Note the following assumes we can define an extension for Consent to apply to store scope instead of patient compartment scope. (i.e allows Admin consents)

Use case 1: Allow notion of group (allow all member of CareTeam to access)

Consent solution: we can enumerate through all actors and give them individual accesses.

On an unrelated note: If a member left the CareTeam, it potentially affect many resources that were previously permitted/denied by this access. Depending on the system, it may raise scalability issues.

Use case 2: Allow patients to access their own data

Consent solution: The implementor of the store may choose to always enforce a Consent that allows each patient to access their own data.

Use case 3: Allow patient's related parties to access their data.

Consent solution: enumerate through each related party and since a patient's most likely don't have much related parties and the related parties don't change very often (e.g. family, spouse etc).

Use case 4: Grant public health authorities to some information

Consent solution: when the patient/subject field is empty, assume this will apply to all the resources in the store. Then we can reuse Consent to define such rule.

Use case 5: Access data to specific sensitivity code

Consent solution: we can tag the resource and use extension to apply Consent on data with specific tags.

Use case 6: Limit under which restriction is data released

Consent solution: Consent with restriction on which data is in the scope of enforcement. Can support consent extension that allows enforcing data with specific tags.

Use case 7: Restrict who can use specific Purpose of Use

This seems to be something that can be restricted in the OAuth UI instead of via a permission.

Use case 8: Use permission to enforce rules on when the AuditEvent/Provenance should be generated

+1 to KC, this seems outside of the scope of Permission (it looks more like a policy)

Use case 9: Support vhDir

Consent solution: We can support consent to enforce access on specific tags. and tag these directories.

Use case 10: PERMIT carry extra obligation to deid certain values

Currently there is no consent solution, but it may raise scalability concerns in certain systems because it add extra post-processing to the requests. Can user perform de-identification for the whole store and redirect the traffic base on who is accessing.

Use case 11: Use permission on OAuth Introspection API

Is there any reason why we couldn’t use consent on this? with some extension value on Consent to make it non-patient specific?

[costateixeira]

I don't understand this proposal - is this showing that we can force patients(?) to give some consent? That is exactly what this is trying to avoid. Or maybe to tweak the Consent resource to do something it is not meant to do?

To clarify, the Permission resource expresses policies and rules that may travel with the data or be part of actor's capabilities, regardless of Consent . Consent may be instantiation of some of these permissions - although normally if the rules exist, there's no need to create a Consent resource that says "I agree to follow the rule".
These use cases are normally metadata that the patient doesn't need to worry about - sometimes they should not be consulted or informed. For example policies. Or just legal dispositions.

In several places (GDPR), Patient-granted is arguably NOT the most important justification for data processing. Others are more important.

To explain the need for a non-consent-based expression of allowance, here are some comments:

Use case 1: Allow notion of group (allow all member of CareTeam to access)

Consent solution: we can enumerate through all actors and give them individual accesses.

Who would enumerate those? Who is the person that would go through all actors? That would indeed be a consent but that is not what this expresses. Also, what if the team changes? Here, Permission (or, if Patient-granted, Consent) to a Group or role, allows exactly to say "Regardless of who is in the team at a given moment, this patient's care plan can be seen by the care team". or "In this country, Pharmacists can read but not write prescriptions".

On an unrelated note: If a member left the CareTeam, it potentially affect many resources that were previously permitted/denied by this access. Depending on the system, it may raise scalability issues.

Right. Permission expresses the rules, not necessarily their instanciation.

Use case 2: Allow patients to access their own data

Consent solution: The implementor of the store may choose to always enforce a Consent that allows each patient to access their own data.

Also here, yes, but we are expressing that "All patients shall be able to see their data unless condition A and condition B", not instantiating that for a patient P.

Use case 3: Allow patient's related parties to access their data.

Consent solution: enumerate through each related party and since a patient's most likely don't have much related parties and the related parties don't change very often (e.g. family, spouse etc).

Same here. you can implement and instantiate Consents based on Permission (not sure why) but that is not what we are transmitting.

Use case 4: Grant public health authorities to some information

Consent solution: when the patient/subject field is empty, assume this will apply to all the resources in the store. Then we can reuse Consent to define such rule.

Also this is how it would be instantiated (not sure I agree), but Permission is to express the rules for that. A Permission resource here would say "In this hospital, all TB data is transmitted to central database, don't bother asking the patient, we don't need a consent"

Use case 5: Access data to specific sensitivity code

Consent solution: we can tag the resource and use extension to apply Consent on data with specific tags.

also here, instantiation is not what we look for.

Use case 6: Limit under which restriction is data released

Consent solution: Consent with restriction on which data is in the scope of enforcement. Can support consent extension that allows enforcing data with specific tags.

Same as above.

Use case 7: Restrict who can use specific Purpose of Use

This seems to be something that can be restricted in the OAuth UI instead of via a permission.

Right, that is the technical how it could be implemented. But how do we say "Data for insurance review is not allowed unless patient consents"? How do 2 developers on opposite ends of the transmission check what rules they need to follow? That is the purpose of Consent.

Use case 8: Use permission to enforce rules on when the AuditEvent/Provenance should be generated

+1 to KC, this seems outside of the scope of Permission (it looks more like a policy)

Yes , that is what Permission is trying to do

Use case 9: Support vhDir

Consent solution: We can support consent to enforce access on specific tags. and tag these directories.

Consent issued by whom? Asking the patient? Also same issue as above.

Use case 10: PERMIT carry extra obligation to deid certain values

Currently there is no consent solution, but it may raise scalability concerns in certain systems because it add extra post-processing to the requests. Can user perform de-identification for the whole store and redirect the traffic base on who is accessing.

Use case 11: Use permission on OAuth Introspection API

Is there any reason why we couldn’t use consent on this? with some extension value on Consent to make it non-patient specific?

[sherryyuan-gcp]

Thanks for your input.

I don't understand this proposal - is this showing that we can force patients(?) to give some consent?

To clarify, most of the consent usage here assumes we defined an "admin" extension and require the Consent resource's patient/subject field to be empty. So whenever the admin extension is present, that consent will apply to whole store scope (rather than patient compartment scope) by default.

I will answer some of the use case in a separate comment.

[sherryyuan-gcp]

For expressing Allow patients to access their own data how would an example permission look like? I agree this is a gap of patient consent since it would be a bad idea to create a consent on patient's behalf.

But what if we can ask patient directly to grant themselves to their own data (for each patient)?

#usecase2