Using Epic's Oauth token against supplemental FHIR API

[veliyan....@gmail.com]

Hello friends,

I am building a patient-facing app that sits on top of Epic's FHIR APIs but I want to supplement the functionality so I am putting together a HAPI-implementation for few other resources that are not yet implemented by Epic. I am wondering if there is a way to use the token issued by Epic against that HAPI implementation so I don't have to make the user login twice with two different sets of credentials.

In general - what are your thoughts on this scenario in general - stock EMR FHIR API and a supplemental stopgap custom FHIR API for all the missing (but needed) functionality until the EMR catches up. 

Thoughts?

[Josh Mandel]

Thanks for the question! Let's unpack two themes here:

1. User sign-in. If you're writing a SMART app that interacts with a patient, and you want to avoid requiring that patient to create a new set of credentials just to sign into your app, then Open ID Connect is the way to go. It is a single-sign-on protocol that works as part of the SMART authorizations specification. Not every EHR that supports SMART today includes support for this functionality, but in cases where it is missing, it's generally not safe just rely on an OAuth approval (without OIDC) as a sign-in protocol. See Justin Richer's write-up at https://oauth.net/articles/authentication/ to understand why.

2. Exposing supplemental data. It sounds like your app or service uses/stores/exposes additional data not available from the EHR FHIR server. Are these data coming directly from the user, from elsewhere in the EHR, or from another source? Do you want to make these data available to third parties, or just to use them within your own app? In general, if you have a relationship with the patient and you want to expose these data to a third party, then you might want to look into implementing the SMART EHR interface directly. 

Zooming out a little bit, part of your question was asking what it would take to build a new API server that uses the same tokens as an existing API server. For this to work reliably, your new API server would need to be able to look at a token and understand what it means, who granted it, what scopes it includes, what limitations it imposes, whether it is still valid, Etc. OAuth token introspection (https://tools.ietf.org/html/rfc7662) provides an API to accomplish exactly this -- but it only makes sense if the authorizing user (patient) expected this behavior and intended to share data from this supplemental server exactly as though it was part of the initial electronic health record data set.The EHR vendor FHIR servers do not yet include support for token introspection, but it is an active area of discussion within the FHIR and Argonaut communities.

Best,

Josh

 

--
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-fhir+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[veliyan....@gmail.com]

Hi Josh,

on 2. The data comes from the same EHR but it is only for consumption within this app. There is no need to make it publicly available at this time. It is a stopgap solution until the next EHR upgrade hopefully. I thought about the introspect endpoint which would've been a great way of handling it but as you pointed out - it is not available yet - hence why I am reaching out for advice. 

Josh

 

To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhi...@googlegroups.com.

[Josh Mandel]

If you're working directly with a hospital in the context of standing up a server inside their firewall, then it's also possible to "fake it" by building your own introspection endpoint -- but the capabilities will be quite limited, so I'm hesitant to suggest this in general.

We have built a very simplistic take on this as part of a Sync for Science imaging data project (it's still very early days... but we're basically asking, "what would it take to stand up a patient-accessible imaging API server next to the EHR's native FHIR server, and allow the patient's portal-based approval to apply to both data servers". Here's a 20 line sketch of what it looks like -- basically, you can build a partially-functional token introspection service by trying to use the tokens at the EHR, to see if they're "still good" for the patient in question). The major drawbacks to this approach include:

1. You don't have a good way to check scopes associated with the token -- all you can do is see whether it's capable of accessing specific resources in the EHR FHIR Server. (For some EHRs, where approval is all-or-nothing, this is less of a big deal, because any access == all access.)

2. You don't have a good way to ensure that the patient understands/wants to enable this access. (If you can add appropriate language to the portal-based approval screen, or if you're working in the context of a hospital providing clinical care, this might be mitigable.)

The nice thing about this approach is that these drawbacks resolve if/when EHRs are able to provide a "proper" token introspection service. So it can be seen as a bridge to better system design. And it's very likely better than some alternative. For example, it's better than opening up a full back-channel API between your app and the hospital with unrestricted access.

Best,

Josh

To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhir+unsubscribe@googlegroups.com.

[veliyan....@gmail.com]

Thanks Josh,

I'll dwell on this over the holidays :-). 

[Adrian Gropper]

We can delay adopting a patient-centered model for FHIR but it's catching up to us through workarounds that will not scale or interoperate. The HEART workgroup profiles http://openid.net/wg/heart/ allow each OAuth2 resource server (the EHR, the PACS, an add-on FHIR server) to use the same authorization server. This avoids the incremental tweaks and wortkarounds that will be incompatible and cannot lead to a longitudinal patient record anyway.

Adrian

To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhir+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.

DONATE: https://patientprivacyrights.org/donate-3/

[Michele Mottini]

Epic supports Open ID Conect, so you can use that to authorize access to your separate server. We did that successfully with our own system'

  - Michele

  CareEvolution Inc

[Kevin Mayfield]

Does EPIC have a fully functioning OAuth2 server?

I'm working on a project similar to Argonaut and researching OAuth2. Where is the best place to keep up to date with SMART, HEART and/or just OAuth2 in health (general principles)?

[Kevin Mayfield]

by fully functioning OAuth2 server, I mean:

HSPC/Mitre's SMART on FHIR server is a comprehensive OAuth2 server and introspection service (and other grant types) are built in.

On Friday, December 22, 2017 at 1:33:07 PM UTC, veliyan....@gmail.com wrote:

[Josh Mandel]

To my knowledge, none of the commercial EHR vendor implementations of SMART on FHIR includes a token introspection service today. (Please anyone do chime in here if you can share a counterexample!) 

--

[veliyan....@gmail.com]

Michele,

can you share more details on the implementation? We are about to start a mini POC project on this so any help will be greatly appreciated.

[Michele Mottini]

Standard open id connect:

1. Do the normal SMART authentication flow passing the additional openid profile scopes

2. When your app requests the token at the end of the sequence the server returns also an id_token containing information about the user that logged in

3. Validate the id_token (https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation)

4. Use the information from the id_token ( + the resource referenced by the 'profile' claim if necessary - http://docs.smarthealthit.org/authorization/scopes-and-launch-context/) to match the id_token user with a user account in your system - if there is none matching create a new one

5. Authorize access to your app by the user account selected or created at step 4

Googling around you can probably find pre-made code to do this stuff for whatever platform you are using - it is all standard except the use of the 'profile' claim to access a FHIR resource

  - Michele

  CareEvolution Inc

[Kevin Mayfield]

How does the supplemental resource server know the access token is valid?

From what I think you’ve said, you could just trust the access token. Which does offer some security and in a closed system that may be enough?

Would the resource server need access to the user info endpoint on the Openid server to get details on the user and possibly an introspection endpoint (or alternative eg sql connection) to validate details the token and get extra information?

Sent from my iPhone

You received this message because you are subscribed to a topic in the Google Groups "SMART on FHIR" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smart-on-fhir/4Q-jal2uIMA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to smart-on-fhi...@googlegroups.com.

[Michele Mottini]

Not sure if you are asking me....what I described is the standard open id connect protocol, with the only twist of the profile claim being a FHIR resource URL (that is a SMART-specific variation). It might be possible to do things in a different way, but for security protocols I'd rather stick to the standards as much as possible...

  - Michele

  CareEvolution Inc

[Kevin Mayfield]

It was a question. I’m new(ish) to OAuth2 and using terms from one of the authors book (OAuth2 in Action - Justin Richer).

From your description I presumed you were talking about client behaviour and I was talking about standard extensions for a (FHIR/OAuth2) resource server to use. When I implemented an OAuth2 previously I followed recommendations to implement a SQL link back to the OAuth2 server to check the access token however a more general approach would be to use a introspection endpoint (https://tools.ietf.org/html/rfc7662). It seems HEART (on FHIR) has gone down this route (http://openid.net/specs/openid-heart-oauth2-1_0-2017-05-31.html#rfc.section.3.2.2)

Sorry if I’m going off on a tangent. I’m trying to understand why SMART does this and why HEART does that

[Grahame Grieve]

The smart on fhir protocol says nothing about the relationship between authorisation server and resource server, though you are right that there must be one, based on some kind of introspection api of one kind or other. Along with additional agreements. UMA/heart goes into what those things are, but has different goals, so the client api is different. Perhaps one day we will be able align for the client

Grahame 

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.

--

-----
http://www.healthintersections.com.au / gra...@healthintersections.com.au / +61 411 867 065

[Adrian Gropper]

In what way is UMA/HEART not a superset of FHIR? To the extent that the goals are different, aligning FHIR with HEART would make sense, at least in the sense of a roadmap. 

Adrian

--

[Justin Richer]

In HEART we mandate both JWT-formatted tokens (with some basic claims and signatures) as well as availability of the token introspection endpoint. We made that choice in HEART to offer flexibility from the RS standpoint. You can parse the token, figure out where it came from, and introspect it to get details as needed. HEART seeks to define compatibility between AS and RS, which as Grahame pointed out, SMART doesn’t — and that’s fine, it’s a difference in scopes between the projects. 

 — Justin

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.

[Grahame Grieve]

the problem is that from the client's point of view, the aud parameter is used differently between smart and heart, and therefore they are not compatible. I think this is regrettable, but we weren't able to address this when we talked about it

Grahame

On Tue, Jan 2, 2018 at 9:26 AM, Justin Richer <jri...@mit.edu> wrote:

In HEART we mandate both JWT-formatted tokens (with some basic claims and signatures) as well as availability of the token introspection endpoint. We made that choice in HEART to offer flexibility from the RS standpoint. You can parse the token, figure out where it came from, and introspect it to get details as needed. HEART seeks to define compatibility between AS and RS, which as Grahame pointed out, SMART doesn’t — and that’s fine, it’s a difference in scopes between the projects. 

 — Justin

On Dec 29, 2017, at 12:23 PM, Kevin Mayfield <mayfiel...@gmail.com> wrote:

It was a question. I’m new(ish) to OAuth2 and using terms from one of the authors book (OAuth2 in Action - Justin Richer).

From your description I presumed you were talking about client behaviour and I was talking about standard extensions for a (FHIR/OAuth2) resource server to use. When I implemented an OAuth2 previously I followed recommendations to implement a SQL link back to the OAuth2 server to check the access token however a more general approach would be to use a introspection endpoint (https://tools.ietf.org/html/rfc7662). It seems HEART (on FHIR) has gone down this route (http://openid.net/specs/openid-heart-oauth2-1_0-2017-05-31.html#rfc.section.3.2.2)

Sorry if I’m going off on a tangent. I’m trying to understand why SMART does this and why HEART does that

On 29 Dec 2017, at 14:42, Michele Mottini <mi...@careevolution.com> wrote:

Not sure if you are asking me....what I described is the standard open id connect protocol, with the only twist of the profile claim being a FHIR resource URL (that is a SMART-specific variation). It might be possible to do things in a different way, but for security protocols I'd rather stick to the standards as much as possible...

  - Michele

  CareEvolution Inc

--
You received this message because you are subscribed to a topic in the Google Groups "SMART on FHIR" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smart-on-fhir/4Q-jal2uIMA/unsubscribe.

To unsubscribe from this group and all its topics, send an email to smart-on-fhir+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-fhir+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-fhir+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Adrian Gropper]

Thanks Justin and Grahame for your comments about scope and the incompatible aud parameter. However, I still don’t understand how this will play out from the perspective of patients trying to maintain a longitudinal health record linked to one AS. Will each hospital have to implement separate FHIR and HEART APIs (with a cost in terms of complexity and attack surface)? Or, will FHIR and HEART be harmonized (echoes of the old CCD / CCR days)?

This incompatibility is playing out in the HIE of One implementation of SMART and UMA / HEART. We currently have separate interfaces for Open.Epic and CMS Blue Button on FHIR and the patient experience is already fragmented. It looks like the Cerner implementation might be different still, at least to the extent that Cerner has not followed Epic’s practice of making the list of accessible Resource Servers open without a sign-in.

This also seems to be linked to the ability for Resource Servers to handle Writes as evidenced by/ the All of Us practices. How will  All of Us implement patient-directed access to the longitudinal health record they are maintaining? Is patient access to All of Us something we can test today?

Where does this community suggest we consider the patient experience around longitudinal health records? 

Adrian

On Mon, Jan 1, 2018 at 6:43 PM Grahame Grieve <gra...@healthintersections.com.au> wrote:

the problem is that from the client's point of view, the aud parameter is used differently between smart and heart, and therefore they are not compatible. I think this is regrettable, but we weren't able to address this when we talked about it

Grahame

On Tue, Jan 2, 2018 at 9:26 AM, Justin Richer <jri...@mit.edu> wrote:

In HEART we mandate both JWT-formatted tokens (with some basic claims and signatures) as well as availability of the token introspection endpoint. We made that choice in HEART to offer flexibility from the RS standpoint. You can parse the token, figure out where it came from, and introspect it to get details as needed. HEART seeks to define compatibility between AS and RS, which as Grahame pointed out, SMART doesn’t — and that’s fine, it’s a difference in scopes between the projects. 

 — Justin

On Dec 29, 2017, at 12:23 PM, Kevin Mayfield <mayfiel...@gmail.com> wrote:

It was a question. I’m new(ish) to OAuth2 and using terms from one of the authors book (OAuth2 in Action - Justin Richer).

From your description I presumed you were talking about client behaviour and I was talking about standard extensions for a (FHIR/OAuth2) resource server to use. When I implemented an OAuth2 previously I followed recommendations to implement a SQL link back to the OAuth2 server to check the access token however a more general approach would be to use a introspection endpoint (https://tools.ietf.org/html/rfc7662). It seems HEART (on FHIR) has gone down this route (http://openid.net/specs/openid-heart-oauth2-1_0-2017-05-31.html#rfc.section.3.2.2)

Sorry if I’m going off on a tangent. I’m trying to understand why SMART does this and why HEART does that

On 29 Dec 2017, at 14:42, Michele Mottini <mi...@careevolution.com> wrote:

Not sure if you are asking me....what I described is the standard open id connect protocol, with the only twist of the profile claim being a FHIR resource URL (that is a SMART-specific variation). It might be possible to do things in a different way, but for security protocols I'd rather stick to the standards as much as possible...

  - Michele

  CareEvolution Inc

--
You received this message because you are subscribed to a topic in the Google Groups "SMART on FHIR" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smart-on-fhir/4Q-jal2uIMA/unsubscribe.

To unsubscribe from this group and all its topics, send an email to smart-on-fhi...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

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

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

--

-----
http://www.healthintersections.com.au / gra...@healthintersections.com.au / +61 411 867 065

--

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.

--

[Grahame Grieve]

Hi Adrian

I’m not familiar with the details of the blue button api security - but I think I heard they are not using smart on fhir? Also, of course, they have different content to an EHR

On the subject of epic vs cerner, we have not settled the question of an end-point registry. There’s work around an end-point registry api, but that’s the same as an actual end point directory. There’s some discussions happening, but not a lot of action at this point. Some of the discussions involve the FHIR foundation hosting the directory - which seems possible, but it’s not the same as making it work - the impetus has to come from somewhere though

Can you illuminate me how AllOfUs has any practices in regards to writes? I thought their use of FHIR was read only?

Grahame

[Michele Mottini]

SMART on FHIR 'as is' is enough to implement patient longitudinal records.

What is hindering progress is:

1) Low providers adoption - only Epic is aggressively rolling it out, and only Epic, Cerner and  Allscripts have a complete implementation

2) End point discovery - only Epic is publishing the list of their end points

3) No offline access support - that forces the user to re-enter their credentials each time

4) No social login support (Google / Facebook) - that forces the user to create and remember different credentials across all their providers

  - Michele 

  CareEvolution Inc

[Adrian Gropper]

From a patient perspective, the content between Open.Epic and Medicare is about them. Who wouldn’t want the EOB from the payer to be linked to the services documented in various EHRs. That’s how I use the Medicare mailings to track where my 91yo mom has been seen and to try and keep up.

I don’t want to speak for AllofUs. From a patient perspective, choosing to participate in All of Us results in various FHIR Resource Servers writing into a longitudinal health record that the patient can direct access to.

Adrian

On Mon, Jan 1, 2018 at 9:39 PM Grahame Grieve <gra...@healthintersections.com.au> wrote:

Hi Adrian

I’m not familiar with the details of the blue button api security - but I think I heard they are not using smart on fhir? Also, of course, they have different content to an EHR

On the subject of epic vs cerner, we have not settled the question of an end-point registry. There’s work around an end-pointregistry api, but that’s the same as an actual end point directory. There’s some discussions happening, but not a lot of action at this point. Some of the discussions involve the FHIR foundation hosting the directory - which seems possible, but it’s not the same as making it work - the impetus has to come from somewhere though

[Justin Richer]

This is hardly the only technical difference between the profiles, and regardless, this difference would not prohibit SMART from mandating support for introspection, even with its own profile. The real difference here is that HEART explicitly defines compatibility for the AS<->RS relationship, where as SMART explicitly leaves that undefined. 

 — Justin

[Josh Mandel]

Thanks all for some robust discuss! 

Adrian, with respect to Epic, Cerner, and CMS BlueButton on FHIR (and others!): all three of these systems should support SMART on FHIR for patient access. Our S4S test suite can connect to each of them (https://tests.demo.syncfor.science/).

The two biggest sticking points in today's implementations are scopes (Cerner doesn't yet support "patient/*.read") and long-term access (all three support long-term access with refresh tokens technically, but Open.Epic's self-service registration process doesn't let a developer request this ability at registration time today). Still, these details boil down to a couple of additional pieces of information that an app needs to track (alongside the mandatory information an app always needs to track, like its client_ids). It's a single protocol implemented in a single client library -- the story is much better than 3 independent code paths, as your note seemed to suggest.

On Jan 2, 2018 08:35, "Justin Richer" <jri...@mit.edu> wrote:

This is hardly the only technical difference between the profiles, and regardless, this difference would not prohibit SMART from mandating support for introspection, even with its own profile. The real difference here is that HEART explicitly defines compatibility for the AS<->RS relationship, where as SMART explicitly leaves that undefined. 

 — Justin

[Adrian Gropper]

Hi Josh,

The S4S vendor list and test suite are wonderful but it seems to be only a fraction of what's needed for patient-directed exchange because it hard-codes the client ID and secret and does not seem to tell us how a patient-directed client will gain access to a patient's data in S4S.

How can we extend the S4S tests to include Who is allowed to register a SMART client on behalf of an individual patient? (Open.Epic, for example just requires a name with no particular credentials or certifications. I don't think CMS BlueButton on FHIR requires even that much. It's not clear what a patient would need to do to get a client registered into Cerner or the other vendors.)

HEART specifies Dynamic Client Registration, which would resolve many of the developer questions on the SMART and Cerner lists. How will S4S support patient-directed client registrations and will that be compatible with SMART?

Adrian

 

[Grahame Grieve]

hi Justin

There's lots of differences for scope and functionality reasons. But as fr as I remember, that's the difference that is client facing and means that a client has to care about the difference. It'd be great if you can point out others. But I think it's disappointing that the client has to care about the difference. 

Grahame

On Wed, Jan 3, 2018 at 3:35 AM, Justin Richer <jri...@mit.edu> wrote:

This is hardly the only technical difference between the profiles, and regardless, this difference would not prohibit SMART from mandating support for introspection, even with its own profile. The real difference here is that HEART explicitly defines compatibility for the AS<->RS relationship, where as SMART explicitly leaves that undefined. 

 — Justin

-----
http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065