Thanks for the Consent Receipt info, Mark! We should perhaps have you demo the receipt generator on our next legal subgroup call. I’m planning to comment on Adrian’s use cases tonight and also send out some of my own, to get ready for Friday. If anyone else has thoughts or questions on use cases for our subgroup work, I encourage you to write in. (I know the list has been full of technical stuff lately. I’ve added “[legal]” in the subject line above to catch the subgroup's attention, and perhaps that’s a good idea for others to do as well.) Eve

On 11 Aug 2015, at 11:33 AM, Mark Lizar wrote:

Great UMA-Legal call.

As mentioned in the call, the CIS WG has a freshly minted, MVCR v0.7 draft, from the CIS WG on GitHub. This is an active working draft, in progress, and can be found here :

https://github.com/KI-CISWG/MVCR/blob/master/mvcr-0.7.md https://github.com/KI-CISWG/MVCR/blob/master/mvcr-0.7.md

There is also a : Consent Receipt Generator on display at http://api.consentreceipt.org, http://api.consentreceipt.org/ and a test implementation for the Example Implementation for th CIS-Join Form, (also in progress) CIS-WG join form:https:// https://kantarainitiative.org/signup/?selectedGroup=3kantarainitiative.org/signup/?selectedGroup=3 http://kantarainitiative.org/signup/?selectedGroup=3 (Be one of the first to using our new consent button and get a consent receipt) The MVCR has just reached (this is the first announcement) v0.7 has been cut to its most minimal, and the plan is to fill in the detail through implementation requirements which we hope UMA can help by providing some use cases. The MVCR wants to be a core consent record format, which can (hypothetically) be extended by UMA (and 3rd part trust frameworks ). We plan to start testing it out as a tool to map information sharing relationships and it can be useful in the context of logging UMA resource access and use from the Authorisation Server.

As it happens, the law provides a great rule set for the consent record format. Consent requirement are the most common privacy requirements across all jurisdictions and cultures, it is what is legitimately authoritative (enforced by law) and we for see using consent to bind terms and logging use of resources with the MVCR format.

Now that we have this new MVCR we really want to play with it. In collaboration with UMA we have a chance to explore the use of the MVCR on aggregate and hopefully get a glimpse of how the MVCR might work on scale and for interoperability.

If you are interested in contributing to the MVCR we are taking issues on the Github repository, everyone is welcome to participate, if you sign the participation agreement.

Kind Regards,

Mark CO-Chair Consent & Information Sharing Work Group

...

On 7 Aug 2015, at 11:29, Dazza Greenwood mailto:dazza@civics.com> wrote:

Good idea to anchor the Legal group to use cases. Here is an issue ticket related to this: https://github.com/xmlgrrl/UMA-Specifications/issues/180 https://github.com/xmlgrrl/UMA-Specifications/issues/180

So they can be iterated,I've added Adrian's initial use cases to the wiki here: https://github.com/xmlgrrl/UMA-Specifications/wiki/UMA-Legal-Anchor-Use-Case... https://github.com/xmlgrrl/UMA-Specifications/wiki/UMA-Legal-Anchor-Use-Case...

Thanks, - Dazza

_ _ _ _ _ _ _ _ _ _ _ _ _ _ | Dazza Greenwood, JD | CIVICS.com http://civics.com/, Founder & Principal | MIT Media Lab, Visiting Scientist | Vmail: 617.500.3644 | Email: dazza@CIVICS.com mailto:dazza@CIVICS.com | Biz: http://CIVICS.com http://civics.com/ | MIT: https://law.MIT.edu https://law.mit.edu/ | Me: DazzaGreenwood.com http://dazzagreenwood.com/ | Twitter: @DazzaGreenwood | Google+: google.com/+DazzaGreenwood http://google.com/+DazzaGreenwood | LinkedIn: linkedin.com/in/DazzaGreenwood http://linkedin.com/in/DazzaGreenwood | GitHub: github.com/DazzaGreenwood/Interface http://github.com/DazzaGreenwood/Interface | Postal: P.O. Box 425845 Cambridge, MA 02142 | _ _ _ _ _ _ _ _ _ _ _ _ _ _

On Fri, Aug 7, 2015 at 10:40 AM, Eve Maler mailto:eve@xmlgrrl.com> wrote: From Adrian for consideration in our legal subgroup meeting coming up shortly. Thanks, Adrian!

...

Begin forwarded message:

From: Adrian Gropper mailto:agropper@healthurl.com> Subject: Four UMA Use-Cases in Healthcare Date: 7 August 2015 at 6:33:18 AM PDT To: Eve Maler mailto:eve@xmlgrrl.com> Cc: "Bucci, Debbie (HHS/ONCIT)" mailto:debbie.bucci@hhs.gov>, Josh Mandel mailto:jmandel@gmail.com>, Justin Richer mailto:jricher@mit.edu>

Eve,

There may be only 4 distinct use-cases for UMA in healthcare. I wrote this in order to prepare for the legal subgroup this morning. Feel free to share if it's useful.

Alice-to-Alice N - The multiple portals problem - Alice wants to direct sharing herself Alice wants to manage her EHR-1 and EHR-2 authorizations in one place. We call that place the AS. Alice registers her AS with her practice’s EHR-1. Alice registers her AS with another practice EHR-2. From then on, Alice can sign-in to her EHR, view accounting for disclosures, and manage authorizations.

Alice-to-Custodian - Delegation to a custodian Custodian creates an AS for Alice. Custodian has a sign-in to Alice’s AS. Alice registers her AS with her PCP’s EHR-1. Alice registers her AS with another practice’s EHR-2. From then on, Custodian can sign-in to Alice’s EHR, view accounting for disclosures, and manage authorizations.

Alice-to-Bob Directed - Alice wants to authorize her PCP for directed sharing Alice registers her AS with her PCP’s EHR-1. The PCP shares an Alice-specific context with Bob. Bob’s client EHR-2 presents claims to Alice’s AS, gets authorization. EHR-2 accesses resource from EHR-1.

Alice-to-Bob HIE - Alice wants to be discoverable Alice registers her AS with her practice’s EHR-1. Alice picks up a flier for the state HIE with a Q/R code, reads their Privacy Policy Alice signs-in into her AS and scans the Q/R code. The HIE allows Alice to pick her discovery attributes, registers Alice’s AS. Bob’s client signs into the HIE, discovers Alice, gets authorization to EHR-1.

--

Adrian Gropper MD

RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/ http://patientprivacyrights.org/donate-2/

Eve Maler | cell +1 425.345.6756 tel:%2B1%20425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com mailto:xmlgrrl@gmail.com

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

Thanks Eve. I've added *comments inline* to clarify the "problem" being solved in each case. Please keep in mind that I'm only considering Alice's perspective on the problems and look to others to add the RS, RqP, and Client perspectives. (Because formatting often doesn't survive the archive, I've labeled my comments <> but feel free to edit and merge in at will.) On Wed, Aug 12, 2015 at 8:43 PM, Eve Maler wrote:

Some thoughts on Adrian's use cases, first from a very high level, then drilling down. Sorry for the length. I hope it’s w

orth it. :-) My goals here are to a) help those on the subgroup who are

less familiar with UMA get more familiar with it (since I owe everyone a “remedial UMA flow explanation" on Friday’s call anyway), and b) connect the dots between these use cases and our discussion of last week.

So first, quoting liberally from the UMA FAQ http://kantarainitiative.org/confluence/display/uma/UMA+FAQ to give us some terminology:

*"Let's use the example of Alice, a typical web user, to introduce UMA terms and concepts. Alice is a "resource owner” [RO] who manages her calendar resource online. She might want to share her calendar information with a number of different parties for a variety of purposes, while not making it fully public to the whole world.*

*The calendar is known as a "protected resource", and Alice manages it at a web application called a "resource server” [RS]. She could have many resource servers for many different kinds of content she creates, along with other data about herself. In some cases, such as with credit scores, she can't actually control the values of data about herself.*

*The parties Alice wants to share her calendar with are called "requesting parties” [RqP]. They use "client” [C] applications to attempt access.*

*In some cases, Alice herself is a requesting party in addition to being a resource owner, such as when she wants to share calendar data out to different calendar applications that she likes to use. We call this "person-to-self" sharing.*

*In other cases, she wants to allow her friend Bob and her various family members to get calendar access. We call this "person-to-person" sharing.*

*Finally, she may want to allow non-individuals, such as e-commerce companies and government agencies, to get access. We call this "person-to-organization" sharing.* *With UMA, Alice can manage all these types of sharing in a unified way, from a single web-application point of control called an "authorization server” [AS]. She can set policies that guide the authorization server in allowing or disallowing access by clients to protected resources at resource servers."*

Now, to the use cases. These are four interestingly distinct design patterns of UMA usage. Some of the details in them represent challenges that UMA needs other technologies to solve fully, that may not have been fully worked out yet, or that may or may not reflect reality as things unfold. I’m pretty sure this is not an exhaustive list of all the design patterns that may be of interest to us, but it’s a good starter set (keeping in mind that it focuses on one vertical out of many).

There may be only 4 distinct use-cases for UMA in healthcare. I wrote this in order to prepare for the legal subgroup this morning. Feel free to share if it's useful.

- Alice-to-Alice N - The multiple portals problem - Alice wants to direct sharing herself

Alice wants to manage her EHR-1 and EHR-2 authorizations in one place. We call that place the AS.

- Alice registers her AS with her practice’s EHR-1. - Alice registers her AS with another practice EHR-2. - From then on, Alice can sign-in to her EHR, view accounting for disclosures, and manage authorizations.

(EHR = electronic health record)

I suspect this is not actually a person-to-self sharing use case, or at least not exclusively, but rather just a case of Alice setting up multiple RS’s to be managed from a single AS, and she might share out those resources to multiple other parties.

“Accounting for disclosures” is an interesting phenomenon. Here, the AS is passively logging that third parties are accessing Alice’s resources, but she can’t do anything about it. Maybe the CDC is accessing her records for public health reasons, etc. If there’s an actual policy on record that allows the access, say, a system-default policy she can’t change, then it’s technically under UMA’s control, but if it happens outside that, then any monitoring is just some application feature. (In fact, logging is not something UMA currently says anything about anyway.)

*<AG> The Accounting for Disclosures (A4D) is meant to be passive and informational only. It belongs here as part of the "N" use-case because Alice has no obvious reason to want to log into a separate server to view the A4D list. The CDC reference in Eve's note is distracting here. The four use-cases are not meant to be exclusive. An application of UMA will often combine two or more of these use-cases. We need a term for when two or more of these four problem-oriented use cases are combined. For example, in my mother's case, I envision the Alice's AS to combine the following features:* - *A single point of access for managing authorizations across various RS across various verticals* - *A single point of access for reviewing disclosures (A4D) across various RS and various verticals* - *The ability for me as Alice's Custodian (where Alice, the RO, is my elderly mom or minor child) to be the online party interacting with Alice's various RS who mostly see her in-person (more below).* - *The ability for Alice to delegate access to Bob to a resource that Alice may not be allowed to view or modify herself, such as an unconfirmed lab result for HIV in the old days.* - *The ability for Alice to add a discovery handle to an otherwise pairwise anonymous registration of her AS with an RS. For example, the RS would publish the discoverable identity in a public or federated directory. * *From Alice's perspective, a single AS should be able to solve all five bulleted problems above.* *</AG>*

- Alice-to-Custodian - Delegation to a custodian - Custodian creates an AS for Alice. Custodian has a sign-in to Alice’s AS. - Alice registers her AS with her PCP’s EHR-1. - Alice registers her AS with another practice’s EHR-2. - From then on, Custodian can sign-in to Alice’s EHR, view accounting for disclosures, and manage authorizations.

(PCP = primary care provider)

Extremely interesting one. I don’t think the custodian “creates” an AS for Alice. Does this mean the custodian creates an AS account for Alice, who is an “offline person” or something? But that can’t be right because then Alice does some online stuff.

*<AG> This use-case assumes that my 89 y/o mom is Alice and, although she has a driver's license and can physically sign a piece of paper, her custodian, me is doing 100% of all digital interactions in-person during registration of the AS and online thereafter. </AG>*

This one hinges on how custodianship and delegation are defined. The “D” word is a slippery one. If the custodian is “acting-as” Alice in her AS (and RS?) accounts, that’s one (tricky) thing. If the goal is chained delegation (beyond the delegate) in a multi-AS environment, that another (tricky) thing.

*<AG> This is the reality of the problem from the Alice's perspective and our design patterns must deal. My goal here is provide a safe harbor for the RS based on my legal proxy for my mom. I think we need to define the D-word accrdingly. </AG>*

- Alice-to-Bob Directed - Alice wants to authorize her PCP for directed sharing - Alice registers her AS with her PCP’s EHR-1. - The PCP shares an Alice-specific context with Bob. - Bob’s client EHR-2 presents claims to Alice’s AS, gets authorization. - EHR-2 accesses resource from EHR-1.

This is sort of “classic UMA”, and it even mentions the client application that Bob is using!

So now it’s interesting to bring up other lurking ghosts that could be important, like Bob’s employer, the company operating the AS (if it’s not Alice personally), the company/ies operating the EHR systems, the hospital or government or whatever that the PCP office is affiliated with, etc.

This is a good time to introduce the “negative use cases”. Let’s say Carlos gets access to a resource, or at a time, or with a scope (permission type), that Alice didn’t want or wasn’t expecting. Who’s at fault? What went wrong?

- Did Alice set the policy wrong? - Did the AS screw up on its back end or ignore Alice’s wishes somehow? - Did EHR-1 wrongly or maliciously release the resource? - Did EHR-2 misinterpret some signal it was given by the RS or the AS? - Did EHR-2 insufficiently protect or maliciously share the access token it was given? - Did Carlos, operating the EHR-2 client, use it wrong, or present false claims, or mistaken claims? - (am I missing anything? probably)

*<AG> Agreed. These issues are critical but invisible to Alice. From

Alice's perspective, they need to be solved without sacrificing Alice's ability to specify an AS that she built from source herself. </AG>*

- Alice-to-Bob HIE - Alice wants to be discoverable - Alice registers her AS with her practice’s EHR-1. - Alice picks up a flier for the state HIE with a Q/R code, reads their Privacy Policy - Alice signs-in into her AS and scans the Q/R code. - The HIE allows Alice to pick her discovery attributes, registers Alice’s AS. - Bob’s client signs into the HIE, discovers Alice, gets authorization to EHR-1.

(HIE = health information exchange)

Another challenging one because you have to tack on a discovery service. This version of the use case looks easier than the usual one because it doesn’t call for the discovery service itself to be protected.

*<AG> I did not mean to imply that the discovery service was or wasn't protected. The HIE here is an example of a server that does not have a direct relationship to Alice. Currently, in 99% of the cases, Alice does not have a sign-in to the HIE. Rather, there are federation relationships between the various institutions that are presented to Alice when she registers her AS with an RS. </AG>* Adrian

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- Adrian Gropper MD RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/