Stream: smart
Topic: Pushing data outside EHR
Grahame Grieve (Oct 17 2017 at 02:12):
@Josh Mandel got a question about pushing data out of an EHR
Grahame Grieve (Oct 17 2017 at 02:14):
once an EHR has set up a smart on FHIR service, the easiest way to refer a patient to an external service, with data, is via a smart on FHIR app - it loads up, loads data from the EHR, asks any additional questions that are relevant, and then submits the data. There's all sorts of uses for that, and it's way cool that the recipient can write the smart up without really needing to work with the EHR provider to do the integration
Grahame Grieve (Oct 17 2017 at 02:15):
but what about the following scenario:
- once a clinician has used the SMART on FHIR application once, then additional changes to the patient's problem list or medication list should be pushed to the external recipient
Grahame Grieve (Oct 17 2017 at 02:15):
(of course, this assumes that appropriate consent etc has been gathered. Let's assume that happens)
Grahame Grieve (Oct 17 2017 at 02:16):
I can't imagine how the recipient could implement this in smart on fhir application.... they'd be stuck back waiting for custom back end integration from the source EHR... or have I missed something?
Josh Mandel (Oct 17 2017 at 02:53):
Definitely a key use case. If I replace the phrase "should be pushed to" with "should be made available to", then long-term access with refresh tokens can help with this scenario.
Grahame Grieve (Oct 17 2017 at 02:56):
umm I don't understand that second bit. How does a long term access / refresh tokens help?
David Teirney (Oct 17 2017 at 02:57):
Assuming that there's a way for that application to continuously run. Some SMART on FHIR applications will only live for as long as they are being driven by the web browser instance that they were launched into. If there is any server component to that web application there's no guarantee that it will have any network connection between them and the EHR. The browser effectively acts like a proxy between EHR and whatever other backend the SMART on FHIR application connects to.
Grahame Grieve (Oct 17 2017 at 02:58):
I guess that's where I'm stuck - I can make a long term access token, but where does the app run?
David Teirney (Oct 17 2017 at 03:03):
We've run into that integration challenge with an application running on a desktop and integrating with an EHR application through FHIR APIs (outside of SMART on FHIR launch). We had feedback that the person using the EHR would like to verify any information that was sent out to our backend (also FHIR based) to ensure only appropriate information was being sent to the other system via that mechanism.
David Teirney (Oct 17 2017 at 03:05):
Are there other parts of the FHIR ecosystem where this challenge resides as well? E.g. CDA push of Patient Summary documents at the end of an encounter within an EHR was hoped to ensure that a bunch of downstream systems were at least updated with core summary information. Not sure where CDA on FHIR is at but is that hoped to cover off part of this?
Grahame Grieve (Oct 17 2017 at 03:07):
@Kevin Shekleton @Brett Esler do you guys have arrangement for long running apps?
Grahame Grieve (Oct 17 2017 at 03:09):
though really, there's a difference here - the UI app is authorised for a single patient. You don't want 1000s of long running apps, one for each patient. This breaks down to a second app using the bulk data interface, I think
Kevin Shekleton (Oct 17 2017 at 03:17):
We don't have any apps used by a practitioner that want to run longer than the user's session. As I'm sure you're already aware, we have a patient facing app (Sync4Science) that is doing this.
Kevin Shekleton (Oct 17 2017 at 03:18):
If you have a long running app like you're describing, the FHIR access needs to be moved to the server rather than the browser
Grahame Grieve (Oct 17 2017 at 03:20):
.... and you don't currently support that except through the patient facing app? And if I think this through you don't have any infrastructure to link a clinician action to a patient OAuth consent - that'd be 2 entirely separate actions
Kevin Shekleton (Oct 17 2017 at 03:26):
Right now, we just support the really long lived access tokens with patient facing apps (simply because we haven't run into provider facing apps that need this yet)
Kevin Shekleton (Oct 17 2017 at 03:27):
Can you clarify what you mean by "you don't have any infrastructure to link a clinician action to a patient OAuth consent - that'd be 2 entirely separate actions"?
Grahame Grieve (Oct 17 2017 at 03:36):
well, in an ideal world - from the patient's POV - the fact that they consented to the sharing, and did share.. they then start again from scratch with consent and sharing on the patient portal... patient matching... ah....
Grahame Grieve (Oct 17 2017 at 10:27):
just looking at yet another proposal. The most natural sequence would be:
- clinician uses a smart app to register a patient with [some clinical repository]
- the smart app knows the patient portal for the system it's running in, and authorizes the [clinical repository] to access data from the patient portal
- the patient can revoke that later if they want
Grahame Grieve (Oct 17 2017 at 10:27):
I think we haven't actually nailed that workflow down, @Josh Mandel
Grahame Grieve (Oct 17 2017 at 10:28):
and also, there's a cds-hook that can prompt the clinician to talk to the user about registering an eligible patient
Grahame Grieve (Oct 17 2017 at 10:33):
(that bit is already all hooked up)
Josh Mandel (Oct 17 2017 at 13:43):
We usually think about which user (or organization) is allowing access. In our current SMART approach, the answer is: someone who has access and is able to share. That is typically a provider working at an organization, or a patient -- what you're describing seems to be a hybrid @Grahame Grieve, where a provider and then also a patient would need to allow access? Can you explain why this model looks important? If either party alone has the right to share, why require both together to enable the connection?
Grahame Grieve (Oct 17 2017 at 13:47):
Well, its more about workflow - the clinician makes the referral, but then data keeps flowing; the patient has control. Better to hand over seamlessly than to make the patient also make the connection again.
Josh Mandel (Oct 17 2017 at 13:51):
So this is supported. The way you'd accomplish it would be with two SMART app launches: one from the EHR, which a clinician approves; and the other a Standalone launch which the patient approves. How these two launches are tied together is not something the platform tries to solve. But for example the external registry could send an email to the patient to kick off the process continuation. Or the initiating provider could print out a sheet of paper with instructions on how to continue sign up. Or the clinician could give the patient a tablet for in-office use. Or any other method you could dream up.
Grahame Grieve (Oct 17 2017 at 22:34):
I will think about this some more but I feel as though there's something missing from SMART here - and it's come up for me in a different context
Grahame Grieve (Oct 17 2017 at 22:34):
I think that a smart app should be able to ask the authorization server to clone it's session, so that it can generate a new session that has different (derived) properties.
Grahame Grieve (Oct 17 2017 at 22:36):
one use where I think this is very pertinent is with cds-hooks, where an application probably doesn't want the cds-hooks server to have all the same rights to access the patient record that it does. In fact, it very likely wants to retain the write level privileges for itself. But as things stand, there's no arrangement for it to get an access token that has different (less) privileges than it has.
Grahame Grieve (Oct 17 2017 at 22:36):
and then this is another case - generate a long lasting session that has different (less) rights than the initial session
Grahame Grieve (Oct 17 2017 at 22:38):
a related question that came up for me while thinking about this: the smart app launch spec is not specific about that you can use an authorization token only once...
Grahame Grieve (Oct 17 2017 at 22:38):
is that meant to be the case? it's the case in my implementation...
Jenni Syed (Oct 18 2017 at 17:27):
@Grahame Grieve what do you mean that you can only use the authorization token once? That would lie in the purview of the OAuth spec - which says you can use the token until it expires
Jenni Syed (Oct 18 2017 at 17:31):
EG: https://tools.ietf.org/html/rfc6749#section-1.4 and https://tools.ietf.org/html/rfc6750 (since we use Bearer tokens in SMART)
Jenni Syed (Oct 18 2017 at 17:32):
expires or becomes otherwise invalid :) but usually that invalid (in my experience) is based on security features that would disable tokens that were compromised
Jenni Syed (Oct 18 2017 at 17:32):
Something neither SMART nor the OAuth 2 Framework want to describe in detail - how that is controled is usually left up to the implementer. The spec allows you to communicate the expiry (if it applies) and errors if the token becomes otherwise invalid
Jenni Syed (Oct 18 2017 at 17:35):
As to the long running session having less permissions than the initial: Yeah, that's not specifically required by SMART nor OAuth (and I'm not sure if we want it to be), but the authorization server can choose to remove scopes when the token is refreshed, or the app can request fewer scopes when they get a new token.
Jenni Syed (Oct 18 2017 at 17:36):
In the S4S case: the app requests the scopes it needs for the long running session. We use those requested scopes to tell the patient what the app will use. S4S could request fewer scopes later, but we already told the patient they have access to more
Jenni Syed (Oct 18 2017 at 17:37):
If S4S tried to ask for more, our server wouldn't let it, since the patient didn't authorize that (S4S would need to kick off a new authorization request somehow)
Elliot Silver (Oct 18 2017 at 21:28):
Grahame's question of long-running apps and notification of updates actually looks like an issue @Isaac Vetter should be considering with his Context Synchronization PSS (not yet approved).
Isaac Vetter (Oct 19 2017 at 02:23):
once a clinician has used the SMART on FHIR application once, then additional changes to the patient's problem list or medication list should be pushed to the external recipient
In my opinion, S4S's model of periodically polling the FHIR server is technically (and understandably) flawed because it simply made use of the RESTful APIs that were being implemented. I believe strongly that periodic polling for event-based data is almost never the elegant design.
Rather, the technically correct approach for both S4S, and (I think), the scenario that you're describing, @Grahame Grieve , is for the clinician-launched SMART app to both get a refresh_token and to create a Subscription.
Isaac Vetter (Oct 19 2017 at 02:24):
I think that a smart app should be able to ask the authorization server to clone it's session, so that it can generate a new session that has different (derived) properties.
This sounds awfully complicated. I'll reiterate @Josh Mandel 's point that:
The way you'd accomplish it would be with two SMART app launches: one from the EHR, which a clinician approves; and the other … which the patient approves … for example the external registry could send an email to the patient … or the initiating provider could print out a sheet of paper … or the clinician could give the patient a tablet for in-office use
or the provider sends the patient a message from their EHR with a link to the app or the app can be launched from the patient's portal or …
Isaac Vetter (Oct 19 2017 at 02:25):
Overall --
- Subscriptions is a great way to push updates. RESTful queries aren't.
- We already do have a great model for either a clinician or a patient authorizing long-running data access to an app. It's refresh tokens via the SMART launch spec.
- In-browser apps aren't good at long-running access -- this isn't a problem that should be solved by the authorization server. It's a simple matter of the app adding minimal, persistent app storage.
Grahame Grieve (Oct 19 2017 at 02:30):
@Jenni Syed I mean to refer to 'authorization code' - can you use that more than once. Sorry for that mistake
Grahame Grieve (Oct 19 2017 at 02:32):
@Isaac Vetter I think I'd prefer a subscription, but what's the timeline for supporting that? But I think you overlooked an important part of my question - how can an EHR client that is itself an OAuth client invoke a cds-hook and provide it with some access to a server, but not all the access the client itself has? at present, we have no infrastructure for this, and I think this is a big security flaw in cds-hooks as it is
Grahame Grieve (Oct 19 2017 at 02:33):
nor do I think that the problem of long running apps can be solved by adding minimal, persistent storage. that might be useful, but where does this stuff happen?
Grahame Grieve (Oct 19 2017 at 02:33):
as for subscriptions.. fine. I like that model... but what's a working model for long term subscriptions from a smart app that's not shot full of security holes or demands for heaps of admnistration?
Grahame Grieve (Oct 19 2017 at 02:34):
I think the S4S model is not terribly efficient, but administation is certainly simple
Isaac Vetter (Oct 19 2017 at 02:37):
Grahame, yes, you're definitely right that I'm overlooking the complexity of your scenario and don't know your timelines. Subscriptions is how we should solve this general problem eventually.
what's a working model for long term subscriptions from a smart app that's not shot full of security holes or demands for heaps of administration?
I think that a working model could be that the FHIR server only accepts a new Subscription with an end datetime equal to or less than the expiration date of the app's token. The app would need to refresh or reauthorize to maintain it's subscription past that time.
Venkateswara R Davuluri (Oct 19 2017 at 02:41):
Not try to change the topic. But I have a question. How complex is to implement Subscriptions in an iOS or web client ? GraphQL vs RESTful vs Subsciptions, which one is better ?
Isaac Vetter (Oct 19 2017 at 02:46):
Hey @Venkateswara R Davuluri, there's a couple different "channel" methods defined in the spec, which I think would influence what platform would be better.
I think that FHIR Subscriptions and REST/GraphQL have different use-cases and naturally complement one another. Subscriptions is FHIR's pub/sub model.
Venkateswara R Davuluri (Oct 19 2017 at 14:18):
Dear @Isaac Vetter Thank you for response. We are presently working on REST for an iOS application. we tried to use SubScriptions - but constant chaning client IP and How to handle the events in Server side are two limitation, I noticed. Thank you.
Josh Mandel (Oct 19 2017 at 14:48):
@Grahame Grieve you may be interested in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-09 which is an effort at:
defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.
Josh Mandel (Oct 19 2017 at 14:48):
It's an interesting area, to be sure.
Josh Mandel (Oct 19 2017 at 14:49):
When it comes to authorization codes: we don't technically require servers to treat these as one-time-use codes, but it is important for servers to prevent inappropriate replay. Our S4S test suite checks to make sure codes don't work more than once, and I think this the right approach. We could definitely add this as guidance.
Grahame Grieve (Oct 22 2017 at 19:50):
yes, that rfc is definitely interesting
Grahame Grieve (Oct 24 2017 at 04:17):
and yes, we should document that authorization codes are one use only.
Last updated: Apr 12 2022 at 19:14 UTC
