...
- Grantee and Resource definitions; how to handle role stacking (Grantor can be Resource Subject, RSO can be ASO, etc.) – handle in a generic way? (see this thread)
- (Based on input from Scott D.) RSO - ASO model clauses (original proposal):
- How to parameterize to enable different legal models for handling the granting of "access"?
- How to identify/parameterize to enable exceptions to normal access/non-access? (see decision tree)
- How to handle notification requirements?
Attending: Eve, Ann, Adrian, Jim, Kathleen, Mark
Adrian's idea for an IIW session: UMA and GDPR.
Do our model clauses actually want to be broad enough to serve the use cases for things like the enterprise as a resource owner/Grantor? So far, we do have a definition of Grantor etc. that admits a Legal Person (e.g. an enterprise or government agency or whatever).
HL7's definition of grantor: "An individual who agrees to confer certain rights or authority to a grantee." A grantee is: An individual who accepts certain rights or authority from a grantor." The various ISO and EU standards discuss collection, access, use, and disclosure. Unfortunately, they didn't think of the case where API access is about other HTTP verbs than GET 
, where the client might be putting data for which it's authoritative back into the server, or whatever; in these cases, collection, use, and disclosure could sort of be reversed. This is why "access" so often carries the burden for the other three.
Jim believes: "A goal might be to create text handles for each of the foreseeable circumstances. So, a complete vocabulary seems better to me." So shall we define the full set, then? We would theoretically know when to use which phrase (potential vs. real) in each clause. After all, the "potential Grantee" doesn't have consent, right? Why conflate?
What about carefully staying away from applying a specific legal theory to underlie the agreement (e.g. license)? We've already put out of scope the different agreement life cycle templates; Jim has done a ton of work on this in CommonAccord. (Kathleen is interested to learn about this so she can apply them in status definitions in the HL7 contract work!) Essentially, we think staying away from picking normative legal contexts, including workflows, is still out of scope, so wherever this might "intrude" on our clause text, we'll need to figure out how to parameterize the text.
Next time without fail: Let's focus on the #RSctrl clauses needed (which may be part of the RSO - ASO trust relationship and also part of the RSO - Grantor (Potential Grantor?) relationship). See the Jan 15 notes for four use cases, and also realize that we have to take into account a fifth use case of "requested access outside of normal UMA mechanisms".
We discussed the GA4GH work on "ADA-M"; they're developing what look like model clauses for the sharing of genome data.
2016-04-08
- Our budget request was accepted! Let's work out a timeline
- Work on RSO - ASO model clauses more – can we get to "beta" quality today?
- How are invitations to our April 15 meeting going?
Attending: Eve, Andrew, Ann, Adrian, Mark, Kathleen
Budget request accepted
The Kantara board has asked us for a cash flow timeline. Eve's estimate was that we could develop our requirements by early Q3, say no later than July, and identify a contractor by early-mid Q3, and ideally conclude the project by the end of Q3 (Sep). This gives us a forcing function to have a credible set of beta model text to work with by Q2. We seem to be able to accept this, even though there are some question marks.
AI: Eve: Reach out to our community of "legal eagle" participants to wake up active participation once again.
Realistic first beta review timelines
Is it realistic to invite anyone to our Apr 15 call? Are we ready with text? There are two parts to this: Can external parties attend, and do we have enough text/materials?
Adrian proposes that Kathleen is on the critical path here. Kathleen just wants to run a FHIR pilot based on our clauses! And doesn't see Andrew's use case as incompatible. What's most practical? Kathleen suggests that getting to the point of real clauses is really the most practical. Let's work hard to continue putting our model clauses together, and reassess just before the IIW timeframe as well as think about a June forum for external review.
Model definition and clause work
The FHIR connectathon is in May. She would like to "XMLize" the clauses for that target. What actual language is being executed here (since XML is just the "punctuation", if you will), if FHIR has a place in the code for a Grantor etc.? It sounds like they are using UMA authorization servers to consume standardized policy expressions in XML (if not necessarily XACML) format, and this would map to the Grantor's wishes for sharing. This could come down to a particular set of trust relationships, and the question of whether it splits into "active" policies vs. things like consent receipts.
Our Grantor - RqP (Grantee?) trust relationship already mentions consent receipts, and we've already discussed how CRs need to be part of a workflow that shows the Grantor what it is they're consenting to (or proactively sharing/delegating or whatever, i.e. setting a policy/sharing preference), so we could already be in the ballpark here. FHIR is using its audit logging framework for this workflow.
Adrian had made a generic "NPE Release of Information Form 1" sample form a few months ago, and Kathleen observes that with a few additions this could be something like what FHIR needs. Adrian is intending this to be used by the RS/RSO for setting up phase 1 (that is perhaps a rathole for our purposes for today's agenda; Eve suggests that Adrian and Kathleen discuss offline as appropriate).
Eve shared a slide deck that runs through various design patterns for splitting the technical resource subject and legal Grantee roles. This deck now has some explanation on the first slide about how the technical UMA flow can stay the same, while the trust relationships and legal/contractual backing might vary significantly.
...