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

Adrian Gropper agropper at healthurl.com
Wed Aug 5 15:26:26 UTC 2015


TL;DR version of long post above:

By design, institutions shouldn't restrict what browser a patient uses to
access the patient portal. For the same reason, institutions should not
restrict what Authorization Server the patient uses to control the
protected FHIR resource. The same interop benefits accrue in both cases.

@ Aaron: The next use-case
<https://docs.google.com/document/d/1V3e_fDH63fNDsV-WOGKcyg0ebuW165DOpjY_RcuMk4U/edit#>
announced on Monday focuses on the common delegation problem.

Adrian

On Wed, Aug 5, 2015 at 10:46 AM, Adrian Gropper <agropper at healthurl.com>
wrote:

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


-- 

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/f3ce8b42/attachment.html>


More information about the Openid-specs-heart mailing list