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

Mon Jan 25 16:48:11 UTC 2016

What's the gap between UMA and HEART and what I'm proposing?

On Monday, January 25, 2016, Justin Richer <jricher at mit.edu> wrote:

> Nothing is *wrong* with it in concept, but it doesn’t do what you want it
> to do and it shouldn’t be a requirement anyway. It’s not how HEART works
> (or any underlying protocols).
>
>  — Justin
>
> On Jan 25, 2016, at 11:43 AM, Adrian Gropper <agropper at healthurl.com
> <javascript:_e(%7B%7D,'cvml','agropper at healthurl.com');>> wrote:
>
> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','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
>>>>> <javascript:_e(%7B%7D,'cvml','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
>>>>> <javascript:_e(%7B%7D,'cvml','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
>>>>>> <javascript:_e(%7B%7D,'cvml','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
>>>>>>> <javascript:_e(%7B%7D,'cvml','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
>>>>>>>> <javascript:_e(%7B%7D,'cvml','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 <
>>>>>>>>> <javascript:_e(%7B%7D,'cvml','jricher at mit.edu');>jricher at mit.edu
>>>>>>>>> <javascript:_e(%7B%7D,'cvml','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 <
>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','aaron.seib at nate-trust.org');>
>>>>>>>>>> aaron.seib at nate-trust.org
>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','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]" <
>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','gfm at securityrs.com');>
>>>>>>>>>>> gfm at securityrs.com
>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','gfm at securityrs.com');>>
>>>>>>>>>>> Date: 2016/01/24 7:07 AM (GMT-08:00)
>>>>>>>>>>> To: HEART List <
>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','openid-specs-heart at lists.openid.net');>
>>>>>>>>>>> openid-specs-heart at lists.openid.net
>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','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>
>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','gfm at securityrs.com');>
>>>>>>>>>>> gfm at securityrs.com
>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','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
>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','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.net <javascript:_e(%7B%7D,'cvml','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=>
>>>>>>>>> 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
>>>>>>> <javascript:_e(%7B%7D,'cvml','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/
>
>
>

-- 

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/10a6b862/attachment-0001.html>