Stream: smart
Topic: registering an app
David Hay (Dec 12 2017 at 22:02):
The spec states that all apps when registered with an EHR must register one or more Launch URL's. But this only applies for an EHR launch, nt a standalone launch - correct?
Douglas DeShazo (Sep 21 2021 at 16:08):
Please let me know if this belongs on the implementers stream. We (LNRS) have a use case we would like to implement which asks the question 'does our customer need to register with each target as an app-developer in the scenario below, or can we manage the entire registration ourselves'. I've read the OAuth2 and Consent thread, looked at FHIR UDAP, etc. but am having trouble getting to an answer on this or if this is even feasible currently.
Workflow:
1. LNRS offers a solution to Health Plan A (Customer) to pull Patient Access data on their behalf
2. Health Plan A (Customer) engages Member A to request permission to receive their “Patient Access” at Health Plan B (Target)
3. Member A authenticates themselves and authorizes the release of information at Health Plan B (Target)
4. Health Plan B (Target) provides a consent token to Health Plan A (Customer) to allow access to the Patient Access API
5. Health Plan A (Customer) passes the consent token to LNRS
6. LNRS accesses Health Plan B (Target) Patient Access API and authenticates the request with the token
7. LNRS pulls down the patient access data onto its platform
8. LNRS provides the normalized and enriched patient access data back to Health Plan A (Customer) via LNRS’ API
Josh Mandel (Sep 21 2021 at 17:06):
- Member A authenticates themselves and authorizes the release of information at Health Plan B (Target)
This is the crux, I think: does the member see a request (in the Health Plan B portal) like "Do you want to share your data with LNRS" or like "Do you want to share your data with Health Plan A"? Assuming the language is about Health Plan A, then you'll need to register an OAuth client representing Health Plan A (rather than LNRS) with Health Plan B.
Douglas DeShazo (Sep 22 2021 at 15:02):
Thanks @Josh Mandel will take under advisement. This seems to be a scenario that is cropping up, certainly for us, so is there anything like this being discussed in WG's anywhere? Davinci has PCDE, UDAP may have an approach for passing consent, IUA, but I haven't been able to locate OAuth.
Michele Mottini (Sep 22 2021 at 15:07):
This all works using standard SMART-on-FHIR, with the following modification: LNRS registers as Plan A, and step (4) and (5) become 'Health Plan B (Target) provides a consent token to LNRS (acting on behalf of Plan A)'
Michele Mottini (Sep 22 2021 at 15:07):
And it is a scenario covered by the DaVinci ePDX guide that the industry is (allegedly) implementing
Josh Mandel (Sep 22 2021 at 15:23):
To be clear in Michele's example, LRNS would need to maintain many individual app registrations (on behalf of its presumably many customers). The scaling story isn't ideal but it works today and doesn't involve exotic requirements.
Douglas DeShazo (Sep 22 2021 at 15:35):
Thanks guys because I'm not too worried about scaling at the moment and it appears that it can be done so that's a positive move forward. @Michele Mottini Are you referring to the base PDEX IG? I've tested that many times at Connectathon but not this scenario.
Michele Mottini (Sep 22 2021 at 15:37):
Yes, I am referring to this: https://build.fhir.org/ig/HL7/davinci-epdx/PDexImplementationActorsInteractionsDataPayloadsandMethods.html#oauth20-and-fhir-api
Michele Mottini (Sep 22 2021 at 15:38):
We are deploying that at our payer customers, most (all) payer seems to be going that way
Michele Mottini (Sep 22 2021 at 15:38):
...but I was not able to test it with anyone at the last connectathon
Michele Mottini (Sep 22 2021 at 15:39):
(although it is basically the standard SMART-on-FHIR flow, that is well tested in patient app connections with providers and now with some payers also)
Josh Mandel (Sep 22 2021 at 15:40):
Interesting that https://build.fhir.org/ig/HL7/davinci-epdx/PDexImplementationActorsInteractionsDataPayloadsandMethods.html#oauth20-and-fhir-api doesn't mention SMART, even though other sections on the same page do. Do you know @Michele Mottini whether this is intentional, or just a quirk?
Josh Mandel (Sep 22 2021 at 15:41):
I guess https://build.fhir.org/ig/HL7/davinci-epdx/Member-AuthorizedOAuth2Exchange.html overall doesn't point to any OAuth 2.0 profile (SMART or otherwise), which is weird; profiling is required for interop, and that's why SMART exists.
Michele Mottini (Sep 22 2021 at 15:41):
I don't know for sure but I think it is just a quirk
Isaac Vetter (Sep 24 2021 at 19:50):
- Member A authenticates themselves and authorizes the release of information at Health Plan B (Target)
This is a legal question, not a technical one.
Actually, if LRNS isn't a covered entity, the member releases their data to LRNS. LRNS merely needs to follow their own privacy policy for handling the data. There's no requirement that "Health Plan B"'s authorization page describes LRNS intended/eventual uses for the data. (Although some AS implementations try to).
My minimal understanding is that the data leaves HIPAA protections when the member authorizes it's release and then re-enters HIPAA protection once it's given to Health Plan A. Can anyone confirm or deny?
Josh Mandel (Sep 24 2021 at 20:22):
Presumably LRNS is acting as a business associate for its health plan customers.
Josh Mandel (Sep 24 2021 at 20:23):
As you say, it's a legal question, but I was assuming BAAs in place covering responsibilities and use of these data -- and in this context it's very much not "leaving" HIPAA. (Could LRNS offer a direct-to-consumer app instead? Sure.)
John Moehrke (Sep 27 2021 at 12:59):
Business Associates (BA) are more controlled now days than back at original HIPAA definition of BA, where the control was limited to the BA Agreement (BAA). -- so, yes a BA handling the data, is a protected space. (or should be)
Last updated: Apr 12 2022 at 19:14 UTC
