<div dir="ltr">Adrian, I love your statement:<div><br></div><div><span style="font-size:12.8000001907349px">The one thing we haven't tried is patient-driven interoperability. Apple</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">has shown us how patient-directed interoperability can work in a highly</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">integrated system. UMA is the only standard we have that has the potential</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">to introduce patient-driven interoperability to healthcare.</span><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 4:06 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: HEART 2015-08-05 meeting notes (Adrian Gropper)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 6 Aug 2015 16:06:14 -0400<br>
From: Adrian Gropper <<a href="mailto:agropper@healthurl.com">agropper@healthurl.com</a>><br>
To: "Maxwell, Jeremy (OS/OCPO)" <<a href="mailto:Jeremy.Maxwell@hhs.gov">Jeremy.Maxwell@hhs.gov</a>><br>
Cc: "<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:<br>
        <CANYRo8iFVD=<a href="mailto:oKD9wSb6j9i%2BJQ82Z0XS7aWbbFWxincpUnYQ67w@mail.gmail.com">oKD9wSb6j9i+JQ82Z0XS7aWbbFWxincpUnYQ67w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<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 of the<br>
reason it doesn't is that privacy approaches that work at a scale of 10K or<br>
100K people don't work when the scale is 100 Million people. I've been a<br>
party to four or five generations of attempts at interoperability (IHE,<br>
NwHIN, CONNECT, DIRECT, BlueButton Plus) and we still don't have a clear<br>
solution. We've also seen that even completely centralized systems like the<br>
UK NHS can't deal with this problem very well so I can't see why CommonWell<br>
or Carequlality or Epic everywhere would succeed.<br>
<br>
The one thing we haven't tried is patient-driven interoperability. Apple<br>
has shown us how patient-directed interoperability can work in a highly<br>
integrated system. UMA is the only standard we have that has the potential<br>
to introduce patient-driven interoperability to healthcare.<br>
<br>
We have to give patients that understand UMA the option to use it. Patients<br>
who don't care will see no difference at all because the Resource Server<br>
will offer a default AS.<br>
<br>
Once patients have the option to specify the AS the other interoperability<br>
issues, including scopes, will incrementally get fixed. But the first step<br>
is to agree that there's only one Alice and she has an AS. That is the only<br>
scalable and non-coercive 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>> wrote:<br>
<br>
> How many patients do we expect to have the technical savvy to say this to<br>
> their provider?  In practice, where will these authorization servers reside?<br>
><br>
><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>, as representing my wishes for disclosure of my<br>
> health data. Use the decisions that server renders to guide your access<br>
> control decisions about my data."<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> *From:* Openid-specs-heart [mailto:<br>
> <a href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a>] *On Behalf Of *Josh Mandel<br>
> *Sent:* Thursday, August 06, 2015 9:19 AM<br>
> *To:* Moehrke, John (GE Healthcare)<br>
> *Cc:* <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>
><br>
><br>
> As to the division between "gross ceremony" and "finer-grain adjustments",<br>
> I want to suss out whether the following model (which readily applies to<br>
> UMA, though not to vanilla OAuth) is consistent with you have in mind, or<br>
> whether this model is addressing a different question entirely:<br>
><br>
><br>
><br>
> 1. *Gross ceremony* consists of Alice introducing her resource server to<br>
> an authorization server of her choice. For example, she might sign a<br>
> document saying (effectively): "Dear Dr. Jones: please treat my<br>
> authorization server, at <a href="https://authz.alice.org" rel="noreferrer" target="_blank">https://authz.alice.org</a>, as representing my<br>
> wishes for disclosure of my health data. Use the decisions that server<br>
> renders to guide your access control decisions about my data." This<br>
> document is easily comprehensible, could serve as evidence in court, etc.<br>
><br>
><br>
><br>
> 2. And then the *finer-grain adjustments* would be made by Alice in<br>
> concert with her authorization server (for example, establishing specific<br>
> policies about who can access her data, and which data, and for what<br>
> purposes, and under what conditions).<br>
><br>
><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>> wrote:<br>
><br>
> I agree with your proposal for ?Authorize for Disclosure? and to<br>
> de-emphasize ?Consent?? (although this problem with ?Consent? is only a USA<br>
> problem)?<br>
><br>
><br>
> But I don?t think that a UMA/OAuth ?token? will be seen as legitimate<br>
> evidence in a court. It would be quickly shown to be not intelligible by<br>
> the layperson, I can barely read them. Thus it is not evidence of the act<br>
> of ?authorizing for disclosure? ceremony.  This is indeed a practice-of-law<br>
> problem that we all hope changes, but I have little hope that it will<br>
> change in the coming 10 years. This is why I want the gross ceremony to be<br>
> a pre-condition, with the UMA/OAuth technology be the fine-grain solution.<br>
> I expect that a gross ceremony can be shown in a court as evidence that all<br>
> parties understood the use of the technology would be used for fine-grain.<br>
> Note that if the courtroom antics change, then this pre-condition simply<br>
> goes away. But by putting it there we enable it to be used, and thus make<br>
> our solution more palatable to the legal folks at those custodian<br>
> organizations that are afraid to release information today.<br>
><br>
><br>
><br>
> John<br>
><br>
><br>
><br>
> *From:* Aaron Seib [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>
> *Subject:* RE: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
><br>
><br>
><br>
> I tend to agree with John?s recommendation with a friendly amendment.<br>
><br>
><br>
><br>
> We should not mis-use the word consent.  We should use the term ?<br>
> authorize for disclosure.<br>
><br>
><br>
><br>
> The primary reason being that the term consent has a lot of baggage and is<br>
> defined in law for Human research protections and authorize for disclosure<br>
> is more accurate to me.  Consent ? as pointed out by the Kind Sir from<br>
> Boston (Adrian) to point out ? meant something before 2002 that it doesn?t<br>
> mean anymore.<br>
><br>
><br>
><br>
> In my opinion the notion of authorize for disclosure also conveniently<br>
> aligns with my understanding of what ab ?UMA/OAuth token? would represent<br>
> on a per transaction basis.<br>
><br>
><br>
><br>
> In court we would expect the entity accused of unauthorized disclosure to<br>
> be able to produce a valid UMA/OAuth token as a sufficient defense from<br>
> mis-representations of trial lawyers.<br>
><br>
><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><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 [<br>
> mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a><br>
> <<a href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a>>] *On Behalf Of *Moehrke,<br>
> 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>
> *Subject:* Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
><br>
><br>
><br>
> At the federal level, under HIPAA alone, there is no need for consent for<br>
> purposes of using the data within the Covered Entity for Treatment,<br>
> Payment, and Normal operations.<br>
><br>
><br>
><br>
> BUT, there are plenty of states that require consent? Ignoring reality of<br>
> states regulations is not useful.<br>
><br>
><br>
><br>
> AND, there are some institutions that would rather have a consent that<br>
> authorizes them to share beyond their Covered Entity boundary. Not everyone<br>
> reads HIPAA ?Treatment? as an authorization to share with any treating<br>
> provider.<br>
><br>
><br>
><br>
> AND, there are some ?sensitive? health topics covered by federal money<br>
> that do come with a requirement for consent for sharing. This was the main<br>
> focus of the DS4P efforts.<br>
><br>
><br>
><br>
> So, let?s not focus on HIPAA alone. Let?s expect that ?for whatever reason<br>
> an organization wants to have positive evidence that the patient desires<br>
> sharing to happen? as the trigger to allow it to happen (otherwise deny it<br>
> from happening. This would seem more helpful to the community we are doing<br>
> this work for.<br>
><br>
><br>
><br>
> An important aspect of all of this is how will the organization holding<br>
> the data be able to legally defend that a UMA/OAuth token was valid<br>
> evidence of consent that would hold up in a courtroom? We can?t address<br>
> this in HEART, but it should not slow us down. We again, document this as a<br>
> precondition to our work. One way this is done is that a paper trail is a<br>
> part of the initial setup of a patient engaging with the system.<br>
><br>
><br>
><br>
> John<br>
><br>
><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>
> <<a href="mailto:openid-specs-heart-bounces@lists.openid.net">openid-specs-heart-bounces@lists.openid.net</a>>] *On Behalf Of *Adrian<br>
> 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>
> *Subject:* Re: [Openid-specs-heart] HEART 2015-08-05 meeting notes<br>
><br>
><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. HIPAA removed<br>
> 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 use cases<br>
> we're tackling these days.<br>
><br>
> Does anyone have an example of consent for clinical data sharing to share<br>
> with us?<br>
><br>
> Adrian<br>
><br>
><br>
><br>
><br>
><br>
> On Thu, Aug 6, 2015 at 12:10 AM, Debbie Bucci <<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>
><br>
><br>
> I know we clarified that the release form is NOT consent in one of our<br>
> earlier meetings  but is this (release of information) what I have heard<br>
> others refer to as simple consent?    During this process would access to<br>
> problems/meds/allergies be included in that authorization/consent flow?<br>
> I visualized more than demographics in the conversation.<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Wed, Aug 5, 2015 at 9:21 PM, Justin Richer <<a href="mailto:jricher@mit.edu">jricher@mit.edu</a>> wrote:<br>
><br>
> Thank you, Adrian, this is a great reference! I think your annotations<br>
> make sense as well, things should map pretty plainly to the OAuth process.<br>
> The tricky part (that we got a start on today) is going to be the scopes<br>
> bits and getting those right.<br>
><br>
> For an UMA flow, it's also similar, except that the "who can see it" is a<br>
> set of claims instead of the client application.<br>
><br>
>  -- Justin<br>
><br>
><br>
><br>
> On 8/5/2015 9:12 PM, Adrian Gropper wrote:<br>
><br>
> I've attached a very typical Release of Information authorization. I've<br>
> annotated the 5 elements common to all such documents that I have ever<br>
> seen. The stuff outside if the rectangles is more or less optional.<br>
><br>
> This form covers one direction of the EHR-PHR Use Case. It is presented to<br>
> the Custodian (the patient or their designate ) and approved by them by the<br>
> Resource Server and pre-filled with information supplied by the Client, if<br>
> available.<br>
><br>
> In some cases, the Client information is not available at the time the<br>
> Authorization form is signed. In that case, it will be up to the<br>
> Authorization Server to consider the Client and User information and<br>
> provide the authorization to the Resource Server.<br>
><br>
> The Resource Server has the final say in all cases and could decide to<br>
> ignore the authorization based on local or jurisdictional policy. This is<br>
> outside the control of the Resource Owner and likely to be out of scope for<br>
> HEART in all use-cases.<br>
><br>
> This ROI Authorization Form is the only "consent" that I'm aware of in<br>
> clinical IT. Patients are asked to sign other documents, including:<br>
><br>
> Registration Form, Notice of Privacy Practices, and Treatment Consent but<br>
> none of these has anything to do with sharing of health data (except for<br>
> HIPAA TPO which we will not get into here.)<br>
><br>
><br>
><br>
> Adrian<br>
><br>
><br>
><br>
> On Wed, Aug 5, 2015 at 8:27 PM, jim kragh <<a href="mailto:kragh65@gmail.com">kragh65@gmail.com</a>> wrote:<br>
><br>
> Thanks for sharing,...  informative and constructive in reaching the<br>
> patient end point.<br>
><br>
><br>
><br>
> May all have a nice evening!<br>
><br>
><br>
><br>
> On Wed, Aug 5, 2015 at 3:26 PM, Debbie Bucci <<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>
><br>
><br>
> We have decided to delineate between mechanical and semantic scope docs.<br>
><br>
><br>
><br>
> For the PCP <-> PHR use case:<br>
><br>
><br>
><br>
> The pre determined choice token confidential token choice and exactly what<br>
> information needs (example: PHR's authorization endpoint)  to be shared in<br>
> advance between the PCP's EHR and Alice's PCP was left out of the<br>
> discussion for now.<br>
><br>
><br>
><br>
> There is one basic mechanical Oauth  generic flow that occurs twice in the<br>
> use case.<br>
><br>
><br>
><br>
> Given the group has generally agreed that the SMART specifications are a<br>
> good place to *start **... *for this particular use case  the only<br>
> semantic FHIR scope that is necessary is the patient/*.read scope that<br>
> grants permission to read any resource for the current patient.<br>
><br>
><br>
><br>
> During the registration process Alice should be able to select at a fine<br>
> grain level which resources she is willing to share with the PHR.   This<br>
> mimic's a specific process - Adrian please provide.  This information will<br>
> be used to generate the access token.<br>
><br>
><br>
><br>
> The one thing left at the end of the discussion is whether the patient<br>
> record is implicit or explicitly stated.  This is a design decision that<br>
> may make a difference as we move towards our next use case in<br>
> which delegation is a factor.<br>
><br>
><br>
><br>
> Corrections/updates appreciated.<br>
><br>
><br>
><br>
><br>
><br>
><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>
> <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>
> --<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>
> 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>
> 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>
--<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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/7efe93a9/attachment.html" rel="noreferrer" target="_blank">http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150806/7efe93a9/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 45<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>