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

Adrian Gropper agropper at healthurl.com
Mon Jan 25 13:57:25 UTC 2016


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://webfinger.net/>https://webfinger.net/ 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>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://en.wikipedia.org/wiki/Halting_problem>.)
>>
>> 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.*
>>
>> *http://www.healthdatamanagement.com/news/chime-launches-1m-challenge-to-solve-patient-id-problem
>> <http://www.healthdatamanagement.com/news/chime-launches-1m-challenge-to-solve-patient-id-problem>*
>> --
>>
>> *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
>> www.SecurityRiskSolutions.com
>>
>> _______________________________________________
>> 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/
>
>
> _______________________________________________
> Openid-specs-heart mailing listOpenid-specs-heart at lists.openid.nethttp://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/20160125/e2b80df0/attachment-0001.html>


More information about the Openid-specs-heart mailing list