Stream: implementers
Topic: Data access privileges: Pracitioner, Oranization, Patient
Rob Resendez (Oct 29 2021 at 21:43):
There are different business cases that come up quite a bit: "Conduct a patient search, but only where patients are managed by an organization I am affiliated with". "What organizations am I affiliated with"
_Context_ "I" am a _Practitioner_ / _user_
In trying to solve for cases such as these, I have a few questions / thoughts and am interested in opinions and recommendations.
What's the correct way to find out what organizations a practitioner is associated with? It seems like PractitionerRole might be the best option?
From there I was thinking Patient?name=foo&managingOrganization=... would be _okay_
It seems like the ergonomics of a custom query parameter would simplify things quite a bit..
Patient?name=foo&userCanAccessTheOrganization=true
I'm always torn here (custom parameters) because it feels like trail blazing. It saves an additional request and I'm not even sure PractitionerRole is really the best way to obtain what I'm after.
Just how frowned upon are custom parameters such as these? Does something already exist which is better suited to my needs? Thanks in advance!
Lloyd McKenzie (Oct 30 2021 at 02:09):
The short answer is "what are you allowed to see?" is often driven by complex business rules, so a one-size-fits-all solution is unlikely.
In more detail: yes, PractitionerRole is the way to capture formal association with an Organization - though keep in mind that Organizations have relationships - there might be ancestor organizations and descendant organizations.
Patient association with organizations is harder. Patient.managingOrganization is "what organization maintains this patient record", not necessarily "what organization is responsible for caring for this patient". As an example, if the Patient is managed by a central registry, there might be lots of organizations that provide care to the patient but don't 'manage' that record.
Other ways to represent relationships to patients: does the practitioner have any involvement in encounters or orders for them? Are they part of a CareTeam associated with the patient? Is there a capitation Contract tying them to the Patient?
Also, a lot of systems won't filter access based on search parameter, they'll pre-filter what you're allowed to see independent of the FHIR interface entirely.
Rob Resendez (Oct 30 2021 at 19:02):
Yeah, policy-based data access restrictions I, too, see as something that should just be enforced at a per-request basis. Putting extra requirements on a requester seems kind of silly, but that's kind of where I am currently since the api is used by many contexts and I must not break any of them. Will have to do some soul-searching to figure out how to transition toward built-in filtering for user access to data. I am leaning toward starting with a custom search parameter and transitioning the behavior altogether based on some scope in the user token
Some system-access contexts will still need this kind of info, so wanting to make sure I'm not way out in left field thinking that practitioner-role would be an okay source for the data that is incidentally behind some of our business policies historically. I try to think in terms of "is this where another system (other than my own) would store this kind of relationship?".
Jose Costa Teixeira (Nov 01 2021 at 07:15):
We have the Permission resource which is intended to convey the "who can read which data for what purpose".
Jose Costa Teixeira (Nov 01 2021 at 07:16):
I think the query by an authorized client would look exactly like the one by an unauthorized client. It's the server that decides whether that query is actually going to be executed.
Mike Lohmeier (Nov 01 2021 at 13:41):
Sorry, I'm not seeing the Permission resource in FHIR r4.0.1, r4.6.0 or build.fhir.org. Can someone provide a link.
John Moehrke (Nov 01 2021 at 14:03):
Permission is a draft resource that is in discussion for these kind of use-cases, but for which we know much more needs to be done. It is http://build.fhir.org/permission
Cooper Thompson (Nov 01 2021 at 17:18):
We (Epic) have been running into this a lot too. We might be bringing something to the SMART spec to include something like a "user login department"(Location) in the context (with a launch/location scope that lets the app ask the EHR to figure it out). For some cases, PractitionerRole/Organization aren't really practical. Using a SMART context approach means that the server can basically figure out the context and let the app know, rather than exposing the entire PractitionerRole/Organization structure to the app and making them dig through it.
Mike Lohmeier (Nov 01 2021 at 21:59):
We're looking at various options to power authz row level security as well to implement in our fork of AWS FHIR Works. Granted our scalability and reliability requirements are very high and have driven us to specific solutions. We'd love to hear more of what people are doing here because it's a beast of a problem that I think any mature FHIR solution will have to address.
The leading contender we're looking at is to leverage Open Policy Agent by synchronizing the Patient, Organization, Location, Practitioner and PractionerRole and building a custom ACL table to override with explicit point to point approvals and denials. Then create dynamic policies that get evaluated in real time on each request that leverage the synchronized FHIR resources and ACL table in OPA. Generally speaking, the solution is standard fare authz in an API powered by a policy engine.
The 2nd leading option we're considering is using one of the zanzibaresque ACL solutions, like spicedb, coming out lately in the open source space. This would be similar to wiring in a policy engine into each request but the operating model would be geared around an infinitely scalable ACL table as opposed to dynamic policies. It's not as clear as a picture how we'd go from FHIR resources and relationships to ACLs systematically.
We're still early in our analysis and have only vetted and prototyped a couple of the options we've identified which resulted in only throwing out options (looking at you keycloak...) but it'd be great to hear what others have done here.
Joel Schneider (Nov 02 2021 at 06:44):
We're currently using FHIR security labels to support our role-based resource-level authz implementation.
Joel Schneider (Nov 02 2021 at 06:45):
(but our use case is probably relatively simple)
Last updated: Apr 12 2022 at 19:14 UTC
