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

Fri Jan 29 23:55:12 UTC 2016

Continuing with the questions below, here's a working example of a patient
ID solution: http://cancerforchristmas.com/qr-code-tattoo/

If the URI did not point to Casey's AS, where would it point to?

On Fri, Jan 29, 2016 at 10:31 AM, Adrian Gropper <agropper at healthurl.com>
wrote:

> What is singular identity of the RO? Is it equivalent to biometric
> identity a la iris scan done by the RS?
>
> In that case, can the AS be associated with one persona of the RO?
>
> What protocol changes would be required?
>
> Adrian

> On Friday, January 29, 2016, Eve Maler <eve.maler at forgerock.com> wrote:
>
>> 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/
>>>
>>
>>
>
> --
>
> 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/20160129/38967289/attachment.html>