Stream: cds hooks
Topic: 'sub' key in JWT token
Kevin Olbrich (May 08 2018 at 13:40):
@Kevin Shekleton what are your current thoughts about the 'sub' key in the JWT token? There's a comment in the sandbox 2.0 issues where you suggest that it might get dropped from the standard.
Kevin Shekleton (May 08 2018 at 14:15):
@Kevin Olbrich - I logged a ballot comment regarding that -- I don't know what value it is providing today. I haven't sat down and really put a ton of thought into what the intention behind that value was trying to serve and any threats it was trying to mitigate. I plan to do that this week/next :)
Kevin Olbrich (May 08 2018 at 14:21):
We're trying to figure out how to associate a particular cds-hooks invocation to an organization. The 'sub' (client_id) field would be one way for us to be able to do that since some of our partners are multi-tenant, which prevents us from just using the 'iss'.
Kevin Shekleton (May 08 2018 at 14:24):
Ah, the same old SMART on FHIR issue too :-)
The way in which the sub field is documented today wouldn't necessary do what you're wanting to do. Today, it is documented as "Client_id of the EHR." The intention from our security auditor was that this is the OAuth 2 client id of the EHR from the Authorization Server (AS). I don't think it is a safe assumption that EHRs will have a client id with the AS.
Kevin Shekleton (May 08 2018 at 14:26):
And by SMART on FHIR issue, I'm referring to this issue here: https://github.com/smart-on-fhir/smart-on-fhir.github.io/issues/133
Kevin Olbrich (May 08 2018 at 14:29):
Hmmm... looks like that didn't actually come to any sort of resolution.
Kevin Olbrich (May 08 2018 at 14:31):
maybe we could just add an optional 'org' attribute and populate it with a FHIR Organization ID that is known to the cds-service provider.
Kevin Shekleton (May 08 2018 at 14:34):
Yeah, we couldn't agree on the name or the semantics of the value. It is just a tough issue because each vendor/app/service has different expectations for what the value should be.
Kevin Shekleton (May 08 2018 at 14:37):
Tagging along to your thoughts, perhaps our best chance to standardize is simply come up with an optional attribute with a name we all agree upon whose value is <list of all of the ways in which apps/services need this similar type of value>.
So, the field name is consistent and the value relates to these different uses everyone has for it. Whether that is a billing code, a logical identifier for the separation of data, an org/facility identifier, etc.
Jim Cain (May 08 2018 at 14:39):
Yes, perhaps specify it as an optional opaque value that has whatever semantics that are meaningful to the consuming system.
Kevin Shekleton (May 08 2018 at 14:47):
Yeah, I agree @Jim Cain
Jim Cain (May 08 2018 at 14:50):
But then that sounds a bit like the ability to include in the payload any claims that are meaningful to the consuming system, so does that really need to be part of the standard?
Kevin Shekleton (May 08 2018 at 14:51):
Now you're asking the questions that caused us to ultimately stop trying to standardize this in the SMART space :-)
Kevin Shekleton (May 08 2018 at 14:53):
I think there may be value in having a consistent field/means in which we all communicate this value. Additionally, this need comes up continually -- both in SMART and here in CDS Hooks. So, addressing it (even if it is just in the documentation rather than some field) would help others see our discussion/thoughts on this, how we're handling it (or not), etc.
Jim Cain (May 08 2018 at 15:09):
Back on the standards argument: It seems like you would want a standard way during discovery to describe the contents of that secondary identifier field, so that integration partners don't have to make any additional development effort to support your hooks.
Kevin Olbrich (May 08 2018 at 15:41):
We could probably work around this limitation if the sandbox gave us the ability to 1) see the contents of the JWT token, and 2) add arbitrary key-value pairs to the token on a per hook basis. Then individual service providers can specify which keys they need in an implementation guide.
Bala Sultanov (Jul 01 2021 at 20:37):
@Kevin Olbrich I am in a similar situation where we are trying to identify the specific tenant that's generating the CDS-hook call. Have you guys figured this out. I would appreciate any help.
Dennis Patterson (Jul 21 2021 at 21:49):
@Bala Sultanov CDS Clients can send a tenant in the Authorization header JWT payload sent to a CDS Service. https://cds-hooks.hl7.org/1.0/#trusting-cds-clients
Bala Sultanov (Jul 21 2021 at 21:57):
Dennis Patterson said:
Bala Sultanov CDS Clients can send a tenant in the Authorization header JWT payload sent to a CDS Service. https://cds-hooks.hl7.org/1.0/#trusting-cds-clients
Hi Dennis, thanks for your reply. Really appreciate it. Do you guys practice that at Cerner for multi-tenant hospitals? If a specific hospital triggers a cds-service call do you guys send a unique id for that tenant as part of JWT payload? It is not the case for Epic CDS-Service calls and we have been trying to figure out a workaround for that. Appreciate your time.
Last updated: Apr 12 2022 at 19:14 UTC
