Stream: smart
Topic: Access Token Payload: Endpoint Reference
Josh Lamb (Jan 26 2021 at 00:15):
Payers and providers may want to expose FHIR related portal functionality. Would the following scope be appropriate?:
"portal_access": "Request an access token that can be used to access a patient portal."
if the scope was fulfilled it would result in two new properties in the access token payload:
"portal_token":"sometokenvalue"
"portal_url":"https://www.something.com"
-or-
"portal_token":"sometokenvalue"
"portal_endpoint":"654987" (FHIR Id for an endpoint resource)
This would help consumer applications support B2B use cases.
Josh Mandel (Jan 26 2021 at 00:16):
can be used to access a patient portal
What does it mean for an app to "access a patient portal"? A portal is a user-facing web site, right?
Josh Lamb (Jan 26 2021 at 00:17):
Yes, exactly.
The portal screen we provide in this endpoint would be for B2B configurations, views, and other FHIR settings.
Josh Lamb (Jan 26 2021 at 00:17):
so they would open up a website, nothing fancy.
Josh Lamb (Jan 26 2021 at 00:18):
or we push them to a "screen" in a payer/provider app...
Josh Mandel (Jan 26 2021 at 00:19):
But what is an app doing with this token? How is it used and what does it accomplish?
Josh Lamb (Jan 26 2021 at 00:20):
Many people do not interact with the portals. They may begin to use an application first. If a patient downloads a consumer application first, they can still select a data source and activate their account. This would provide a consistent way for people who interact with their portals when using a consumer application as the point of entry.
Josh Lamb (Jan 26 2021 at 00:21):
Even if they get the consumer application second, it may be nice to have easy access to the relevant portal webpage.
Josh Lamb (Jan 26 2021 at 00:22):
A consumer applicatino will not be able to perform certain types of activities, like opt-in to share prior authorization status or to request that a diagnosis is shared with a physician.
Josh Mandel (Jan 26 2021 at 00:23):
I think we're schedule for a 1:1 conversation soon -- would be good to talk through this, because I'm fundamentally not getting what you're saying. Patients need "portal" access in order to approve an app; that's where the approval happens.
Josh Lamb (Jan 26 2021 at 00:32):
Sounds good. We can go through it then.
One last attempt at clarity: Once a patient adds a data source (during the app login sequence), they will generally have portal access, but they did not necessarily interact with the portal in a meaningful way.
These patients may have only interacted with the IMS and Authorization screens. We would not want someone to have to go through the login sequence every time they wanted to change a setting on their portal. Because of this, payers and providers may eventually have dedicated screens to perform FHIR functionality, like prior auths, and to manage opt-ins (consumer devices cannot act as a HIPAA covered entity).
This link in the access token payload would provide easy access to the portal. The "portal_token" is used to enable the portal to open instantly without login.
Josh Lamb (Jan 26 2021 at 00:33):
Ideally, this would be a direct link to the FHIR. configurations
Josh Mandel (Jan 26 2021 at 00:35):
I see. You are basically asking the app to hold on to an authentication cookie for the user. This seems like a dramatically painful real-world security and compliance challenge
Josh Mandel (Jan 26 2021 at 00:35):
But I get it now!
Josh Lamb (Jan 26 2021 at 00:40):
The app already has a dangerous token, but i see your point. The security is not worth the minimal convenience.
They can log in again. I am okay with that. In most cases, the phone/internet browser saved the PW anyway.
Josh Mandel (Jan 26 2021 at 00:41):
Yeah, I would focus on defining apis for the features you want, and if you want a little bit of flexibility you can define apis by which the app can discover URLs representing to-do items, and those URLs can come with authorization tokens built in specifically for completing one task like approving one prior authorization request.
Josh Mandel (Jan 26 2021 at 00:42):
(and then it is up to the EHR to decide whether a specific prior auth link works on a simple click-through or whether requires a full sign-in event or something in between like a pin entry)
Josh Lamb (Jan 26 2021 at 00:57):
Some payers and providers may update their web portals to support new use cases like FHIR configurations. Creating new b2c APIs to support configurations changes is certainly an option. I see this as a different IG, perhaps under CARIN. Providing a link to a portal webpage that has the FHIR settings may be a good stopgap measure.
Last updated: Apr 12 2022 at 19:14 UTC
