July 2016 - DG-BSC - mailman.kantarainitiative.org

IAPP views of blockchain
by John Wunderlich 01 Aug '16

01 Aug '16

The IAPP (International Association of Privacy Professionals) has published a number of small pieces for privacy professionals about blockchain on its web site and newsletters. I've attached a representative sample for your edification Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749 eMail: john(a)wunderlich.ca -- 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.

4 8

Use Case updated
by John Wunderlich 31 Jul '16

31 Jul '16

I've renamed the use case and put in a basic narrative and use case diagram. I've tried to put forward the simplest case. Please review and comment if you have a chance, before I move on and fill in the rest of the use case. http://kantarainitiative.org/confluence/display/BSC/Trust+and+verification+… Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749 eMail: john(a)wunderlich.ca -- 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.

4 9

Re: [DG-BSC] Use Case updated
by j stollman 31 Jul '16

31 Jul '16

John, It is reassuring that we share sensitivity to the issues researchers would face if they had to individualize consents to meet each patient's unique requirements. We appear to part ways (at least for purposes of this discussion) on the best ways to compose and memorialize medical research consents. Regarding consent composition, perhaps, it is best addressed by developing a few model consents that afford different levels of control to data subjects. In this way, review boards might then challenge researchers on why they didn't use the model with the most user control and the researcher would be obliged to justify his selection from among the models. I don't know that allowing subjects full ability to tailor their consent won't raise the objections you cite of sample size and cost. And I don't know that giving subjects such power has much impact on the doctor who recommends participation in the wrong study for the wrong reasons. Regarding memorializing the consents, I could be persuaded that merely giving a subject a copy of a signed consent may be too burdensome on the subject. Storing and tracking the document (in hard copy of digital form) is such a rare event for most subject that they are unlikely to have a good system for doing so that allows for ready retrieval when an issue arises. But I also suspect that adding such a consent to a blockchain may be unnecessarily costly. It could just as easily be stored in a standard database by some independent administrator of such research consents that would operated like a library. The funding for the administrator could come from the same source as funding for a blockchain. I also suspect that giving individuals additional consent opportunities with regard to re-use of research in which they were a subject could dramatically reduce the opportunity to re-use the data. If a large study has 10,000 subjects and the data from it could be used for another study, the new researchers have merely to show that their reuse is consistent with the original consent. If they have to go to each subject to obtain a new, separate consent, the database could well become unusable. Subjects may have new addresses (physical or digital) and tracking them down too costly. I had a similar experience when I wrote a musical several years ago. The entire point of the musical was to re-use existing rock songs that told a story. I assumed that a theater could just pay ASCAP or BMI their licensing fees and be free to have the songs performed in the context of the musical. Not so. Bands can play copyrighted songs under ASCAP and BMI. But a musical requires obtaining unique consent from every publisher. No theater would consider my musical until I first obtained consent from each publisher. I began contacting the publishers. After a few replies such as, "Mr. Morrison needs to know how many seats are in the theater and what is the price per seat," I abandoned the effort. I see individualized consents causing the same problem. I suppose it could be argued that if we can't obtain such individualized consents, perhaps the research is not in the public interest. Perhaps that current practices is tilted too strongly towards the researchers. But I would not want to be the spokesperson representing individualized consents -- even though I am a strong adherent of the rights of the individual. Jef --------------------------------- Jeff Stollman stollman.j(a)gmail.com 1 202.683.8699 Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck On Sat, Jul 30, 2016 at 10:13 PM, John Wunderlich <john(a)wunderlich.ca> wrote: > Jeff; > > I’ll not disagree that at first blush the value add for smart contracts > and blockchain doesn’t leap off the page. You may recall me trying to argue > against a health research/consent use case in the DG. That being said, the > basic use case can be used throughout Kantara - once elaborated and > validated since there is a lot of work in Kantara that could touch health > research. > > I agree with your assessment of how clinical trials and the YES/NO > decision is made. From sitting on REBs I believe that a study sponsor, > especially in an RCT (randomized controlled trial) literally can’t let in > too much variability how subjects participate in a drug trial. It would > essentially add another independent variable and balloon the sample size > and cost requirements. > > But here’s the issue arising out of that that may make this worth > addressing. Public ledgers can be tools for better governance and > transparency to address power imbalances between the information ‘elites’ > and the information ‘masses’. And I don’t there that there is an imbalance > greater that between a patient that has just been told that the 5 year > survival rate for Stage 3 exocrine pancreatic cancer is 3% (ref. here > <http://www.cancer.org/cancer/pancreaticcancer/detailedguide/pancreatic-canc…>) > and the doctor that is offering an ‘experimental treatment’. How meaningful > is consent (which is supposed to be ‘free of coercion’ and ‘informed’) at > this point? The circumstances are inherently coercive. This is not to blame > the study team or the doctor. It is what it is. > > The vast majority, but not all physicians and researchers will make the > best choices they can in what they believe to be the patient’s best > interests. But even then, once consent has been obtained, some researchers > see data as proprietary and something over which the patient has no right > to a say. (After all, do rocks have any rights to seismological data?) > Consents are often written to enable that proprietary view, and some > countries’ laws agree. Research ethics boards are generally self policing, > with some governance, and some lay input. But the fact remains that they > are mainly researchers approving other researchers’ work. Quis custodiet > ipsos custodes? > > If it is the case that a doctor recommends certain studies over others > based on bad medical judgement, or her relationship with the investigators, > or for rewards and recognition (either academic or cash) what tools can a > patient or her estate use? A public ledger could protect patient privacy > and still provide regulators, auditors and investigators something more to > go on that self reports from the investigated. But until such tools are > available, it is hard to advocate for them. > > As an aside I would argue that consent receipts, if developed and > implemented create a whole new potential for consent based big data type > recruitment and data mining (thinking of thinks like some of the studies > that the Apple Health Kit is starting to make possible). These would be > voluntary, so the consent would be real, and real benefits could accrue > from such large scale studies. More robust and accurate wearable hardware > and software could have large implications, but not for drug trials. > > > > > Sincerely, > John Wunderlich > @PrivacyCDN > > Call: +1 (647) 669-4749 > eMail: john(a)wunderlich.ca > > On 30 July 2016 at 16:52, j stollman <stollman.j(a)gmail.com> wrote: > >> John, et al, >> >> I agree that this is a real-world use case. But I am not certain how >> blockchain has much value add. Perhaps I am too rigid in my thinking, but >> I see this as a classic example of a use case that is well served by >> consent consent processes. >> >> If I were conducting a clinical trial, I will need consent from all >> participants. But consent will be on my terms and will be a YES/NO >> decision. Ideally, it would be nice to allow some give and take and allow >> for customized consents for each user. But practically speaking this could >> become a management nightmare and there is likely too much risk in >> violating HIPAA for researchers to tolerate anything beyond a traditional >> consent. Why couldn't this just be stored in a file cabinet. >> >> If, subsequent to the consent, another researcher desires to re-purpose >> data developed in the first clinical trial, the new researcher would have >> to obtain separate consents from the users, unless the original consent >> included consent for using subject data to support other research efforts. >> >> Am I missing something? >> >> If not, what benefit do we expect to get from using the blockchain to >> track this simple logging of consent receipts? >> >> Thank you. >> >> Jeff >> >> >> --------------------------------- >> Jeff Stollman >> stollman.j(a)gmail.com >> 1 202.683.8699 >> >> Truth never triumphs — its opponents just die out. >> Science advances one funeral at a time. >> Max Planck >> >> On Fri, Jul 29, 2016 at 3:45 PM, John Wunderlich <john(a)wunderlich.ca> >> wrote: >> >>> I've renamed the use case and put in a basic narrative and use case >>> diagram. I've tried to put forward the simplest case. Please review and >>> comment if you have a chance, before I move on and fill in the rest of the >>> use case. >>> >>> >>> http://kantarainitiative.org/confluence/display/BSC/Trust+and+verification+… >>> >>> >>> Sincerely, >>> John Wunderlich >>> @PrivacyCDN >>> >>> Call: +1 (647) 669-4749 >>> eMail: john(a)wunderlich.ca >>> >>> >>> 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(a)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. >

1 0

Where blockchain COULD BE used
by Salvatore D'Agostino 29 Jul '16

29 Jul '16

https://www.cbinsights.com/blog/industries-disrupted-blockchain/?utm_source= CB+Insights+Newsletter <https://www.cbinsights.com/blog/industries-disrupted-blockchain/?utm_source =CB+Insights+Newsletter&utm_campaign=ec0d61b746-ThursNL_7_28_2016&utm_medium =email&utm_term=0_9dc0513989-ec0d61b746-86864785> &utm_campaign=ec0d61b746-ThursNL_7_28_2016&utm_medium=email&utm_term=0_9dc05 13989-ec0d61b746-86864785 Salvatore D'Agostino IDmachines LLC 1264 Beacon Street, #5 Brookline, MA 02446 USA http://www.idmachines.com <http://www.idmachines.com/> http://idmachines.blogspot.com <http://idmachines.blogspot.com/> @idmachines +1 617.201.4809 ph +1 617.812.6495 fax

1 0

Notes from BSC telecon Thursday July 28
by Eve Maler 28 Jul '16

28 Jul '16

http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29… Agenda: - Work on Alice Consents to Health Research <http://kantarainitiative.org/confluence/display/BSC/Alice+Consents+to+Healt…> - Report <http://kantarainitiative.org/confluence/display/BSC/Report+from+the+Blockch…> 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 <http://summits.forgerock.com/> *Sydney, London, and Paris!*

5 10

Agenda for BSC telecon Thursday July 28
by Eve Maler 27 Jul '16

27 Jul '16

http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29… We meet *Thursdays* for 30 minutes at 11am PT / 2pm ET / 7pm UK / 8pm CET. We use Kantara Line A (US +1-805-309-2350, Skype +99051000000481, international options <https://www.turbobridge.com/international.html>, web interface <https://panel.turbobridge.com/webcall/>, more info <https://www.turbobridge.com/join.html>, code 4022737) and http://join.me/findthomas for screen sharing. See the DG calendar <http://kantarainitiative.org/confluence/display/BSC/Calendar> for our full meeting schedule. Agenda: - Work on Alice Consents to Health Research <http://kantarainitiative.org/confluence/display/BSC/Alice+Consents+to+Healt…> - Report <http://kantarainitiative.org/confluence/display/BSC/Report+from+the+Blockch…> section assignments and review if time *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 <http://summits.forgerock.com/> *Sydney, London, and Paris!*

1 0

New thoughts for the report: add IAM as a technology
by Eve Maler 26 Jul '16

26 Jul '16

I'm thinking we should add "Identity and access management" as a technology in the report, and then discuss taxonomies a bit within that subsection (and maybe more extensively elsewhere, if they play an extensive role in our recommendations). I have in mind a description of the blockchain technology that differentiates between the (potential) need for identification/authentication/authorization of those who *interact with* it and the use case of putting identity-related information *on* it. (*Jeff S:* If I were to draft V1 of this, would you be willing to review it? I already have some candidate text that's short and hopefully pithy.) And wherever we have a section/subsection that analyzes connections between technologies/techniques, we can perhaps touch on the "self-sovereign identity" solutions that are coming out that use blockchain technology to address user-centric types of identity use cases. If non objections, I can add outline stubs as above so we don't lose the ideas. *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 <http://summits.forgerock.com/> *Sydney, London, and Paris!*

2 1

blockchain is and isn't
by Salvatore D'Agostino 26 Jul '16

26 Jul '16

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

2 1

Notes from BSC telecon July 26
by Eve Maler 26 Jul '16

26 Jul '16

http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29… Agenda: - Review of BSC DG Report outline <http://kantarainitiative.org/confluence/display/BSC/Report+from+the+Blockch…> - Use case <http://kantarainitiative.org/confluence/display/BSC/Use+Cases?src=contextna…> work Attending: Eve, Matisse, Jeff, Scott, Don, Thomas, Jim, Andrew (from the Kantara LC), John, Colin Lurking *Discussing the outline:* We should ensure that we satisfy the needs of an external audience that shares our purpose too. We could, in part, do this by including a review (John: "environmental scan") of other activities attempting to address some of these issues. The world seems to just be entering the trough of disillusionment. We want to achieve empowerment and the "P2P-ness" in a *functional* sense, even if not in a strictly technical sense. It's a good idea to reference the Kantara vision/mission wording. Jeff suggests: Maybe we shouldn't say "P2P" at all in our goal, because it implies a (technical) technique too strongly. We could illustrate the power imbalance instead by talking about "contracts of adhesion" or simply talk about addressing the power imbalance directly (brute force method!). Eve essays a goal: Solve the use cases, with whatever technologies. This may mean not always using a pure blockchain model if that has certain vulnerabilities, or requires a TTP in the mix, or whatever. We could discuss how blockchain has started to be over-applied to solve problems it perhaps wasn't meant for (the root of the trough-of-disillusionment phenomenon!). >From the chat: Technology cannot solve problems that require management and governance . But technology can provide tools to manage and govern. Jim shares this link as a resource <https://docs.google.com/document/d/1AIuACsbe5B4I438r0vS6dS9jZFZUOBh6uJeGxrw…> for helping with the first use case. Next time: Continue with the same agenda. *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 <http://summits.forgerock.com/> *Sydney, London, and Paris!*

1 0

Agenda for BSC telecon July 26
by Eve Maler 25 Jul '16

25 Jul '16

http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29… We meet *Tuesdays* for 30 minutes at 7:30am PT / 10:30am ET / 3:30pm UK / 4:30pm CET. We use Kantara Line A (US +1-805-309-2350, Skype +99051000000481, international options <https://www.turbobridge.com/international.html>, web interface <https://panel.turbobridge.com/webcall/>, more info <https://www.turbobridge.com/join.html>, code 4022737) and http://join.me/findthomas for screen sharing. See the DG calendar <http://kantarainitiative.org/confluence/display/BSC/Calendar> for our full meeting schedule. Agenda: - Review of briefing note outline (to be supplied) - Use case work *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 <http://summits.forgerock.com/> *Sydney, London, and Paris!*

1 1