SMART app with REST server backend

[gtor...@us.ibm.com]

Hi all,

Sorry if this is a ignorant question:

It seems to me that the majority of SMART apps handle all SMART and EHR FHIR interactions on the client layer (in JavaScript).

But say one has an app with a REST backend (written in Java, for example): I'm trying to get my mind around the feasibility of doing some or all for the SMART and EHR FHIR interactions on the REST backend rather than in JavaScript on the front-end. (In particular, accessing EHR FHIR resources on the backend is appealing, even if SMART authentication is handled on the frontend.)

Is that even feasible?

Are there any examples out there of how to accomplish this?

I'd appreciate any thoughts on what would be involved in doing this.

Thanks,
Greg

[Dan Gottlieb]

Hi Greg,

This is definitely feasible, and many SMART apps are built this way! There's an example of a Java REST app at: https://healthservices.atlassian.net/wiki/spaces/HSPC/pages/61767778/Quick+Start+Java+Spring+MVC+App+for+a+Provider and a Python REST app at: https://github.com/smart-on-fhir/sample-apps/blob/master/rest-app .

Regards,

Dan

[gtor...@us.ibm.com]

Thanks for the reply, Dan!

I feel I didn't do a good job of describing what I'm thinking. (I'm new to web development, so all the pieces and parts aren't necessarily clear yet.)

As I see it, the examples you sent are for web apps where the web app itself has a front-end and a back-end layer, but it's all quite well integrated such that the app can easily respond to transactions on the server (such as SMART oauth or FHIR calls) with page re-directs and user prompts as necessary. Front-end and back-end are a unified whole.

The scenario I was thinking of was one where the web app is it's own self-contained entity (possibly with a front-end and a back-end), and there is a separate and distinct REST layer that the web app can query -- but which has no direct control over the way the web app works. In this scenario, the web app would query the REST layer for data for a particular patient. This data to be returined might include patient data from the EHR FHIR server combined with other non-EHR data and analytics. In other words, the REST layer -- not the web app -- would be responsible for querying the EHR FHIR server. Does that make sense?

Questions that come to mind in this example are:

(1) If SMART authentication and patient selection occur in the web app, is it feasible to send the EHR OAuth token to the REST layer to have the REST layer query the EHR FHIR server? (Or does the REST layer need to authenticate with the EHR separately?)

(2) If we do this, would it even work, or would the EHR servers complain about the origin of the FHIR calls (given that they'd be coming from the REST layer rather than from the web app)?

(3) Is there a better way of doing this, or is the whole idea fundamentally wrong?

BTW, I am aware that SMART can be used by backend services (as described here: http://docs.smarthealthit.org/authorization/backend-services/). But in this particular case it seems one needs to have permission to access the entire patient population in the EHR FHIR server, rather than just the records of a selected patient. (While that might be possible if a SMART app legitimately needs to access all patient data for analysis, it would be harder to justify for apps that only work with single-patient data.)

I know I'm probably not explaining it well. Hope it makes some sense.

Thanks,
Greg

[Vladimir Ignatov]

Hi Greg,

I’m not really sure if I fully understand the question but I hope the following might be of use:

@1 - Yes, it is possible and it would be necessary in that case. However, if you implement that you will end up having an “app” and a REST API that are no longer as decoupled as you initially intended.

@2 - Unlike in the browsers, on the server you are free to forge all kinds of requests, send request headers, tokens etc. This have been done multiple times so far and it works but I can’t think of any example that is open-source.

@3 - I think that http://docs.smarthealthit.org/authorization/backend-services/ is what you need. You shouldn’t worry about those permissions - you will need them anyway. This way you will authorize your REST API to access every patient but the API will become something like a middleware between the FHIR server and your app(s). I would assume that in this case the API layer should be the one to decide if certain app can “see” certain patient. BTW, even in the front-end, if an app needs to work with patients it will require access to ALL the patients because the exact patient is not known at registration time.

As an example consider the following very simple architecture:

1. Create your back-end REST API and authorize it to work with the FHIR servers.

2. Add an endpoint for registering client applications

- each registered app receives some unique token (like the google API token for example)

- apps are required to pass that api token in their requests

- requests to the API without (or with invalid) token are rejected

This way you will not expose the FHIR server to the entire world but only to the registered apps.

I guess you can imagine this augmented with additional functionality...

Hope that helps,

Vlad

--
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.

[gtor...@us.ibm.com]

Thanks Vladimir! I think you definitely understood what I was getting at, and what you have said make a lot of sense.

I appreciate you taking the time to respond.

Greg

[Vladimir Ignatov]

After further consideration I realized that I need to add some things here.

First, http://docs.smarthealthit.org/authorization/backend-services/ is not the right spec. As far as I know this is not even supported by any EHR yet. What I meant to recommend was the standard authentication. In your case the REST API is a back-end app and you can register it as a confidential client and also use refresh tokens to persist the authorization.

Also, passing the token from the apps to the API layer should work fine. It is not ideal but you cannot go through the entire auth flow on the backend, thus delegating the auth part to the apps is probably better than trying to do that in the backend.

When I say that it is not ideal I mean that your browser will maintain a session with the auth server for some time (typically 1 hour). After that session expires the requests (in your case made by the REST API layer) will fail. You will have to detect that, probably pass the error response back to the apps, hope that they will understand it and re-authenticate and try again… Another option would be to maintain a session for each app in you backend API and also use that backend to obtain refresh tokens. That is technically possible but difficult to implement and debug.

Regards,

[gtor...@us.ibm.com]

OK, thanks for the additional info, Vlad. That makes sense.

Have a great weekend,
Greg