Just a though – might be well to bear in mind that the blockchain thing in general is presently in its nascient stages and is indeed a coat of many colors, by which I simply mean that use cases are good and necessary scenario speculations but it’s always well to periodically ck to make sure that they’re tethered at ground to something defined  …

In that spirit, here’s a short comment piece I found well-stated:

https://medium.com/@pavelkravchenko/decline-of-blockchain-hype-and-rise-of-a-common-sense-8de5789a794d

From: dg-bsc-bounces@kantarainitiative.org [mailto:dg-bsc-bounces@kantarainitiative.org] On Behalf Of Eve Maler
Sent: Thursday, July 28, 2016 2:32 PM
To: dg-bsc@kantarainitiative.org
Subject: [DG-BSC] Notes from BSC telecon Thursday July 28

http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+Meetings#id-2016-07(July2016)Meetings-ThursdayJuly28

Agenda:

• Work on Alice Consents to Health Research
• Report section assignments and review if time

Attending: Thomas, Eve, Scott, Ann, Andrew, Mark, Kathleen, Jeff, Don, John

Research use case: We looked at the use case text and explored the model data sharing consent form, which has been "accordified" in CmA. This is one of the technologies we're explicating and exploring. In Jim's candidate cast of actors, we're missing a likely clinician (dealing with Alice and her treatment for a particular condition) or investigator (looking into, say, an experimental drug), which two roles might be filled by the same person (say, Dr. Whoever). The data might be collected for research generically, or in a different fork of the data flow, it's collected in the course of a specific treatment that Alice is undergoing.

Is there a fork as well for aggregation of data and then dissemination to multiple research teams, vs. direct data donation to a specific research effort? Could be both.

Our concerns would be that the use case:

• Captures requirements for deidentification
• Captures the different parties to whom it's being shared
• Captures the different intermediaries
• Captures data usage requirements and constraints
• Captures the ethical considerations for the patient (data subject) but also others sharing part of the same genome
• Captures the patient's requirements for comfort around consenting so that they can verify compliance of the other parties more stringently (smart contract implications?)
• Captures cross-cutting jurisdictional regime implications of the patient as a stakeholder (rights vs. property) – affects data usage, compliance, etc.
• Captures granularity and specificity of consent throughout the consent life cycle (UMA and Consent Receipts implications?)

Kathleen has seen ugly lawsuits where, because even deidentified data was unconsented, it had to be destroyed.

We're guessing that some of the above list items will become standard use case "Considerations" items, and some will be use-case-specific "Observations" items.

Technologies we haven't listed yet include UMA and Consent Receipts; they should be added to the report outline.

Eve Maler
ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
ForgeRock Summits and UnSummits are coming to Sydney, London, and Paris!