Stream: Security and Privacy
Topic: Individual access control to resource
Heath Frankel (Jan 31 2022 at 06:35):
I have a requirement to specify an access control list of individuals that can access DocumentReference resources, each document should have their own list. After much review of security labels, the Consent resource and Zulip topics, I would like to confirm if below is how this should be done or if the Permission resource is going to replace this previously recommended approach.
The solution I have derived based on http://build.fhir.org/consent-example-grantor.json.html is that a Consent resource should specify a root provision of deny and a child provision of allow with an actor reference to the individual. Given the consent is for a specific DocumentReference, the data.reference would refer to the resource to be protected.
I also need to indicate in the DocumentReference there is a security policy in order to know I need to retrieve the associated Consent resource.
Given the patterns specified in http://build.fhir.org/consent.html#model, should I use OPTOUTE (opt-out with exceptions) as the securityLabel in DocumentReference? Should this also go in Consent.provision.securityLabel.
BTW, the last sentence in the General Model section says "These exceptions are explicitly recorded in the except element", but there is no 'except' element. Should this refer to 'Nested Exception Rules' provision element?
John Moehrke (Jan 31 2022 at 13:28):
Hi @Heath Frankel We have not been presented with this kind of a usecase until this point, so I would not expect any part of the current model to support this kind of a usecase. I think the most likely resource to meet this use-case 'will be' Permission, meaning it is not fully ready for use but would be the best fit given the intent. We could look at using your use-case as a driving use-case. But, since Permission is not ready for use; then the next best solution would be Consent, and given that this is not at all the intent of Consent then any way of hacking it in there might work.
John Moehrke (Jan 31 2022 at 13:31):
I am not clear on your use-case, and the more i look at it the more I am worried that you might be encoding functionality what Consent is about, but choosing to encode it in an inverted way. The Consent model is designed the way it is because patients area all individually allowed to change their consent rules, so having the rules in one location and having that location point at all the affected data enables a more controlled environment that supports changing consent policies.
John Moehrke (Jan 31 2022 at 13:32):
In your use-case, who are the "individuals"? What is the rational for them? What are the kinds of rules?
John Moehrke (Jan 31 2022 at 13:33):
on your last observation, that sentence has been corrected in the current build -- http://build.fhir.org/consent -- which is on pathway for R5 of FHIR sometime around next year.
Heath Frankel (Feb 01 2022 at 01:49):
Thanks @John Moehrke for your responses. The use case is a document that has been indexed using documentReference resource where we want to state which individual providers can access the document over above those already referenced in the resource. In its simplest case, there may be an access control list (ACL) for each document. Although we may want a group of documents have the same access control list, we don't want to be limited to a single access control list for all documents.
The example http://build.fhir.org/consent-example-grantor.json.html seems to satisfy the use case up to restricting access to the patient record, we just need to further specify the documentReference(s), which I assume is done using provision.data.reference.
However, I also want to have a marker on the documentReference to indicate that there is an access control list policy applied to resource so that a consent manager knows that it needs to find the Consent resource that applies to the document. Being just a security label, there is no need to update the document when the ACL is changed.
I was looking at the privacy consent patterns and thought OPTOUTE (opt-out with exceptions) would seem to be an appropriate security label, but there was no detail on how the exceptions were intended to be specified.
Heath Frankel (Feb 01 2022 at 01:52):
John Moehrke said:
on your last observation, that sentence has been corrected in the current build -- http://build.fhir.org/consent -- which is on pathway for R5 of FHIR sometime around next year.
From what I can see on the build (Release 5 Draft Ballot) consent page, this has not yet been corrected.
John Moehrke (Feb 01 2022 at 12:16):
sure enough. I logged FHIR-35910
John Moehrke (Feb 01 2022 at 12:20):
on the more general rule, we did not think that it was proper standards behavior to define a FHIR resource for a universal IT security concept as ACL. We expected that it is better that these fundamental security rules be using a security module that has a language specialized for that. The Permission resource does fall within that principle, but the difference being that one organization is communicating to another organization about the rules the recipient is expected to enforce. I think for that kind of a setting your use-case might apply, but I am not hearing that you are needing this rule encoding for an interop reason, but rather for systems design.
Last updated: Apr 12 2022 at 19:14 UTC
