On 29 Aug 2015, at 12:44, James Hazard <james.g.hazard@gmail.com> wrote:Just now reviewing the discussion at https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles-and-Obligations. It repeatedly surprised me with it's broad and persuasive analytical position of the issues.
Two thoughts:
1. We could work on a taxonomy of legal issues and provisions. The taxonomy could include ideas such as signature, authorization, revocation, ownership, disputes, etc. We already have a lot to work with from the discussion, and can also work backwards from precedent documents. A small way to start would be an outline for ToU or system rules. We could focus on US health records, while keeping an eye on expanding it to non-US, non-health, non-English, etc. Statutory and other "primary" materials could be linked to. We could also link to lists of model and precedent documents. (Something similar was done by some UMKC students in connection with municipal data sharing agreements, sponteneously or at Dazza's suggestion.)
2. It might be simplifying and empowering to generalize the notion of "events" - to treat all events that might need to be legally proved as being effectuated by records in a common format. For swimlanes, each step (lap in the pool?) should generate a text record that renders into a document and is shared among the directly concerned parties. The record would render a document/webpage such as ToU or the NYPH patient consent, or as little as a mere selection or "yes" in the context of a form. The format of the records would be such that they can be added to a log. Each party would have (or have the right to) a log of the interaction.
Purpose Specification - [discussed deeply in this Article 29 WP Opinion Paper ] "The purpose of the collection must be clearly and specifically identified: it must be detailed enough to determine what kind of processing is and is not included within the specified purpose, and to allow that compliance with the law can be assessed and data protection safeguards applied.
Purpose
specification lies at the core of the legal framework established for the
protection of personal data. In order to determine whether data processing
complies with the law, and to establish what data protection safeguards should
be applied, it is a necessary precondition to identify the specific purpose(s)
for which the collection of personal data is required. Purpose specification
thus sets limits on the purposes for which controllers may use the personal
data collected, and also helps establish the necessary data protection
safeguards.
Somewhere early in the interaction (in a ToU or the like, perhaps system-wide or jurisdiction-wide) there could be a stipulation of formal requirements. E.g., for an event to be legally cognizable it must: 1) be in the form of a record "signed" by the party to be charged, 2) each party must "have" a copy ("have" can mean immediately possession or have permanent access to), 3) legal provisions that are knowingly derived from publicly-available provisions must link to the original and be able to show the diff. (In the old days, each party received an original of signed agreements!)
The escrow demo and some of the work Adrian and I did show the notion of laps in swim lanes - (http://www.commonaccord.org/index.php?action=list&file=doc/escrow/). This can be extended to even small interactions such as radio buttons or yes/no dialog boxes.
I have not worked much on logs. In blockchain implementations, the records and logs are (from the perspective of CommonAccord) an application-side implementation issue. The log is necessarily shared on the blockchain and the challenge is to avoid over-circulation of the information (e.g., using sidechains). In non-blockchain, a log could be kept by having each record added to a log as a single JSON-formatted line of text, with some metadata such as a GUID, time and author. The JSON aspect ties in with a discussion on a GitHub issue that I did with Dazza on design of a more modular and generalizable implementation of CommonAccord rendering.
Expecting to be better connected starting on September 2.
_______________________________________________
On 8/28/15 6:35 PM, Dazza Greenwood wrote:
The legal subgroup is reviewing use cases now here:https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Use-Cases,-Roles-and-Obligations
Also, we are walking through some healthcare wrinkles that Adrian contributed, here: https://docs.google.com/document/d/1wygXX8FvHif07KA0P4IocBL-tsUGoXEFDpEwxNLrRh8/edit
Thanks,- Dazza
_ _ _ _ _ _ _ _ _ _ _ _ _ _
| Dazza Greenwood, JD
| CIVICS.com, Founder & Principal
| MIT Media Lab, Visiting Scientist
| Vmail: 617.500.3644
| Email: dazza@CIVICS.com
| Biz: http://CIVICS.com
| MIT: https://law.MIT.edu
| Me: DazzaGreenwood.com
| Twitter: @DazzaGreenwood
| Google+: google.com/+DazzaGreenwood
| LinkedIn: linkedin.com/in/DazzaGreenwood
| GitHub: github.com/DazzaGreenwood/Interface
| Postal: P.O. Box 425845 Cambridge, MA 02142
| _ _ _ _ _ _ _ _ _ _ _ _ _ _
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- @commonaccord
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma