[Openid-specs-heart] CHIME Launches $1M Challenge to Solve Patient ID Problem

Adrian Gropper agropper at healthurl.com
Mon Jan 25 16:43:04 UTC 2016


Fine. What is the problem with a persona owning an AS that holds a private
key?

On Mon, Jan 25, 2016 at 11:41 AM, Justin Richer <jricher at mit.edu> wrote:

> Adrian, we’re not using the blockchain here. That’s irrelevant and seems
> to be leading you to incorrect conclusions.
>
>  — Justin
>
> On Jan 25, 2016, at 11:40 AM, Adrian Gropper <agropper at healthurl.com>
> wrote:
>
> No, I'm not saying anything about how the public key associated with a
> persona is used for encrypting messages to the client. The use of a public
> key the way to identify a persona or account is already well established in
> blockchain and is completely compatible with a personal owned AS. That's
> all I'm saying.
>
> The use of whatever keys or tokens will be used in messaging between the
> RS and the Client is up to the "security folk" Justin refers to. Are the
> security folk saying that having a personal persona AS is impossible?
>
> Adrian
>
> On Mon, Jan 25, 2016 at 11:34 AM, Josh Mandel <
> Joshua.Mandel at childrens.harvard.edu> wrote:
>
>> In UMA, the RS does indeed learn the AS's public key (by asking the AS).
>> But the public key is not used in the way you seem to want (namely, it's
>> not used to encrypt any patient data). It sounds to me like you're focusing
>> on an implementation detail (the fact that the AS happens to have a public
>> key associated with it), and extrapolating to some unfounded conclusions
>> (that this forms the basis for encrypting patient data with a
>> patient-specific key) from that detail.
>>
>>   -J
>>
>> On Mon, Jan 25, 2016 at 11:26 AM, Adrian Gropper <agropper at healthurl.com>
>> wrote:
>>
>>> Justin,
>>>
>>> All I'm saying is that each patient persona gets to have a private key
>>> and that key is kept safe in their AS - period.
>>>
>>> Let's start with that, and then the security folks can tell us how the
>>> RS gets the Client's public key. Can't UMA do that?
>>>
>>> Adrian
>>>
>>> On Mon, Jan 25, 2016 at 11:02 AM, Justin Richer <jricher at mit.edu> wrote:
>>>
>>>> The way encryption is handled between the RS and the Client does not
>>>> follow from the right to choose an AS and has nothing to do with the AS’s
>>>> JWK. Think about it this way: how would the client get the AS’s private key
>>>> to decrypt the message?
>>>>
>>>>  — Justin
>>>>
>>>> On Jan 25, 2016, at 10:52 AM, Adrian Gropper <agropper at healthurl.com>
>>>> wrote:
>>>>
>>>> I think we're mostly all on the same wavelength. The first priority is
>>>> to bake the right to control one's own AS and the corresponding jwk into
>>>> FHIR and HEART. This should be easy to reach consensus on given recent OCR
>>>> guidance that includes the "right to delegate access to a third party".
>>>>
>>>> The way encryption is handled between the RS and Client follows from
>>>> the above.
>>>>
>>>> Adrian
>>>>
>>>> On Mon, Jan 25, 2016 at 10:38 AM, Josh Mandel <
>>>> Joshua.Mandel at childrens.harvard.edu> wrote:
>>>>
>>>>> Let's generously read Adrian's claim here as "a patient who cares
>>>>> enough can set up her own AS, and thereby ensure that her AS's jwk is
>>>>> unique to her". So yes, you can (with enough effort -- which might be
>>>>> driven down by technology) get to the point of one jwk per AS, if you
>>>>> really want.
>>>>>
>>>>> But even if you do so, the AS's jwk in HEART* isn't really an
>>>>> "encryption key" sense in the way Adrian would have it*. In other
>>>>> words, the AS's jwk is not used as an "encryption key" for the patient's
>>>>> healthcare data at any point. (It *is* used to sign tokens in the UMA
>>>>> flow, including the PAT and the AAT.)
>>>>>
>>>>> By the way,
>>>>> http://openid.bitbucket.org/HEART/openid-heart-uma.html#rfc.section.2.1
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.bitbucket.org_HEART_openid-2Dheart-2Duma.html-23rfc.section.2.1&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6qsDGXlfn6YB2nKRHOhQbq7-F60_1nlM8F6SOwyMwac&s=h493E96bkQd-wdHQtG9rOI29YYNBoODJ5dv5jBohH8M&e=>
>>>>> says that an "aud" claim in the AAT specifies the "RPT authorization
>>>>> endpoint"; UMA refers to this as simply the "RPT endpoint", and I think the
>>>>> HEART profile's language should be consistent (this tripped me up for 10min
>>>>> just now).
>>>>>
>>>>>   -J
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 25, 2016 at 10:02 AM, Adrian Gropper <
>>>>> agropper at healthurl.com> wrote:
>>>>>
>>>>>> Why "most likely not"? Is it a security issue? a cost issue? We don't
>>>>>> have to compromise privacy for security in our connected world.
>>>>>>
>>>>>> On Mon, Jan 25, 2016 at 9:55 AM, Justin Richer <jricher at mit.edu>
>>>>>> wrote:
>>>>>>
>>>>>>> But it's not like that, the arity is very different.
>>>>>>>
>>>>>>> Every record is associated with an AS, perhaps a separate AS for
>>>>>>> each record/patient but most likely not.
>>>>>>>
>>>>>>> Every AS is associated with a jwks_uri, but only one per AS.
>>>>>>>
>>>>>>>  -- Justin
>>>>>>>
>>>>>>>
>>>>>>> On 1/25/2016 9:02 AM, Adrian Gropper wrote:
>>>>>>>
>>>>>>> It means that every patient record is associated with a separate
>>>>>>> jwks_uri for that patient's AS.
>>>>>>>
>>>>>>> On Mon, Jan 25, 2016 at 8:59 AM, Justin Richer <jricher at mit.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yes you did. Quote:
>>>>>>>>
>>>>>>>> "The system is also much more resistant to data breaches as data
>>>>>>>> holders (UMA Resource Servers) must implement separate *encryption
>>>>>>>> keys *for each patient."
>>>>>>>>
>>>>>>>> So if you don't mean separately encrypting the data for each user,
>>>>>>>> what does that statement mean? The access token isn't an encryption key.
>>>>>>>>
>>>>>>>>  -- Justin
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/25/2016 8:57 AM, Adrian Gropper wrote:
>>>>>>>>
>>>>>>>> I never said anything about how the data is encrypted. I only talk
>>>>>>>> about how access to the FHIR API is controlled.
>>>>>>>>
>>>>>>>> Adrian
>>>>>>>>
>>>>>>>> On Mon, Jan 25, 2016 at 8:55 AM, Justin Richer < <jricher at mit.edu>
>>>>>>>> jricher at mit.edu> wrote:
>>>>>>>>
>>>>>>>>> Adrian,
>>>>>>>>>
>>>>>>>>> I've asked this before and thought we'd settled it, but it keeps
>>>>>>>>> coming up: where are you getting the idea of encrypting the data to the
>>>>>>>>> patient using a patient's key? That is not in scope for HEART, nor is it
>>>>>>>>> part of any of the underlying protocols.
>>>>>>>>>
>>>>>>>>>  -- Justin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/25/2016 8:52 AM, Adrian Gropper wrote:
>>>>>>>>>
>>>>>>>>> Establishing a separate URI for each patient is likely to be the
>>>>>>>>> only stable solution to the patient ID problem. The issue, however, is how
>>>>>>>>> many URIs will a patient be allowed to have? If the URIs are coercive, in
>>>>>>>>> the sense of a chip or tattoo issued by government or an equivalent global
>>>>>>>>> authority (Facebook?) or the URI is derived from DNA or an iris scan. (Iris
>>>>>>>>> scans are a good positive IDs and can be read from 30 feet away with modern
>>>>>>>>> technology.)
>>>>>>>>>
>>>>>>>>> Let's assume, for our purposes, that an iris scanner costs about
>>>>>>>>> as much as a credit card terminal, cheap enough for every front office,
>>>>>>>>> ambulance, and police car. Is the patient ID problem solved? I don't think
>>>>>>>>> so.
>>>>>>>>>
>>>>>>>>> Patients can have one or more separate URIs in order to help
>>>>>>>>> manage their health records. Today, we typically use email address for this
>>>>>>>>> purpose, with WebFinger
>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__webfinger.net_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=qupbYXH4yZuzhNsgW0jcwq786o--G6D1m7GlkENe1lw&e=>
>>>>>>>>> https://webfinger.net/
>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__webfinger.net_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=qupbYXH4yZuzhNsgW0jcwq786o--G6D1m7GlkENe1lw&e=>
>>>>>>>>> as a standardized way to discover linked attributes such as the patient's
>>>>>>>>> UMA Authorization Server and the associated public key.
>>>>>>>>>
>>>>>>>>> UMA for patient ID brings numerous benefits including much greater
>>>>>>>>> transparency and security. The patient now has a single portal (their UMA
>>>>>>>>> AS) to view all current relationships under that particular patient ID
>>>>>>>>> persona. The system is also much more resistant to data breaches as data
>>>>>>>>> holders (UMA Resource Servers) must implement separate encryption keys for
>>>>>>>>> each patient.
>>>>>>>>>
>>>>>>>>> I think the HEART group is in a good position to compete for the
>>>>>>>>> CHIME challenge on this basis and I'd be happy for me and PPR to help
>>>>>>>>> organize a submission.
>>>>>>>>>
>>>>>>>>> Adrian
>>>>>>>>>
>>>>>>>>> On Sun, Jan 24, 2016 at 1:20 PM, Aaron Seib <
>>>>>>>>> <aaron.seib at nate-trust.org>aaron.seib at nate-trust.org> wrote:
>>>>>>>>>
>>>>>>>>>> I appreciate your expertise and action.
>>>>>>>>>>
>>>>>>>>>> I don't necessarily agree with some of your statements here but
>>>>>>>>>> that is the beauty of open processes.
>>>>>>>>>>
>>>>>>>>>> Let's strive to do all we can - together.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Aaron Seib
>>>>>>>>>> @CaptBlueButton
>>>>>>>>>> (O) 301-540-9549
>>>>>>>>>> (M) 301-326-6843
>>>>>>>>>>
>>>>>>>>>> "The trick to earning trust is to avoid all tricks.  Including
>>>>>>>>>> tricks on yourself."
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -------- Original message --------
>>>>>>>>>> From: "Glen Marshall [SRS]" < <gfm at securityrs.com>
>>>>>>>>>> gfm at securityrs.com>
>>>>>>>>>> Date: 2016/01/24 7:07 AM (GMT-08:00)
>>>>>>>>>> To: HEART List < <openid-specs-heart at lists.openid.net>
>>>>>>>>>> openid-specs-heart at lists.openid.net>
>>>>>>>>>> Subject: [Openid-specs-heart] CHIME Launches $1M Challenge to
>>>>>>>>>> Solve Patient ID Problem
>>>>>>>>>>
>>>>>>>>>> This is pertinent to our data-sharing use cases.  There is no
>>>>>>>>>> current solution to accurately sharing/gathering patients' clinical data
>>>>>>>>>> stored among various repositories.  In turn, that makes applying access
>>>>>>>>>> controls across all of a patient's data in those repositories difficult.
>>>>>>>>>> I'm happy to see Chime's challenge.
>>>>>>>>>>
>>>>>>>>>> However, the related problem of discovering where all of one's
>>>>>>>>>> data might be is computationally intractable.  It is equally intractable to
>>>>>>>>>> gather and combine all access permissions and regulatory restrictions on
>>>>>>>>>> patients' data, even if there were a useful means to do so.  (Both are
>>>>>>>>>> equivalent to the halting problem
>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Halting-5Fproblem&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=eVT2hXrUini0He7H6c-zHwPxd4ROV6nwfZ53AECX76o&e=>
>>>>>>>>>> .)
>>>>>>>>>>
>>>>>>>>>> Having a single "source of truth" repository is one direction for
>>>>>>>>>> a solution, as is having a single access permissions source.  Keeping them
>>>>>>>>>> updated with new data and permissions is possible, even if difficult in the
>>>>>>>>>> short run.
>>>>>>>>>>
>>>>>>>>>> However, establishing unique URIs for each patient's data and
>>>>>>>>>> permissions is the same as having a universal patient identifier.  That
>>>>>>>>>> might be subject to current Congressional funding restrictions.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *The College of Healthcare Information Management Executives on
>>>>>>>>>> Tuesday launched a $1 million National Patient ID Challenge to develop
>>>>>>>>>> solutions to ensure 100 percent accuracy of every patient’s identity to
>>>>>>>>>> reduce preventable medical errors.*
>>>>>>>>>>
>>>>>>>>>> *
>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.healthdatamanagement.com_news_chime-2Dlaunches-2D1m-2Dchallenge-2Dto-2Dsolve-2Dpatient-2Did-2Dproblem&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=_qW1n-yVrg_DP1kqs-CW-XiipWZapB1GXpTiUdB-pMo&e=>http://www.healthdatamanagement.com/news/chime-launches-1m-challenge-to-solve-patient-id-problem
>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.healthdatamanagement.com_news_chime-2Dlaunches-2D1m-2Dchallenge-2Dto-2Dsolve-2Dpatient-2Did-2Dproblem&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=_qW1n-yVrg_DP1kqs-CW-XiipWZapB1GXpTiUdB-pMo&e=>*
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> *Glen F. Marshall*
>>>>>>>>>> Consultant
>>>>>>>>>> Security Risk Solutions, Inc.
>>>>>>>>>> 698 Fishermans Bend
>>>>>>>>>> Mount Pleasant, SC 29464
>>>>>>>>>> Tel: (610) 644-2452 <%28610%29%20644-2452>
>>>>>>>>>> Mobile: (610) 613-3084 <%28610%29%20613-3084>
>>>>>>>>>> <gfm at securityrs.com>gfm at securityrs.com
>>>>>>>>>>
>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.SecurityRiskSolutions.com&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=sO0EFn2RDc6nTcNVSjD-lEfCdZqy-TatdAT6ccpnTZI&e=>
>>>>>>>>>> www.SecurityRiskSolutions.com
>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.SecurityRiskSolutions.com&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=sO0EFn2RDc6nTcNVSjD-lEfCdZqy-TatdAT6ccpnTZI&e=>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Openid-specs-heart mailing list
>>>>>>>>>> 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=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=YlZbL57zFJCHlm8lTsjPaao9DWipNm9s50Q8ZFOgk54&e=>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Adrian Gropper MD
>>>>>>>>>
>>>>>>>>> PROTECT YOUR FUTURE - RESTORE Health Privacy!
>>>>>>>>> HELP us fight for the right to control personal health data.
>>>>>>>>> DONATE:
>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>>>>>>> http://patientprivacyrights.org/donate-2/
>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Openid-specs-heart mailing listOpenid-specs-heart at lists.openid.nethttp://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=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=YlZbL57zFJCHlm8lTsjPaao9DWipNm9s50Q8ZFOgk54&e=>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Adrian Gropper MD
>>>>>>>>
>>>>>>>> PROTECT YOUR FUTURE - RESTORE Health Privacy!
>>>>>>>> HELP us fight for the right to control personal health data.
>>>>>>>> DONATE:
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>>>>>> http://patientprivacyrights.org/donate-2/
>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Adrian Gropper MD
>>>>>>>
>>>>>>> PROTECT YOUR FUTURE - 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=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Adrian Gropper MD
>>>>>>
>>>>>> PROTECT YOUR FUTURE - 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=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Openid-specs-heart mailing list
>>>>>> Openid-specs-heart at lists.openid.net
>>>>>>
>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=YlZbL57zFJCHlm8lTsjPaao9DWipNm9s50Q8ZFOgk54&e=
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Adrian Gropper MD
>>>>
>>>> PROTECT YOUR FUTURE - 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=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6qsDGXlfn6YB2nKRHOhQbq7-F60_1nlM8F6SOwyMwac&s=rAJTxml04Ym8Bi0-vj0w_QpsXopAevr1vwGI1Qko-Jw&e=>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Adrian Gropper MD
>>>
>>> PROTECT YOUR FUTURE - 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=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6qsDGXlfn6YB2nKRHOhQbq7-F60_1nlM8F6SOwyMwac&s=rAJTxml04Ym8Bi0-vj0w_QpsXopAevr1vwGI1Qko-Jw&e=>
>>>
>>
>>
>
>
> --
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
>
>
>


-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160125/83875521/attachment-0001.html>


More information about the Openid-specs-heart mailing list