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

25 Jan 2016

      (apologies for cross-posting)

Thanks, Josh. As always, you are able to explain the issue much better than
me. This is why I've tried my best to understand the gaps between UMA as it
is today and something that lays cliaim to user-managed access. FHIR and
UMA and, consequently, HEART are all new and we need to be very clear about
how we design this next generation of protocols.

In the UMA legal subgroup, we've tried to map UMA into "Agency Law", the
relatively simple branch of law that dictates how an individual (patient)
can specify an agent (as in lawyer, accountant, or doctor) to act on their
behalf. Suffice it to say, that agency law does not assume that an agent
will have any conflict of interest in the baseline case but that conflicts
of interest can arise in the real world (for example when a broker is put
in an agency role).

It's up to all of us, FHIR, UMA, and HEART, to develop around the
requirement for agency on the part of the individual. We can layer on all
sorts of other complexities to deal with brokerage and jurisdictional
issues, but if we don't start with clear personal agency in the
Authorization Server, then we will keep chasing the increased complexity
and insecurity of our networks for another 10 years.

Adrian

On Monday, January 25, 2016, Josh Mandel <
Joshua.Mandel@childrens.harvard.edu> wrote:
...
That's illuminating, at least. It sounds like you're interested in
changing the underlying protocol (i.e. effectively designing something new
instead of UMA). There's nothing wrong with that, but making these changes
implicitly and then calling the new thing "UMA" is exacerbating the
confusion on this list.
Also, I can't help responding to the following comment that you made on #5:
...
You're mixing up the identity of an authorization service with the
identity of a user or persona.
-- that's exactly correct! Using the AS's public key to identify the user
would be mixing up the identity of the AS with the user. That's exactly why
I'm saying you *cannot equate* them. So perhaps we agree on this point at
least :-)
-J
On Mon, Jan 25, 2016 at 11:56 AM, Adrian Gropper javascript:_e(%7B%7D,'cvml','agropper@healthurl.com');> wrote:
...
On Mon, Jan 25, 2016 at 11:49 AM, Josh Mandel <
Joshua.Mandel@childrens.harvard.edu
javascript:_e(%7B%7D,'cvml','Joshua.Mandel@childrens.harvard.edu');>
wrote:
...
Adrian, I'm afraid we're talking past one another here. Let me try to
spell out the logic and see if you follow and agree with each step:
1. UMA allows a user to stand up her own Authorization Server
Yes
...
2. UMA does not require a user to stand up her own Authorization Server
I don't know. It may be that's the only way for an UMA-like approach to
privacy and security to scale.
...
3. Given #2, an UMA-based protocol cannot assume that every user will
stand up her own Authorization Server
Why not? Can't a service host an arbitrary number of AS?
...
4. Given #3, an UMA-based protocol must assume that some Authorization
Servers will work on behalf of multiple users
That depends on how we choose to define Authorization Server.
...
5. Given #4, an UMA-based protocol cannot equate an Authorization
Server's identity with a user's identity
You're mixing up the identity of an authorization service with the
identity of a user or persona.
...
6. Given #5, an UMA-based protocol cannot use an Authorization Servers
public key to identify a user.
It's all in how we define Authorization Server, isn't it?
Adrian
...
Is there a point at which you disagree?
-J
On Mon, Jan 25, 2016 at 11:40 AM, Adrian Gropper javascript:_e(%7B%7D,'cvml','agropper@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@childrens.harvard.edu
javascript:_e(%7B%7D,'cvml','Joshua.Mandel@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@healthurl.com
javascript:_e(%7B%7D,'cvml','agropper@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 javascript:_e(%7B%7D,'cvml','jricher@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  javascript:_e(%7B%7D,'cvml','agropper@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@childrens.harvard.edu
> javascript:_e(%7B%7D,'cvml','Joshua.Mandel@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@healthurl.com
>> javascript:_e(%7B%7D,'cvml','agropper@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 >> javascript:_e(%7B%7D,'cvml','jricher@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 >>> javascript:_e(%7B%7D,'cvml','jricher@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@mit.edu');jricher@mit.edu
>>>>> javascript:_e(%7B%7D,'cvml','jricher@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@nate-trust.org');
>>>>>> aaron.seib@nate-trust.org
>>>>>> javascript:_e(%7B%7D,'cvml','aaron.seib@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@securityrs.com');
>>>>>>> gfm@securityrs.com
>>>>>>> javascript:_e(%7B%7D,'cvml','gfm@securityrs.com');>
>>>>>>> Date: 2016/01/24 7:07 AM (GMT-08:00)
>>>>>>> To: HEART List <
>>>>>>> javascript:_e(%7B%7D,'cvml','openid-specs-heart@lists.openid.net');
>>>>>>> openid-specs-heart@lists.openid.net
>>>>>>> javascript:_e(%7B%7D,'cvml','openid-specs-heart@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-solv...
>>>>>>> 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@securityrs.com');
>>>>>>> gfm@securityrs.com
>>>>>>> javascript:_e(%7B%7D,'cvml','gfm@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@lists.openid.net
>>>>>>> javascript:_e(%7B%7D,'cvml','Openid-specs-heart@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@lists.openid.net javascript:_e(%7B%7D,'cvml','Openid-specs-heart@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@lists.openid.net
>>> javascript:_e(%7B%7D,'cvml','Openid-specs-heart@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/
https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=1UaGqWJeKd4UdDAld99dOkLSgTEJUfV8Vu3sylh0h5E&s=mJ4JXE5T1szAX1UEoejeV2TSq_kh1t6enN2DsyBOd5g&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=w3SjjqRMdmtH3aphsxB60HkTmVUKOv5ObNc_9eJxmtY&s=5L56gsnzOm5hcTK0lJvbihx2PFR-5L-hscdP5z__0WE&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/