Workflow or API calls:
Reminder: If this is referring to a client domain or EHR activity—not the public sandbox—do not include API request data or live patient data.
Background Information:
Failure to provide answers will impact our ability to respond in a timely and effective manner
Developer questions:
Are you an OPN Member? Yes
Have you signed up to be in the Healthcare Developer Track? Yes
Are you a registered Code Program member? Yes
Does your App have a presence on the Oracle Healthcare App Marketplace? Yes
Are you developing on behalf of an Oracle Health client?
If so, which client:
Application's Client ID and App ID, if relevant:
Our Client ID: 355dd40a-e8c8-48d4-bc9c-06d88458fbc5
Our Application ID: f52ab19d-d1d1-45e1-8037-2817de6ae7e1
Summary
When our app is launched from a Cerner mPage (or from a test patient in Code Console), we request SMART scopes including patient-level read access (e.g. user/Patient.read or launch/Patient.read). No matter what scopes we request, we consistently receive tokens whose granted scopes are trimmed down to only "openid fhirUser launch online_access". This subsequently causes authorization errors when we try to read patient data from FHIR.
What we've already checked
- aud matches tenant's FHIR base
- Issue occurs when launched from Cerner patient chart or code console patient
- Within the code console, we've checked/enabled all the scopes
- We understand the granted scopes are the intersection of the requested scopes + app registration + context. We suspect our app registration and/or tenant policy may not be allowing resource scopes, or the server is trimming them down for other reasons.
- Issue does not occur when we target the fhir-open environment, presumably because it does not enforce scopes.
Requests for assistance
1. Could you please review our app registration and confirm that the following scopes are enabled/approved for our client ID?
'launch'
'openid'
'fhirUser'
'online_access'
'user/Patient.read'
'user/Observation.read'
'user/AllergyIntolerance.read'
'user/Condition.read'
'user/Condition.write'
'user/Immunization.read'
'user/Procedure.read'
'user/FamilyMemberHistory.read'
'user/Coverage.read'
'user/Appointment.read'
'user/MedicationRequest.read'
'user/Encounter.read'
'user/DiagnosticReport.read'
'user/Practitioner.read'
'user/Location.read'
'user/DocumentReference.read'
'user/DocumentReference.write'
- Are there tenant policies or persona restrictions that would cause trimming to the four generic scopes, even when launched from a patient chart?
3. From the correlation ID listed below, can you tell if there's any mistake we're making during the authentication/authorization process that would cause the scopes to be trimmed?
IDs and Details
Our Client ID: 355dd40a-e8c8-48d4-bc9c-06d88458fbc5
Our Application ID: f52ab19d-d1d1-45e1-8037-2817de6ae7e1
Tenant: ec2458f2-1e24-41c8-b71b-0e701af7583d
Token Request Correlation ID: 46378e5b-997a-4f2c-b30a-b67fb48458f0
Scopes requested (example): "launch launch/patient openid fhirUser online_access patient/Patient.read"
Scopes received (always): "fhirUser launch online_access openid"