[Openid-specs-heart] Bloomberg article highlights pitfalls associated with patient matching

Sun Sep 27 00:03:04 UTC 2015

There is no objecting to that reasoning.  

I would add that the system operator is responsible for disclosing to the
potential user that these risks exist and allow the user to exercise their
right not to participate if they do not feel the approach being proposed is
sufficient.  

Where I am not following is the following phrase.

"help us define a secure means to support arbitrary policy-based privacy
objectives."

I wonder if when you say 'support arbitrary policy based privacy objectives'
is that mean the same thing as 'support the ability of an individual to
define their own privacy preferences' as in "I am not ready to share with
these people the fact that I am being treated for pancreatitis" and the
authorization server prevents information related to my treatments from
being shared or do you mean something else entirely? 

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843

From: Openid-specs-heart
[mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Glen
Marshall [SRS]
Sent: Saturday, September 26, 2015 7:37 PM
Cc: Catherine Schulten; openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Bloomberg article highlights pitfalls
associated with patient matching

Let's assume an accurate patient-matching "black box" exists.  What are the
use cases that would help us define a secure means to support arbitrary
policy-based privacy objectives?  

Let's not seek 100% assurance of privacy, as that is an NP-complete problem.
What we need is a solution that can be incrementally improved.

Glen     

Glen F. Marshall
Consultant
Security Risk Solutions, Inc.
698 Fishermans Bend
Mount Pleasant, SC 29464
Tel: (610) 644-2452
Mobile: (610) 613-3084
gfm at securityrs.com
www.SecurityRiskSolutions.com

On 9/26/15 16:32, Adrian Gropper wrote:

If it were under the cover of TPO, then why wouldn't all health information
exchanges do the same thing?

Adrian

On Sat, Sep 26, 2015 at 11:34 AM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

If you figure out how SureScripts does it please don't share with anyone
else.  J

Isn't it just under the cover of TPO?

Aaron Seib

 <http://www.nate-trust.org/> NATE, CEO

@CaptBlueButton

(o) 301-540-2311

(m) 301-326-6843

From: Openid-specs-heart
[mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Adrian
Gropper
Sent: Saturday, September 26, 2015 10:14 AM
To: Maxwell, Jeremy (OS/OCPO)
Cc: Catherine Schulten; openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Bloomberg article highlights pitfalls
associated with patient matching

I agree with Jeremy about transparency as the solution but I also think that
what Catherine calls "anonymization" would have solved the problem. 

Anonymization or pairwise pseudonumity forces the patient to be an explicit
actor to the matching process. It replaces an error-prone probabilistic and
hidden process with a clear informed consent by the patient being matched. 

Although not mentioned in this Bloomberg article, Surescripts is the
de-facto national patient surveillance system. Pretty much every
prescription we have ever had from any Meaningful Use EHR and beyond is
identity matched, tracked, and stored forever by Surescripts. I am currently
trying to figure out how Surescripts is able to do this without any visible
consent or transparency.

Adrian

On Friday, September 25, 2015, Maxwell, Jeremy (OS/OCPO)
<Jeremy.Maxwell at hhs.gov> wrote:

Probably not.  It sounds like it was either human error (e.g., someone
entered information into a wrong chart) or a software error (e.g., the EHR
software mixed up its database indices).  Or it could be simple fraud (e.g.,
doctor shopping).  In any event, I think the best defense against erroneous
records is greater, easier, and quicker patient access.  Just like paper
charts before them, electronic records will always have inaccuracies.  This
isn't really news.  It's how quickly they can be identified and
remedied-that's the key.

From: Openid-specs-heart
[mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Catherine
Schulten
Sent: Friday, September 25, 2015 11:07 AM
To: openid-specs-heart at lists.openid.net
Subject: [Openid-specs-heart] Bloomberg article highlights pitfalls
associated with patient matching

http://www.bloomberg.com/news/articles/2015-09-23/the-pitfalls-of-health-car
e-companies-addiction-to-big-data

Mother's prescription information is linked to daughter's record - would
anonomyziation have solved this problem?

Catherine Schulten

Director, Product Management

LifeMed ID, Inc. 

6349 Auburn Blvd., Citrus Heights, CA 95621

Office: 888.550.6550 x135 <tel:888.550.6550%20x135>  | Cell: 954.290.1991 

 <http://www.lifemedid.com/> Website |
<https://www.facebook.com/pages/LifeMed-ID/168424683331516?ref=bookmarks>
Facebook |
<https://www.linkedin.com/company/1893899?trk=tyah&trkInfo=clickedVertical%3
Acompany%2Cidx%3A1-1-1%2CtarId%3A1436221486696%2Ctas%3ALifeMed%20Id>
LinkedIn |  <https://twitter.com/LifemedID> Twitter |
<https://plus.google.com/106315953419857947247/posts> Google+

lifemedid_logo

-- 

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/>
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/>
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150926/d7958a3c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150926/d7958a3c/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 6249 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150926/d7958a3c/attachment.png>