SMART-on-FHIR needs Additional Claims in OpenID Connect

75 views
Skip to first unread message

Michael Juhl

unread,
Jan 10, 2022, 11:21:05 AMJan 10
to Cerner FHIR Developers
We have a large shared customer base that uses our product and Cerner.  We want to use the SMART on FHIR launch so that our users have a single sign on experience. Our implementation requires that the OpenId Connect token pass the Active Directory credentials for the user context so that we can manage role based authorization in our application. The Cerner SMART-on-FHIR implementation does not support this and we would like to know if this will be added in a future release.

Fenil Desani (Cerner)

unread,
Jan 10, 2022, 3:19:19 PMJan 10
to Cerner FHIR Developers
Hello,

As per group guidelines we cannot comment on future release/timelines!

Thanks,
Fenil

Matt Randall (Cerner)

unread,
Jan 10, 2022, 5:12:17 PMJan 10
to Cerner FHIR Developers
Just to confirm what you are requesting:  you are looking for one or more Active Directory identifiers to be returned within Practitioner.identifier (SMART doesn't directly return identifiers, so I assume the payload in question must be being returned as an identifier as part of the referenced Practitioner record in the OIDC token)?

If so, are you expecting userPrincipalName (urn:oid:1.2.840.113556.1.4.656) as the type of attribute for global uniqueness?



On Monday, January 10, 2022 at 10:21:05 AM UTC-6 michae...@med.ge.com wrote:
Message has been deleted
Message has been deleted

Michael Juhl

unread,
Jan 13, 2022, 9:56:04 AMJan 13
to Cerner FHIR Developers
Just to clarify the ask, SMART on FHIR launch already returns a token with claims in it. We are simply requesting to add a claim for user context (down level logon name) and a claim for order/test result context. This will optimize the launch process and reduce cost for our large shared customer base.

Matt Randall (Cerner)

unread,
Jan 14, 2022, 11:17:33 AMJan 14
to Cerner FHIR Developers
"down level logon name" -- in context of your Active Directory integration, is this sAMAccountName, or userPrincipalName?

As a follow-up, is there any form of presumption that a customer must have integrated the electronic health record with an instance of Active Directory to function?  Is there a required cardinality between those systems (1:1), or should this function with multiple possible Active Directory domains?  In the case of the latter, I presume userPrincipalName must be used?

"a claim for order/test result context" --  are you referring to an Encounter resource, here?  Or, something else?


Reply all
Reply to author
Forward
0 new messages