[Openid-specs-heart] Purpose of Use

Tue May 16 16:23:40 UTC 2017

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
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/4414a6d9/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/4414a6d9/attachment.jpg>