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

[Eve Maler]

Funny, I took "arbitrary" more as Glen meant it, in a sort of
computer-science sense, as here
<http://math.stackexchange.com/questions/319739/what-does-arbitrary-mean>.
:-) Good thing we are all getting used to asking for and providing term
definitions!


*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 Sun, Sep 27, 2015 at 5:18 AM, Aaron Seib (NATE) <
aaron.seib at nate-trust.org> wrote:

> Thanks.  Arbitrary is a loaded term for me in the sense that in law it
> seems to mean a decision that is not based on reason or justification.
>
>
> Sent from my Verizon Wireless 4G LTE smartphone
>
>
> -------- Original message --------
> From: "Glen Marshall [SRS]"
> Date:09/26/2015 11:47 PM (GMT-05:00)
> To: openid-specs-heart at lists.openid.net
> Subject: Re: [Openid-specs-heart] Bloomberg article highlights pitfalls
> associated with patient matching
>
> 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
>
> <http://nate-trust.org>
>
>
>
> *From:* Openid-specs-heart [
> mailto:openid-specs-heart-bounces at lists.openid.net
> <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
>
> NATE <http://www.nate-trust.org/>, CEO
>
> @CaptBlueButton
>
> (o) 301-540-2311
>
> (m) 301-326-6843
>
>
>
>
>
> *From:* Openid-specs-heart [mailto:
> <openid-specs-heart-bounces at lists.openid.net>
> 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>
> 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 de
>
>
> _______________________________________________
> 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/20150927/6457a343/attachment.html>