Possible to have both system and provider launch scope?

[jlie...@gmail.com]

We have an application that providers and coders use.  It generates documentation that then gets signed and into pushed into the medical record.  The documents are signed by the provider.  We originally designed the integration with Cerner with a system scope because there is some offline, delayed asynchronous communication that happens even after a provider logs out.  The problem is that the DocumentReference requires a FHIR resource id for the practitioner who signed the note.  We have not found a good way of getting the resource id for a provider user except via the data returned from a SMART launch.  A couple questions.

1. Can an application be registered twice?  Once for provider access and once for system access.
2. Is there any mechanism for getting the resource id's for all providers external to a standard FHIR call?

[Kristof Taveirne]

Hi,

I'm having a simular issue. 

I just now registered a separate App and requested and new account with Provider scope next to the System scope.

We're looking into using OpenID to authenticate the users, hoping we can get the related Practitioner resource from that.

Maybe that's a solution for you as well if you already have authentication support?

I've read the following paragraph on the wiki (https://fhir.cerner.com/authorization/ under the section "Identity Scopes: ‘openid’ and ‘profile’")

The scope ‘profile’ will additionally request that the OpenID Connect token include the claim “profileURL”, as defined by the SMART® on FHIR® authorization framework. This URL identifies the specific FHIR® resource URL of the authenticated user.

So, then at least we can fetch the Practitioner after authentication and use it later as the author of the DocumentReference when we create the DocRef using the  System scope account. (or we could use the offline access mechanism method) 

If we would be able to search for a Practitioner using some attributes the user actually knows (like email, or Identifiers), that would simplify a lot.

That's the direction I'm looking into right now ... don't know if this is helpful for you.

Kind regards,

Kristof.

Op woensdag 2 januari 2019 16:21:58 UTC+1 schreef jlie...@gmail.com:

[jlie...@gmail.com]

Yes, that is the same approach I am taking.  Ideally, we wouldn't want to have to register twice, but for now that's what we've done.  Not sure what complications having a system registered twice does to the certification, approval, and marketing processes.

Jake