[Openid-specs-heart] Is HEART profiling privacy?

[Adrian Gropper]

I doubt that I'm alone in being totally confused by Eve's use-case as it
relates to developing a HEART profile. But just in case, I'm putting my
concern in a separate thread. I'm cross-posting to the UMA group because
there's an active thread there about scopes right now.

Let me try to convince you that there's no need for HEART to be profiling
privacy and that trying to do so would do more harm than good.

During today's HEART call we agreed that "Alice completely trusts her UMA
Authorization Server." I take this to mean that Alice has no reason to
restrict her Resource Type registration with the UMA Authorization Server
to anything less than 'FHIR'/patient/* . Any subsequent restrictions or
scoping would then be decided by the AS based on Alice's policies and
client needs.

FHIR, in its evolving wisdom, will define and standardize hundreds of
resource types below patient as 'FHIR'/patient/xyz. Alice's AS will take
the applicable FHIR standard and expose a policy-setting UI to Alice well
before the time that the FHIR client shows up.

The FHIR clients will have access to the FHIR standard and will therefore
know what the standard resource types are. Of course, some FHIR resource
servers may not implement the entire set of hundreds of potential resource
types, maybe because they don't handle that kind of patient data, but let's
not get ahead of ourselves.

The point of UMA is that Alice can set and can change her policies at any
time between the time of resource registration and before the FHIR client
shows up to her AS. Alice can do this policy setting based on either:

   - the published set of FHIR patient-level resource types, or
   - the subset of resource types that the particular FHIR Resource Server
   actually supports for all patients, or
   - the subset of resource types that the FHIR Resource Server supports in
   her particular case.


Which brings us to my question: What purpose is served by HEART profiling
some subset of the FHIR patient-level resource types? Presumably it's to
improve her user experience at her AS by "graying out" privacy options
supported by the FHIR standard but not offered by that particular FHIR
Resource Server. This "graying out" is purely a user experience issue. It
has nothing to do with interoperability because no harm is done if Alice
chooses to restrict or enable resource types that are not supported by the
particular resource server anyway.

Much as I like to advocate for a good user experience, giving the FHIR
Resource Server a particular subset of "privacy-related" resource types as
a profile will do much more harm to interoperability and information
blocking than it will do good. It sets a low bar. It restricts the kind of
policies that Alice could set if the scope calculus is always done at the
point when the FHIR client presents to the AS.

In general, (not just FHIR or HEART) any resource server is free to publish
the actual subject-level resource types it supports. This is easier when
there's a standard. UMA may or may not also provide an endpoint for
communicating the resource types that a particular resource server makes
available to as particular resource subject. This is a nice-to-have to
improve the user experience by "graying out" the resource types that are
not available for that particular subject but it is not an interoperability
issue.

PS: It is often pointed out that merely "graying out" certain resource
types for a particular subject could leak private information. This is not
an issue if "Alice completely trusts her UMA Authorization Server." In
cases where Alice does not have complete trust of her AS, then indeed, she
needs to restrict the types of resources that are registered with the AS by
using the FHIR resource server's patient portal or some other out-of band
mechanism that is beyond both UMA and HEART.

Adrian







-- 

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/20160620/2adaaa8f/attachment.html>