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