Stream: Security and Privacy
Topic: Improvement beyond SMART scopes
John Moehrke (Apr 03 2018 at 14:12):
The SMART-on-FHIR project has a fantastic starter set of scope patterns. But these scopes are considered too basic. There are many proposals for improvement that were submitted to the SMART-on-FHIR ballot in HL7. These proposals have been deferred, and would be input for this improvement opportunity. There are also many proposals that have been created as part of various projects. Please catalog here your scope needs, and your scope proposals.
John Moehrke (Apr 03 2018 at 14:15):
scope proposal using FHIR query parameters pattern https://healthcaresecprivacy.blogspot.com/2017/05/fhir-oauth-scope-proposal-using-fhir.html
John Moehrke (Apr 03 2018 at 14:16):
OpenID HEART workgroup https://openid.net/wg/heart/
John Moehrke (Apr 03 2018 at 14:17):
incremental to SMART-on-FHIR with PurposeOfUse and _confidentiality https://healthcaresecprivacy.blogspot.com/2016/01/fhir-oauth-scope.html
John Moehrke (Apr 03 2018 at 14:19):
scope is a URL to a FHIR Consent resource where the rules are . (I have not written this up).
John Moehrke (Apr 03 2018 at 14:22):
Niquola article https://medium.com/@niquola/access-control-model-for-fhir-generic-server-dd66deb7cae6
John Moehrke (Apr 03 2018 at 14:22):
Mohammad Jafari -- JSON encoded scope values https://medium.com/@jafarim/using-json-to-model-complex-oauth-scopes-fa8a054b2a28
Kevin Shekleton (Apr 03 2018 at 14:59):
I would like to see the community resolve the current differences in how scopes have been implemented today first. After that, we'd look to making further changes to scopes.
1. Epic requires .search and .create scopes for search and create requests, respectively. The SMART on FHIR specification uses .read and .write for these types of requests. We should have a discussion as to why Epic went that route and if all other vendors should also implement scopes in that matter.
2. Cerner disagrees with wildcard scopes on two fronts: the encourage app developers to request more data than necessary and we feel providers + patients should not be asked to share all current and future data with the app (this is incredibly broad and Cerner feels users should not be asked for something so sweeping, nor will they likely understand what it means). While Cerner's implementation is not contrary to the SMART on FHIR specification, we should have a discussion as to if wildcard scopes should be removed from the specification.
After these two topics have been resolved, I think it would be great to explore other changes to scopes.
John Moehrke (Apr 03 2018 at 15:09):
Is that current scope problem on the radar for the SMART-on-FHIR ballot reconciliation? I can't make that call, so I don't know what is going on there. @Josh Mandel ?
Kevin Shekleton (Apr 03 2018 at 15:13):
I'm not sure if the first topic (.search and .create) was made as a ballot comment.
John Moehrke (Apr 03 2018 at 15:16):
How is SMART-on-FHIR tracking post ballot comments? I presume it is not gForge. Ownership of this should be resolved regarding Security wg vs FHIR-I wg. Today SMART-on-FHIR is owned by FHIR-I. @Grahame Grieve ?
Kevin Shekleton (Apr 03 2018 at 15:17):
They are being tracked via a spreadsheet
Kevin Shekleton (Apr 03 2018 at 15:18):
I'm kicking myself for not raising my concerns with wildcard scopes last year. At the time, since our implementation was still compliant with the SMART spec (as you don't have to support all of the scopes), I didn't think it was a problem. However, I realize I should have spoken up as I think wildcard scopes promote implementations and user experiences that do not have good security (data privacy) practices in mind.
Kevin Shekleton (Apr 03 2018 at 15:24):
Here is the Google Sheet of SMART ballot comments
Grahame Grieve (Apr 03 2018 at 18:25):
I'm checking with the other FHIR-I co-chairs, but I think that the answer will be, issues with smart app launch are managed just like everything else we manage. Which will mean that remaining open issues will have to migrated out of the spreadsheet into gForge
Grahame Grieve (Apr 03 2018 at 18:26):
it would certainly be good to know why Epic diverged from the spec. @Isaac Vetter / @Danielle Friend? I didn't see anything about in ballot
Grahame Grieve (Apr 03 2018 at 18:27):
I'll follow up the email questions about scope as soon as I get a chance... but I think that there's a very valid use case for */... even if it can be abused
Grahame Grieve (Apr 03 2018 at 18:30):
i think this is particularly acute while the scopes are so technical. I just want my PHR to have everything I can get... I think most patients would assume that they can say this about their own personal store of data. And I think that Cerner is looking at patient trust the wrong way around about this. I could ask SPM for opinions, I guess
Kevin Shekleton (Apr 03 2018 at 18:41):
I can write up a detailed write up as to our position. I think we're approaching this very rationally.
There is also a very easy alternative to wildcard scopes -- an app can simply explicitly request each scope they want! For new scopes a FHIR server adds in the future, the app can request those too and the user will be re-prompted to authorize that new scope.
Grahame Grieve (Apr 03 2018 at 18:42):
once the client is updated to ask for it...
Danielle Friend (Apr 03 2018 at 18:42):
@Grahame Grieve we broke ours down by interaction, which was long enough ago I don't know why we did not bring this up as a comment. If I were to make a ballot item about it now I'd say scopes should be interaction based as it provides a clear representation of what a client is able to do. Does write = create, update, delete? Does read = read or read = read, search?
Kevin Shekleton (Apr 03 2018 at 18:43):
Grahame - the client should absolutely be updated for any new data / permissions it wants
Grahame Grieve (Apr 03 2018 at 18:43):
why would a patient differentiate between read and search? what % would understand the choice?
Kevin Shekleton (Apr 03 2018 at 18:44):
I mentioned this on my mailing list post, but no other analog exists where you grant an app access to a current set of permissions and any future permissions that may be added
Danielle Friend (Apr 03 2018 at 18:45):
The patient wouldn't - the client would. Like I mentioned in the google groups - for Epic, the scopes are defined at client creation.
Kevin Shekleton (Apr 03 2018 at 18:45):
Josh's Github example is not an analog. Yes, when you grant a Github app access to your repositories, it is to all of your current + future repositories. However, that's like saying you grant a SMART app access to patient/AllergyIntolerance.read -- all of your current + future allergies. Github's permissions cannot be granted wildcard access to a 3rd party app.
Grahame Grieve (Apr 03 2018 at 18:46):
I don't understand that. Sure, the client asks for it.... but the authorization server then asks the patient... what..? and if the patient doesn't get asked about it, why differentiate it?
Grahame Grieve (Apr 03 2018 at 18:46):
scopes are for authorization, not access control
Grahame Grieve (Apr 03 2018 at 18:47):
Kevin, I'm not convinced about the analogy.
Kevin Shekleton (Apr 03 2018 at 18:50):
Ok. This is probably best for a call or WGM discussion anyway.
Danielle Friend (Apr 03 2018 at 18:56):
Yeah I get that - the patient only cares at a content and read/write level. But I think there is another piece in there for a lot of our workflows - where before a patient or provider sees an app, a healthcare organization has said I'd like to "buy"/"install"/"share" this app, what does it want to do. Ex: The organization decides to make an app available to providers via an embedded SMART app - why does it need "Patient.search" when it is only ever launched from a patient's chart? Or I want to advertise a patient facing app to my organization's patient population - it should be able to file patient entered meds but not update existing ones.
Danielle Friend (Apr 03 2018 at 18:56):
And to be fair, those are made up examples. I don't know of a time when we've actually needed the granularity yet. But I'm just trying share some of our reasoning for making that choice.
Grahame Grieve (Apr 03 2018 at 19:01):
ok so you're talking about organization authorization at registration... that makes more sense. Which reminds me... both Epic and Cerner agree on the scopes at registration, right? what the app asks for at authorization time has to be the same? or is ignored? either way, this is part of the app registration question
Kevin Shekleton (Apr 03 2018 at 19:04):
For Cerner:
Provider apps: Yes, we agree on scopes between Cerner & the app at registration time. What the app is granted at launch is an intersection of what the app asks for + what the registration scopes are.
Patient apps: The scopes are defined by the app at registration time. What the app is granted at launch is an intersection of what the app asks for + what the registration scopes are. In the future, we will allow patients to selectively choose the scopes granted which means that this will be a further set in that final intersection.
Grahame Grieve (Apr 03 2018 at 19:05):
I'm very interested in what the patient choice UI looks like. But for now, what does the patient see? nothing?
Kevin Shekleton (Apr 03 2018 at 19:06):
For Cerner, the patient sees the scopes they are authorizing the app to use. Let me grab screenshots, we've shared this publicly before....
Grahame Grieve (Apr 03 2018 at 19:06):
great thanks
Kevin Shekleton (Apr 03 2018 at 19:24):
I just went through the authorization flow with the Apple Health app and my Cerner Clinic account. I took screenshots and blurred out my name so it can be shared.
Kevin Shekleton (Apr 03 2018 at 19:25):
We're iterating on our authorization UI and have several improvements lined up in our backlog.
Isaac Vetter (Apr 03 2018 at 19:26):
(I was about to say that ours is pretty similar, but with a better UI).
Grahame Grieve (Apr 03 2018 at 19:26):
great - really appreciate. "the information you share may be subject to re-disclosure" - that's obscure. is cerner redisclosing, or apple? Why is cerner warning about it? seems like a few more words would make it clearer..
Grahame Grieve (Apr 03 2018 at 19:26):
@Isaac Vetter show us the money ;-)
Kevin Shekleton (Apr 03 2018 at 19:29):
Re: redisclosing. That would be Apple since they are getting copy of your data. I don't know why the verbiage/wording is the way it is.
Grahame Grieve (Apr 03 2018 at 19:30):
did Cerner consider whether the Observation/* scope is too wide, then, if you don't like wildcards?
John Moehrke (Apr 03 2018 at 19:30):
how can you control redisclosure or not? And I am sure many other apps (espeially PHR) do similar
Isaac Vetter (Apr 03 2018 at 19:31):
This is the stock functionality that we released in v2015 and that every patient/consumer sees when authorizing an app via the SMART standalone launch. It's also viewable by developers using our open.epic and/or App Orchard portals.
It's, of course, skinnable by the health system.
Grahame Grieve (Apr 03 2018 at 19:31):
you can't control t - that's what the obscure language is trying to say
Grahame Grieve (Apr 03 2018 at 19:32):
Isaac, I have to comment on this too. "Keep my logged in to MyChart" - that's completely obscure to me
John Moehrke (Apr 03 2018 at 19:33):
understood... which is strange as to why it is mentioned.. I hope it isn't just with Apple
Kevin Shekleton (Apr 03 2018 at 19:35):
I think it's a fair discussion to have on Observation given the breadth of data you have access to via this FHIR resource. However, I think that this discussion is best had after our first two as this would delve into discussions of further granularity of scopes.
Kevin Shekleton (Apr 03 2018 at 19:38):
Our authorization UI has that same verbiage regardless of what app you are authorizing.
John Moehrke (Apr 03 2018 at 19:38):
right... separate bug with current SMART scopes, from future improvements. Should we move bug to a different thread?
Luis Maas (Apr 03 2018 at 19:46):
Regarding the redisclosure language, there is similar language in the KEY PRIVACY AND SECURITY CONSIDERATIONS
FOR HEALTHCARE APPLICATION PROGRAMMING INTERFACES (APIS) document we were reviewing today in the FHIR Security meeting
See page 7 re: end-user authorization screen at https://www.healthit.gov/sites/default/files/privacy-security-api.pdf
"In accordance with the PMI Privacy Principle of transparency, the approval text should make
clear to the individual that once the third-party receives the transmitted health information, the
healthcare provider is not responsible for what happens to the information maintained by the
third-party."
John Moehrke (Apr 03 2018 at 19:52):
I think we all agree about downstream disclosure, the concern is around clarity to a common patient in language they can understand. Not a technical issue. But would be good topic under "Patient Empowerment". How to make clear to the consumer these facts of life.
Last updated: Apr 12 2022 at 19:14 UTC
