Re: [Txauth] Possible Use Case for GNAP

[Tom Jones <[e-mail]>]

My guess is that txauth is only concerned with the link between the user
(indirectly to get consent) the destination EHR, which is perversely called
the client of the user, and the RS which is the combined HIE in its
entirety. The RCE should work out the hop x hop stuff. This link (which i
sent out previously) is intended to address the patient as the AS with a
self issued ID. The interesting problem from health care is that the AS
consent will need to be in terms that the user understands, which is not
defined, and not the FHIR claims detail. The HIAWG of Kantara has taken on
the challenge of healthcare identity assurance semantics. A different
Kantara WG is working on the syntax of these messages.
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
Peace ..tom


On Thu, Jul 2, 2020 at 10:02 AM David Pyke <[e-mail]>
wrote:

> Each hop relays the information but may have to do a transform on the data
> on the way through.  So, the data shouldn't be archived as the network is
> designed purely to route request and responses from originator to
> responder.  As such, there's no need for individual access notifications.
> However, the data is not necessarily encrypted as this is designed as a
> trusted network.  The FHIR query would be routed through to the responder,
> and the results routed back to the query originator.
>
> Notifications to the user would be not needed as to the originator system
> the network is (should be) transparent.  However, to maintain the trust of
> the authorization/authentication, each hop will have to capture, and
> forward to one or more responders in the network.
>
> For example
>
>    1. EHR A sends out a patient record discovery request to it's upstream
>    actor, that is forwarded to it's upstream HIN.
>    2. The HIN sends that request to all other HINs who forward it
>    (depending on the capabilities of the HIN) to the various actors.  The
>    originating user needs to be identified to the responders for audit and
>    access consent. However, the cert that is used may (and likely will) change
>    for each hop and be different the org that was the query source, which will
>    still need to be identified to the responders
>    3. Some of those actors' EHRs respond saying they have data on that
>    patient.
>    4. The responding HINs aggregates the responses and sends on bundle to
>    the initiating HIN who forwards it via it's network to the query source
>    5. That source sends out a requests to saying "Send me the data from
>    all the sources", that goes out, and results are aggregated on the way back
>    into one bundle.  Same requirements as 2
>
> All of that needs to be managed from a trust/authentication/authorization
> point of view. Simple, right?
>
>
> On 2020-07-02 12:45 p.m., Tom Jones wrote:
>
> without a better understanding of the "hop" it is hard to say. Does each
> "hop" archive the PHI in FHIR format? if so each would need to notify the
> user of access, as i see the problem. That sounds like something that would
> scare the patient. If the "hop" just handled (for example) an encrypted
> packet, that would not be a problem. OTOH if a federation were involved,
> the federation could notify the user. Less scary perhaps.
> Peace ..tom
>
>
> On Thu, Jul 2, 2020 at 9:41 AM David Pyke <david.pyke=
> [e-mail]> wrote:
>
>> Great to hear!
>>
>> My main concern is that the cert use may be an issue as it's passed
>> through the hops.  A hop may want to have their predecessor  use the
>> predecessor's cert coming in but may swap out their own cert for the next
>> connection (and the same happening on the way back).  So, the ability to
>> trace certs through the relaying would be an issue so that trust is
>> maintained even when those certs aren't chained together.  It would be good
>> if there was one cert or a set of chained certs used for the two traversal
>> but that's not likely to be the case..
>>
>> Thanks!
>> On 2020-07-02 12:26 p.m., Tom Jones wrote:
>>
>> We discussed that use case this morning in OIDC. A proposal has been made
>> for a new endpoint that I would like to see working from the EHR endpoints.
>> Did you have other concerns besides the source and destination endpoints
>> for the data?
>> Peace ..tom
>>
>>
>> On Thu, Jul 2, 2020 at 8:30 AM David Pyke <david.pyke=
>> [e-mail]> wrote:
>>
>>> I am working on a Healthcare IT project that requires multi-hop
>>> transmission of REST based (FHIR: fhir.hl7.org) resources.  The
>>> established protocol uses OAuth2 which doens't lend itself to multi-hop
>>> relay.
>>>
>>> I saw a presentation on XYZ/GNAP and thought it might be early enough to
>>> get on the train to consider how it might address that structure.  The
>>> system I'm working on is from the US Office of the National Coordinator for
>>> Healthcare IT (ONC) called TEFCA.  At minimum there would be 4 hops, at
>>> maximum, could be 8-10 and no bypassing of the network can be done.  As I
>>> said, OAuth2 doesn't handle that without significant issues.
>>>
>>> If this is not a use case that can be considered, please accept my
>>> apologies.
>>>
>>> Thanks
>>>
>>> Dave Pyke
>>> --
>>>
>>> *David Pyke*
>>>
>>> Manager, Strategic Consulting
>>>
>>>
>>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>
>>> [image: Logo] <http://www.readycomputing.com/>
>>>
>>> [image: LinkedIn icon]
>>> <https://www.linkedin.com/company/ready-computing> [image: Twitter icon]
>>> <https://twitter.com/ready_computing?lang=en> [image: Youtbue icon]
>>> <https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>
>>>
>>> Office: [phone] x5001
>>>
>>> * [e-mail] <[e-mail]>*
>>>
>>> * www.readycomputing.com <http://www.readycomputing.com/>*
>>>
>>> 150 Beekman Street, Floor 3, New York, NY 10038
>>>
>>> The information in this e-mail communication together with any
>>> attachments is intended only for the person or entity to which it is
>>> addressed and may contain confidential and/or privileged material. If you
>>> are not the intended recipient of this communication, please notify us
>>> immediately. Any views expressed in this communication are those of the
>>> sender, unless otherwise specifically stated. Ready Computing does not
>>> represent, warrant or guarantee that the integrity of this communication
>>> has been maintained or the communication is free of errors, virus or
>>> interference.
>>>
>>> This is not a secure transmission. The information contained in this
>>> transmission is highly prohibited from containing privileged and
>>> confidential information, including patient information protected by
>>> federal and state privacy laws. It is intended only for the use of the
>>> person(s) named above. If you are not the intended recipient, you are
>>> hereby notified that any review, dissemination, distribution, or
>>> duplication of this communication is strictly prohibited. If you are not
>>> the intended recipient, please contact the sender by reply email and
>>> destroy all copies of the original message. --
>>> Txauth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>> --
>>
>> *David Pyke*
>>
>> Manager, Strategic Consulting
>>
>>
>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> [image: Logo] <http://www.readycomputing.com/>
>>
>> [image: LinkedIn icon] <https://www.linkedin.com/company/ready-computing> [image:
>> Twitter icon] <https://twitter.com/ready_computing?lang=en> [image:
>> Youtbue icon] <https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>
>>
>> Office: [phone] x5001
>>
>> * [e-mail] <[e-mail]>*
>>
>> * www.readycomputing.com <http://www.readycomputing.com/>*
>>
>> 150 Beekman Street, Floor 3, New York, NY 10038
>>
>> The information in this e-mail communication together with any
>> attachments is intended only for the person or entity to which it is
>> addressed and may contain confidential and/or privileged material. If you
>> are not the intended recipient of this communication, please notify us
>> immediately. Any views expressed in this communication are those of the
>> sender, unless otherwise specifically stated. Ready Computing does not
>> represent, warrant or guarantee that the integrity of this communication
>> has been maintained or the communication is free of errors, virus or
>> interference.
>>
>> This is not a secure transmission. The information contained in this
>> transmission is highly prohibited from containing privileged and
>> confidential information, including patient information protected by
>> federal and state privacy laws. It is intended only for the use of the
>> person(s) named above. If you are not the intended recipient, you are
>> hereby notified that any review, dissemination, distribution, or
>> duplication of this communication is strictly prohibited. If you are not
>> the intended recipient, please contact the sender by reply email and
>> destroy all copies of the original message. --
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> --
>
> *David Pyke*
>
> Manager, Strategic Consulting
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> [image: Logo] <http://www.readycomputing.com/>
>
> [image: LinkedIn icon] <https://www.linkedin.com/company/ready-computing> [image:
> Twitter icon] <https://twitter.com/ready_computing?lang=en> [image:
> Youtbue icon] <https://www.youtube.com/channel/UCtA7SflMXNTkY0MWL-79LDQ>
>
> Office: [phone] x5001
>
> * [e-mail] <[e-mail]>*
>
> * www.readycomputing.com <http://www.readycomputing.com/>*
>
> 150 Beekman Street, Floor 3, New York, NY 10038
>
> The information in this e-mail communication together with any attachments
> is intended only for the person or entity to which it is addressed and may
> contain confidential and/or privileged material. If you are not the
> intended recipient of this communication, please notify us immediately. Any
> views expressed in this communication are those of the sender, unless
> otherwise specifically stated. Ready Computing does not represent, warrant
> or guarantee that the integrity of this communication has been maintained
> or the communication is free of errors, virus or interference.
>
> This is not a secure transmission. The information contained in this
> transmission is highly prohibited from containing privileged and
> confidential information, including patient information protected by
> federal and state privacy laws. It is intended only for the use of the
> person(s) named above. If you are not the intended recipient, you are
> hereby notified that any review, dissemination, distribution, or
> duplication of this communication is strictly prohibited. If you are not
> the intended recipient, please contact the sender by reply email and
> destroy all copies of the original message.