#FHIR DevDays: Smart Scopes

Jun 14, 2019

One of the subjects we discussed at DevDays in Redmond Seattle (2019) was starting to plan what changes to make for scopes in v2 of the Smart App Launch specification.

The scopes are used as the language for the user, the resource owner, and the application to negotiate how much access the user wants to grant to the application.

The current scopes are fairly simple:

In principle, these are simple: read and/or write resource to all or particular resources, and do so as the patient, or as a regular system user (reading the syntax backwards there).

We’ve long known that there’s problems with these scopes:

  • The scopes are too fine grained for some resources - the user isn’t interested in differentiating between (e.g.) DocumentReference and DocumentManifest
  • Some of the resources don’t make sense as as a scope - List, for instance
  • Some of the resources need a finer grained scope - particularly Observation. Users don’t grant access to “Observations” - they would think in terms of Vital Signs, Labs, Clinical Measures
  • All of that is assuming we are talking about clinical users. Patients would generally think in functional terms - ‘all my records except for my X”, where X could be something like:
  • contact details (e.g. in the case of domestic violence)
  • STD history
  • Mental Health
  • Substance Abuse History
  • Pregnancy record history (newly a concern in USA)

The problem with the last set of choices is that we don’t know how to compute those kind of choices - so the APIs can’t enforce them. That’s work in progress.

So we have plenty of open issues, and it’s now time to start working on them. Some outcomes from our discussion at DevDays (credits to Isaac Vettor from Epic for the notes and running the discussion):

Next steps:

  1. As a research step, collect and share the different production, SMART authorization servers’ user-facing description of scopes. How are production AS’s describing SMART scopes to users now?
  2. Simply adding in resource categorycategorys to our existing SMART syntax may quickly and simply alleviate a lot of the pain. Why not simply toss the resource category’s name into the scope. e.g. patient/Observation:lab.read  patient/Observation:activity.read patient/Condition:encounter-diagnosis.read
    • Somewhat related: specify a method for an OperationOutcomeOperationOutcome to specify the scope that would be required to resolve an access denied error to enable a progressive authorization approach. (a la enabling a HATEOAS approach).

  • While SMART already describes a method for authorizing non-FHIR scopes by prefixing the scope with __ (two underscores), it doesn’t explicitly describe how to describe access to FHIR operations.

  •  Is there something we want to do withconfidentiality classification? E.g. set a baseline confidentiality across resources (“normal”?), and if an app wants to access higher levels (e.g. “restricted” or “very restricted”) there is an additional scope that needs to be requested?

If you’re interested in follow ups to this - see Zulip

Btw, several implementers have asked me about the problem that the Smart App Launch scopes are not fine grained enough to give proper security control over the user’s access to the resources and services provided by the server.

The scopes are not intended to be a language used to manage access control for the user; they are just a language for the user to authorize the application, and they can’t grant the application any access that they themselves do not have on the underlying system.

Note that we’ve talked occasionally about extending HL7 standards to cover security provisioning, but vendors are by and large uninterested (it’s too invasive for system design, and too hard to get perfect, and it’s an area that demands perfection). So we have no technical standards, though we have published a standard describing ideas for standard roles in the past.