Here's one idea for how CommonAccord could work with UMA:

1 - Modify CommonAccord so the Document and Print tabs create an HTML form
2 - Enable the RS to author the HTML form to describe the accessible resources and policies
3 - Help the RS create separate sections for each choice they are willing to offer the Resource Owner (via UMA)
4 - Give each choice (3) a unique identifier within the form
5 - Publish the form so that any interested Client or Requesting Party can find it anytime

When an AS is specified as part of Resource Registration (UMA Phase 1)

6 - Transmit the HTML form to the AS
7 - The AS notifies the RO and hosts a secure link to the Form
8 - The RO reads the form, makes choices, and saves the result locally at the AS
9 - The AS returns success to the RS and the resource is registered

When a RqP / Client pair approach the AS (UMA Phase 2)

10 - The Client, having access to the published form from step (5) requests access in terms of the locally unique identifiers (4)
11 - The AS compares the request to the policies stored in step (8)
12 - The AS issues a token to the C to present to the RS
13 - The RS introspects the token to get the identifiers (4) applicable to this particular authorization
14 - The RS provides access to the Client according to (13)

In this sequence, CommonAccord is only active relative to the RS. The simplest AS knows nothing about CommonAccord, although a more sophisticated AS could look up the CommonAccord details if they are published along with (5) and use that information to provide additional context to the RO.

In addition, a public ledger (e.g.: blockchain) for non-repudiation could be used to document:
- the claims presented by the RqP / C in order to protect the AS / RO
- the the RS-AS token introspection transaction in order to protect the RS
- the actual accounting for disclosure in step 14

This pattern has two major benefits. It allows for generic authorization servers that have no domain-specific ontologies. Second, this pattern is privacy-preserving for the RO because details of policy are not shared with the RS - only the outcome. Also, when this pattern is combined with a personal AS, it avoids a major problem with management of sensitive data (e.g: 42CFR Part 2  substance abuse information in healthcare) by a highly regulated separate consent management service.

Could we hack CommonAccord and UMA to do this?

Adrian





On Sat, Nov 14, 2015 at 7:41 AM, Adrian Gropper <agropper@healthurl.com> wrote:
It will be hard to find an example of consent/authorization/etc... originated by an individual because the world does not work that way. The scopes are defined by the technical capability and the jurisdictional mandates of the resource server. The authorization server can only choose among scopes originated by the resource server institution and is unlikely to be able to suggest or negotiate new scopes.

It is for this reason that I'm modeling the simplest practical authorization server as an offer of an HTML form authored by the resource server.

There are only two "negotiations" between the resource server and AS/resource owner that I easily imagine at resource registration time: (a) negotiation of what scopes the AS is actually aware of, and (b) negotiation of what services the RS may be able to offer to a future client if certain scopes are denied by the AS. 

The first is not a negotiation in the legal sense but more like a notice on the part of the AS, if it chooses, to say "I don't know anything about healthcare" so don't expect me to compute policy decisions around healthcare-specific vocabulary in the authorization phase 2 of UMA. To improve this, the notion of an AS installing a "healthcare plug-in" to expand its vocabulary is certainly attractive but it is also out of band for the resource registration contract we're discussing.

The second possible negotiation is nicely illustrated in Ken Klingenstein's consent work where the resource owner is dynamically advised or warned by the resource server of the impact of elections made by the resource owner. E.g.: "If you don't check this box, I will not be able to send information to out of state providers." This is not a legal negotiation either as it simply implies that the resource registration HTML form must have some built-in warnings or patient education materials that could require JavaScript or equivalent to trigger. That could be a security problem for the AS but it is not a negotiation.

Therefore, I claim that the simplest practical AS can be generic and dumb and simply display an RS-authored HTML form for the resource owner to make elections at resource registration time. There could be CommonAccord behind the scenes in the process the RS used to author its HTML form, but this is not a negotiation with the RO, and the AS would be unaware of CommonAccord. 

Adrian

On Saturday, November 14, 2015, James Hazard <jh@hazardj.com> wrote:
I think we are talking past one another, but I think it doesn't matter.  

Do you (or any of us) have an example of a consent/authorization/etc. originated by an individual?  I could put it in the system and we could work from there.  A one-way NDA is an example (and collection of some relevant issues), but I agree it is an awkward starting place. 






On Sat, Nov 14, 2015 at 7:57 AM, Adrian Gropper <agropper@healthurl.com> wrote:
Jim,

This does not make sense to me from a personal or an UMA perspective. I get that this is what the researcher wants and if they are the customer, then do what they ask. But this is not about the patient and it's not about _User_ Managed Access. The penultimate election in your example says it all:

"I agree to be contacted again to update my information or to be involved in new research projects:
No
"

UMA, personal AS or institutional AS, is not about consent. UMA is about authorization of each transaction that involves a new requesting party or a new client. 

I'm getting the impression that the information exchange or information release contract is not interesting or complex enough for the CommonAccord demo. It may just be that a simple HTML form is all that's required. 

The hack I propose is designed to demonstrate UMA and facilitate its adoption. The simpler everything else is, the better.

Adrian


On Saturday, November 14, 2015, James Hazard <jh@hazardj.com> wrote:
Adrian, 

Agree that a consent-to-use-my-data case is better, and it fits with a lot of the current activity around CommonAccord.  That includes the genomics machine-readable consents, UMKC data sharing and Mark's consentreceipts.org.  

From my perspective, information about a person (hereinafter, "me") needs:
  • places to store info about me that are under my control (and the places are compatible with one another so that I can manage and get full value from them) 
  • a way to let some others access some parts of my info for some periods of time and some purposes
  • a policy that specifies permissions which can be grokked and tweaked by people and executed by machines
  • a way to pass along those permissions so that the person who has accessed the information (by looking, copying, listening, whatever) can comply.
Your HIE starts from the perspective of "me" and imagines policies which others can adopt if they want to deal with me.  The genomics folks are interested in a similar posing at the group level - a researcher wants to expose the terms of availability of their data set.  To do that, of course, the permissions need to trace back to those given by the donors (principals, subjects).  While the initiator may differ there is structurally no difference:  some set of terms, comprehensible to both parties and to machines, needs to be accepted by both sides of each of the hops in the transfer of information.  As a practical matter, the permissions and limitations have to come from a common source. Hence the standardization work, clause banks, etc. 

Consent, authorization, data sharing agreement, NDA, Creative Commons license all are names given to flavors of a single structure - a text, agreed by parties, that sets permissions, limitations and what-ifs.  The first hop in the chain seems a good starting point for making this better since it is the first, hardest, most common, and most abused.

A goal could be:

1.  Some common resources for these documents (C/A/DSA/NDA/CCL) and the surrounding documents (like the NYPresbyterian brochure explaining the rights).
2.  Some common formats for the records themselves (which can render into the full documents or be subject to a master agreement).
3.  Extensible clause banks of permissions and limitations that can be referenced in the records (and rendered into the documents) AND can be understood by a machine so that there can be automatic matching.  These would need to be remixable and have a way to pass them along but also overridable (in the direction of more limitation) at each hop. 
4.  Automatic matching of conditions via UMA, with a pass-along of the permissions along with the data so that the receiving party on each hop can comply with the conditions imposed on previous hops.
5. A way to do parts or all of this with blockchain for audit, security, automatic execution, further permissions, payments and integration with the rest of your life.

Does this make sense?

As little examples of a consent/authorization/etc records:

The GA4GH consent - 

A group of tissue samples provided from one researcher to another under Materials Transfer Agreements:
(this is a good use case because there is already a substantial infrastructure for sharing - Dazza's kind of master agreement, subscription by the institution, and particular transaction)
One thought is that this package of permissions could be packaged with the actual information (e.g., as a folder of /Doc/... and of /File/....) and accessed or transmitted as such. 

I'm particularly interested in having the machine-readability result from the authoring of the consent form and surrounding documents (CommonAccord), and fitting this in with the rest of the eco-system - regulators, IRBs, funders, etc.  If we can get some of this ecosystem on the same boilerplate page(s), the legal advantages can help drive the tech solution. 

Again, I ask, does this make sense?
 
Jim



On Sat, Nov 14, 2015 at 5:05 AM, Adrian Gropper <agropper@healthurl.com> wrote:
The legal call today had a clear focus at the junction of CommonAccord, blockchain, and UMA. The use-case was negotiation of a Non-Disclosure Agreement between two parties using CommonAccord as a structure for the changes that each of the parties would make as they passed the drafts back and forth. Blockchain was introduced as the non-repudiation mechanism to track the intermediate and final version of the NDA contract.

UMA was not central to the discussion on the legal call today but was tacked on vaguely as the means to control access to the final contract by unspecified parties. It was not clear to me who the Resource Owner would be in the use-case we discussed.

For the FutureCommerce hackathon, I'm hoping to gather a team to hack a personal UMA authorization server. This server, which I'm calling HIE of One http://hieofone.org/ could be linked to the CommonAccord project we discussed today to the extent there was a Resource Owner to associate with the contract being negotiated. At this point, instead of an NDA, the contract being negotiated in HIE of One is a Release of Information policy that establishes what requesting parties and clients can access the protected resource.

An NDA is, in some sense, the opposite of a release of information agreement. An NDA is often mutual and therefore does not have a clear resource owner. This may not be a problem for some applications of UMA but it doesn't seem to work well for a personal authorization server linked to a personal resource.

I'm hoping we could coordinate some of the FutureCommerce hacks over the coming week. Ideally, the CommonAccord hack and the personal AS hack would complement each other around the same type of contract and we could even try to demo some interaction between them.

Please let us know your thoughts and consider joining FutureCommerce http://futurecommerce.civics.com/index.html online Nov 20-22.  Anyone specifically interested in working on the personal AS hack should email me and I will invite you to the GitHub project.

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/


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




--

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/




--

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/