[Openid-specs-heart] Proposal for reworked use case AND use case template

[Adrian Gropper]

It's the difference between verticals and people. The vertical ends where
person as the autonomous, sovereign subject begins. This is not only
critical for human dignity but it will also drive interoperability across
otherwise reluctant competitors.

The technology we're designing in FHIR and HEART will cross a line from the
institution able to compete and choose to the human individual able to
compete and choose. Otherwise, we're just treating patients like cattle.

The patient ID issue is a very clear example of this. When patient ID is
managed through probabilistic master patient indexes (MPI) in institutions
that the patient doesn't know exist, the patient is being tracked and
managed as if by a deity with almost no choice in the matter. This may or
may not be efficient from the institutional perspective but it's
undignified from the personal perspective. It limits the human's
opportunity for reason or action without a clear explanation.

To understand this clearly, consider the question of how we "improve" on
patient matching using MPI? Do we consider success when every healthcare
interaction, hospital, doctor, payer, pharmacy, and personal device are all
100% accurately registered in one or more secret data registries operated
by state and private actors? Is it better if there's only one panoptical
patient registry? Do we have a governance mechanism for who can access this
registry and a way to control the registry if it's in the private sector?

My point is that Patient Identity and Patient Authorization are first about
people and need to be standardized and frameworked by governance mechanisms
that give people the trump card. NSTIC figured this out years ago and is
trying to embody it in IDESG. Healthcare is struggling with this in PCORI
trying to create interoperability between institutional databases of people.

UMA is a groundbreaking innovation because it is technology accessible to
the individual person irrespective of any institution. It's like the Web
browser in this respect. Verticals do try to mess with the browser as an
autonomous agent of one human, for example media companies and DRM.

Healthcare companies will rationally try to design FHIR to give them as
much institutional DRM capability in OAuth or UMA as they can get. As with
the patient matching example above, it's up to all of us as privacy
engineers to envision and clarify the limit of institutional control.

The User Managed Access Authorizatiion Server is the Machine-to-Machine
(M2M) equivalent of Web browser. Both the AS and the Browser are
fundamentally agents of one human being across very different verticals.
HTTP, HTML, OAUth, FHIR, and many other standards now need to deal with the
fact that humans can control our agents whether we're live on-line or
asleep.

Adrian

On Wednesday, August 5, 2015, Josh Mandel <
Joshua.Mandel at childrens.harvard.edu> wrote:

> Adrian,
>
> I take your point that the healthcare vertical must end somewhere, but I
> can't quite follow this argument:
>
> I suggest that authentication, authorization, delegation, and credential
>> management... are ... not specific to any particular vertical. The OpenID
>> Foundation and HEART are as good a place to deal with these standards ...
>
>
> But HEART is OpenID's *Health* Relationship Trust Workgroup; as such, it
> appears to be a health-vertical-oriented approach, even if the underlying
> technology isn't vertical-specific. I don't see many efforts defining (say)
> healthcare-specific alternatives to OAuth or SAML (or UMA). Instead, I see
> groups using those standards much the same way HEART is doing. But I may be
> missing the thrust of your argument.
>
> What specifically are the stuffing-too-much-into-the-health-vertical
> activities that you are arguing against?
>
>  -J
>
>

-- 

Adrian Gropper MD

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/20150805/1a27bda1/attachment-0001.html>