Here's how we're currently summarizing our goal: "solving use cases for empowering traditionally disempowered parties (such as individuals) to "contract and transact" e.g. with parties that traditionally hold greater power (such as companies and large countries)".

It would be great to identify whether there actually is a (sufficient?) power imbalance before we proceed with each use case. Can we do so in our Alice Consents to Health Research use case?

We don't want to go to huge fractal detail in our use cases; otherwise we certainly will run out of time! (I do think our bullet list from today's meeting is a big step forward in identifying what would be productive and useful to do in a use case, though.)

But our goal is not simply to "apply blockchain" to every use case like a band-aid. :-) It's, I think, to identify ways in which the various technologies in the entire orbit might help or hinder the use cases we identify.

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!


On Thu, Jul 28, 2016 at 6:39 PM, John Wunderlich <john@wunderlich.ca> wrote:
The case was chosen, as I recall, because of all the activity in the health space. In other words where there is a potential market. 

John Wunderlich,

Sent frum a mobile device,
Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin




On Thu, Jul 28, 2016 at 6:54 PM -0400, "M AV" <av_m@hotmail.com> wrote:

As for the research consent use case - just listening in, my thought is that perhaps it'd be helpful to winnow the instance down to some simpler subset of the overall challenge - like the MVP (minimal viable product) concept - since lot of the scarce resource of team time seems to be being spent more and more on explaining the rather intricate details of human research consent at the expense of focusing on what a more generalized  linkage with smart contract / blockchain tech can bring "new" to the thing - but that's just me ... :-)

Get Outlook for Android




On Thu, Jul 28, 2016 at 6:33 PM -0400, "j stollman" <stollman.j@gmail.com> wrote:

John,

In the research consent use cases that you reference, I would be interested in learning how this is done today.  Is there a problem with present procedures?

One of the features of blockchains is that they do create immutable records, but they are not the only technology available for doing this.  And even though encryption is used in blockchains, not all blockchains afford the same level of privacy of their underlying data.

I am personally invested in developing blockchain solutions and tools to expand the capabilities of blockchains.  But, I am concerned that we are viewing blockchain as a great tool and now are out to fix everything with it.  But, just as a great hammer isn't likely to be the best choice for unscrewing a bolt, I do not believe that blockchain -- valuable as it is -- is appropriate for every use case that it might have an ability to address.  

Jeff



---------------------------------
Jeff Stollman
stollman.j@gmail.com
1 202.683.8699

Truth never triumphs — its opponents just die out.
Science advances one funeral at a time.
                                    Max Planck

On Thu, Jul 28, 2016 at 2:59 PM, John Wunderlich <john@wunderlich.ca> wrote:
It occurred to me after the call that if I pull back and look I see the following:

1. When the principal investigator has the research plan approved by a Research Ethics Board or REB (Institutional Research Board or IRB in the U.S.) this will include the text of the consent or consents that will be used, such as:
A) Main Consent
B) Optional Consent for Biobanking
C) Optional Consent for Genomics
 Etc....
Each of these consent describe in a general sense the purpose of the research, what will be done with the data and commitments to privacy protection.  In the course of a long drug trial, the consents may be modified or updated as a result of what is being learned in the trial, or issues that arise such as serious adverse events (SAE's)

In both the US and Canada, it is often the case that research will be entered into a clinical trials registry (see http://n2canada.ca/category/resources/clinical-trials-registries/ although I don't think these registries normally include the text of consents.

It seems to me that the Blockchain use case for research consents contains two components:

1. Putting the text or texts of a consent on the chain, cryptographically signed for an immutable record of the investigators' commitments.
2. Recording the consent of participants anonymously on the chain (usually a participant is assigned a study ID number (ideally a nonce) that is used to identify their study data, but not them. When a participant consents to a study, a salted hash of their ID, plus a reference to the particular version of the consent on the blockchain could be entered on the chain to enable them to identify what they gave consent for and hold the investigator or their institution or sponsor accountable.

Does this make sense?

John Wunderlich,

Sent frum a mobile device,
Pleez 4give speling erurz

"...a world of near-total surveillance and endless record-keeping is likely to be one with less liberty, less experimentation, and certainly far less joy..." A. Michael Froomkin




On Thu, Jul 28, 2016 at 2:32 PM -0400, "Eve Maler" <eve.maler@forgerock.com> wrote:

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

Agenda:

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!



This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

_______________________________________________
DG-BSC mailing list
DG-BSC@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-bsc




This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

_______________________________________________
DG-BSC mailing list
DG-BSC@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-bsc