FHIR Chat · Token Validity · smart

Stream: smart

Topic: Token Validity


view this post on Zulip Aju Jacob (Sep 03 2020 at 11:11):

In the context of the 2021 CMS Patient Access rule, is there a requirement around how long the payer-issued token should be valid (refresh token)?

view this post on Zulip Michele Mottini (Sep 03 2020 at 12:31):

I don't think there is a requirement from CMS. ONC rule has three months. Current CMS BlueButton refresh tokens never expire - so I'd say either never expire or long (>= 3 months). We are doing 1 year

view this post on Zulip Josh Mandel (Sep 03 2020 at 13:08):

And to be clear for the ONC rule: while individual refresh tokens need to last at least three months, the time resets when the refresh tokens are exercised so that an app can maintain persistent access until the user decides to stop this.

view this post on Zulip Aju Jacob (Sep 03 2020 at 13:50):

This is good information. Thanks @Michele Mottini and @Josh Mandel!

view this post on Zulip Isaac Vetter (Sep 09 2020 at 20:35):

the time resets when the refresh tokens are exercised

Josh, Guys -- I was trying to re-validate this recently. Could you point to language in the rule that explicitly says this?

The actual regulation text doesn't actually say this.

view this post on Zulip Josh Mandel (Sep 09 2020 at 20:42):

Let's see... It's subtle, so thanks for bringing this up:-)

As background, the clearest articulation is in commentary provided in the proposed rule:

For example, if an application were issued a refresh token that was good for three months upon its first-ever connection and then subsequently connected to the FHIR server one month later, the FHIR server would need to enable that connection to occur without re-authentication and re-authorization, and it would need to issue a new refresh token for a new three-month period from that access date.

Now in the final rule, the key language is here: for "Subsequent connections...", the client "must be issued a new refresh token valid for a new period of no less than three months."

view this post on Zulip Josh Mandel (Sep 09 2020 at 20:44):

The term "new period" here is what clues you in to the fact that access periods are chained together indefinitely.

view this post on Zulip Isaac Vetter (Sep 09 2020 at 21:05):

I'm trying to answer the question -- what are the choices that a patient should have for length of persistent access during authorization?

The rule imagines that apps will only get a new refresh token when the user uses their app, but there's no technical method to enforce this and obviously won't be the case in reality. Most apps will likely simply ensure that persistent access is maintained for as long as possible, regardless.

Without an additional authorization decision by the patient, I don't understand how this jives with the patient's ability to determine the length of time an app should be able to access their data (unless the only choice presented to the patient is [] forever).

view this post on Zulip Josh Mandel (Sep 09 2020 at 21:06):

You can give the patient all kinds of choices; the ONC rule requires that patients can choose to enable persistent access.

view this post on Zulip Josh Mandel (Sep 09 2020 at 21:07):

And honestly, explaining to a patient "this app will be able to access your data until you withdraw permissions" and then sending periodic reminders like "Hey, the following apps have access to your record" is probably more effective than trying to explain this stuff about "Well, it's at 3 months, unless the app chooses to extend it, in which case it's longer..."

view this post on Zulip Isaac Vetter (Sep 09 2020 at 21:25):

Josh, are you really saying the rule doesn't allow a patient to specify the total amount of time an app can access their data? (But instead, can only legally control the amount of time that an app has to renew it's access?!?)

view this post on Zulip Josh Mandel (Sep 09 2020 at 21:26):

I'm not saying that at all!

view this post on Zulip Josh Mandel (Sep 09 2020 at 21:26):

The rule requires that patients be able to grant persistent access.

view this post on Zulip Josh Mandel (Sep 09 2020 at 21:27):

The rule is a floor, not a ceiling: certified EHR products can offer additional options / capabilities that allow users to apply additional restrictions (beyond SMART scopes, beyond basic time limits, etc).

view this post on Zulip Isaac Vetter (Sep 09 2020 at 21:27):

where persistent means forever, yes, agreed. Do you agree that other valid options, for example, presented to the patient could be : 1 year, 3 months, 2 weeks, today ... ?

view this post on Zulip Josh Mandel (Sep 09 2020 at 21:27):

My recommendation would be to make it easy to approve long-term sharing, and keep users informed about their choices over time.

view this post on Zulip Isaac Vetter (Sep 09 2020 at 21:28):

and that those options would control how long an app could access the data and not merely, the amount of time between refreshes?

view this post on Zulip Josh Mandel (Sep 09 2020 at 21:28):

for example, this is how Google keeps me informed about location sharing -- by default, I can share my location with you "until I revoke it," but then every so often they remind me that I'm sharing my location with you. So it's low friction, but not quite set and forget, because you don't accidentally forget.

view this post on Zulip Josh Mandel (Sep 09 2020 at 21:29):

"amount of time between refreshes" is a meaningless concept, from the consumer PoV. I wouldn't try to explain it.

view this post on Zulip Isaac Vetter (Sep 09 2020 at 21:29):

and yet, length of refresh is the only clear-cut patient-controlled aspect described:

Refresh tokens are an OAuth 2.0 concept, and are largely opaque to the end user. However, we clarify that patients are not prohibited from changing the length of refresh tokens to the degree this option is available to them. 

https://www.federalregister.gov/d/2020-07419/p-1254

view this post on Zulip Josh Mandel (Sep 09 2020 at 21:30):

Specifically: it doesn't impact a consumer's decision, because the details of refresh token usage are unknown/unknowable to consumers (these are technical decisions implemented by an app, out of a user's control).

view this post on Zulip Josh Mandel (Sep 09 2020 at 21:30):

Why do you say "and yet"? The excerpt you shared is 100% consistent with our discussion here.

view this post on Zulip Isaac Vetter (Sep 09 2020 at 21:33):

alright - I understand what you're saying, Josh. I wish the rule were a bit more clear or sophisticated about the refresh process, but I agree with your description of the intent -- patients must be able to enable persistent access and should be able to choose other lengths of time.

view this post on Zulip Josh Mandel (Sep 09 2020 at 21:35):

I don't think the rule opines on the "patients should be able to choose other lengths of time" question. But certainly they MAY, in conformance language :-)

patients are not prohibited

view this post on Zulip Isaac Vetter (Sep 09 2020 at 21:37):

:thank_you:


Last updated: Apr 12 2022 at 19:14 UTC