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