How to indentify which EHR system is requesting my application?

[Waqas Durrani]

Hello Everyone,

I am developing a single Smart on FHIR provider facing application for EPIC, Cerner and Allscripts. Can anyone tell me how can i uniquely identify each EHR system in my application.

Please help me.

Thank You.

[Travis Cummings]

The technique we have used is to configure our app at the healthcare site to send a SOF custom launch parameter such as “ehr-vendor”=“epic”. This is a custom solution and not a standard though. Prior to that we mapped the ISS to {client-id, ehr-vendor, ...}.  

I think neither is a great solution but they give you something to move forward with.

Travis

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "SMART on FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Waqas Durrani]

Makes sense to me. Thank You.

[Josh Mandel]

I had a similar discussion at chat.fhir.org recently, and I wonder if I'm missing something important here. This is a problem that "iss" was intended to address (i.e., ensuring that a client knows which system it's being launched from).

Travis, you are obviously familiar with the issuer parameter, since you previously used it to access a client-side map from issuers to EHR vendors. Can you say a bit more about why you moved away from this approach and introduced a new custom parameter?

Thanks!

Josh

[Travis Cummings]

Hi Josh,

The specific problems that required the app to know the vendor were:

- variability between EHR vendors approach to providing information about the user

- variability between EHR vendors in querying observations by code

This was complicated in that an EHR vendor would often change their ISS URL from day to day. Ex: .../srv1/..., .../srv2/... breaking any mapping we had from ISS to client id.  We also needed to know if it was their prod/non-prod environment so we couldn’t just go off the ISS domain name, resulting in the ISS directly not being a key to a launch confit map needed by the app.

Thanks,

Travis

Sent from my iPhone

[Josh Mandel]

Thanks! The issue of a server changing its issuer URL is a huge one. If a client doesn't know (in advance) what issuer values it's intended to work with, the client developer has no way to pick a client ID/secret or determine whether the calling system is valid/authorized, or perhaps even authenticate id tokens. (I can imagine the need for greater flexibility in a dev environment, but if this is happening in production, we'd have a problem.)

[Tara Swelstad]

Hi, 
Can you elaborate more on on you handled the SOF Custom Launch Parameter? Is there some documentation I can read on how to develop this for my current client between Epic and Cerner. Thank you. 

Tara

[Travis Cummings]

Just to be clear, I stated a bad work-around.  I don't want to give an example of a bad solution but instead show an example of a better way:

example:

"apps-registered-issuers" : {

  "https://{some hospital fhir server url}": { "client-id": "123", "requesting-scopes": "{some scopes}", "ehr-vendor": "epic",  ...},

  "https://{another hospital fhir server url}": { "client-id": "456", "requesting-scopes": "{some scopes}", "ehr-vendor": "allscripts", ...},

...

}

Then from the ISS your app can determine your client id, scopes, vendor, etc. In my experience, this method hasn't always worked.  In those cases it was a short-term decision to send a custom launch parameter from the launching system to the app that explicitly stated the ehr vendor.

Thanks,

Travis Cummings

CTO, Solutions Architect

801-874-9357

[Patrick Haren]

I took a slightly different approach. Not sure it's any better though... 

There are multiple client-ids, but an individual instance of the EHR could use the same client-id just with a different iss (i.e. it's for the same healthcare org). Thus, I control the selection of configuration parameters based on a client number in the launch: 

e.g. https://ourapp.atsomeurl/launch/15/intended-function

where '15' corresponds to the intended configuration of scope, client-id, fhir-version, server-nuance, etc.

At the moment, I don't store or configure anything related to iss, since it is passed during launch (i.e. a dynamic variable). 

For the app to trust the launching EHR, I need to rely on PKI/certs from the supplied endpoint.

// patrick