2016-08 (August 2016) Meetings

This page records the Discussion Group's meeting notes for August 2016. We meet Tuesdays for 30 minutes at 7:30am PT / 10:30am ET / 3:30pm UK / 4:30pm CET. We meet Thursdays for 30 minutes at 11am PT / 2pm ET / 7pm UK / 8pm CET. US times are normative during daylight saving time changes. We use Kantara Line A (US +1-805-309-2350, Skype +99051000000481, international options, web interfacemore info, code 4022737) and http://join.me/findthomas for screen sharing. See the DG calendar for our full meeting schedule. Previous meeting minutes are here: July.

Tuesday, August 30

Agenda:

  • Confirm timeline, scope, and approach, or revise in specific
  • Assign action items for report next steps

Attending: Scott S, Thomas, Jeff S, Ann V, Mattisse, Scott D, Thorsten, Jim H, Luk V, Marc, Kathleen, John M, Eve

Congrats to Thomas (and his students) and Adrian on their awards!

In Italy, law has a general structure and then specific cases separately. Ethereum's recent fork required recalculating to a point before the hack (this was in July). Is this a problem for us? Jim comments: DAO demonstrates a number of things - that you need legal framing and that even decentralized protocols depend on communities. Eve notes that many of today's technologies and techniques seem to undermine DLTs and similar in that they centralize to protect them: TTPs, trust frameworks, permissioning, etc. Scott D thinks undermining isn't necessary: e.g., a dairy coop or a partnership could overcome the need for the "poison of centralization" (Eve phrase). Since any realistic IAM system injects this poison today, and any sufficiently "wide-ecosystem" (cross-domain) distributed use case will likely need some element of IAM and/or governance to achieve its goals, can the circle be squared?

What are the techniques that temper the need for centralization-style governance? Can Matisse and Scott D discuss this on the list? We can add them to the report.

Do we need to write several reports? There are several themes here. One is about specific technologies being missing, e.g. (as Jeff S notes) a query language and specific techniques missing (as noted above), and one is about the central tension here. Alternatively, Eve suggests our six-month goal is to write the first broad report about the central tension given the many use cases that want to achieve empowerment.

Thomas, Eric, and Scott D have already been writing a paper called Computational Sovereignty. They can distribute it – there's definitely interest!

There's some support for one report with recommendations for the breakdown of several reports/maybe specs in future. Jim suggests adding analysis to break down "smart contracts" vs. generic blockchain. And there's support for putting a stake in terminology generally.

AI: Eve: Ensure Ann's list contributions get into the minutes more properly.

Thursday, August 25

Agenda/Discussion

  • Reviewing use cases to determine if there are common building blocks amongst themselves
    • i.e Template Smart Contract for consent

Attending: JohnW, Ann Vroom, Jim Hazard, Jeff Stollman, JohnM, Kathleen, Matisse, Marco, Thomas

 

  • Thomas refers to paper at Barclays (one side prose <=> one side code) http://www0.cs.ucl.ac.uk/staff/C.Clack/SCT2016.pdf
    • discussion ensues re: consent, patient, form etc
    • Why/What goes on blockchain and/or recorded in smart contract (assuming BC and SC not necessarily the same)
    • Needs a reference to form of consent 
    • Needs record (publicly anonymous) record of patient agreeing to consent
    • Record of other researchers requesting access so Alice in the loop
    • Forms (consents & questions), Responses from patient, requests for access, ledger contains uuid reference to consent
    • Kathleen and John M. working on this and will work with Common Accord for common representation?
  • Interedger? as term of art for connecting blockchains
  • Options (Ann?):
    • Alice is party to a contract (consent) with a researcher - state of contract entered to blockchain
    • New researcher comes along:
      • Alice can be notified OR
      • New contract updates old contract and new version entered into blockchain

 

Tuesday August 23

Agenda:

  • Completing existing use-cases.

Attending: Matisse, Kathleen, John W., Jim, JohnM, Marc, Jeff,Thomas.

Thomas: Lets complete current-uses cases.  Looking at the patient data sharing there at least 2 cases we could claim. (1) The patient consent is captured on a blockchain (which acts as a simple public notary); (2) Prefabricated contracts for accessing data, using data, sharing results (etc) is represented as a smart contract.  John stated that privacy  of the patient and unlikability are important aspects.  Thomas: this requirements for privacy or anonymity is also true for financial transactions. Kathleen/John agrees.

Jeff: Can SC contain all the info regarding all the possibilities, turn around time, etc. Is it practical, deployable, or even untenable. Currently they use databases etc for this purpose.  Kathleen: Precision Medicine requires precise patient identification. John: we need to evolve slowly into complex cases. Tease out components. John: there is complexity as to how researchers view data and management aspects of studies/trials. Each project has admins, assistants, CROs, org that collect research info. Most orgs have standardized consent forms.  What is we move these into a slightly changed format so that it can be used on a blockchain. This allows the (new) infrastructure to develop gradually. Jim:  such a format is what we (Jim) is working on. Using SC to automate some of the functions. Must work on/off the blockchain. Address complexity thru layering.

John: this is ok, but it doesn't convey the transparency of usage back to the data holder and patient. A "template" of the SC could be used. Kathleen: templates themselves can be analyzed and adjudicated/? John: similarities with Thomas's use case.

Thomas: yes, lots of similarities. We need to tease-out common components and building block.  Kathleen/John: there are 2 usages of blockchain: (a) for recording, and (b) for enforcing. One can live without the other. Incrementally can move forward with one or the other, not both. John: part of the research statement and agreement, it should call out that it has to make use of blockchain and SC in a given way. Transparency addresses through preconditions (e.g. pseudo-identifier) defined elsewhere. We just define the usage/functionality that it provides. Also satisifes clinical obligations wrt patient rights/autonomy. Katheleen: there's an org working on this called "Patient Choice" project. Kathleen will email URL.

Thursday August 18

Agenda:

  • Blockchain subsection: can we fill in draft text?
  • Other technology/technique subsections: common approaches? champions?
  • Approach to mapping use case contents to technology/technique contents?

Attending: Thomas, ScottD, Matisse, Marco, ScottS, Thorsten, Colin, Adam,

Use Cases

 

WEF report. ScottD reports that new group inside WEF has been created called "Future of Digital Economy & Society".

Thomas: Finish the text of the current use-cases so that we can include into the report.  (Thomas explains again the need for the DG to submit a report with recommendation to the Kantara LC).  Colin: part of the purpose of the report is to select a number/strains of use-cases that may warrant carrying forward into a Working Group with a Charter. We report to the LC to indicate how useful the DG has been.

 

Tuesday August 16

Screen share: http://join.me/findthomas

Agenda:

  • Technology subsection candidate: describing and analyzing "blockchain" (Jeff and Eve)
    • Vs. "smart contract"?
  • Use case content mappings to technology content

Attending: Eve, John W, Domenico, Scott S, Thomas, Jeff, Scott D (deeply interested in progress in distributed systems that are reliable), Jim, Andrew, John M, Colin

Looking at Eve's candidate definition of blockchain: The second bullet: The value is transparency, is not privacy per se. Or secrecy per se? Transparency isn't necessarily inconsistent with privacy. Data controllers need to be transparent.

If many of the risks are controlled for by putting all the nodes in the same cloud or the same organizational domain (where "distributed" is defined in a very special way), it's still a blockchain.

There's support for the three bullets at least as a starter definition, along with the "SWOT" subbullets beneath them. Jeff believes that the only requirement for it to be a blockchain is a particular encryption mechanism for the ledger, but we didn't reach (ahem) consensus on that. Let's share the writeups on the list and see if we can form a draft subsection shortly, and then leverage the SWOTs and other analyses to build our understanding of how well the use cases can be served by the technologies and techniques. Eve makes an exhortation for use cases not to assume use of technologies, but to test them for suitability.

Thursday August 11

Screen share: http://join.me/findthomas

Agenda:

  • Consideration:  should we start-off use cases "without blockchains"
  • Continue reviewing uses cases:  Certificate Transparency, Privacy-Preserving Data Sharing, Medial Identity.

Attending:

 

Tuesday August 9

Today's screen share: http://join.me/findscott 

Agenda:

  • Review Certificate Transparency use case
  • Discuss potential use cases
    • Privacy-Preserving Data Sharing on Blockchain P2P Nodes (Thomas)
    • Medical Identity Theft (John W)

Attending: Ann Vroom, John W, Scott S, Jeff S, Matisse, Marc D, Hazard, Kathleen, Don Q, John, Marco

Discussion:

John W shared medical identity theft infographic from inexperts.

Jeff is having some confusion about whether we're using the rigid definition of a use case.  Scott observes that we may have groups or domains with multiple use cases in them.

John added the actor #Edna to the Alice participates in Bob's research study use case.

Scott talks to the new use case, got some vocal support from Jeff for the salience of the example.

Question from John W about Lets Encrypt (https://letsencrypt.org/) - free CA operated by the internet security task force, automated way to issue certificates to websites - do we have connections with that group? 

 

General Wellness Product (John W) is background information for IOT considerations, its FDA guidance on what constitutes a fitness devices as opposed to a medical device. Helpful information on how to articulate the devices.

Thursday August 4

Agenda:

  • Observation: DG is at the one-month mark
  • Can we add something like a "technology SWOT analysis" to Alice participates in Bob's Research Study as a criterion for approving it as complete?
    • Plotting and analyzing aspects of blockchain overall, smart contracts, CmA, other related tech – see the report outline
  • Do we want to categorize use cases/organize them into a taxonomy? Is this helpful for our report purposes?
  • What use cases do we want to take up next week? (Scott as chair pro tem on Tuesday)

Attending: Thomas, Jim, Mattise, Scott, Kathleen, Domenico, John W., Marc, Ann Vroom, Luk, Marco, Andrew.

Would SWOT analysis help us closeup use-cases.  Can we flip the question:  does my use case require a blockchain (with its features, such as consensus algorithm)?

Anne V. asks a definition of blockchains as we understand, and then  see if it fits the use-case.  Marc states if smart-contracts could be used to improve efficiency/automation while leaving out use-cases that don't benefit from it. Kathleen: rule engine running & coming up decisions. Thomas:  blockchain as one-function ledger (e.g. bitcoin mining node) and Ethereum node as highly programmable nodes (smart contracts).  John W:  at IIW one working defintion of block chain is a system with distributed ledger and a leader selection process. Also notes difference between ledger and smart contracts.  PoW systems and Non-PoW system (eg. Stellar). Anne: bimodal description is useful.

Thomas:  does this bimodal view help the use case, such as Alice and consent to research data. Kathleen: the consent model is what the industry understands today. Alice could have a life-threatening situation and she has to consent to her data being accessed.  Policy-enabling vs policy agnostic.

Thomas:  blockchain is used to capture the act of Alice consenting and the hash of the data being released.  So the blockchain acts as a digital notary.

Blockchain empowering Alice is a new aspect in this area.  Kathleen: this is critical in Precision Medicine. Alice still co-owner of her data, and must not be cut out of the loop.  Blockchain can increase transparency.

John:  add 5th actor (Edna).  Edna wants to access Alice's data at the sponsor's location (after Alice's data is accessed and copied to sponsor's org).  

Tuesday August 2

Agenda:

  • Work on "Trust and verification in a health research context" (was: Alice Consents to Health Research) and discuss implications for technologies sections in the report

Attending: Eve, Jeff S, Andrew, Thomas, John W, Matisse, Scott S, Jim, Adam, Domenico, John M, Colin "L"

The new title is a working title. And...now it's Alice participates in Bob's Research Study!

There's a bifurcation of PHI for healthcare and PHI for health research.

The biggest question: Is there a role for the blockchain? The three lightbulbs highlight the particular steps where this comes into play. (Scott suggested to the chat that the lightbulbs in the recent edit can be broken out into individual use cases. As mentioned on the call, the use cases will form an ontology, these would be different instances of “record X on a ledger”, with a different X for each lightbulb.) Thomas notes there is a bit of a crisis of repeatability in research. Could that be addressed with the new technologies somehow? John suspects that this is where putting the protocols (the descriptions of the studies) themselves on the blockchain would be more productive, and this is where his mention of a "predecessor or stereotypical case" of Human Research Consent could encompass that solution. He points to https://clinicaltrials.gov.

John M has written up a use case on his blog that leverages the blockchain for blinded (lightly deidentified) identity, not for the consent per se, in a research context. Jeff comments that if hashing for pseudonymity is being suggested (yes), then the entire suite of technologies that constitute "blockchain" may not be needed.

One theme of blockchain application, therefore, is "identity proving". Another that we started with was "agreement proving" ??

So:

Do we have use case bundles that are related, and can we write them quickly and with their relatedness exposed? (whether that relation is hierarchy, mind map, or whatever) It appears so, yes. 

Does it make sense to think of problems blockchain purports to solve, in specific, as things like "proving identity", "proving of agreement status" (e.g. whether consent has currently been given) – or "proving an event"? (suggested in the chat), and "proving that conditions have been met" (smart contracts)?

Eve will reach out to Bart Suichies' erstwhile colleagues at the Philips Blockchain Lab to see if they have someone interested to join.

There's no doubt that today's notes are incomplete or – gasp! – even wrong in spots. Please correct in followup email.