- Patient vs 'user' --
- Where a scope of 'patient' means all results must be from that one patient
- Where scope of 'user' means all results are relative to that user rights to data
- fhir-resource --
- Where a FHIR Resource named will limit results to only that Resource type
- This is a valueset of fixed strings (e.g. "Observation", etc)
- REST operation
- SMART specification - Scopes and Launch Context
- David Hay - SMART - Scopes and Profiles
- My - alternatives to SMART scopes - FHIR Scopes
- My - Healthcare access control scope constraints on OAuth tokens
patient/Observation.readA problem with this is that the actual identifier of the "Patient" is undefined. For SMART this is handled by the 'launch context'.
Propose using common "patient" query parameter for patient scopeWith the new FHIR STU3 common shared query parameters, we could identify the specific patient within the Scope. There is a common query parameter for "patient" against 35 different Resources. This has an advantage to be specific, but has a disadvantage that the scopes are not made up of static strings. I would like to suggest that this use of shared query parameters would be a replacement form the first part of the SMART scopes.
So, rather than relying on the SMART launch context to hold the patient identifier. The example with a patient of 'http://myserver.example/fhir/Patient/f5c7395'
More common query parameters
- _id -- when the scope is restricted to exactly ONE resource
- _tag -- when the scope is restricted generally to some tag
- _profile -- when the scope is restricted to some specific _profile tag
- _security -- when the scope is restricted to some vocabulary from the HCS (e.g. confidentiality of "N" normal)
- encounter -- when the scope is restricted to a specified encounter
Clearly missing but needed
- Timeframe for when the data was created - used to hide timeframe or enable a timeframe
- Authored by - used when policy allows only data authored by some org or user