Restrict which records / rows an API user can access based on the user's affiliation to an organisation.

[uxbridgeroad]

User story
As an MS FHIR Server admin, I want to be able to restrict which records / rows an API user can access based on the user's affiliation to an organisation.

For example in Patient.managingOrganization (Organization that is the custodian of the patient record), an authenticated API User, with an affiliation to the Patient.managingOrganization that is the custodian of the patient record can only see patient records linked to the Patient.managingOrganization.

Could this be implemented using database policies / row level security in SQL database? A similar concept exists in Oracle virtual private database :- https://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm#DBSEG007

The id of the caller is passed to the database where the database policy adds a dynamic WHERE clause to a SQL statement that is issued against the table, view, or synonym to which the Database security policy was applied.

Acceptance criteria

When an authenticated API User, with an affiliation to the Patient.managingOrganization submits a search request, the database policies / row level security will only return matches which are also linked to the Patient.managingOrganization.
Search matches which are not also linked to the Patient.managingOrganization will not be returned.

[valeneiko]

I would be interested in similar functionality on a more granular level: CareTeam, PractitionerRole. Something like RBAC derived from FHIR resources.

But, AFAIK, there is no specification for AuthZ on FHIR. Maybe some kind of generic solution is possible? Where an admin could upload a policy file defining which roles are allowed to view/edit which resources and within what scopes (compartments).

Four things would be needed:

1. Mapping Identity (Patient, ReleatedPerson, Practitioner, Device) into a Role
   The Role I refer here would be something defined in a policy file
2. A way to define what actions (read/write) a Role can perform on what types of resources
   (scopes from role definition should be intersected with SMART scopes from the token to obtain actual scopes)
3. A way to define the scope (compartment) for a Role
   (for each type of resource in scope define a query relating it to Identity resources)
4. A way to define what anonymization strategies to apply for each resource
   e.g. Redact, Generalize

This all will get complicated very quickly when we start to consider chaining/includes:

• Actions/Scopes/Anonymization from the role needs to apply to included resources as well
• When search includes chains, it should only chain of resources the user is allowed to see
• With anonymization, it should be performed before a chain or include
• etc.

@jmandel We have talked about this at FHIR DevDays a bit. Do you have any thoughs? Can this solution be generic and simple enough to be useful? Is there any the reason AuthZ is not part of the FHIR spec (not even an implementation guide)?

[CaitlinV39]

@uxbridgeroad right now we don't have a solution for fine-grain access control within the FHIR Server. We have this in our backlog but no timeline on when we would address it. We have an architect team that works with the FHIR Server and they have created a proxy that will help with some scenarios. You can see details of that here: https://github.com/microsoft/health-architectures/tree/master/FHIR/FHIRProxy

[uxbridgeroad]

@CaitlinV39 , Thanks for the update. I had a look at the FHIRProxy previously but the required granularity was not there at that time. I will will investigate again and see if it can help.
Regarding the backlog and timelines, is there any visibility of this on GitHub? We are using MS-FHIR in a major project and it would really help to be able to align our releases with expected delivery of backlog items.

[CaitlinV39]

@uxbridgeroad right now the best way is to just see the activity on the repo. I know that isn't a very satisfying answer but we continue to reprioritize features based on what we hear from customers and our roadmap changes. For big features, we are typically pushing PRs adding features for a bit. Right now you can see that we are adding support to define search parameters and also supporting some sort capabilities in SQL. We will continue to think about how we can better surface this.

[uxbridgeroad]

@CaitlinV39 , just to confirm that this is one of the issues we were discussing earlier today with Marc and yourself.

[CaitlinV39]

Thanks @uxbridgeroad. Right now, our answer is still the same as it was in February that the proxy is probably the best route. Marc's team is the one that owns the proxy so may be able to make some updates there as well. We'll continue to keep this open but I don't have a timeline for when this would be supported in the server natively.