[DG-BSC] Ann Vroom Followup toBSC telecon Thursday August 25 2016

Thorsten H. Niebuhr [WedaCon GmbH] tniebuhr at wedacon.net
Sat Aug 27 15:09:40 CDT 2016


Hi All,

Still trying to catch up all the great stuff you all did in the past
weeks, and sorry for not taking part of it due to my vacation!

This comment from Jeff is the one which finally make me step in again:

Question: What is it, which can not be achieved because we do not have a
blockchain (yet) ? In my eyes, the only thing which limits 'the digital
world' is the current lack of (universal) trust.

Assuming we would have such a trustworthy (from all possible angles)
instance right now: Which usecase can NOT be realized with current
technology?


thx,


Thorsten



On 26.08.2016 19:32, j stollman wrote:
> All,
> It's been said that when you are keeping you head and everyone around
> you is losing theirs, maybe you don't understand the situation.
> So I'll allow that, perhaps, I am guilty of missing something
> important here.
>
> I see this consent as an excellent demonstration of an UMA
> application, but I fail to understand the benefits of using
> blockchain.  Any database could track the consents.  And an SQL
> database could perform queries much faster and cheaper.  The only
> justification I can imagine for using blockchain would be if you could
> not find a trustworthy owner for the database.  In this instance,
> using a public blockchain would remove the fear that the database
> owner might be unscrupulous and try to modify the data to some
> advantage.  Other than that, I don't know why it would be beneficial
> to engage a blockchain network to perform this simple record keeping.
>
> So what am I missing?
>
> Thank you.
>
> Jeff
>
>
> ---------------------------------
> Jeff Stollman
> stollman.j at gmail.com <mailto:stollman.j at 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, Aug 26, 2016 at 12:50 PM, M AV <av_m at hotmail.com
> <mailto:av_m at hotmail.com>> wrote:
>
>     Critiques coming in are great, thx – super advantage of
>     cartoon-simple illustrations is that is spoofs out places where
>     there’s fundamental lack of clarity or consensus on the basics of
>     the proposed flow – deep details are eventually necessary, but at
>     the brain-storming use case level a beehive of details can be more
>     obfuscating than illuminative (excuse my mixed metaphors –
>     obviously I’m a “visual” thinker …  so I always kind of push back
>     for a “draw it” explanation and trimming the proffered flow idea
>     down to it’s bare essentials .. J
>
>      
>
>     All that said – I think the concept of Alice co-owning the consent
>     with the researcher(s) is one of the radical ideas here that could
>     be facilitated in a new way by the new BC technology – i.e., the
>     idea that Alice’s consent is an “asset” that she shares with the
>     co-parties to the consent contract and which she therefore
>     thereafter participates actively in vis-à-vis the addition of new
>     co-parties, i.e., researchers using the asset – e.g. Alice’s data –
>
>      
>
>     My knowledge of research consents is not current enough (former
>     JHMI administrator and then health care biz lawyer, but
>     semi-retired now) to know whether a downstream researcher could
>     piggy-back on to an existing consent asset (contract agreement),
>     but I guess as long as we blue-sky use-case-ing we can assume
>     anything arguendo J
>
>      
>
>     Best to all, ann v.
>
>      
>
>     *From:*James Hazard [mailto:james.g.hazard at gmail.com
>     <mailto:james.g.hazard at gmail.com>]
>     *Sent:* Friday, August 26, 2016 12:11 PM
>     *To:* John Moehrke <johnmoehrke at gmail.com
>     <mailto:johnmoehrke at gmail.com>>
>     *Cc:* M AV <av_m at hotmail.com <mailto:av_m at hotmail.com>>;
>     dg-bsc at kantarainitiative.org <mailto:dg-bsc at kantarainitiative.org>
>
>
>     *Subject:* Re: [DG-BSC] Ann Vroom Followup toBSC telecon Thursday
>     August 25 2016
>
>      
>
>     Hi, 
>
>      
>
>     John and I discussed this a bit off channel (some issue re the
>     mailing list), and I suggested that all use cases need to be
>     accommodated.  The one that Ann posed makes sense in many contexts
>     (for instance, I think it is like the use case for the GA4GH's
>     ADAM consents - but giving Alice a direct role). 
>
>      
>
>     So I did a start on John's use case - of Alice offering the same
>     materials - and present a base for negotiation of the conditions
>     of the use, which can then take place as an exchange of records
>     between Alice and Researcher B.  
>
>     http://www.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/DG-BSC/Consent/Use2/01-Data.md
>     <http://www.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/DG-BSC/Consent/Use2/01-Data.md>
>
>      
>
>     Maybe John can correct or round this out.
>
>      
>
>     Jim
>
>       
>
>      
>
>     On Fri, Aug 26, 2016 at 8:33 AM, John Moehrke
>     <johnmoehrke at gmail.com <mailto:johnmoehrke at gmail.com>> wrote:
>
>         I don't think this flow is realistic. he second  researcher
>         (B) would not likely be added to the existing consent, but
>         rather build a new consent.
>
>          
>
>         An alternative flow :
>
>          1. Alice publishing her 'preferences' first, likely
>             advertising specific health attributes to help researchers
>             select. (blockchain publication, likely using Pseudonym)
>          2. The researcher discovering Alice, and determines
>             preferences meet the research terms. (possibly using
>             smart-contracts)
>          3. The researcher approaches Alice with the offer.
>             (blockchain messaging)
>          4. Note at this point, as JohnW diagram shows, there is
>             usually some form of 'negotiation'. This might be simply
>             Alice making selections (web form), or might be an
>             interactive session using technology (Oauth/UMA), human
>             interaction, or smart-contracts. This negotiation phase is
>             to optimize the terms of the consent  (possibly through
>             smart-contract).
>          5. The terms of the interaction are fixed (likely published
>             on blockchain) - possibly in smart-contract)
>          6. The researcher accesses the data (with authorization from
>             blockchain evidence, or other such as UMA)
>
>
>         In this flow, what you have diagrammed as a new researcher (B)
>         is really a new opportunity -- starting at step 2. This would
>         certainly be a new consent.
>
>          
>
>         I realize I might be bias, as this is the scenario that I
>         diagrammed on my blog in May. But I still think it holds up,
>         and would love to see it developed under kantara
>
>           https://healthcaresecprivacy.blogspot.com/2016/05/healthcare-blockchain-big-data.html
>         <https://healthcaresecprivacy.blogspot.com/2016/05/healthcare-blockchain-big-data.html>
>
>          
>
>         John
>
>
>         John Moehrke
>         Principal Engineering Architect: Standards - Interoperability,
>         Privacy, and Security
>         CyberPrivacy – Enabling authorized communications while
>         respecting Privacy
>         M +1 920-564-2067 <tel:%2B1%20920-564-2067>
>         JohnMoehrke at gmail.com <mailto:JohnMoehrke at gmail.com>
>         https://www.linkedin.com/in/johnmoehrke
>         <https://www.linkedin.com/in/johnmoehrke>
>         https://healthcaresecprivacy.blogspot.com
>         <https://healthcaresecprivacy.blogspot.com>
>         "Quis custodiet ipsos custodes?" ("Who watches the watchers?")
>
>          
>
>         On Thu, Aug 25, 2016 at 6:27 PM, James Hazard
>         <james.g.hazard at gmail.com <mailto:james.g.hazard at gmail.com>>
>         wrote:
>
>             Hi, 
>
>              
>
>             Here is a first, rough sketch.  There are five steps in
>             the transaction.  It is structured to anticipate
>             additional requests and grants.  05-AliceGrants, is the
>             last link in the chain and gives an overview of the
>             steps.  You could click on it, then on "Document".  Note
>             that a few nuances have been captured, such as the request
>             being more limited in scope than the full data.
>
>              
>
>             The general principle is that each step in a transaction
>             that needs to be persisted is documented as a record.  The
>             record states particulars and references its context,
>             including the prior step.  
>
>              
>
>             In a production system, each record can be stored under a
>             friendly name, like this, or under a hash.  Records can be
>             stored in a file system versioned with git, like this, or
>             in a database such as IPFS or a blockchain, as needed. 
>
>              
>
>             http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative/DG-BSC/Consent/Use1/
>             <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative/DG-BSC/Consent/Use1/>
>
>                 
>
>              
>
>             On Thu, Aug 25, 2016 at 4:14 PM, M AV <av_m at hotmail.com
>             <mailto:av_m at hotmail.com>> wrote:
>
>                 It’s one .jpeg you should be able to cut and paste
>                 from the email …
>
>                  
>
>                 *From:*James Hazard [mailto:james.g.hazard at gmail.com
>                 <mailto:james.g.hazard at gmail.com>]
>                 *Sent:* Thursday, August 25, 2016 4:13 PM
>                 *To:* M AV <av_m at hotmail.com <mailto:av_m at hotmail.com>>
>                 *Cc:* Eve Maler <eve.maler at forgerock.com
>                 <mailto:eve.maler at forgerock.com>>;
>                 dg-bsc at kantarainitiative.org
>                 <mailto:dg-bsc at kantarainitiative.org>
>                 *Subject:* Re: [DG-BSC] Ann Vroom Followup toBSC
>                 telecon Thursday August 25 2016
>
>                  
>
>                 Excellent!  I'll do a minimal sketch of this flow.
>
>                  
>
>                 On Thu, Aug 25, 2016 at 4:02 PM, M AV
>                 <av_m at hotmail.com <mailto:av_m at hotmail.com>> wrote:
>
>                     Hi – in reference to this afternoon’s conf call,
>                     here’s my super-simplified version of the flow I
>                     described:
>
>
>                     _______________________________________________
>                     DG-BSC mailing list
>                     DG-BSC at kantarainitiative.org
>                     <mailto:DG-BSC at kantarainitiative.org>
>                     http://kantarainitiative.org/mailman/listinfo/dg-bsc
>                     <http://kantarainitiative.org/mailman/listinfo/dg-bsc>
>
>
>
>                  
>
>                 -- 
>
>                 @commonaccord
>
>
>
>              
>
>             -- 
>
>             @commonaccord
>
>
>             _______________________________________________
>             DG-BSC mailing list
>             DG-BSC at kantarainitiative.org
>             <mailto:DG-BSC at kantarainitiative.org>
>             http://kantarainitiative.org/mailman/listinfo/dg-bsc
>             <http://kantarainitiative.org/mailman/listinfo/dg-bsc>
>
>          
>
>
>
>      
>
>     -- 
>
>     @commonaccord
>
>
>     _______________________________________________
>     DG-BSC mailing list
>     DG-BSC at kantarainitiative.org <mailto:DG-BSC at kantarainitiative.org>
>     http://kantarainitiative.org/mailman/listinfo/dg-bsc
>     <http://kantarainitiative.org/mailman/listinfo/dg-bsc>
>
>
>
>
> _______________________________________________
> DG-BSC mailing list
> DG-BSC at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/dg-bsc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20160827/58615069/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 26119 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20160827/58615069/attachment-0001.jpe>


More information about the DG-BSC mailing list