Group 9.14 behavior when multiple US Core-defined v2 scopes apply to the resource

[jwjahns]

Hello,

USCDIv3 defines the Health Concern data element as part of the Problems data class. US Core 6 introduced granular scopes of:

• Condition.rs?category=problem-list-item
• Condition.rs?category=health-concern

These concepts can overlap, but across SMART, US Core, CCG, and HTI-1, authorization server behavior for overlapping granular scopes is not formally defined.

For example, consider a Condition with a category of both health-concern and problem-list-item, and an app authorized for patient/Condition.rs?category=health-concern but not for patient/Condition.rs?category=problem-list-item.

The g(10) Test Kit Group 9.14 tests, as currently implemented, require the Condition with both categories (above) to be shared with the app, but –

1. It’s unclear that this is the "correct" behavior. The opposite behavior is also justifiable
2. There’s no normative or regulatory language defining this expectation

This has sparked a conversation at chat.fhir.org which hasn't yet reached consensus: https://chat.fhir.org/#narrow/stream/179175-argonaut/topic/authorization.20of.20a.20resource.20that's.20in.20multiple.20categories

Ideally, US Core will patch a clear requirement to US Core 6.1 as part of the resolution to https://jira.hl7.org/browse/FHIR-46748, by defining normative requirements for multiple SMART granular scopes applied to a single FHIR resource. Until then, the extent of guidance to implementers is this section of the SMART App Launch spec:

As such, clients can attempt to perform FHIR operations based on the scopes they are granted — but depending on the details of the underlying permission system (e.g., the permissions of the approving user and/or permissions assigned in a client-specific policy) these requests may be rejected, or results may be omitted from responses.

Given the current ambiguity, and ultimate responsibility of the authorization server to determine appropriateness of sharing data, we suggest that test group 9.14 be modified to not mandate behavior around resources to which multiple granular scopes could apply.

This is detail is important, and also time-sensitive given certification timelines, so we’d appreciate any determination or clarification on this behavior.

Test Group 9.14, for reference: https://inferno.healthit.gov/suites/g10_certification/k32hPWG2xla#9.14

[isaacvetter]

Hey inferno folks, FYI - CGP just voted on this jira -- https://jira.hl7.org/browse/FHIR-46748, setting a direction for implementers of US Core to return resources which are described by multiple OAuth scopes, for which the client is authorized for only some of.

[jwjahns]

The test kit's current behavior matches the above Jira's clarification, so closing this issue