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

James Hazard james.g.hazard at gmail.com
Fri Aug 26 11:10:38 CDT 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

Maybe John can correct or round this out.

Jim


On Fri, Aug 26, 2016 at 8:33 AM, John Moehrke <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
>
> John
>
> John Moehrke
> Principal Engineering Architect: Standards - Interoperability, Privacy,
> and Security
> CyberPrivacy – Enabling authorized communications while respecting Privacy
> M +1 920-564-2067
> JohnMoehrke at gmail.com
> https://www.linkedin.com/in/johnmoehrke
> 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>
> 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/Ka
>> ntaraInitiative/DG-BSC/Consent/Use1/
>>
>>
>> On Thu, Aug 25, 2016 at 4:14 PM, M AV <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]
>>> *Sent:* Thursday, August 25, 2016 4:13 PM
>>> *To:* M AV <av_m at hotmail.com>
>>> *Cc:* Eve Maler <eve.maler at forgerock.com>; 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> 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
>>> http://kantarainitiative.org/mailman/listinfo/dg-bsc
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> @commonaccord
>>>
>>
>>
>>
>> --
>> @commonaccord
>>
>> _______________________________________________
>> DG-BSC mailing list
>> DG-BSC at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/dg-bsc
>>
>>
>


-- 
@commonaccord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20160826/691b6075/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 57216 bytes
Desc: not available
URL: <http://kantarainitiative.org/pipermail/dg-bsc/attachments/20160826/691b6075/attachment-0001.jpg>


More information about the DG-BSC mailing list