Details
-
Change Request
-
Resolution: Persuasive with Modification
-
Highest
-
SMART on FHIR (FHIR)
-
current
-
FHIR Infrastructure
-
STU
-
App Launch: Scopes and Launch Context
-
2.2.4
-
-
Alexander Zautke / Yunwei Wang: 8-0-0
-
Enhancement
-
Compatible, substantive
Description
While the search parameter based syntax here is quite general, and could be used for any search parameter defined in FHIR, we're seeking community consensus on a small common core of search parameters for broad support.
There is difference in indicating the scopes that are supported, the scopes that are requested and those that are granted. As long as a client does not change the scopes, this should not cause any issues. The trouble is in a client requesting non-standard/published scopes. Isn't the ruling on that a client MAY use them and server MAY grant them?
Initially, servers supporting SMART v2 scopes SHALL support: category= constraints for any supported resource types where category is a defined search parameter. This includes support for category-based Observation access on any server that supports Observation access.
Why is this mandated? Isn't up to the server to decide what resources and scopes it offers and communicate this in the /wellknown endpoint?
Suggest to remove this requirement.
Attachments
Issue Links
- is voted on by
-
BALLOT-17341 Negative - Bas van den Heuvel : 2021-May-HL7 FHIR IG SMART APP LAUNCH R2 STU
- Closed
-
BALLOT-17701 Negative - Ana Kostadinovska : 2021-May-HL7 FHIR IG SMART APP LAUNCH R2 STU
- Closed
-
BALLOT-17763 Negative - Ricardo Quintano : 2021-May-HL7 FHIR IG SMART APP LAUNCH R2 STU
- Closed
-
BALLOT-17807 Negative - Timon Grob : 2021-May-HL7 FHIR IG SMART APP LAUNCH R2 STU
- Closed
-
BALLOT-17847 Negative - Chris Melo : 2021-May-HL7 FHIR IG SMART APP LAUNCH R2 STU
- Closed
-
BALLOT-17906 Negative - Javier Espina : 2021-May-HL7 FHIR IG SMART APP LAUNCH R2 STU
- Closed