[Openid-specs-heart] Purpose of Use

Tue May 16 17:42:42 UTC 2017

well... if not third party access, then normal OAuth will work just fine...

See the fine work done leveraging this patient right of access, Sync for
Science
https://www.healthit.gov/buzz-blog/health-innovation/nih-and-onc-launch-the-sync-for-science-pilot/

And if you are finding that normal OAuth or even lesser technology
(username/password) is not working, then adding another layer of OAuth/UMA
is not likely to fix the problem...

again, I am not arguing that Patient Right of Access is universally
accepted and implemented... Just that adding more technology will not fix a
fundamental misunderstand. A misunderstanding that HHS has tried over and
over to fix.

Of course, I live in Wisconsin were there is no such data blocking...   :-)

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and
Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067
JohnMoehrke at gmail.com
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Tue, May 16, 2017 at 12:19 PM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> John
>
>
>
> Your point is certainly well taken.
>
>
>
> UMA is more powerful when it enables the user to manage third party access
> rights.  I am just not sure I subscribe to the notion that we should be
> building toward a world where there are still 3rd party access rights.
>
>
>
> I may be alone in seeing it this way but I had thought that UMA was a
> candidate for the consumer to convey to its app what the individual’s
> sharing preferences would be.  In the future the holder of a 3rd Party
> Auth would be going to their Consumer Controlled app to collect data for a
> given purpose of use.  I see how it could work both ways.
>
>
>
> I may be speaking heretically here but do we really believe that a
> Provider Organization should be accountable for handling 3rd party auths?
>
>
>
> I am speaking really practically here.  Do Provider Organizations have the
> bandwidth to handle 3rd party auths at scale?  I am not talking about the
> volume of these kinds of Auths today.  I am envisioning in the future when
> more consumers are authorizing sharing with researchers or for other
> purposes of use.
>
>
>
> It seems to me that the Consumer Apps would be the place that would have
> the value add from building the computing capacity to manage those
> transactions.  Not the Data Source.  The benefit of the Data Source doing
> it is that you don’t have to solve the Provenance Problem but if I am
> following along the FHIR Resources are being defined to account for that.
>
>
>
> At the end of the day it may be a policy question but I would argue from a
> policy perspective that in the best of all possible worlds the data should
> flow from the consumer to the researcher.
>
>
>
> There is probably more to it that others can point out that I am missing
> but from an SDO perspective what you say makes sense.
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311 <(301)%20540-2311>
>
> (m) 301-326-6843 <(301)%20326-6843>
>
> <http://nate-trust.org>
>
>
>
> *From:* John Moehrke [mailto:johnmoehrke at gmail.com]
> *Sent:* Tuesday, May 16, 2017 12:24 PM
> *To:* Aaron Seib
> *Cc:* Justin Richer; HEART List
>
> *Subject:* Re: [Openid-specs-heart] Purpose of Use
>
>
>
> Aaron,
>
>
>
> Thanks for illuminating. I have not been able to keep up with all of the
> current intent of HEART. It seems that you are saying that the current goal
> of HEART is always patient access. As you point out PurposeOfUse = “Patient
> Access”... If this is indeed the case, then it would be best to state that
> as a fixed PurposeOfUse. When stated that way, it is more clear.
>
>
>
> This means however that other PurposeOfUse are not accepted. I seem to
> recall use-cases that were being discussed where the HEART AS was
> intermediating Treatment use-cases. Where the patient would be authorizing
> specific Providers to access their data through HEART (UMA). This would be
> a PurposeOfUse of TPO. It would be important to be specific that "Dr Bob"
> has TPO access, but not research or other access.
>
>
>
> Or uses where the Patient is authorizing access by a Research project...
> or where they are authorizing access for other uses.
>
>
>
> I am not trying to say that PurposeOfUse is essential, but rather to point
> out that it enables an 'intent' vector.
>
>
>
> I think limiting HEART to only the patient accessing their own data is too
> limiting. This is indeed an important use-case, isn't that a much more
> simple two party use-case? UMA is more powerful when it enables the "User"
> (aka Patient) to manage third parties access rights. Thus it seems way too
> limiting to just focus on patient access.
>
>
>
> John
>
>
> John Moehrke
> Principal Engineering Architect: Standards - Interoperability, Privacy,
> and Security
> CyberPrivacy – Enabling authorized communications while respecting Privacy
> M +1 920-564-2067 <(920)%20564-2067>
> JohnMoehrke at gmail.com
> https://www.linkedin.com/in/johnmoehrke
> https://healthcaresecprivacy.blogspot.com
> "Quis custodiet ipsos custodes?" ("Who watches the watchers?")
>
>
>
> On Fri, May 12, 2017 at 8:19 AM, Aaron Seib <aaron.seib at nate-trust.org>
> wrote:
>
> Perhaps a very important qualification to add to this discussion is that
> the PurposeOfUse = “Patient Access” is the essential trump card in the
> entire paradigm as far as I am concerned.
>
>
>
> This is what I mean.  If consumer wants their data the data holders
> (specific the Covered Entities of HIPAA) have absolutely no right asking
> what the consumers intended “pou” is and they are obligated by law to send
> their data to the designated endpoint indicated by the consumer.
>
>
>
> I am sure no one on this thread needs to hear that reminder but I am not
> exaggerating when I tell you *every single time* I am trying to help
> someone get - their data out in the real world - that I have to “educate”
> the data holders about this fact.  Every time I make a call the first
> question out of the orgs mouth is “What do you want it for.”
>
>
>
> PurposeOfUse comes into play when the Institution Data Holder is pushing
> the data to a 3rd party independent of the consumer.  Perhaps it also has
> a role to play when the consumer directs the data holder to share the PHI
> with another third party *on their behalf*, such as when they direct a
> Provider to share their data with an a research repository – a workflow
> that I have seen proposed by a couple of programs in the country.
>
>
>
> In a perfect world I argue that this not the best practice – the consumer
> should request the data to a consumer app that they control and then
> subsequently share that date with the destination(*s*) of their choice.
> The programs that are building “middle-ware” that takes the consumer’s
> approval to share with their research end-point and presents that to the
> Institution where upon the data is transferred to the Program’s destination
> are inadvertently leaving a lot of value on the table as I believe the
> consumer should have access to this data in an app that they can use for
> other purposes.  Including making donations of their data to other research
> activities.
>
>
>
> Of course the catch 22 for the research community is that not enough
> consumers have their own apps that can support that today *but they
> will.  *If in were in fact a perfect world the Program’s would be able to
> provide the consumer’s with a way to pick a consumer app of their choice to
> populate.  The consumer apps would have the enabling infrastructure to make
> the donation of their data to one or more research destinations of their
> choice and everyone would benefit significantly more.
>
>
>
> But that is only a dream today and probably not relevant to this work
> group, right?
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311 <(301)%20540-2311>
>
> (m) 301-326-6843 <(301)%20326-6843>
>
> <http://nate-trust.org>
>
>
>
> *From:* Openid-specs-heart [mailto:openid-specs-heart-
> bounces at lists.openid.net] *On Behalf Of *John Moehrke
> *Sent:* Friday, May 12, 2017 4:20 AM
> *To:* Justin Richer
> *Cc:* duane decouteau; openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Purpose of Use
>
>
>
> PurposeOfUse is indeed a critical aspect in healthcare. It is the highest
> differentiation, higher than user-role. It indicates the broader context
> that the data is to be used within. For example a request for data in
> healthcare often is onbehalf of a broader use: Treatment, Coverage,
> Research, etc. It is not an attribute of the user, it is an attribute of
> the request for information. It is not uncommon for identity and context
> attributes to be conflated or simply communicated in one token; however
> that does not mean they really are the same, it just means that the
> environment has made a simplifying assumption to combine for ease of
> technology. It is most closely aligned with the broadest part of a OAuth
> scope. So it should be included in the request for authorization decision,
> and authorization token.
>
>
> John Moehrke
> Principal Engineering Architect: Standards - Interoperability, Privacy,
> and Security
> CyberPrivacy – Enabling authorized communications while respecting Privacy
> M +1 920-564-2067 <(920)%20564-2067>
> JohnMoehrke at gmail.com
> https://www.linkedin.com/in/johnmoehrke
> https://healthcaresecprivacy.blogspot.com
> "Quis custodiet ipsos custodes?" ("Who watches the watchers?")
>
>
>
> On Thu, May 11, 2017 at 3:29 PM, Justin Richer <jricher at mit.edu> wrote:
>
> The “pou” claim as it was specified in HEART does not fit this use case,
> then, and it’s appropriate that we removed it. This was a claim presented
> by the requesting party’s identity provider, and had nothing to do with the
> request being made by the client itself. That’s why I argued it wasn’t a
> good fit where it was. If we were to add it back in, it should go elsewhere
> in the protocol.
>
>
>
>  — Justin
>
>
>
> On May 11, 2017, at 2:01 PM, Nancy Lush <nlush at lgisoftware.com> wrote:
>
>
>
> Hello all,
>
>
>
> Per our last meeting, I agreed to provide more information on the need for
> the pou claim.
>
>
>
> The claim pou was recently removed from the HEART specs and needs to be
> restored.
>
>
>
> I spoke with Duane Decouteau from the VA team and provide the following
> details:
>
>
>
> Purpose of use drives policy in many electronic exchanges today.  The
> custodian organization uses the claimed purpose of use to interpret
> policy.  For instance, if the pou is ‘Treatment’ a complete record might be
> provided, but if the pou is ‘Coverage’ the policy may limit what is sent.
> If the pou is ‘Research’ then the custodian organization might need to
> de-identify the data on the way out.
>
>
>
> The pou is passed as a claim within the request. It is a determining
> factor in evaluating which policies apply to a request.  Pou is implemented
> in ehealth exchange as an underlying principal.  Duane feels that pou
> should be a cornerstone for patient consent.  It is fully implemented now
> in ehealth exchange at the VA, Kaiser and others.
>
>
>
> The list of pou values can be found at this link:   https://www.hl7.org/
> fhir/v3/PurposeOfUse/vs.html
>
>
>
> Respectively,
>
> Nancy
>
>
>
>
>
>
>
>
>
> *Nancy Lush          *
>
> nancy.lush at lgisoftware.com
>
> *Lush Group, Inc*
>
> Office: (401) 423-9111
>
> 28 Narragansett Ave
>
> PO Box 651
>
> www.lgisoftware.com
>
> Cell:(401) 965-9347
>
> Jamestown, RI 02835
>
>
>
> <image001.gif>
>
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170516/24b25210/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2369 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170516/24b25210/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 2369 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170516/24b25210/attachment-0001.jpg>