Stream: CARIN IG for Blue Button®
Topic: App authorization - SMART
Michele Mottini (May 15 2020 at 19:55):
Do we all agree that the specs to follow for app authorization to access the data are the SMART on FHIR ones: http://www.hl7.org/fhir/smart-app-launch/ ?
Benjamin Langley (May 15 2020 at 19:57):
@Michele Mottini yes, that's what the IG says
Michele Mottini (May 15 2020 at 20:20):
OK, thanks
Michele Mottini (May 19 2020 at 13:16):
The use case is apps used by patients to access their data, so the relevant flow is standalone launch sequence: http://www.hl7.org/fhir/smart-app-launch/#standalone-launch-sequence
Michele Mottini (May 19 2020 at 13:17):
.../metadata should be accessible without authorization, and the returned CapabilityStatement should contain the OAuth2 authorize and token URLs (that's the first step in that flow)
Michele Mottini (May 19 2020 at 13:19):
Access should typically be only to the data of the patient, so access scope can be a general Patient/*.read or specific Patient/ExplanationOfBenefit.read Patient/Coverage.read Patient/Pateint.read . . . .
Michele Mottini (May 19 2020 at 13:20):
The app typically needs the id of the patient, so launch/Patient should be supported
Michele Mottini (May 19 2020 at 13:20):
..and offline_access for confidential app that want a refresh token
Michele Mottini (May 19 2020 at 13:23):
The state parameter passed to the authorization server must be preserved (typically app use it to keep track of each authorization sequence), see http://www.hl7.org/fhir/smart-app-launch/#step-1-app-asks-for-authorization: 'The authorization server includes this value when redirecting the user-agent back to the client.'
Michele Mottini (May 19 2020 at 13:34):
Finally: bonus for supporting OpenID connect for single-sign on (openid fhirUser scopes)
Michele Mottini (May 20 2020 at 16:03):
@Amol Vyas maybe this should be emphasized? Most of the server appear not to be compliant and I just heard from people saying 'we are not planning to implement it'
Aju Jacob (May 20 2020 at 17:32):
I agree @Michele Mottini, we'd like clarification on whether we need to implement 'SMART App Launch' or just OAuth2/OpenID from the perspective of the 2021 CMS ruling. We are under the assumption that SMART App Launch is out of scope for the 2021 ruling. Thanks.
Michele Mottini (May 20 2020 at 17:53):
The CMS ruling does not really specify that level of detail, does it? It just point to CARIN BB IG - that _does_ include SMART app launch
Michele Mottini (May 20 2020 at 17:54):
Also: if you do not have SMART app launch how do the app know which (FHIR) patient to use? Which permissions scopes to require?
Pat Taylor (May 20 2020 at 18:37):
The CARIN BB IG will call out compliance with the SMART Application Launch Framework IG
Pat Taylor (May 20 2020 at 18:57):
... is required
Josh Lamb (May 21 2020 at 13:00):
Proposed language (language is not final):
The IG will require the use of the SMART App Launch Framework’s standalone launch sequence and data holders SHALL support the use of the launch/Patient scope. The use of the launch/Patient scope will make it clear to an application the patient context that must be used for the duration of the connection. The authorization sequence supports the ability for data holders to provide a patient selection widget that can be used to enable delegated access to member information. Details about the SMART App Launch Framework and standalone launch sequence can be found here: http://www.hl7.org/fhir/smart-app-launch/#standalone-launch-sequence
Ryan Howells (Jun 01 2020 at 16:08):
Agree with @josh lamb and @Pat Taylor. Health plans need to implement the SMART App Launch Framework standalone launch sequence similar to what the provider community has implemented to support user authentication. This is critically important for multiple reasons including: the health care app community uses today as the central way in which they are authenticating users, it's a proven framework that is working in production today, and it's the primary way a health plan/data holder will know the request is coming from an individual by leveraging the member portal UN/PW for authentication.
Sudheesh Thuruthiyil (Sep 03 2020 at 20:53):
Hello, I work with the States running their Medicaid programs helping them to meet the CMS mandate on interoperability and Patient Access. While working with couple of States, we realize that most of them dont have an existing Member (Patient) Portal where members have already registered and have existing user credentials. OAuth and OpenID Connect standards do expect a member to have their user credentials already set up with the healhplan (State Medicaid in this case) before they can utilize the third party app to access their health data through API. I was wondering if you have any recommendation for patient authentication flow in these circumstances.
When there is already an existing member portal credential available, we are designing the API so that member can authenticate themselves by providing the userid and password of their Member portal account.
Josh Mandel (Sep 03 2020 at 22:04):
For organizations that do not have an existing way to authenticate their beneficiaries... part of the job of ensuring API access will be creating a way to authenticate their beneficiaries. Common approaches for bootstrapping this kind of thing include knowledge-based identity proofing; this is sometimes combined with mailing out a sign up code to a person's home address.
Ryan Howells (Sep 14 2020 at 20:35):
Hi @Sudheesh Thuruthiyil: We would be happy to further discuss offline how you could procure an identity and access management (IAM) solution independent of developing a portal portal infrastructure and still use SMART. I will send you an email offline to discuss.
Last updated: Apr 12 2022 at 19:14 UTC
