[Openid-specs-heart] Fresh take on problem statement for OAuth-Only Two-Way Exchange use case

[Adrian Gropper]

Great list but with one key issue.

Blue Button Plus Pull is a polling mechanism. The BB+ work talked of BB+
Push which would be based on specific triggers such as admission, writing
an order or prescription, new lab or imaging result, etc... Most of these
potential triggers are associated with sharing some data about Alice
(eligibility on admission, e-prescription, incoming lab or consult report).
As long as these transfers involved Alice's Authorization Server in some
way, the trigger would be easy, the PHR would be up to date, and push vs.
pull would not be an issue.

Adrian

On Sat, Aug 15, 2015 at 8:13 AM, Aaron Seib (NATE) <
aaron.seib at nate-trust.org> wrote:

> Great.  When can you have this ready?  ;)
>
>
> Sent from my Verizon Wireless 4G LTE smartphone
>
>
> -------- Original message --------
> From: Eve Maler
> Date:08/14/2015 5:21 PM (GMT-05:00)
> To: openid-specs-heart at lists.openid.net
> Subject: [Openid-specs-heart] Fresh take on problem statement for
> OAuth-Only Two-Way Exchange use case
>
> Seeing as the discussion of potential problem statements for our current
> use case was a) attached to a longer and longer thread that started out as
> meeting minutes and b) drifting in the direction of identity federation and
> UMA topics :-), I thought I make another run at what problems might be
> tackled by Bill's use case. Here are the problems that I see it solving:
>
>    - Security protections over data: The data that flows in either
>    direction is protected.
>
>    - Privacy protections over identity: The identifiers that Alice uses
>    at the EHR and PHR systems need not be exposed to each other in order for
>    the data to flow in either direction.
>
>    - Some species of the "clipboard problem": Because Alice keeps
>    accurate data in her PHR system and can hook it up to the PCP's EHR system
>    at enrollment/registration time, she gets a "virtual clipboard" effect at
>    that time, making enrollment easier for her and more accurate for the PCP
>    and making registration for her easier. And there are even *ongoing*
>    benefits whenever her personal data changes: it flows naturally to the
>    PCP's system as needed.
>
>    - Some species of the "lack of control over her own healthcare"
>    problem: Because Alice's PHR system can automatically receive authoritative
>    copies of medical data about her through a "Blue Button Plus Pull" fashion,
>    she can get all the benefits touted by the BB program
>    <http://www.healthit.gov/patients-families/benefits-blue-button>, as
>    conveniently as possible. (The obvious extension of this use case,
>    "multiple EHR systems feeding into the same PHR system using OAuth", gives
>    her this result even more strongly.)
>
>    - Control over stopping data flows: Should Alice change healthcare
>    providers, she gets a privacy benefit by being able to revoke the
>    authorization for each of the systems so they can't continue communicating
>    with each other.
>
> Thoughts on this?
>
> *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!
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>


-- 

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/20150815/47cf12ac/attachment.html>