Stream: implementers
Topic: Security roles and priveleges
ravi.kuchi (Nov 08 2016 at 15:31):
Hi, We have mapped all our clinical users like physicians, Nurses, technicians to Practitioner resource and also have mapped roles to these users present in our EHR system. The issue we are facing is each of these roles have a set of privileges that basically identify the set of tasks that the user can either view, modify, approve etc. The Practitioner role does capture the role accurately but does not provide any means to map the privileges associated with the roles. Was this intended to be handled out of the FHIR resources at application layer? Or is there a means of representing this in FHIR world. For a sample of privileges that exist in our world the nurse advocate role can place order in some of the categories like Home medications, Nutrition services, laboratory services etc. while a role called social worker has only view access to the orders. Any help is appreciated!
John Moehrke (Nov 08 2016 at 16:00):
Privilege management is a broader concept than the FHIR model. The FHIR model is organizing health information. As you indicate there is an overlapping of the concepts as you have identified. But the management of the privileges is expected to be the domain of the access control system. This might be OAuth based, XACML, or might be based on something else. See the security page for more detail
Grahame Grieve (Nov 08 2016 at 20:58):
and check out SCIM at http://www.simplecloud.info/
Christiaan Knaap (Nov 22 2016 at 09:50):
Although I like the concepts in SCIM, it still does not include a means of expressing what *actions* a user or group is allowed to execute. That is the realm of authorization (vs. authentication), and indeed the domain of the access control system. It is usually very specific to the application and the organization it is used in. Nevertheless, SMART on FHIR has a set of scopes that may help you. They are specific for the SoF usecase: start an app in the context of an EHR.
http://docs.smarthealthit.org/authorization/scopes-and-launch-context/
Grahame Grieve (Nov 22 2016 at 10:06):
yes, it's the intersection of the 2 that's interesting. But SCIM does support extensions, and I just extended it with the smart on fhir scopes.
John Moehrke (Nov 23 2016 at 16:01):
I continue to work with some external organizations to better clarify how Access Control is implemented. Even when constrained to using OAuth on FHIR resources, it is very difficult to get a group to understand the complexity of access control in healthcare. The SMART scopes are a stop-gap, they are not really that helpful to the kinds of vectors of control needed in healthcare. I have outlined a solution, but that solution is also too big of a change... See https://healthcaresecprivacy.blogspot.com/2016/01/fhir-oauth-scope.html
Grahame Grieve (Nov 24 2016 at 07:51):
I had to create some scopes of my own for my very limited use case - supporting smart on fhir and the fhir api
Grahame Grieve (Nov 24 2016 at 07:51):
but I didn't think your solution was heading in the right direction. Personally
Grahame Grieve (Nov 24 2016 at 07:52):
however, it's clear that we will have to make access control interoperable in the future - maybe a draft in STU4
Grahame Grieve (Nov 24 2016 at 07:52):
that will be lots of fun ;-)
John Moehrke (Nov 24 2016 at 14:03):
I agree there is no good solution defined yet. And we will not be able to make that solution until we get our minds past building the core Resources. The problem with my scope proposal is it is too complex and requires too much compute on the server.
John Moehrke (Nov 24 2016 at 14:10):
An emerging solution is to define a FHIR based Security Labeling Service (SLS). Much like you are defining for Conformance checking. It will classify the data, as an authoritative classification. And then use classifications as the scopes that are authorized by the OAuth authority. We have in HL7 a definition of this SLS service, don't have a FHIR specific version. You have implemented similar with Duane and Mike. The simplest classification vector is the _confidentiality; as it is small, linear, and non overlapping. Other valuesets could be used at the discretion of the SLS and OAuth authority -- aka it is not needed to be known by client or server.
John Moehrke (Nov 24 2016 at 14:11):
The logic problem we have is that in healthcare we tend to have rules about what can't be viewed, where as scopes are a statement of what can be done.
Dunmail (Nov 24 2016 at 14:28):
We've tried using fhir resources and fhir restful interactions to provide access control to resources and actions [https://github.com/BlackPearSw/jwt-claims-fhir/blob/master/jwt-claims-fhir.md]. We now have this working in production and it works to quickly reduce the surface area a user can access.
This doesn't help with controlling access based on either resource content or metadata which is considerably more complex. Will fhirpath provide a language to describe controls?
nicola (RIO/SS) (Nov 24 2016 at 14:30):
@Dunmail Take a look at https://medium.com/@niquola/access-control-model-for-fhir-generic-server-dd66deb7cae6#.xmhfertgu
nicola (RIO/SS) (Nov 24 2016 at 14:32):
General idea is policy based control, where policy could be expressed as schema on request represented as document with all context included, like user, groups, client (if you add response to this document you could do mix of RBAC & ACL).
nicola (RIO/SS) (Nov 24 2016 at 14:33):
The idea was stolen from AWS access policies (but they use quite complicated DSL for that).
nicola (RIO/SS) (Nov 24 2016 at 14:35):
You can put policy in jwt :), ie signed policy
Dunmail (Nov 24 2016 at 14:46):
Standing on the shoulders of giants is allowed! :)
I think this approach will work - it's fundamentally the same concept but you're expressing it with a richer syntax. I like the use of json-schema for this - cunning! I think we could easily transform our operation based syntax to json-schema so that instead of using the shape of the request to tell us what it means in FHIR terms, we would express the request in FHIR terms and then create the schema for an expected request.
Have you tried implementing this yet?
nicola (RIO/SS) (Nov 24 2016 at 14:48):
No
Last updated: Apr 12 2022 at 19:14 UTC
