Stream: implementers
Topic: Access Control rules for FHIR
Krzysztof Suchomski (Apr 29 2016 at 08:20):
Have anybody looked at advanced ACL for FHIR servers, is it possible that there will be some standard way to express access control rules. I've gone trough security section and IHE access control whitepaper but it's generic. SMART on FHIR does not really go into complex scenarios.
I'm interested in situations like:
- Controlling access of guardians acting on behalf of incapable persons
- Controlling access based on organization or location. This may be required for some distributed scenarios.
Vadim Peretokin (Apr 29 2016 at 08:25):
There's this article that I know of: https://medium.com/@niquola/access-control-model-for-fhir-generic-server-dd66deb7cae6#.nrwwpky8l
Might or might not be useful
Grahame Grieve (Apr 29 2016 at 08:31):
so far, no one has presented any argument that the details of access control (ABAC or RBAC) is something that should be shared and inteoperable.
Grahame Grieve (Apr 29 2016 at 08:31):
of course, everyone needs to implement this in their server, but if we tried to make it interoperable, we'd also restrict people's choices greatly, and that's never seemed like a value proposition
Grahame Grieve (Apr 29 2016 at 08:32):
note that SMART on FHIR is not doing access control rules - it's doing something slightly different, though it looks similar
Krzysztof Suchomski (Apr 29 2016 at 09:08):
Restricting choices around access control would be definitely not a good path to choose. The article written by @nicola is interesting in this context because policy-based access control may give enough flexibility when it comes to expressing the access control rules and allowing interoperability in this case. It would be possible to extend the rule engine over time.
If there are no guidelines or best practices around this topic implementers may use extensions or abuse certain fields in order to restrict access in certain scenarios and eventually create issues around interoperability or potential issues around proper data usage and sharing.
The rule engine may be quite sophisticated and the rules in certain scenarios could be shared. Some standard and guidelines could help with implementation of the solutions using FHIR as a core part of the system.
Grahame Grieve (Apr 29 2016 at 09:18):
have you read the security page and looked at security labels? that part we are standardizing
Grahame Grieve (Apr 29 2016 at 09:18):
we could consider a white paper for best practices to post on FHIR.org
Krzysztof Suchomski (Apr 29 2016 at 10:08):
Yes, we are using security labels at the moment for certain scenarios like break the glass but the rule engine would need to consider much more sophisticated scenarios.
Grahame Grieve (Apr 29 2016 at 10:09):
such as? anything that needs explicit marking in the resources?
Krzysztof Suchomski (Apr 29 2016 at 10:30):
Let's say that we have a distributed environment. Single Fhir serving multiple organizations. You have MDs which are part of a single organization, you have MDs who are part of multiple organizations. They should see data only from specific organization. You have patients who should have access only to their data across multiple organizations and you have guardians who can access the data of patient they are responsible for. In theory this can be achieved without any security labels because all of the resources are linked together. It's about restricting searches and read/write access based on user defined rules and references between resources.
It gets more complicated with the patient data I think because of different regulations. I may be totally wrong here but what data is owned and visible to the patient may be totally different based on the location. The same applies to a search that different users can perform. Patient would be restricted to particular search queries to ensure that no data is being leaked. Even from the performance perspective it's much better to prevent access to a particular resources before even reading the meta data on the resource and fail as fast as possible.
Grahame Grieve (Apr 29 2016 at 10:36):
so most of these are 'user' level restrictions. We've said that:
(a) we won't have a user resource
(b) you'll have some other layer where by you administer users, user rights, and mappings between the user and the Patient/Practitioner resources
Grahame Grieve (Apr 29 2016 at 10:37):
I use SCIM for the other layer (http://www.simplecloud.info/)
Grahame Grieve (Apr 29 2016 at 10:38):
the interesting question, which hasn't really been discussed since early on, is to what degree you derive rules from the FHIR content that is linked from the user administration layer, and whether this reflects into the resources or expected patterns of use.
Grahame Grieve (Apr 29 2016 at 10:39):
In every project I've been involved in, this has all ended up being handled implicitly (from the perspective of the FHIR API) and surfaces during the OAuth process (e.g. there's a list of patients you have access to by way of being a guardian, and you can pick one), and then the intersection of the user's permissions and the authorizations that the user grants to the client are applied in the background
Krzysztof Suchomski (Apr 29 2016 at 11:08):
Lack of user resource and separating administration of it from FHIR is probably the best possible solution. In most of the scenarios user will be already existing in some place or authorization server like oAuth can handle that in a much better way. This would end up in duplication in most common scenarios as you would have auth server user, user in FHIR and a link to patient or practitioner.
On the other hand if we have a way to express explicitly expected patterns of use in standard way it would allow to restrict access properly, share the rules in distributed environment to make sure that the patient record is protected properly and that it is easy to understand what can be done with it.
Grahame Grieve (Apr 29 2016 at 12:02):
is there a 'standard' way in that space? I'm skeptical. If, on the other hand, you wanted to write a white paper describing what you've done, like niquola, I'd be happy to link to it from fhir.org in the whitepapers section I'm about to add
John Moehrke (May 10 2016 at 14:00):
Please join the Security WG to discuss the various Access Control (and Audit Control) models, and CBCC wg for discussions on Patient Privacy Consent capture and encoding. We are trying to standardize the encoding of a privacy consent directive, need lots more active engagement from the implementer community. In Security we standardize just enough to enable reasonable policies without forcing any specific architecture, rules engine, or enforcement model.
Mohammad Jafari (May 10 2016 at 15:01):
@Krzysztof Kowalski There has been some efforts for using external access control solutions in FHIR, including XACML and UMA. We, at the VHA's EHTAC lab, have demonstrated these in various past projects and also people at OpenID HEART WG are working on it. Please feel free to join the Security WG today or contact Duane or myself to have a chat if you're interested in any of this.
Ewout Kramer (May 19 2016 at 09:45):
Have you seen this: https://chat.fhir.org/#narrow/stream/implementers/topic/Labeling.20Service ?
Last updated: Apr 12 2022 at 19:14 UTC
