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

Glen Marshall [SRS] gfm at securityrs.com
Sun Sep 27 03:47:14 UTC 2015


Policy-based privacy objectives cannot be predicted, hence they are 
arbitrary relative to the use cases.  They may be individual, 
institutional, governmental, cultural, etc.  The technology should be 
secure and enabling, not constraining, to the objectives.

Our assumptions about the provenance of the policies and how they 
operate needs to be unconstrained as well.  For example, not all privacy 
preferences are restrictive, e.g., a patient may choose to disclose more 
than a default privacy policy allows.  Some policies may conflict with 
each other, with a compromise resolution outside of the use case.  And 
so on.  We just need to support them, regardless.

*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 20:03, Aaron Seib wrote:
>
> 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
>
> <nate-trust.org>
>
> *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 <mailto:gfm at securityrs.com>
> www.SecurityRiskSolutions.com <http://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 <mailto: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
>
>     NATE <http://www.nate-trust.org/>, CEO
>
>     @CaptBlueButton
>
>     (o) 301-540-2311 <tel:301-540-2311>
>
>     (m) 301-326-6843 <tel:301-326-6843>
>
>     *From:*Openid-specs-heart
>     [mailto:openid-specs-heart-bounces at lists.openid.net
>     <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
>     <mailto: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 <mailto: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
>     <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
>     <mailto: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-care-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 <tel:954.290.1991>
>
>     Website <http://www.lifemedid.com/> |Facebook
>     <https://www.facebook.com/pages/LifeMed-ID/168424683331516?ref=bookmarks>
>     |LinkedIn
>     <https://www.linkedin.com/company/1893899?trk=tyah&trkInfo=clickedVertical%3Acompany%2Cidx%3A1-1-1%2CtarId%3A1436221486696%2Ctas%3ALifeMed%20Id>
>     |Twitter <https://twitter.com/LifemedID> |Google+
>     <https://plus.google.com/106315953419857947247/posts>
>
>     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/
>
>
>
>
>     -- 
>
>     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
>

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


More information about the Openid-specs-heart mailing list