Stream: smart
Topic: reason for request
Eric Haas (Oct 21 2020 at 18:48):
On a discussion for Da Vinic CDEX there was question about providing a reason for a specific query and was suggested is part of OAUTH. Can requester A get access only for reason B but no other reason? does it work that way? (e.g. I'm want to see the data to verify a claim). I wanted to follow up here to see if there is general agreement and how the heck a reason would be incorporated into SMART Launch.
Jenni Syed (Oct 21 2020 at 19:05):
Usually only a human would know why they're opening something - eg: it's not something we could really assume
Jenni Syed (Oct 21 2020 at 19:06):
so, for example, let's say I have a growth chart app. The physician might launch it as part of their appt to evaluate growth compared to norms, to discuss something with a patient, or to look at the last measurements b/c the patient was admitted somewhere and they're doing a risk assessment/evaluation for treatment
Eric Haas (Oct 21 2020 at 19:06):
that was my conclusion: essentially is "out-of-band" right?
Jenni Syed (Oct 21 2020 at 19:06):
if all daVinci wants to know is "physician launched app" - we can tell them that without a human :)
Jenni Syed (Oct 21 2020 at 19:07):
you could make it in band, but it would require manual entry
Jenni Syed (Oct 21 2020 at 19:07):
I thought this was actually more provenance than for a whole session
Eric Haas (Oct 21 2020 at 19:08):
out-of-band = usage agreement
Jenni Syed (Oct 21 2020 at 19:08):
ie: ONC requires provider offline access but not online. The reason they accessed data X today may be very different than when they accessed it yesterday
Jenni Syed (Oct 21 2020 at 19:08):
Again, depends at what level they're trying to get :/
Jenni Syed (Oct 21 2020 at 19:09):
http://build.fhir.org/provenance-definitions.html#Provenance.reason
Jenni Syed (Oct 21 2020 at 19:09):
That is a way for an app/system to give the reason it did something. I don't think most support this today
Jenni Syed (Oct 21 2020 at 19:10):
But there's also: http://build.fhir.org/auditevent-definitions.html#AuditEvent.agent.purposeOfUse
Jenni Syed (Oct 21 2020 at 19:10):
which seems more in line??
Eric Haas (Oct 21 2020 at 19:10):
I am referring to data access query
Jenni Syed (Oct 21 2020 at 19:10):
cc @John Moehrke because I'm going by past discussions and am definitely not the expert
Eric Haas (Oct 21 2020 at 19:10):
that would be a trail
Jenni Syed (Oct 21 2020 at 19:11):
I think it has to be per access/query
Jenni Syed (Oct 21 2020 at 19:11):
the "session" is very blurry and is even regulated in the US today to only require offline access :rolling_on_the_floor_laughing:
Jenni Syed (Oct 21 2020 at 19:12):
(at least for on behalf of user - system access doesn't have a session nor SMART context to hook into)
Jenni Syed (Oct 21 2020 at 19:15):
If they're wanting to restrict auth based on a reason then that's a different way than we've thought of auth today
Jenni Syed (Oct 21 2020 at 19:15):
that would have impacts to the online vs offline access vs single use rules, I would think
Jenni Syed (Oct 21 2020 at 19:17):
So I would go back to "what level" they're wanting to know re:what data is being accessed/why, then to who is going to know that and when. That would help us figure out where in the process it would be available for input
John Moehrke (Oct 21 2020 at 19:29):
I have been trying to get this kind of discussion going. Two things. 1) the authZ token needs to indicate ALL the uses (PurposeOfUse) that the requested results will be used. Not just what triggered 'this' request. 2) the request can indicate the trigger action (activity). Too often I see #2 being talked about as if it was #1.
John Moehrke (Oct 21 2020 at 19:31):
Audit log.is in addition. Recording what happened. Access to the log would be protected for very specific and targeted (not bulk) access. Like investigating a suspected failure to follow rules.
Lloyd McKenzie (Oct 21 2020 at 19:58):
Where do you stick PurposeOfUse in OAuth? Is there any guidance about how that can/should be computable?
Jenni Syed (Oct 21 2020 at 21:55):
Given the offline access workflow, and that applications may change their data use over time, I'm not sure it's realistic to expect that the initial authorization would contain it. If this is something that could be change on refresh... then that's also interesting
Jenni Syed (Oct 21 2020 at 21:56):
Same question as Lloyd: how is that communicated?
Isaac Vetter (Oct 23 2020 at 22:02):
Hey Guys, in our system, this is communicated during registration. Jenni, during registration for your system, does an app communicate if it is patient-facing vs provider-facing?
Jenni Syed (Oct 26 2020 at 14:07):
We know if it is patient facing, provider, or system but that is NOT the purpose of use. Also, as discussed above, we may know the app is generally a growth chart provider facing app, but that doesn't mean you know why the provider is launching that application
Isaac Vetter (Oct 26 2020 at 22:40):
This list is terribly intimidating (for me at least), but really there's only a few purposes of use: treatment, patient-requested, public health, marketing, operations, payment, and research. (And some networks have even cut this list down further). All CCDS/USCDI patient-facing apps are registered with an implicit, but concrete, purpose of patient-requested; aren't they?
Jenni Syed (Oct 27 2020 at 02:21):
Those are all extensible or example bindings - this is why I was curious about what "level" DaVinci is needing to track. So, using that it would be hard to tell a training data access from a real clinical scenario, if that is the level of detail needed. Similarly, research vs trial vs treatment could be all valid reasons a doctor launches an app that graphs data.
John Moehrke (Oct 27 2020 at 12:34):
would love to see you all provide comments to improve the vocabulary...
John Moehrke (Oct 27 2020 at 12:38):
I have seen a few recommendations for how purposeOfUse is carried. In IHE IUA it is carried as an attribute in the OAuth token. In HEART it is part of the scope. In the break-glass proposal in the FHIR core it is carried in an http x-header. And SMART is looking at it as well... There is also the proposed Permission resource that seems could be in many places. So this all shows that we are in experimental stage at this point. It seems to be agreed that it is an important vector to authorization decisions, and authorization enforcements. It should be clear it is an important vector in data-use after data are communicated (use needs to be restricted to the PurposeOfUse(s) under which it was released)...
Last updated: Apr 12 2022 at 19:14 UTC
