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

Eve Maler eve.maler at forgerock.com
Fri Jan 29 14:47:19 UTC 2016


UMA as designed is well compatible with n ROs and 1 AS, where the AS is an
always-on service acting in the interests of each of the ROs in turn.
(Think about how a SaaS service represents and serves each of its users
without mixing them up.)

It can be technically compatible with 1 RO and 1 AS as well in the exact
same way, but things start to break down when others in the ecosystem want
to make a hard assumption that the *identity* of the AS (as an agent of the
RO) is "as good as knowing" the singular identity of the RO it represents.
This would require protocol changes.


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
New ForgeRock Identity Platform <https://www.forgerock.com> with UMA support
<https://www.forgerock.com/platform/user-managed-access/> and an OpenUMA
community <https://forgerock.org/openuma/>!

On Mon, Jan 25, 2016 at 12:31 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> Eve, can you unpack the technical solution point that you're making? Are
> you saying that an n:1 solution is currently incompatible with a 1:1
> solution and which role is on either side of the : ?
>
> Adrian
>
> On Mon, Jan 25, 2016 at 3:23 PM, Eve Maler <eve.maler at forgerock.com>
> wrote:
>
>> I'm very glad to see this clear elucidation of where the splits in
>> understanding/belief are.
>>
>> The UMA WG's design center never actually assumed or required a strict
>> 1:1 relationship between RO and AS, as can be seen in the charter
>> <http://kantarainitiative.org/confluence/display/uma/Charter> and requirements
>> and design principles
>> <http://kantarainitiative.org/confluence/display/uma/UMA+Requirements>.
>>
>> The nature of agency law, as I understand it, is precisely to ensure that
>> the agent's interests align properly with those of the principal so that
>> the agent acts within their authority when they act on behalf of the
>> principal. This should hold true whether there is a 1:1 or n:1
>> relationship, and it's part of why the UMA legal subgroup is doing its work.
>>
>> Of course, if technology can do a good job of keeping an agent in line,
>> then a legal remedy might not be required. But so far, I haven't seen jwk
>> be a good candidate for a technical solution.
>>
>> People have asked me about various encryption or DRM solutions being used
>> on top of UMA. Generally my response to them is that they can use such a
>> thing if they want to. However, solutions involving encryption can impose
>> costs that many ecosystems can't bear (particularly wide ecosystems with
>> lots of third-party clients -- witness OAuth V1.0), and often the players
>> end up treating such requirements as failure and route around them by
>> emailing content or sharing passwords. :-) Access control systems must make
>> the right thing to do be the easiest thing to do.
>>
>>
>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
>> Technology
>> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
>> Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!
>>
>> On Mon, Jan 25, 2016 at 9:32 AM, Adrian Gropper <agropper at healthurl.com>
>> wrote:
>>
>>> (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 at 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 <
>>>> agropper at healthurl.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 25, 2016 at 11:49 AM, Josh Mandel <
>>>>> Joshua.Mandel at 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 <
>>>>>> 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> 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> 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>
>>>>>>>>>>>>>>>> Date: 2016/01/24 7:07 AM (GMT-08:00)
>>>>>>>>>>>>>>>> To: HEART List <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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <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/
>>>>>>> <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/
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-heart mailing list
>>> Openid-specs-heart at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>
>>>
>>
>
>
> --
>
> 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/20160129/725445a7/attachment.html>


More information about the Openid-specs-heart mailing list