Define a mechanism to declare support for specific capabilities

[jmandel]

The SMART on FHIR specification leaves open the question of which capabilities a given EHR server needs to support. To help drive more consistent support, we can take two steps:

1. Define a way for SMART on FHIR servers to explicitly list the capabilities they can support
2. Define a set of "Core Capabilities" that represent a useful target for general implementations

Draft definitions at:

https://github.com/smart-on-fhir/smart-on-fhir.github.io/blob/into-hl7/conformance/index.md
https://github.com/smart-on-fhir/smart-on-fhir.github.io/blob/into-hl7/conformance/core-set.md

[nschwertner]

Modularizing a SMART on FHIR implementation and formally describing it via the core capability concepts makes sense. This will provide an achievement-style staged road map for future implementations where partial implementations are not seen as failure. Also, sets the stage for extending the standard in a discoverable way. Two observations here:

1. I am not sure that CapabilityStatement.rest.security is the most logical place for the core capabilities in a FHIR server's CapabilityStatement however, since a number of them have little to do with security (context-style, launch-standalone, etc). In general, authentication/authorization is not the only problem addressed by SMART.

2. It looks like the Core SMART on FHIR Capabilities package includes all the currently defined capabilities except permission-offline. I wonder what the reasoning here is? If permission-offline is viewed as icing on the cake for a SMART on FHIR implementation, then the same could be argued for context-banner and context-style...

[jmandel]

Thanks @nschwertner. For (1), is there a different place you'd naturally put this info?

For (2), I think offline is in the core list (it shows up for me):

[nschwertner]

Cool. I didn't see the refresh token in the core list description file which made me wonder (db07b55)

Regarding (1), I don't see any better place to put it in the current definition of the CapabilitiesStatement. Just saying that security is not a perfect fit. I imagine that adding a special purpose parameter for app capabilities description could be part of the next STU if this takes off.

[davidhay25]

The core capabilities seem to refer to the various ways and contexts in which the app can be launched (?correct)

What is the thinking around specific scopes (read/write access to specific resources) and resource content profiles?

[jmandel]

You're correct, @davidhay25.

Overall, there are a great number of combinations of these granular permissions, and

1. I'm not sure we can get the details perfectly correct "in general".
2. I'm not in love with our permission model, and while I don't propose to revise it here, neither do I want to invest too much more in it.

I might rather fall back to the server's stated capabilities (via standard FHIR properties) with the expectation that if a server can support reading or writing a particular resource, then the relevant scopes should also be supported. It is not a perfect assumption, but I suspect it is a lot of bang for the buck.

[davidhay25]

That would seem to be a pragmatic way for the client to understand a servers capabilities. So SMART won't itself define (or refer to) a profile - rather leave that to the individual client/server interaction...

…

On Wed, Apr 12, 2017 at 1:21 PM, Josh Mandel ***@***.***> wrote: You're correct, @davidhay25 <https://github.com/davidhay25>. Overall, there are a great number of combinations of these granular permissions, and 1. I'm not sure we can get the details perfectly correct "in general". 2. I'm not in love with our permission model, and while I don't propose to revise it here, neither do I want to invest too much more in it. I might rather fall back to the server's stated capabilities (via standard FHIR properties) with the expectation that if a server can support reading or writing a particular resource, then the relevant scopes should also be supported. It is not a perfect assumption, but I suspect it is a lot of bang for the buck. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#136 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFYPFE9vDvkhE1G1xCqBOBm6ILMufuBVks5rvCcNgaJpZM4M5Onz> .

[daliboz]

for these capabilities:

context-patient: support for patient-level launch context (requested by launch/patient scope, conveyed via patient token parameter)
context-encounter: support for encounter-level launch context (requested by launch/encounter scope, conveyed via encounter token parameter)

Are these intended to also cover if these contexts are returned when just "launch" scope is requested (in the ehr launched scenario) and not just the standalone? Or only intended to cover the standalone launch scenarios that would use launch/patient and launch/encounter?

[jmandel]

The intention would be that these context parameters are available for both EHR Launch and Standalone Launch @daliboz; would you propose separating these out?

[daliboz]

I think we should clarify the text to indicate it's not just applicable to launch/patient and launch/encounter if that's the direction this goes.

As to separating them:
In our current implementation, we do support both contexts during an embedded launch. So, declaring only embedded launch along with those would indicate they weren't supported in standalone. If we added support for standalone, the question would be if we would implement both encounter and patient at the same time (patient is the one that is typically requested)... Would be interesting to know what others have done as well?

[isaacvetter]

Hey @daliboz , @jmandel,

I think that we should consider grouping the declaration of support for the launch-context capabilities under or within the launch modes. context-banner and perhaps context-style don't really make sense to be used for launch-standalone.

We primarily only support contextual launch parameters from EHR/embedded launches.

Standalone launches with contextual launch parameters can only be supported if the EHR provides a selector UI to the authorizing user. The value in a patient/encounter selector is to enable dynamic OAuth scopes. E.g. A provider only wants to enable an app to access data on her behalf for a specific patient's encounter. We don't currently support these types of dynamic scopes, so we, therefore, also don't have this selector UI.

Isaac

[isaacvetter]

Referring to: http://www.hl7.org/fhir/smart-app-launch/conformance/core-set/

Making the context-standalone-patient and context-standalone-encounter part of the core capabilities of a SMART server require that the server implement a "patient/encounter picker". This UI element seems above and beyond the basic authnz functionality provided by the rest of the minimal, "core" functionality defined in Core Capabilities.

I think that context-standalone-patient and context-standalone-encounter should be removed from Core Capabilities.