FHIR Chat · SMART and Basic · smart

Stream: smart

Topic: SMART and Basic

---

Jenni Syed (Jun 03 2019 at 18:39):

What would be the expectation if someone profiled Basic to create a draft resource from a SMART perspective?

Jenni Syed (Jun 03 2019 at 18:40):

My assumption was that it was similar to Binary, where you can say that both Binary and the referring resource was required. EG: patient/Binary.read and patient/DocumentReference.read

Jenni Syed (Jun 03 2019 at 18:41):

or would we not expect them to also have the Basic scope, since that is just a "placeholder" for draft resources?

Grahame Grieve (Jun 04 2019 at 00:36):

I'm not following. Basic is like any other resource

Jenni Syed (Jun 04 2019 at 14:21):

So, for Binary, you can enforce other scopes since "Binary" is a very broad swath of things to authorize. IE: Did you want pictures? DiagnosticReports? DocumentReference? What did they actually intend to authorize? This is communicated via: http://hl7.org/fhir/r4/binary.html#rest (for some reason, I can't link to 2.25.3.4 - it just goes to .3)

Jenni Syed (Jun 04 2019 at 14:22):

Basic is an even broader, more undefined bunch of things, since it can be literally any draft resource

Jenni Syed (Jun 04 2019 at 14:23):

It doesn't seem to have a security considerations section though

Jenni Syed (Jun 04 2019 at 14:23):

But trying to describe to a patient (for example) what granting access to "Basic" is seems pretty useless - even more useless than trying to describe Binary without that additional context

Jenni Syed (Jun 04 2019 at 14:24):

Since Basic is actually equivalent to Basic.code from a logical Resource perspective

John Moehrke (Jun 04 2019 at 14:25):

If you use Basic, you are on your own. I can't imagine how SMART could define any rules

Jenni Syed (Jun 04 2019 at 14:26):

Yes, Basic would imply (beyond SMART) that there is special code in an app that needs to use it, a lot of doc - though maybe an IG

Jenni Syed (Jun 04 2019 at 14:26):

And some usage of "pre-draft" resources - at least in our case

John Moehrke (Jun 04 2019 at 14:26):

I could imagine an IG could...

Jenni Syed (Jun 04 2019 at 14:27):

and, in our case, the hope that R5 brings the actual resource and Basic would go away

John Moehrke (Jun 04 2019 at 14:27):

good plan

Grahame Grieve (Jun 04 2019 at 14:38):

you can ask for access to a binary by media type, but I'm not aware of any arrangements for this in Smart?

Jenni Syed (Jun 04 2019 at 14:45):

@Grahame Grieve what do you mean? For SMART, to get access to Binary (and per that security considerations section), you can require access to patient/Binary.read AND some other resource (or, depending on how you interpret that section, only the other resources as described in the http://hl7.org/fhir/r4/binary-definitions.html#Binary.securityContext). IE: if securityContext = DiagnosticReport/1, you would need access to a DiagnosticReport.read scope, and the user/app would need to have ability to read that specific resource

Jenni Syed (Jun 04 2019 at 14:45):

The Basic concept seems pretty similar, except that it wouldn't be another specific resource instance

Grahame Grieve (Jun 04 2019 at 14:46):

I don't believe we've ever linked that statement to smart scopes.

Grahame Grieve (Jun 04 2019 at 14:47):

I think it makes sense to do so, but I don't think we have.

Jenni Syed (Jun 04 2019 at 14:48):

Our server does in DSTU 2 + :)

Grahame Grieve (Jun 04 2019 at 14:48):

there's lots of things I want to do to smart scopes, but we were waiting for round #2

John Moehrke (Jun 04 2019 at 14:48):

seems Basic should have the securityContext mechanism too...

Jenni Syed (Jun 04 2019 at 14:48):

Otherwise doing the ONC stuff would have been... interesting to describe to the patient

John Moehrke (Jun 04 2019 at 14:48):

yes, when does round #2 start?

Grahame Grieve (Jun 04 2019 at 14:48):

Basic has a subject. So I find it less compelling. Basic, like Observation, would be category or code

Jenni Syed (Jun 04 2019 at 14:48):

Basic wouldn't have that concept though - it's likely to be a resource on its own that isn't represented elsewhere ein FHIR

Jenni Syed (Jun 04 2019 at 14:49):

(to John's statement about securityContext)

John Moehrke (Jun 04 2019 at 14:49):

right... sorry

Jenni Syed (Jun 04 2019 at 14:49):

How do you describe to a patient what you're granting access to?

Jenni Syed (Jun 04 2019 at 14:49):

and how does an app describe what it needs access to?

Grahame Grieve (Jun 04 2019 at 14:51):

right. I have lots to say about those things. But I"m not sure how to comment further since you've done your own extensions... are you proposing not to to that here?

John Moehrke (Jun 04 2019 at 14:51):

I am lost... if Basic has a subject... then it is like all other patient focused resources... right?

Grahame Grieve (Jun 04 2019 at 14:51):

yeah, but how do you describe it to a patient? I see the problem, but it feels more like Observation

John Moehrke (Jun 04 2019 at 14:53):

I am still not clear how Basic is different than Observation... Are you assuming that the patient understands the concept and breath of Observation, but can't understand the Profiles you have created for Basic? They both seem just as hard to explain to a layperson. Im not even all that clear

John Moehrke (Jun 04 2019 at 14:54):

I did make an assumption that one would always be using a Profile of Basic... never having in the custodian system any Basic that is not compliant with some Profile of Basic... thus they are all describable

Jenni Syed (Jun 04 2019 at 14:54):

For Observation, there is a defined set of data that is included in there for all implementations

Jenni Syed (Jun 04 2019 at 14:55):

That is a lot to describe, and we would like to limit it more, but at least I can say " labs, measurements, ..."

Jenni Syed (Jun 04 2019 at 14:55):

Basic can literally be anything at all

John Moehrke (Jun 04 2019 at 14:55):

only if you have the same criteria that all instances of Observation are profiled...

John Moehrke (Jun 04 2019 at 14:55):

so can Observation

John Moehrke (Jun 04 2019 at 14:55):

I have heard Lloyd say so...

Jenni Syed (Jun 04 2019 at 14:56):

So, I can implement FHIR, with only Observation? :)

Jenni Syed (Jun 04 2019 at 14:56):

I'm dubious

Jenni Syed (Jun 04 2019 at 14:56):

Seems like a hackathon challenge

John Moehrke (Jun 04 2019 at 14:56):

You need to spend more time with Lloyd

John Moehrke (Jun 04 2019 at 14:56):

:-)

Jenni Syed (Jun 04 2019 at 14:56):

Patient can't be observation

Jenni Syed (Jun 04 2019 at 14:56):

Most individuals can't be

Jenni Syed (Jun 04 2019 at 14:57):

You're not supposed to do media as observation (unless it's an actual EKG)

John Moehrke (Jun 04 2019 at 14:57):

but you get my point... Your system only contains the Argonaut profiled Observations... thus you can explain all the Observation types

Jenni Syed (Jun 04 2019 at 14:57):

I know what he's saying in theory

John Moehrke (Jun 04 2019 at 14:57):

same with Basic.. you have only profiled Basic... thus you can explain the meaning of those profiles of basic

Jenni Syed (Jun 04 2019 at 14:57):

No, in my system, I can say observation in R4 means this now and will always mean this

Jenni Syed (Jun 04 2019 at 14:58):

I may implement a new resource in Basic in R4 later

Jenni Syed (Jun 04 2019 at 14:58):

that I can't imagine when I write the first profile

John Moehrke (Jun 04 2019 at 14:58):

you might add new observations too

Jenni Syed (Jun 04 2019 at 14:58):

Nope, I can say in my system, it matches with this definition of Observation

Jenni Syed (Jun 04 2019 at 14:58):

I won't be adding more outside of what FHIR says it is

John Moehrke (Jun 04 2019 at 14:59):

when a new medical concept comes around?

Jenni Syed (Jun 04 2019 at 14:59):

again, I'm not saying observation needs the capability to break it down more

Jenni Syed (Jun 04 2019 at 14:59):

that's SMART v2

Jenni Syed (Jun 04 2019 at 14:59):

so that vitals and labs etc can be described better

Jenni Syed (Jun 04 2019 at 14:59):

I don't think we don't currently implement something that is defined in the scope of Observation

Jenni Syed (Jun 04 2019 at 14:59):

My system has the equivalent of that "dumping ground" already

Jenni Syed (Jun 04 2019 at 15:00):

but also can more specifically categorize things

Jenni Syed (Jun 04 2019 at 15:01):

Whereas there's a large world of things FHIR hasn't implemented yet or has only in early draft

John Moehrke (Jun 04 2019 at 15:01):

so, my assertion is that it is not harder than Observation... you disagree. I can understand the more open-ended fact of Basic than Observation... what is your solution?

Jenni Syed (Jun 04 2019 at 15:01):

To use SMART scope "resource" == Basic.code

Jenni Syed (Jun 04 2019 at 15:01):

If you look at that value set, it's the equivalent of "Resource name"

Jenni Syed (Jun 04 2019 at 15:02):

And my understanding of usage today, outside going well beyond the spec, is that many have used it to give early feedback to proposed resources that aren't listed in "draft" yet in their current release

Jenni Syed (Jun 04 2019 at 15:02):

which means that in the next release, that same scope would still exist, but be exposed via a real resource vs. Basic

Jenni Syed (Jun 04 2019 at 15:03):

But I admit I'm looking at this through our intention of use with Basic (I've seen other descriptions here on zulip that match this though)

John Moehrke (Jun 04 2019 at 15:04):

reasonable. Now we just need to get SMART v2 going. Because there are many comments on improving the scope that were deferred in order to allow v1 to be Argonaut compatible... many people are waiting for v2 discussion to happen. We just need a sponsor and resources.

Lloyd McKenzie (Jun 04 2019 at 15:23):

With Observation, you're really driven by Observation.category. You have a terminology that groups Observations into meaningful collections that makes sense to both clinicians and patients and you can grant access on that basis. You can also often infer the category based on the Observation.code. In Basic, you've got the same thing through Basic.code. The main difference is that there's no proposed binding to leverage - it's a wild west, and is intended to be. So long as the Basic.code terminology is appropriately sized and clear, it's a reasonable basis for granting access and will hopefully be clear to patients. One of the challenges is that stuff in Basic will typically be somewhat "weird" so coming up with a name that will be intuitive to both patients and clinicians is going to be tricky.

Lloyd McKenzie (Jun 04 2019 at 15:24):

(And I don't think Lloyd has ever been a proponent of "everything's an Observation" - I'm a proponent of clearly defined resource scopes to avoid exactly that :>)

Grahame Grieve (Jun 05 2019 at 09:57):

Basic might need a category element

Lloyd McKenzie (Jun 05 2019 at 13:18):

The code element currently behaves as a category. We could rename it. The screams of anguish might give us enough evidence to move up the maturity of Basic :>

John Moehrke (Jun 05 2019 at 14:19):

one proposal for improving the SMART scopes is to include security tag values desired/authorized. This is needed for more privacy enabled use-cases. Related to Basic... of course ALL resources have .meta.security... and you can always define codes you want to use for security tags within your domain. You can use existing confidentiality and sensitivity codes, but you can define your own. This is already a consistent security mechanism across all resources. So security tags are an available solution that is built into fundamentals of FHIR, just needs to be added to SMART (already part of HEART, and IUA).
Note, I don't indicate that the category method should be abandoned, just offering security solution.

Josh Mandel (Jun 05 2019 at 16:55):

Do you prefer to cover this with incremental additions to the current syntax, or a new approach (like structured scopes)?

John Moehrke (Jun 05 2019 at 17:17):

excellent question. I would hope it is incremental.

John Moehrke (Jun 05 2019 at 17:19):

any use of security-tags is intended to be in addition to a scope that is patient specific, workflow specific (episode or time), etc. Security-tags are just another vector that access control would use to provide the right data to the right people/services while preventing the wrong data get exposed improperly.

John Moehrke (Jun 05 2019 at 17:38):

there are some 'attribute-based-access-control' (ABAC) purest, that have a model that all users are issued "clearances", and that those clearances are sufficient to support access control. (Where a clearance would have a direct map to a security-tag of the clearance necessary to access this data). This would still be possible in our environment. This would be a "new approach". However this model requires active management of these clearance values on all data constantly, which is possible, but puts much of the management on the data. Note that this clearance model is what one commonly sees in TV-shows and movies depicting military 'special projects'. Thus all the data for special project - opossum is tagged with the opossum tag, and all users that are on the project are given the opossum clearance. It must be defined if owing the opossum tag gives only read access, CR, CRU, or all of CRUD. If differentiation is needed between for example Read access from CRUD access; then I guess two clearance are managed with the same tag.
I think this model is also commonly used in internet services like wiki, blog, and possibly in github. I say "think" as it appears to work this way, but I don't have insider knowledge. Where the end users are managed by project leaders who can bring other users into their project, and by being in the project you go from just read access, to CRUD access. Note that in an ABAC model the tags that go on the data are called... "compartments".... This ABAC concept of "compartments" is architecturally related to the http REST concept also called a "compartment"... <mic-drop/>

Isaac Vetter (Jun 06 2019 at 17:10):

What I'm taking away from this thread is that SMARTv2 should occur soon and a solid outcome would be enabling scopes at the resource.category level.

John Moehrke (Jun 06 2019 at 17:49):

that is what you got out of my ABAC? hmmm... should have been a desire for scopes that include a security-tag vector.

Josh Mandel (Jun 06 2019 at 21:10):

;-) What I'm taking away is that different people have different "nice-to-haves" and "must-haves".

Josh Mandel (Jun 06 2019 at 21:10):

Maybe we could each start writing a list of what we consider in each category for SMART scopes v2.

John Moehrke (Jun 07 2019 at 01:07):

yes there should be a small number of patterns.

Grahame Grieve (Jun 07 2019 at 04:02):

we should definitely start working on smart v2. And scopes is where most of the work will lie, I think. Unless we want to add app registration (I'd be fan). And maybe we want to spec the relationship between AS and RS (not a fan)

Isaac Vetter (Jun 07 2019 at 04:06):

Hey @Grahame Grieve , all -- just threw this together: https://github.com/smart-on-fhir/smart-on-fhir.github.io/wiki/scopes-v2

Isaac Vetter (Jun 07 2019 at 04:07):

(I tried to put it on the github.com/hl7.smart-on-fhir/wiki, but didn't have permissions).

Isaac Vetter (Jun 07 2019 at 04:08):

Will y'all add your needs/priorities for what a SMART scope should describe on this wiki page, keeping in mind John's goal of "a small number of patterns".

Grahame Grieve (Jun 07 2019 at 04:08):

I think that the patient decision point is at a different granularity to resources. Observation is too coarse, medication request/dispense is too fine.

Grahame Grieve (Jun 07 2019 at 04:09):

and when I talk to patients, their real concerns are about the functional impact of the information, not the type of the information, so scopes are a total mishit for patients

Isaac Vetter (Jun 07 2019 at 04:09):

agreed! Yet, the patient login screen must present her with the requested scopes.

Isaac Vetter (Jun 07 2019 at 04:10):

hmmm, what would be a successful representation of "the functional impact of the information" ?

Isaac Vetter (Jun 07 2019 at 04:10):

data use information? secondary use explanation?

Grahame Grieve (Jun 07 2019 at 04:10):

so I'm saying that the scopes are wrong. And I don't want to just enhance the current pattern without asking whether there's a better alternative

Grahame Grieve (Jun 07 2019 at 04:14):

for me, this is how I feel as a patient:

• allow this application to write: Y/N
• current summary (e.g. emergency summary) vs all medical information is a decision
• don't release: contact details | STD | reproduction | substance abuse | mental health
• don't release: information marked as confidential

(as long as I can mark information as confidential somewhere)

Grahame Grieve (Jun 07 2019 at 04:15):

maybe that's a little too coarse, but when i've talked to non-programmers, those are the terms they are thinking in. The second is interesting - there's lots of 'emergency summary apps' but we don't provide smart support for the scopes that are relevant for that

Isaac Vetter (Jun 07 2019 at 04:18):

Grahame, some of the information that we (Epic) try to collect during patient-facing app registrations is:

Isaac Vetter (Jun 07 2019 at 04:19):

• How is the app funded?
• Where does the app store data?
• How long does the app store my data?
• Can I delete my data?
• Who has access to my data?
• Can I get my data from the app?
• What are the secondary uses (research, ads, etc)
• does the app have a BAA with my provider?

Isaac Vetter (Jun 07 2019 at 04:19):

These are finer-grained than yours, both are way more complex than an enhancement to existing SMART scopes. We'd need a whole new language.

Isaac Vetter (Jun 07 2019 at 04:19):

both sets of questions are highly targeted, however. We should use that.

Grahame Grieve (Jun 07 2019 at 04:20):

I think those are important to display to the user,but what does the user decide about those other than yes or no to the scopes? (e.g. I think they are not scopes but something to capture formally if we take on app registration)

Isaac Vetter (Jun 07 2019 at 04:21):

but something to capture formally if we take on app registration

Yes, you're right. It's important to distinguish between app registration details and scopes.

Isaac Vetter (Jun 07 2019 at 04:22):

What would emergency summary vs all medical information mean? Something like only active clinical resources ?

Grahame Grieve (Jun 07 2019 at 04:24):

clinical decision on the server side, I think. I'd make it something like current meds, allergies, problems, and leave out documents, observations etc

Grahame Grieve (Jun 07 2019 at 04:25):

the characteristic feature of my choices above is that they are orthogonal to the API calls, difficult to implement, and in some cases, not subject to computation. All of which are a problem....

Isaac Vetter (Jun 07 2019 at 04:26):

lol

Grahame Grieve (Jun 07 2019 at 04:26):

but I think this is important if we're going to scale this. The current choices are far from satisfactory.

Isaac Vetter (Jun 07 2019 at 04:26):

my take-away here is that scopes should be appropriate for the user, not the system. Even though they might be difficult for the system, that's still the right approach.

Grahame Grieve (Jun 07 2019 at 04:27):

the contact details thing - critical for domestic violence situations...

Isaac Vetter (Jun 07 2019 at 04:27):

and user privacy in general

Isaac Vetter (Jun 07 2019 at 04:29):

Alright, probably we need to create something completely new. Focused on the user (mostly meaning the patient). We need brilliant minds like Josh's on it ...

Grahame Grieve (Jun 07 2019 at 04:43):

Josh and I have discussed this before. It may be that I merely want to repeal the laws of mathematics... so let's not say "need" - but I do think we need to talk/think about it hard. Perhaps we can do an informal session on this at DevDays

Isaac Vetter (Jun 07 2019 at 04:47):

I expect this will be a year+ of conversations. I updated https://github.com/smart-on-fhir/smart-on-fhir.github.io/wiki/scopes-v2 with some of your feedback. Hopefully, this page will be a source of inspiration.

Rien Wertheim (Jun 07 2019 at 05:50):

Josh and I have discussed this before. It may be that I merely want to repeal the laws of mathematics... so let's not say "need" - but I do think we need to talk/think about it hard. Perhaps we can do an informal session on this at DevDays

Great idea, since everyone on this thread seems to be there anyway. Send me a title and a summary please and we will add a pop-up session to the schedule. @Isaac Vetter can you do the introduction in the session?

Grahame Grieve (Jun 07 2019 at 05:53):

I have 4 popup sessions now - was going to get to this over the weekend:
- Slicing and polymorphic types
- packaging and composition plans
- returning extensions in value set expansions
- + this subject

Grahame Grieve (Jun 07 2019 at 05:54):

I'm not sure whether this subject is "plans for smart v2" or "scope plans for smart v2"

Rien Wertheim (Jun 07 2019 at 11:36):

I'll do Plans for SMART v2. @Sebastiaan Knijnenburg want to join?

John Moehrke (Jun 07 2019 at 13:56):

Another common vector a patient desires to block (or explicitly allow) is purely time-range based.

John Moehrke (Jun 07 2019 at 13:59):

most radical scopes pattern, that I am sure is not viable... using query parameters as scopes -- https://healthcaresecprivacy.blogspot.com/2017/05/fhir-oauth-scope-proposal-using-fhir.html

John Moehrke (Jun 07 2019 at 13:59):

This one just adds a very few Privacy vectors to the current smart scopes -- https://healthcaresecprivacy.blogspot.com/2016/01/fhir-oauth-scope.html

Josh Mandel (Jun 07 2019 at 21:18):

Just catching up here -- love the discussion. I think there are competing needs on scopes, and we may want a couple of families/approaches to address

1) User approval of access (this has clearly been the focus for SMART user-facing apps, and it's the #1 priority)

2) Machine-readable access policies (which is especially important for backend services, or generic authorization servers trying to enforce policies consistently without relying on proprietary / out-of-band definitions)

Should we start by saying our focus right now is on (1), and we might address (2) through a separate effort in the future?

Isaac Vetter (Jun 08 2019 at 03:23):

@Rien Wertheim - I'd be honored to introduce the topic. I'll walk through current state and explain some of the needs as I understand them and encourage discussion.

Isaac Vetter (Jun 08 2019 at 03:53):

Title: Zooming in on FHIR authz: How can we improve SMART scopes?

Abstract: SMART on FHIR is the defacto authorization layer used by FHIR apps. Built on the widely deployed OAuth 2.0 authorization code flow, it tightly integrates FHIR resources with a launch extension. SMART's scope syntax has served us well, but is beginning to strain under the needs for finer grained control -- should patient/Observation.read really authorize access to all lab results and my steps? While both loved and maligned, does the patient/*.* scope really communicate to the consumer the data they're sharing?

• How can SMART scopes fit patient's goals for sharing?
• How can clinical systems better implement these scopes?

Let's figure out what the future will hold!

Isaac Vetter (Jun 08 2019 at 03:57):

@Rien Wertheim, All - does the above work for a pop-up session next week?

Sebastiaan Knijnenburg (Jun 08 2019 at 05:19):

I'll do Plans for SMART v2. Sebastiaan Knijnenburg want to join?

Definitely! I think there's quite some overlap between the 'Exploring SMART on FHIR for research and quality purposes' (see https://chat.fhir.org/#narrow/stream/179170-smart/topic/SMART.20for.20research.2Fquality.20purposes) and this session, but both have a slightly different angle. Looking forward to it!

John Moehrke (Jun 08 2019 at 14:53):

Nice to see movement. Yes @Isaac Vetter that is a fine outline. I look forward to seeing the results. I hope you get some people willing to engage with real-world needs and real-world 'reality'.

Rien Wertheim (Jun 08 2019 at 19:45):

This is perfect. I will forward this to Marita, who keeps track of the popups.

Isaac Vetter (Jun 10 2019 at 17:14):

Hey everyone, we'll be zooming into SMART scopes this afternoon at 3:50 in McKinley! Session details should be soon on the web schedule. @Sebastiaan Knijnenburg @John Moehrke @Jenni Syed @Grahame Grieve @Josh Mandel

Isaac Vetter (Jun 10 2019 at 22:43):

Hey Everyone -- meeting now in McKinley (back right corner)

---

Last updated: Apr 12 2022 at 19:14 UTC