Stream: Security and Privacy
Topic: Patient directed backend communication
John Moehrke (Apr 03 2018 at 14:07):
A use-case has come forward where the Patient authorizes communications between two backend services. For example where the Patient as part of a CarePlan, endorses a specific clinician to be part of the CarePlan. The overall use-case is not specific to CarePlan, this is just one case. The point is that the backend services are authorized to communicate with each other by way of the Patient authorization.
John Moehrke (Apr 03 2018 at 14:07):
This might be enabled by an OAuth token? This might be enabled by a Consent resource? What are the specific characteristics?
John Moehrke (Apr 03 2018 at 14:08):
Are there some pilot projects that might inform us?
Kevin Shekleton (Apr 03 2018 at 14:52):
This sounds like the Sync for Science and Apple Health app use case: the patient authorizes an app (S4S or Apple Health app) that runs a backend process that periodically retrieves their data via FHIR.
John Moehrke (Apr 03 2018 at 15:07):
That is one perspective. I would agree that SfS can be used here. It does require a specific token configuration for long term use. I think the question is if this is intended by SfS, or not? Is it obvious to the patient, or not?
Kevin Shekleton (Apr 03 2018 at 15:09):
It's not just S4S -- the Apple Health app works in the same way.
Kevin Shekleton (Apr 03 2018 at 15:11):
It is the authorization server's responsibility to make the patient aware as to what they are agreeing to. I think it is a fair question as to whether the patient understands what they are agreeing to. With the latest Facebook data sharing (both Cambridge Analytica and the Fb Android app permission with call logs) conversation in the public right now would say people do not really understand what they are agreeing to.
John Moehrke (Apr 03 2018 at 15:13):
I am not clear on the specifics that @Grahame Grieve brought this to us. Is this simply documenting SfS as a solution? Or is there a specific problem with SfS here?
Kevin Shekleton (Apr 03 2018 at 15:27):
¯\_(ツ)_/¯
Grahame Grieve (Apr 03 2018 at 18:20):
no this is more that s4s. At present, if I wanted to use smart app launch the way s4s does, to enable to health services to communicate with each other, one has to offer a sync client, and there's a distinct directionality to it. That's definitely not the same as 'instruct 2 health providers to communicate about me'
Kevin Shekleton (Apr 03 2018 at 18:34):
Can you elaborate on this use case, Grahame?
Grahame Grieve (Apr 03 2018 at 18:35):
the use case came to me from several VA related providers, but @Aaron Seib may describe it better
Grahame Grieve (Apr 03 2018 at 18:38):
at present, in USA, my providers may communicate about me to each other using direct. if they have the appropriate trust relationships set up with each other. Which holds patients to what institutions can agree. But the patient can make their own agreements. Instructing 2 institutions to share data about a patient is different to providing one instutition with access to my patient summary information from another
And in lots of jurisdictions, what the providers can/must say to each other is different from what the patient has access to.
John Moehrke (Apr 03 2018 at 19:18):
So, the question we have is why is Sync For Science method of enabling a service to talk to an app not sufficient. Where the one provider's backend is the app, and the other is the service? Thus the patient authorizes the two to bidirectionally talk (over a client/server relationship).
Grahame Grieve (Apr 03 2018 at 19:19):
it's not really bi-directional then is it?
John Moehrke (Apr 03 2018 at 19:20):
is that the key differentiatior?
Grahame Grieve (Apr 03 2018 at 19:22):
no. for me, there 3 key differentiators:
- true bi-directional communications (not one as client, one as server)
- institutions can trust each other as opposed to having to trust the patient (not established by S4S at this time)
- authorized by the patient without requiring all institutions to be registered with each other
Grahame Grieve (Apr 03 2018 at 19:23):
if you can sort that out on the existing smart app launch spec... I'm all ears
John Moehrke (Apr 03 2018 at 19:27):
so it is differentiated from backend trust, in that it is dynamically created by the patient? That is that it isn't a persistent trust (DURSA)? Is backend trust looking at bi-directional communication, or is that new here too?
Grahame Grieve (Apr 03 2018 at 19:27):
backend trust would be where the institutions have the trust arrangement. There's a big place for that, but it's not this problem
John Moehrke (Apr 03 2018 at 19:29):
understood, and I think I recognized that fact.... but I am still not sure what all the new characteristics are.
Julie Maas (Apr 11 2018 at 16:22):
It seems like there are two pieces here--the patient directed authorization and the actual cross-system authentication. The patient directive can identify the systems who are authorized to share data about him/her (assuming authorization isn't already implicit via regulatory avenues such as TPO under HIPAA). However, a reliable and trustworthy way for the systems to authenticate each other is still needed since it seems this use case assumes the participants may not have pre-existing relationships. This is the same issue we were addressing in the Direct/Certificates track at the New Orleans connectathon to enable cross-system data access using certificate-based trust networks for provider system authentication without n*(n-1) preregistration events. It seems like the authentication piece of this use case would be a good fit to add to the Direct/Certificates track.
Mohammad Jafari (Apr 21 2018 at 21:57):
@John Moehrke This seems to be aligned with the work we did which was based on using a Consent resource as the governing policy over issuing UMA/OAuth tokens. The goal was to use UMA/OAuth while not necessarily requiring active involvement of the patient since the use-case takes place between two backend systems. I think that report can inform this discussion. https://gforge.hl7.org/gf/project/security/docman/CCDE%20Consumer%20Centered%20Data%20Exchange%20Connectathon/CCDE%20Interim/UMA_Consent_Management_Service-2017-11-27.pdf
Last updated: Apr 12 2022 at 19:14 UTC
