<div dir="ltr">I love the idea of a glossary. I would be happy to participate from a health literacy point of view. Good for my education.<div><br></div><div>BTW: why does nobody change the subject line so threads can be more easily tracked? Following these conversations is much work.<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 8:29 PM, <span dir="ltr"><<a href="mailto:openid-specs-heart-request@lists.openid.net" target="_blank">openid-specs-heart-request@lists.openid.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Openid-specs-heart mailing list submissions to<br>
<a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openid-specs-heart-request@lists.openid.net">openid-specs-heart-request@lists.openid.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openid-specs-heart-owner@lists.openid.net">openid-specs-heart-owner@lists.openid.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Openid-specs-heart digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Links on the HEART WG home page (Aaron Seib)<br>
2. Re: HEART 2015-08-05 meeting notes (Glen Marshall [SRS])<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 6 Aug 2015 19:27:02 -0400<br>
From: "Aaron Seib" <<a href="mailto:aaron.seib@nate-trust.org">aaron.seib@nate-trust.org</a>><br>
To: "'Debbie Bucci'" <<a href="mailto:debbucci@gmail.com">debbucci@gmail.com</a>>, "'Josh Mandel'"<br>
<<a href="mailto:Joshua.Mandel@childrens.harvard.edu">Joshua.Mandel@childrens.harvard.edu</a>><br>
Cc: <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
Subject: Re: [Openid-specs-heart] Links on the HEART WG home page<br>
Message-ID: <02b801d0d09f$66b01e60$34105b20$@<a href="http://nate-trust.org" rel="noreferrer" target="_blank">nate-trust.org</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Debbie ? as you are tidying up the page is there any way you can add a page just for terms? I have seen some helpful descriptions that might help folks like Jeremy and I catch up and it would be good to have as a reference for the hordes of folks that will begin following the topic as the culture changes to embrace the liberty of a person who chooses to operate their own AS or the business prospects of supporting such an offering at scale.<br>
<br>
<br>
<br>
Aaron Seib<br>
<br>
<<a href="http://www.nate-trust.org/" rel="noreferrer" target="_blank">http://www.nate-trust.org/</a>> NATE, CEO<br>
<br>
@CaptBlueButton<br>
<br>
(o) <a href="tel:301-540-2311" value="+13015402311">301-540-2311</a><br>
<br>
(m) <a href="tel:301-326-6843" value="+13013266843">301-326-6843</a><br>
<br>
<br>
<br>
<br>
<br>
From: Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a>] On Behalf Of Debbie Bucci<br>
Sent: Wednesday, August 5, 2015 3:11 PM<br>
To: Josh Mandel<br>
Cc: <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
Subject: Re: [Openid-specs-heart] Links on the HEART WG home page<br>
<br>
<br>
<br>
I will take that as an action item.<br>
<br>
<br>
<br>
Please verify you can see this link without logging in: <a href="http://openid.bitbucket.org/HEART/" rel="noreferrer" target="_blank">http://openid.bitbucket.org/HEART/</a> - current rendered version of specs<br>
<br>
<br>
<br>
Link to spec<br>
<br>
<br>
<br>
On Wed, Aug 5, 2015 at 1:54 PM, Josh Mandel <<a href="mailto:Joshua.Mandel@childrens.harvard.edu">Joshua.Mandel@childrens.harvard.edu</a>> wrote:<br>
<br>
In trying to point some folks to the HEART specs, I had some trouble finding the from the HEART WG home page. Can someone help clean up <a href="http://openid.net/wg/heart/" rel="noreferrer" target="_blank">http://openid.net/wg/heart/</a> with the following three changes?<br>
<br>
<br>
<br>
1. Link the words "list of specifications" to the current landing page for HEART's specs<br>
<br>
2. Link the individual items in the "list of specifications" directly to whatever drafts already exist, if any.<br>
<br>
3. Replace <a href="http://svn.openid.net/repos/specifications/heart/1.0/" rel="noreferrer" target="_blank">http://svn.openid.net/repos/specifications/heart/1.0/</a> with a working URL<br>
<br>
<br>
<br>
Thanks,<br>
<br>
<br>
<br>
Josh<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/7a44c199/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/7a44c199/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 6 Aug 2015 20:09:01 -0400<br>
From: "Glen Marshall [SRS]" <<a href="mailto:gfm@securityrs.com">gfm@securityrs.com</a>><br>
To: "<a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a>"<br>
<<a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a>><br>
Subject: Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
Message-ID: <<a href="mailto:55C3F71D.9020208@securityrs.com">55C3F71D.9020208@securityrs.com</a>><br>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"<br>
<br>
It appears that we are discussing a five-part problem:<br>
<br>
* The technical aspects, driven by use cases, of how to secure,<br>
communicate, and assure identity, authentication, authorizations,<br>
and obligations.<br>
* The technical aspects, also driven by uses cases, of how to express,<br>
communicate, and assure patients', and their delegates', disclosure<br>
preferences at sufficient (TBD) granularity.<br>
* The human engineering aspects of how to minimize the effort and<br>
technical knowledge required for the end-users - both patients and<br>
providers.<br>
* The technical, business, and legal aspects of federating the<br>
participants and their automated systems.<br>
* The economic aspects of how to minimize costs while allocating those<br>
costs equitably.<br>
<br>
I'm sure there may be other ways to slice and dice the problem space.<br>
However, the first two points above seem to be well within our immediate<br>
capabilities. The human engineering aspects require additional<br>
expertise as well as end-user input. And the last two points need<br>
policy-level resolution, i.e., out of this group's scope.<br>
<br>
I'd recommend we revisit these points before we engage in the next use<br>
case, but after we finalize the current one.<br>
<br>
Thanks,<br>
Glen<br>
<br>
*Glen F. Marshall*<br>
Consultant<br>
Security Risk Solutions, Inc.<br>
698 Fishermans Bend<br>
Mount Pleasant, SC 29464<br>
Tel: <a href="tel:%28610%29%20644-2452" value="+16106442452">(610) 644-2452</a><br>
Mobile: <a href="tel:%28610%29%20613-3084" value="+16106133084">(610) 613-3084</a><br>
<a href="mailto:gfm@securityrs.com">gfm@securityrs.com</a><br>
<a href="http://www.SecurityRiskSolutions.com" rel="noreferrer" target="_blank">www.SecurityRiskSolutions.com</a><br>
<br>
On 8/6/15 19:05, Adrian Gropper wrote:<br>
> The only information Alice should have to give to her provider is the<br>
> URL of her UMA Authorization Server (if she has one) or something else<br>
> that resolves to her UMA Authorization Server. In many cases, this<br>
> pointer to her UMA AS could be accessible as part of a federated IdP<br>
> service but we may not be able to count on federation being readily<br>
> acceptable to the providers.<br>
><br>
> Adrian<br>
><br>
> On Thu, Aug 6, 2015 at 5:00 PM, Maxwell, Jeremy (OS/OCPO)<br>
> <<a href="mailto:Jeremy.Maxwell@hhs.gov">Jeremy.Maxwell@hhs.gov</a> <mailto:<a href="mailto:Jeremy.Maxwell@hhs.gov">Jeremy.Maxwell@hhs.gov</a>>> wrote:<br>
><br>
> This thread began when I asked what does this look like for the<br>
> patient? What information does Alice need to give her provider?<br>
><br>
> *From:*Moehrke, John (GE Healthcare)<br>
> [mailto:<a href="mailto:John.Moehrke@med.ge.com">John.Moehrke@med.ge.com</a> <mailto:<a href="mailto:John.Moehrke@med.ge.com">John.Moehrke@med.ge.com</a>>]<br>
> *Sent:* Thursday, August 06, 2015 4:51 PM<br>
> *To:* Adrian Gropper; Maxwell, Jeremy (OS/OCPO)<br>
> *Cc:* Josh Mandel; <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
> <mailto:<a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a>><br>
><br>
><br>
> *Subject:* RE: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
><br>
> Those of us that are not in Mass, have great healthcare<br>
> interoperability through the NwHIN??? I agree that it is not<br>
> patient directed, but my records are available anywhere in the<br>
> NwHIN. I am not trying to disagree with you, but when you say that<br>
> ???Apple has shown us how patient-directed interoperability can<br>
> work in a highly integrated system.??? is just way too<br>
> argumentative. A walled-garden is always well manicured.<br>
><br>
> I too have lost track of what the argument is??? all this<br>
> discussion around ???technical savvy??? vs not is irrelevant to<br>
> the work that we can accomplish in HEART.<br>
><br>
> John<br>
><br>
> *From:*<a href="mailto:agropper@gmail.com">agropper@gmail.com</a> <mailto:<a href="mailto:agropper@gmail.com">agropper@gmail.com</a>><br>
> [mailto:<a href="mailto:agropper@gmail.com">agropper@gmail.com</a>] *On Behalf Of *Adrian Gropper<br>
> *Sent:* Thursday, August 06, 2015 3:06 PM<br>
> *To:* Maxwell, Jeremy (OS/OCPO)<br>
> *Cc:* Josh Mandel; Moehrke, John (GE Healthcare);<br>
> <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
> <mailto:<a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a>><br>
> *Subject:* Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
><br>
> I'm not sure what we're negotiating here. The current approach to<br>
> interoperability does not work for many, maybe most people. Part<br>
> of the reason it doesn't is that privacy approaches that work at a<br>
> scale of 10K or 100K people don't work when the scale is 100<br>
> Million people. I've been a party to four or five generations of<br>
> attempts at interoperability (IHE, NwHIN, CONNECT, DIRECT,<br>
> BlueButton Plus) and we still don't have a clear solution. We've<br>
> also seen that even completely centralized systems like the UK NHS<br>
> can't deal with this problem very well so I can't see why<br>
> CommonWell or Carequlality or Epic everywhere would succeed.<br>
><br>
> The one thing we haven't tried is patient-driven interoperability.<br>
> Apple has shown us how patient-directed interoperability can work<br>
> in a highly integrated system. UMA is the only standard we have<br>
> that has the potential to introduce patient-driven<br>
> interoperability to healthcare.<br>
><br>
> We have to give patients that understand UMA the option to use it.<br>
> Patients who don't care will see no difference at all because the<br>
> Resource Server will offer a default AS.<br>
><br>
> Once patients have the option to specify the AS the other<br>
> interoperability issues, including scopes, will incrementally get<br>
> fixed. But the first step is to agree that there's only one Alice<br>
> and she has an AS. That is the only scalable and non-coercive<br>
> solution.<br>
><br>
> Adrian<br>
><br>
> On Thu, Aug 6, 2015 at 9:51 AM, Maxwell, Jeremy (OS/OCPO)<br>
> <<a href="mailto:Jeremy.Maxwell@hhs.gov">Jeremy.Maxwell@hhs.gov</a> <mailto:<a href="mailto:Jeremy.Maxwell@hhs.gov">Jeremy.Maxwell@hhs.gov</a>>> wrote:<br>
><br>
> How many patients do we expect to have the technical savvy to say<br>
> this to their provider? In practice, where will these<br>
> authorization servers reside?<br>
><br>
> "Dear Dr. Jones: please treat my authorization server, at<br>
> <a href="https://authz.alice.org" rel="noreferrer" target="_blank">https://authz.alice.org</a><br>
> <<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__authz.alice.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=YNb7HB0fsZmQTY8glywsqyEBVsXi88kGWmzbLaDQU9U&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__authz.alice.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=YNb7HB0fsZmQTY8glywsqyEBVsXi88kGWmzbLaDQU9U&e=</a>>,<br>
> as representing my wishes for disclosure of my health data. Use<br>
> the decisions that server renders to guide your access control<br>
> decisions about my data."<br>
><br>
> *From:*Openid-specs-heart<br>
> [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a><br>
> <mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a>>] *On Behalf<br>
> Of *Josh Mandel<br>
> *Sent:* Thursday, August 06, 2015 9:19 AM<br>
> *To:* Moehrke, John (GE Healthcare)<br>
><br>
> *Cc:* <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
> <mailto:<a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a>><br>
> *Subject:* Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
><br>
> As to the division between "gross ceremony" and "finer-grain<br>
> adjustments", I want to suss out whether the following model<br>
> (which readily applies to UMA, though not to vanilla OAuth) is<br>
> consistent with you have in mind, or whether this model is<br>
> addressing a different question entirely:<br>
><br>
> 1. *Gross ceremony* consists of Alice introducing her resource<br>
> server to an authorization server of her choice. For example, she<br>
> might sign a document saying (effectively): "Dear Dr. Jones:<br>
> please treat my authorization server, at <a href="https://authz.alice.org" rel="noreferrer" target="_blank">https://authz.alice.org</a><br>
> <<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__authz.alice.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=YNb7HB0fsZmQTY8glywsqyEBVsXi88kGWmzbLaDQU9U&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__authz.alice.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=YNb7HB0fsZmQTY8glywsqyEBVsXi88kGWmzbLaDQU9U&e=</a>>,<br>
> as representing my wishes for disclosure of my health data. Use<br>
> the decisions that server renders to guide your access control<br>
> decisions about my data." This document is easily comprehensible,<br>
> could serve as evidence in court, etc.<br>
><br>
> 2. And then the *finer-grain adjustments* would be made by Alice<br>
> in concert with her authorization server (for example,<br>
> establishing specific policies about who can access her data, and<br>
> which data, and for what purposes, and under what conditions).<br>
><br>
> On Thu, Aug 6, 2015 at 9:06 AM, Moehrke, John (GE Healthcare)<br>
> <<a href="mailto:John.Moehrke@med.ge.com">John.Moehrke@med.ge.com</a> <mailto:<a href="mailto:John.Moehrke@med.ge.com">John.Moehrke@med.ge.com</a>>> wrote:<br>
><br>
> I agree with your proposal for ???Authorize for Disclosure??? and<br>
> to de-emphasize ???Consent?????? (although this problem with<br>
> ???Consent??? is only a USA problem)???<br>
><br>
><br>
> But I don???t think that a UMA/OAuth ???token??? will be seen as<br>
> legitimate evidence in a court. It would be quickly shown to be<br>
> not intelligible by the layperson, I can barely read them. Thus it<br>
> is not evidence of the act of ???authorizing for disclosure???<br>
> ceremony. This is indeed a practice-of-law problem that we all<br>
> hope changes, but I have little hope that it will change in the<br>
> coming 10 years. This is why I want the gross ceremony to be a<br>
> pre-condition, with the UMA/OAuth technology be the fine-grain<br>
> solution. I expect that a gross ceremony can be shown in a court<br>
> as evidence that all parties understood the use of the technology<br>
> would be used for fine-grain. Note that if the courtroom antics<br>
> change, then this pre-condition simply goes away. But by putting<br>
> it there we enable it to be used, and thus make our solution more<br>
> palatable to the legal folks at those custodian organizations that<br>
> are afraid to release information today.<br>
><br>
> John<br>
><br>
> *From:*Aaron Seib [mailto:<a href="mailto:aaron.seib@nate-trust.org">aaron.seib@nate-trust.org</a><br>
> <mailto:<a href="mailto:aaron.seib@nate-trust.org">aaron.seib@nate-trust.org</a>>]<br>
> *Sent:* Thursday, August 06, 2015 7:58 AM<br>
> *To:* Moehrke, John (GE Healthcare); 'Adrian Gropper'; 'Debbie Bucci'<br>
> *Cc:* <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
> <mailto:<a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a>><br>
> *Subject:* RE: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
><br>
> I tend to agree with John???s recommendation with a friendly<br>
> amendment.<br>
><br>
> We should not mis-use the word consent. We should use the term<br>
> ??? authorize for disclosure.<br>
><br>
> The primary reason being that the term consent has a lot of<br>
> baggage and is defined in law for Human research protections and<br>
> authorize for disclosure is more accurate to me. Consent ??? as<br>
> pointed out by the Kind Sir from Boston (Adrian) to point out ???<br>
> meant something before 2002 that it doesn???t mean anymore.<br>
><br>
> In my opinion the notion of authorize for disclosure also<br>
> conveniently aligns with my understanding of what ab<br>
> ???UMA/OAuth token??? would represent on a per transaction basis.<br>
><br>
> In court we would expect the entity accused of unauthorized<br>
> disclosure to be able to produce a valid UMA/OAuth token as a<br>
> sufficient defense from mis-representations of trial lawyers.<br>
><br>
> Aaron Seib<br>
><br>
> NATE<br>
> <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.nate-2Dtrust.org_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=87vCtxeoEunALdecDlNur8aIU5qcY6YWTAxWw6j34cs&s=PU_01do09mzHBYjfdhFvZCLDAP7Tpxnm1P001w-6AlU&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__www.nate-2Dtrust.org_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=87vCtxeoEunALdecDlNur8aIU5qcY6YWTAxWw6j34cs&s=PU_01do09mzHBYjfdhFvZCLDAP7Tpxnm1P001w-6AlU&e=</a>>,<br>
> CEO<br>
><br>
> @CaptBlueButton<br>
><br>
> (o) <a href="tel:301-540-2311" value="+13015402311">301-540-2311</a> <tel:<a href="tel:301-540-2311" value="+13015402311">301-540-2311</a>><br>
><br>
> (m) <a href="tel:301-326-6843" value="+13013266843">301-326-6843</a> <tel:<a href="tel:301-326-6843" value="+13013266843">301-326-6843</a>><br>
><br>
> *From:*Openid-specs-heart<br>
> [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a>] *On Behalf Of<br>
> *Moehrke, John (GE Healthcare)<br>
> *Sent:* Thursday, August 6, 2015 7:27 AM<br>
> *To:* Adrian Gropper; Debbie Bucci<br>
> *Cc:* <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
> <mailto:<a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a>><br>
> *Subject:* Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
><br>
> At the federal level, under HIPAA alone, there is no need for<br>
> consent for purposes of using the data within the Covered Entity<br>
> for Treatment, Payment, and Normal operations.<br>
><br>
> BUT, there are plenty of states that require consent??? Ignoring<br>
> reality of states regulations is not useful.<br>
><br>
> AND, there are some institutions that would rather have a consent<br>
> that authorizes them to share beyond their Covered Entity<br>
> boundary. Not everyone reads HIPAA ???Treatment??? as an<br>
> authorization to share with any treating provider.<br>
><br>
> AND, there are some ???sensitive??? health topics covered by<br>
> federal money that do come with a requirement for consent for<br>
> sharing. This was the main focus of the DS4P efforts.<br>
><br>
> So, let???s not focus on HIPAA alone. Let???s expect that ???for<br>
> whatever reason an organization wants to have positive evidence<br>
> that the patient desires sharing to happen??? as the trigger to<br>
> allow it to happen (otherwise deny it from happening. This would<br>
> seem more helpful to the community we are doing this work for.<br>
><br>
> An important aspect of all of this is how will the organization<br>
> holding the data be able to legally defend that a UMA/OAuth token<br>
> was valid evidence of consent that would hold up in a courtroom???<br>
> We can???t address this in HEART, but it should not slow us down.<br>
> We again, document this as a precondition to our work. One way<br>
> this is done is that a paper trail is a part of the initial setup<br>
> of a patient engaging with the system.<br>
><br>
> John<br>
><br>
> *From:*Openid-specs-heart<br>
> [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a>] *On Behalf Of<br>
> *Adrian Gropper<br>
> *Sent:* Wednesday, August 05, 2015 11:49 PM<br>
> *To:* Debbie Bucci<br>
> *Cc:* <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br>
> <mailto:<a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a>><br>
> *Subject:* Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
><br>
> I have never heard the term "simple consent". There's nothing like<br>
> "consent" in the context of data sharing that I can think of.<br>
> HIPAA removed the patient's right of consent in 2002<br>
> <a href="https://patientprivacyrights.org/?s=HIPAA+Consent" rel="noreferrer" target="_blank">https://patientprivacyrights.org/?s=HIPAA+Consent</a><br>
> <<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__patientprivacyrights.org_-3Fs-3DHIPAA-2BConsent&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=QPfpP6tNPhNn0uCYFnfBuRqSH5IVEwKw_Jqp3j4NGRQ&s=u1OCcH7ZkX-4jzmNs_eIhVZUi0lQOy0npXd30zYGE8I&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__patientprivacyrights.org_-3Fs-3DHIPAA-2BConsent&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=QPfpP6tNPhNn0uCYFnfBuRqSH5IVEwKw_Jqp3j4NGRQ&s=u1OCcH7ZkX-4jzmNs_eIhVZUi0lQOy0npXd30zYGE8I&e=</a>><br>
><br>
> There are consent forms for research but that's not part of the<br>
> use cases we're tackling these days.<br>
><br>
> Does anyone have an example of consent for clinical data sharing<br>
> to share with us?<br>
><br>
> Adrian<br>
><br>
> On Thu, Aug 6, 2015 at 12:10 AM, Debbie Bucci <<a href="mailto:debbucci@gmail.com">debbucci@gmail.com</a><br>
> <mailto:<a href="mailto:debbucci@gmail.com">debbucci@gmail.com</a>>> wrote:<br>
><br>
> @Eve - yes I know its client but I'm really hung up on the token<br>
> generation/choices. Thanks for the tweaks.<br>
><br>
> I know we clarified that the release form is NOT consent in one of<br>
> our earlier meetings but is this (release of information) what I<br>
> have heard others refer to as simple consent? During this process<br>
> would access to problems/meds/allergies be included in that<br>
> authorization/consent flow? I visualized more than demographics in<br>
> the conversation.<br>
><br>
> On Wed, Aug 5, 2015 at 9:21 PM, Justin Richer <<a href="mailto:jricher@mit.edu">jricher@mit.edu</a><br>
> <mailto:<a href="mailto:jricher@mit.edu">jricher@mit.edu</a>>> wrote:<br>
><br>
> Thank you, Adrian, this is a great reference! I think your<br>
> annotations make sense as well, things should map pretty plainly<br>
> to the OAuth process. The tricky part (that we got a start on<br>
> today) is going to be the scopes bits and getting those right.<br>
><br>
> For an UMA flow, it's also similar, except that the "who can see<br>
> it" is a set of claims instead of the client application.<br>
><br>
> -- Justin<br>
><br>
> On 8/5/2015 9:12 PM, Adrian Gropper wrote:<br>
><br>
> I've attached a very typical Release of Information<br>
> authorization. I've annotated the 5 elements common to all<br>
> such documents that I have ever seen. The stuff outside if the<br>
> rectangles is more or less optional.<br>
><br>
> This form covers one direction of the EHR-PHR Use Case. It is<br>
> presented to the Custodian (the patient or their designate )<br>
> and approved by them by the Resource Server and pre-filled<br>
> with information supplied by the Client, if available.<br>
><br>
> In some cases, the Client information is not available at the<br>
> time the Authorization form is signed. In that case, it will<br>
> be up to the Authorization Server to consider the Client and<br>
> User information and provide the authorization to the Resource<br>
> Server.<br>
><br>
> The Resource Server has the final say in all cases and could<br>
> decide to ignore the authorization based on local or<br>
> jurisdictional policy. This is outside the control of the<br>
> Resource Owner and likely to be out of scope for HEART in all<br>
> use-cases.<br>
><br>
> This ROI Authorization Form is the only "consent" that I'm<br>
> aware of in clinical IT. Patients are asked to sign other<br>
> documents, including:<br>
><br>
> Registration Form, Notice of Privacy Practices, and Treatment<br>
> Consent but none of these has anything to do with sharing of<br>
> health data (except for HIPAA TPO which we will not get into<br>
> here.)<br>
><br>
> Adrian<br>
><br>
> On Wed, Aug 5, 2015 at 8:27 PM, jim kragh <<a href="mailto:kragh65@gmail.com">kragh65@gmail.com</a><br>
> <mailto:<a href="mailto:kragh65@gmail.com">kragh65@gmail.com</a>>> wrote:<br>
><br>
> Thanks for sharing,... informative and constructive in<br>
> reaching the patient end point.<br>
><br>
> May all have a nice evening!<br>
><br>
> On Wed, Aug 5, 2015 at 3:26 PM, Debbie Bucci<br>
> <<a href="mailto:debbucci@gmail.com">debbucci@gmail.com</a> <mailto:<a href="mailto:debbucci@gmail.com">debbucci@gmail.com</a>>> wrote:<br>
><br>
> Attendees:<br>
><br>
> Eve Maler<br>
><br>
> Justin Richer<br>
><br>
> Josh Mandel<br>
><br>
> Adrian Gropper<br>
><br>
> Thomas Sullivan<br>
><br>
> Debbie Bucci<br>
><br>
> We have decided to delineate between mechanical and<br>
> semantic scope docs.<br>
><br>
> For the PCP <-> PHR use case:<br>
><br>
> The pre determined choice token confidential token choice<br>
> and exactly what information needs (example:<br>
> PHR's authorization endpoint) to be shared in advance<br>
> between the PCP's EHR and Alice's PCP was left out of the<br>
> discussion for now.<br>
><br>
> There is one basic mechanical Oauth generic flow that<br>
> occurs twice in the use case.<br>
><br>
> Given the group has generally agreed that the SMART<br>
> specifications are a good place to */start /*/... /for<br>
> this particular use case the only semantic FHIR scope<br>
> that is necessary is the patient/*.read scope that grants<br>
> permission to read any resource for the current patient.<br>
><br>
> During the registration process Alice should be able to<br>
> select at a fine grain level which resources she is<br>
> willing to share with the PHR. This mimic's a specific<br>
> process - Adrian please provide. This information will be<br>
> used to generate the access token.<br>
><br>
> The one thing left at the end of the discussion is whether<br>
> the patient record is implicit or explicitly stated. This<br>
> is a design decision that may make a difference as we move<br>
> towards our next use case in which delegation is a factor.<br>
><br>
> Corrections/updates appreciated.<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Openid-specs-heart mailing list<br>
> <a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
> <mailto:<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a>><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
> <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=QPfpP6tNPhNn0uCYFnfBuRqSH5IVEwKw_Jqp3j4NGRQ&s=rCzIAK2qBPKQaibR7Ns2AF69bEcf2hFBrgPF6wgZ0i4&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=QPfpP6tNPhNn0uCYFnfBuRqSH5IVEwKw_Jqp3j4NGRQ&s=rCzIAK2qBPKQaibR7Ns2AF69bEcf2hFBrgPF6wgZ0i4&e=</a>><br>
><br>
><br>
><br>
><br>
> --<br>
><br>
> Adrian Gropper MD<br>
><br>
> RESTORE Health Privacy!<br>
> HELP us fight for the right to control personal health data.<br>
> DONATE: <a href="http://patientprivacyrights.org/donate-2/" rel="noreferrer" target="_blank">http://patientprivacyrights.org/donate-2/</a><br>
> <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=QPfpP6tNPhNn0uCYFnfBuRqSH5IVEwKw_Jqp3j4NGRQ&s=5EO5dh5y1O7CjbbjqdwxTBcdii8ABtLHO2waj3VDYfw&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=QPfpP6tNPhNn0uCYFnfBuRqSH5IVEwKw_Jqp3j4NGRQ&s=5EO5dh5y1O7CjbbjqdwxTBcdii8ABtLHO2waj3VDYfw&e=</a>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Openid-specs-heart mailing list<br>
> <a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
> <mailto:<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a>><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
> <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=xfS-FhCWnt8T2azGqiQ9w0j0r8gsr_Wq5e1DFqr6j2c&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=xfS-FhCWnt8T2azGqiQ9w0j0r8gsr_Wq5e1DFqr6j2c&e=</a>><br>
><br>
><br>
> _______________________________________________<br>
> Openid-specs-heart mailing list<br>
> <a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
> <mailto:<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a>><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
> <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=xfS-FhCWnt8T2azGqiQ9w0j0r8gsr_Wq5e1DFqr6j2c&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=xfS-FhCWnt8T2azGqiQ9w0j0r8gsr_Wq5e1DFqr6j2c&e=</a>><br>
><br>
><br>
><br>
><br>
> --<br>
><br>
> Adrian Gropper MD<br>
><br>
> RESTORE Health Privacy!<br>
> HELP us fight for the right to control personal health data.<br>
> DONATE: <a href="http://patientprivacyrights.org/donate-2/" rel="noreferrer" target="_blank">http://patientprivacyrights.org/donate-2/</a><br>
> <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=gMoU7Tc7dOq204V3ITLDRXfW91DvOUFqkOKkdBgG4Y8&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=cpoRMhQHerIlja_ffVTQNKS7xUf9tRDFgogzkp23Ycs&s=gMoU7Tc7dOq204V3ITLDRXfW91DvOUFqkOKkdBgG4Y8&e=</a>><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
><br>
> Adrian Gropper MD<br>
><br>
> RESTORE Health Privacy!<br>
> HELP us fight for the right to control personal health data.<br>
> DONATE: <a href="http://patientprivacyrights.org/donate-2/" rel="noreferrer" target="_blank">http://patientprivacyrights.org/donate-2/</a><br>
><br>
><br>
> _______________________________________________<br>
> Openid-specs-heart mailing list<br>
> <a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/e0e80c71/attachment.html" rel="noreferrer" target="_blank">http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/e0e80c71/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Openid-specs-heart Digest, Vol 32, Issue 50<br>
**************************************************<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><font color="#330099">Danny van Leeuwen<br>617-304-4681<br></font><div><b><font color="#330099"><br></font></b><div><b><font color="#330099">Blog <a href="http://www.health-hats.com/" target="_blank">www.health-hats.com</a> <i><span style="font-size:8pt;font-family:'Arial Black',sans-serif">discovering the magic levers of best health</span></i></font></b></div></div><div><b><font color="#330099">Twitter </font></b><b><font color="#330099"><i><span style="font-size:8pt;font-family:'Arial Black',sans-serif">@healthhats</span></i></font></b></div></div>
</div></div></div>