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

Justin Richer jricher at mit.edu
Mon Jan 25 13:59:56 UTC 2016


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 
> <mailto: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/
>>     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 <mailto: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 <tel:301-540-9549>
>>         (M) 301-326-6843 <tel: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
>>         <mailto:gfm at securityrs.com>>
>>         Date: 2016/01/24 7:07 AM (GMT-08:00)
>>         To: HEART List <openid-specs-heart at lists.openid.net
>>         <mailto: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/
>>         -- 
>>
>>         *Glen F. Marshall*
>>         Consultant
>>         Security Risk Solutions, Inc.
>>         698 Fishermans Bend
>>         Mount Pleasant, SC 29464
>>         Tel: (610) 644-2452 <tel:%28610%29%20644-2452>
>>         Mobile: (610) 613-3084 <tel:%28610%29%20613-3084>
>>         gfm at securityrs.com <mailto:gfm at securityrs.com>
>>         www.SecurityRiskSolutions.com
>>         <http://www.SecurityRiskSolutions.com>
>>
>>
>>         _______________________________________________
>>         Openid-specs-heart mailing list
>>         Openid-specs-heart at lists.openid.net
>>         <mailto: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 list
>>     Openid-specs-heart at lists.openid.net
>>     <mailto: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/20160125/e0be6da3/attachment.html>


More information about the Openid-specs-heart mailing list