Stream: smart
Topic: Authorization for transactions
Josh Mandel (Sep 30 2020 at 19:02):
@Paul Church just brought up some interesting edge cases that we can take up on a future call. As background reading, https://cloudblogs.microsoft.com/opensource/2020/01/07/fhir-subscriptions-state-changes/ deals with some similar issues.
Paul Church (Oct 13 2020 at 21:18):
Wrote up some examples and proposed rules for SMART and transactions: https://gist.github.com/paulchurch/92d2385dca120fb51a43a45289d37bd1
Josh Mandel (Oct 13 2020 at 22:05):
Thanks for this!
Josh Mandel (Oct 13 2020 at 22:06):
root patient being updated to refer to the CREATE entry
Can you explain what this means? A patient's id presumably can't change, but that's the only way I'm thinking of to interpret...
Josh Mandel (Oct 13 2020 at 22:12):
Reading the examples now... I'm starting to understand it has something to do with Patient.link. There's an interesting underlying assumption about compartment membership and Patient.link, which is maybe worth making explicit.
Josh Mandel (Oct 13 2020 at 22:19):
It'd also be good to say something about the implied processing model: taking FHIR semantics to evaluate the deletes, then creates, then updates, then reads... And after doing all of that, making a determination about whether the transaction is allowed by policy to be applied (which in turn means evaluating some pre- transaction state and some post-transaction state).
Paul Church (Oct 13 2020 at 22:21):
I'm creating an Organization, and updating Patient/123 to refer to it, and I have patient/*.* for Patient/123
Paul Church (Oct 13 2020 at 22:21):
otherwise you can create things in a compartment that refer to the Patient, but you can't create things in a compartment that the Patient refers to
Josh Mandel (Oct 13 2020 at 23:20):
OK -- so we're using the word "compartment" here in not-quite-precisely the way that FHIR uses it.
Paul Church (Oct 14 2020 at 00:11):
hmm, that's true - we're using the Patient $everything definition
Josh Mandel (Oct 14 2020 at 13:37):
Do you want to comment on the "headers" as well? Is this just ad hoc syntax or something you'd want to formalize for reverse proxies in front of a FHIR server?
Paul Church (Oct 14 2020 at 14:39):
That's just ad hoc for this discussion
Paul Church (Oct 14 2020 at 15:19):
We are probably too casual about using "compartment" to mean "resources associated with a patient".
As far as I can tell, the SMART spec doesn't say anything about what resources are associated with a patient, or whether a patient scope gives access to some or all non-compartment resources. It does say "Note that some EHRs may not enable access to all related resources - for example, Practitioners linked to/from Patient-specific resources" which seems completely unhelpful. Maybe you'll get some data, maybe you won't. Can we standardize the answer to that?
ryan moehrke (Oct 14 2020 at 15:24):
are we considering in these usecases the use of ids and references that are only persistent within the bundle (uuids) These usecases seem to rely on PUT to create and referencing the soon-to-be id in any other resources in the transaction.
I bring this up because the core fhir spec defines the transaction processing rules as DELETE > POST > PUT (and to my knowledge they are ordered this way to specifically be able to resolve any uuid references before the resources are created) https://www.hl7.org/fhir/http.html#trules
But I noticed that this proposal seems to re-organize those to instead be DELETE > PUT > POST
The more I consider this as I type I think I'm wrong in my interpretation, but I'm not sure of what else you could be proposing; a pre-commit walkthrough the affected resources to see if any references break?
Paul Church (Oct 14 2020 at 15:33):
No, we are considering real IDs set by the client (upserts). It's possible that we still need to reconcile these ideas with the transaction processing rules.
Josh Mandel (Oct 14 2020 at 19:08):
On today's call, this discussion expanded to "wait, how does reading data work"; which expanded to "should access like patient/*.rs come along with the ability to read data about Practitioners, Organizations, and metadata like ValueSets, etc?
We didn't have a super-crisp answer, and that's kind of intentional.
Josh Mandel (Oct 14 2020 at 19:09):
Here's where I got to in jotting down my thoughts post-call (captured in our shared notes doc):
- "What permissions come along with access to observations?" e.g., linked patients, etc?
- "Party line" == the decision about what data the user is allowed to see belongs to the EHR; rule of thumb might be "data in your record + data needed to interpret your record" but the real-life details are super complex (influenced by state laws, health system policies/defaults, etc). SMART doesn't try to model this, but only models how a user's permissions are shared downstream with an app
- "Generic FHIR server needs" == Much, much more!
- General-purpose language for defining data that can be read/written, possibly in terms of references to other data, or in terms of coded data types (e.g., one set of rules for data about substance abuse history), or in terms of time/lockos (e.g., how to specify when a lab result is "released to" a patient)
Josh Mandel (Oct 14 2020 at 19:10):
I'd welcome feedback! And I continue to believe that work is required on the "Generic FHIR server" front, but the consensus group is slightly different than the SMART v2 project.
Jenni Syed (Oct 14 2020 at 19:20):
We actually do not allow apps to ask for patient/Organization or patient/Practitioner (many others) type scopes because they're nonsensical/aren't enforceable
Jenni Syed (Oct 14 2020 at 19:21):
and we do require that they have the scope for any linked (not contained) resource in order to read it
Jenni Syed (Oct 14 2020 at 19:22):
(note: I believe we started using user/... only for those types of resources after conversation on here... I can try to track down the original discussion)
Paul Church (Oct 14 2020 at 19:23):
If I have patient/Patient.read can I read the Organization referenced by it though? Or do I need user/Organization.read?
Jenni Syed (Oct 14 2020 at 19:26):
You would need the user/Organization.read as well/the app would need to request it
Jenni Syed (Oct 14 2020 at 19:27):
here's the old conversation (notice how long ago... and that as it goes on it starts to discuss the "SMART 2.0" approaches :) ).
Paul Church (Oct 14 2020 at 20:36):
Jenni's statement makes sense to me. How about this: patient scopes only apply to actual compartment members. To read referenced non-compartment resources you need user scopes for those resource types. I don't know if we want to allow searches on non-compartment resources under that scope since the user scope is going to be all resources in a non-EHR permissions model.
Gino Canessa (Oct 14 2020 at 20:40):
Are any elements filtered based on user information? E.g., if I have an app that wants practitioner names and photos, it doesn't mean that I should have their home addresses.
Otherwise, it might be a good boundary point (e.g., user has everything, patient has limited access).
Paul Church (Oct 14 2020 at 20:45):
Out of scope for the general-purpose fhir server case. We currently have no way to specify that, so we just give out the resources.
Yunwei Wang (Feb 24 2021 at 22:01):
Paul Church said:
patient scopes only apply to actual compartment members. To read referenced non-compartment resources you need user scopes for those resource types.
Could user scope apply to compartment members? If yes, why not just use user scope instead of mixing patient scope and user scope? Is this also true for patient facing standalone app? @Paul Church
Paul Church (Feb 25 2021 at 01:26):
Yes, this is sort of a mismatch for our use case and we could just use user scopes. Without an EHR permissions model to draw on, there is no concept of a user separate from a patient.
Yunwei Wang (Feb 25 2021 at 16:46):
Then what is the purpose for patient scope? Almost all patient compartment resources haver reference to non compartment resources. A simple query to get Observations could not be fully achieved by using patient scope only without pull Observation.performer information.
Tanvi Shah (Mar 02 2022 at 17:16):
Quick question
A client application that is authenticating with my system for SoF tests, is providing a “state” value in its authorization request that is too long for my system to handle. Currently my system can accept a state value up to 100 characters (this is the maximum size that the database table column can currently handle for this value). In this case, it appears that the state value being provided by the client app is 124 characters long.
My question is, what is a best practice “state value”. Is there a length that is recommended?
Josh Mandel (Mar 02 2022 at 18:35):
We don't have any formal requirements on how long a state the EHR needs to support. We do have a hard requirement that apps
SHALL use an unpredictable value for the state parameter with at least 122 bits of entropy
This can be achieved in 36-char UUIDs, So your current implementation supporting 100 characters meets that floor and provides breathing room.
That said, without digging into the details I was going to suggest 128 characters would be a fair target, and it sounds like that would support this specific client app. Do you know how they are structuring their state values and whether they are conforming with our requirements above?
Last updated: Apr 12 2022 at 19:14 UTC
