FHIR Chat · SMART: Register with multiple EMRs · implementers

Stream: implementers

Topic: SMART: Register with multiple EMRs

John Martin (Mar 02 2018 at 13:03):

In the SMART Simple authorization app here:
http://docs.smarthealthit.org/tutorials/authorization/

And in the Cerner Sandbox tutorial here:
http://engineering.cerner.com/smart-on-fhir-tutorial/

There is a step in the process of making a SMART application that requires the application to be registered with the EHR. The EHR then provides an application id. This application id is then hardcoded into the redirect page:

<script>
  FHIR.oauth2.authorize({
    'client_id': 'd6b5406a-fb9e-439e-987e-d1afd0c5ee2c',
    'scope':  'patient/Patient.read patient/Observation.read launch online_access openid profile'
  });
</script>

This seems to limit the application to a single EHR vendor that is hardcoded (or require the SMART application to maintain some sort of map of registered EHRs and client_id values).

Is there a standard way to allow a SMART application to be registered with multiple EHR endpoints? Is there a standard way I can add the application I created for the Cerner sandbox to also use the SMART sandbox at https://sandbox.smarthealthit.org/smartdstu2#/manage-apps?

What have others done in the past?

Lloyd McKenzie (Mar 02 2018 at 15:06):

@Josh Mandel

Josh Mandel (Mar 02 2018 at 15:07):

In general you'll need a map of clients IDs, and you'd look up an entry bases on the launch issuer. @Kevin Shekleton @Jenni Syed do you agree it'd make sense to generalize this example?

Kevin Shekleton (Mar 02 2018 at 15:44):

Sure, generalizing this would be fine. The SMART tutorial we wrote here at Cerner is open source and we would love any PRs to improve it! :smile:

Kevin Shekleton (Mar 02 2018 at 15:51):

Also, the tutorial we wrote isn't intended to be used as production code which is why we kept it as simple as possible. With that being said, I realize that most people start from some example code snippet and use that as the basis for their production apps (I see that all the time)

Kevin Shekleton (Mar 02 2018 at 15:51):

In production, you definitely would need to map client ids to launch issuers

Tim Berezny (Mar 02 2018 at 18:22):

I have a similar-ish question, In my SMART app I want to map
a) users from and EMR to their existing accounts in my application
b) patients in an EMR to corresponding information about that patient in my application (i.e., Lookup of the status of referrals in a SMART app for a patient that were previously submitted via a SMART app)

What approaches have people taken to do this, my current thought is as follows

For a), look up the in-context user data launching the SMART app, and in conjunction with a registered app ClientID map the user to an existing user in my application?
I thought that perhaps also when the user launches my SMART app for the first time, it could include a step when they open the window to ask for the user's credentials in my application, and then save the in-context user info in conjunction with the Client ID so that they don't need to enter their credentials to my application the second time.

for b), user the EMR supplied patient ID, and in conjunction with the client ID, map to the patient data saved in my application.

Are there others show have experienced similar processes?

John Moehrke (Mar 02 2018 at 18:50):

The trick is how to assure that the electronic user identity is indeed that which is know as the patient identity. Once you get this confirmed, then it is just a mapping as you have identified (provided stable identity pools). I have a short article on this https://healthcaresecprivacy.blogspot.com/2016/02/patient-as-user-becoming-known-to.html

John Martin (Mar 02 2018 at 18:58):

Also

On this page:
http://docs.smarthealthit.org/tutorials/server-quick-start/

The link for "SMART on FHIR Authorization protocols" (http://docs.smarthealthit.org/authorization/public) in the paragraph shown below seems to be broken:

Once you’ve implemented the SMART on FHIR Authorization protocols, you can wire up your “launch” button to launch the app in production mode (with authorization) by completing the following sequence:

John Martin (Mar 02 2018 at 19:31):

Also...

Does someone have an answer for this question on stackoverflow?
https://stackoverflow.com/questions/49057210/in-a-smart-fhir-application-can-the-application-authenticate-the-ehr

Thanks

Josh Mandel (Mar 02 2018 at 23:30):

Responded to the Stackoverflow question.

Josh Mandel (Mar 02 2018 at 23:30):

Fixed broken link

Grahame Grieve (Mar 03 2018 at 00:06):

Josh - you get a signed openid token too- isn't that a verification point?

Josh Mandel (Mar 03 2018 at 04:49):

The openid token comes after the launch is complete -- yes, that's signed and non-repudiable. But as far as just authenticating: the entire token response comes from the TLS-protected EHR authorization server, so should fit the bill.

Josh Mandel (Mar 03 2018 at 04:51):

On @Tim Berezny's question, there are a few ways to skin this:

1. Pure relying party. Allow users to sign into your app via OIDC, where the SMART EHR acts as an ID provider.
2. Hybrid. Allow users to create accounts within your app using their own credentials (e.g., username + password) and allow each account to be associated with 0..* EHR-supplied IDs. This requires some setup the first time for each user, but after that point users can sign in with an EHR account or with credentials you supply.

Last updated: Apr 12 2022 at 19:14 UTC