FHIR Chat · OpenID Connect for SMART on FHIR · smart

Stream: smart

Topic: OpenID Connect for SMART on FHIR


view this post on Zulip Benjamin Maisano (Oct 01 2018 at 21:48):

Hi FHIR Community, we are big fans at Mount Sinai and just attended the FHIR App roundtable in DC. Lots of conversations we had were around a federated identity server for authentication to be coupled with the existing SMART on FHIR OAuth2 flow. We found in practice many many patients are bouncing on the portal login pages b/c they do not know their login or never registered to begin with. We are hoping to collaborate to solve this and find out about any existing conversations or agendas in this area. Thoughts:

1. Use “OpenID Connect” standard on top of the OAuth2 based SMART spec.
2. Standard way for health portals (Clinical, Payors, and Health Apps) to list all the Identity Providers they integrate with. Google, Facebook, LinkedIn, Amazon, Microsoft, etc
3. Have the government host a default Identity Provider (since many consumers wont trust the above brands with medical records). Perhaps extending what Medicare has in place for all...
4. Standardize registration signup and patient pairing if they are not already activated. Optionally add certified KYC/Auth question providers to plug in.

Would love to hear thoughts on this, thank you!

view this post on Zulip Grahame Grieve (Oct 02 2018 at 09:51):

we strongly recommend OIDC. It would be up to ONC to use levers to require it

view this post on Zulip Grahame Grieve (Oct 02 2018 at 09:53):

There's been a lot of discussion about the identity providers - whether people trust them to know where they have health records, and also the considerably difficult problem of mapping between the identity provider's identity and the institutions identity. I'm not aware of the social media providers being used as identity providers in any situation where you first establish a real world relationship, and then log in through a social media account which is .... somehow... mapped to your record. In a domain as sensitive as health

view this post on Zulip Grahame Grieve (Oct 02 2018 at 09:54):

I am familiar with the idea, and proposed something similar for Australia (see http://www.healthintersections.com.au/?p=2868) but I'd be completely sceptical that the social media providers would ever be part of that picture.

view this post on Zulip Grahame Grieve (Oct 02 2018 at 09:54):

so in essence, I favor #3. As does the Australian government. Even then, it may not fly in Australia. And it seems unlikely to fly in USA.

view this post on Zulip Grahame Grieve (Oct 02 2018 at 09:57):

there's a fairly obvious approach with a identity provider for health run by a dedicated commercial entity under strict government supervision with several simple token exchange protocols to allow cross-mapping identity during the admission process. That's a variant of your #4, but it's a difficult market proposition to set up

view this post on Zulip Grahame Grieve (Oct 02 2018 at 09:58):

my view is that the cultural/political environment in USA means that you can't solve this problem. And you'll have to fall back to managed access tokens (e.g. passwords) with the cost this entails

view this post on Zulip John Moehrke (Oct 02 2018 at 14:26):

is this discussion being applied to the SMART-on-FHIR version 1 that I am told is now done? Or is this future revision discussion?

view this post on Zulip Benjamin Maisano (Oct 02 2018 at 14:40):

Thanks Grahame - agree on what you've said, a single identity provider is problematic and likely the health system or hosting organization of the portal's decision on who they support. Consumers may not trust social, they may also not trust the government. I do believe allowing each person to make their own choice as to where they authenticate is important. I think the SMART on FHIR spec simply supporting OpenID Connect or something similar would do, as it sets a recommendation that this is a hugely important step for activation. #3 would be a big nice to have in that context that isn't in the spec, but a collaboration and perhaps the FHIR community builds up a list of certified IDps.

Similarly #4 gets at the hairy part of online activation, its the wild west now with many varying implementations or lack of. If one could say you can signup/register and patient pair in a FHIR standard compliant way that would have value to just focus and iterate on the UI, workflow, etc, and make sure these very important functions are available for a portal that is "SMART on FHIR" compliant.

view this post on Zulip Josh Mandel (Oct 02 2018 at 15:53):

I'm not aware of the social media providers being used as identity providers in any situation where you first establish a real world relationship, and then log in through a social media account

https://www.followmyhealth.com/ does exactly this.

view this post on Zulip Josh Mandel (Oct 02 2018 at 15:54):

(And they have a FHIR/Argonaut API.)

view this post on Zulip Alexander Mense (Oct 02 2018 at 15:59):

Thanks Josh for the link. I am really wondering ... IMHO access to sensitive healthcare information shall be only provided to proven identities. Therefore any kind of IDP shall be at least compliant with IAL2 according to NIST SP 800-63 (https://pages.nist.gov/800-63-3/sp800-63-3.html)

view this post on Zulip Alexander Mense (Oct 02 2018 at 16:02):

I am not aware of any real world identity check process at Facebook, Google, etc.

view this post on Zulip John Moehrke (Oct 03 2018 at 13:29):

A healthcare app would do additional identity proofing, to elevate the low assurance Facebook identity, to a higher assurance identity that is also cross-referenced to a Patient identity. -- such as using Postal Mail (covered by federal fraud rules) to send a secret challenge.

view this post on Zulip John Moehrke (Oct 03 2018 at 13:30):

This does nothing to elevate the level of assurance for authentication, or the management risks of Facebook. But many consumers have facebook identity, and don't want to manage yet-another-password. Adding more passwords the consumer must remember presents risks itself


Last updated: Apr 12 2022 at 19:14 UTC