I am concerned that there may be an important misunderstanding about the
power of blockchain in a large scale deployment with regards to query
capability.
It is easy to add transactions of all kinds to the blockchain. It is
harder to query the blockchain efficiently to get information out. The
blockchain does store data, but it is not a database. It does not directly
support indexed fields that make queries efficient and scalable. With
crypto-currencies such as Bitcoin, all transactions are for anonymous,
fungible, virtual assets (e.g., Bitcoins). But once the transactions
become explicit, unique, assets (e.g., various identity attributes or
consent receipts unique to particular websites or transactions), it becomes
necessary to find individual needles in the haystack. And the latency for
such searches degrades rapidly as the blockchain grows larger.
Because scalability and performance are merely assumed and not explicitly
specified in our discussions, I wanted to point out that just because
something can be added to a blockchain does not imply that it will be
scalable and provide adequate performance. To assume this could lead to a
lot of churn.
Thank you.
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 Wed, Jul 13, 2016 at 6:50 PM, James Hazard
On the theme of Patient Consents, I put one of the documents that John suggested into modular format. The organization of the document follows the original, with meaningful names for the various sections based on my hunches. The names for roles are not yet meaningful, just placeholders.
Click "Document"
On Tue, Jul 12, 2016 at 11:23 AM, Eve Maler
wrote: http://kantarainitiative.org/confluence/display/BSC/2016-07+%28July+2016%29+...
Attending: Thomas, Eve, Jim, Scott S, Don, Marc, Philippe, Thorsten, Ann, John W
The May 23-24 event at MIT, variously called *Digital Contracts, Identities, and Blockchain* and *Digital Identities, Contracts, and Blockchain*, had some notes as output. Here are relevant links:
- Technical and Future Infrastructure track notes https://docs.google.com/a/forgerock.com/document/d/14KD-KA-XPKKvuSfNx4E5B2Zf... - Business track notes https://docs.google.com/document/d/1fNjd25h_Ne4HUedn-vKkfNP73TKZAG-PM_K7Qf6u... - Healthcare use cases track notes https://docs.google.com/document/d/1nGTZHq7Q_51tu46jcivLLlS-1vTKXr9z_JcyntBY... - IBM Open Blockchain white paper https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md - Article https://medium.com/enspiral-tales/bootstrapping-a-bossless-organisation-in-3... on bootstrapping a bosses organization - Screenshot https://slack-files.com/T02DW4GQE-F1BEJRL2G-7421d194f1 from Bart's presentation comparing "smart" and "legal" contracts (did his whole presentation get posted?) - CommonAccord intro presentation https://docs.google.com/presentation/d/1LqdDjo41PlXBUj3l84gUVQI4H8GH04mvavHj... - CommonAccord site http://www.commonaccord.org/ - CommonAccord Slack team invitation https://cmacc-slack-add.herokuapp.com/
For a candidate use case, Jim proposes: Patient consent, in a context of 3-4 countries – e.g., including France, Germany. Leverage the GA4GH (Global Alliance for Genomics and Health) and genetic research. Jim has been discussing this use case with Bart Suiches of Philips Blockchain Lab. Would this be about storing consents? The GA4GH folks have a committee that created a model data sharing consent form http://www.commonaccord.org/index.php?action=doc&file=Wx/org/genomicsandhealth/REWG/Demo/Roberta_Robinson_US in CommonAccord. There's capacity for it to be signed.
Would the Consent Receipts work be able to handle a machine-readable representation? It might need to be extended. This would be a good use case for extensibility for that spec.
Culture might be the biggest barrier around consent – IRBs and equivalents would have trouble conceiving of consent as anything but a one-way door. John notes that there are six different ways to get approval to process data, and only one of them is consent. John recommends narrowing down this as a use case a bit, since it involves research and IRBs and such and takes it out of the full health regulatory environment (at least in the Canadian system). This is really a "health research" use case more than a "healthcare" use case, as it stands.
*AI:* John to share research consent templates with Jim/the group.
On Thursday, Scott will present a sample use case template into which we can fill use case content. Everybody should take the opportunity to get familiar with the linked material above, and start to think about their own use cases they'd like to collect.
*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!*
_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
-- @commonaccord
_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc