Re: [DG-BSC] Use Case updated

Ann, While I favor the concept of giving the individual the right to choose, I am not certain that making the individual the owner of a research consent is the right answer. What happens when the researcher needs to verify consent? 1. Will s/he have to contact each subject individual to obtain a verifiable proof of consent? 2. What happens if the subject who had previously given consent changes her/his mind? 3. What happens if the subject changes her/his contact information and the researcher can no longer find them? 4. What happens if the subject dies and there is no trail to a representative of the estate? I seems to me that if the researcher can't be trusted to be the "owner" of the receipt, then it might be a better solution to create an independent administrator to be librarian for such documentation. They could operate something like SAFE Biopharma. Fees to fund the administrator could be raised as a fundamental cost of all research efforts. Your thoughts? Jef --------------------------------- 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 Sat, Jul 30, 2016 at 6:51 PM, M AV wrote:

A couple more thoughts (thank goodness, you-all are doing the heavy lifting J …

I come from a financial context – so, by analogy, seems to me that the unique “asset” in this use case is the Consent Form.

And the “owner” of the Consent Form is the patient.

Following this thinking, the “smart contract” business logic would be:

- Alice has established ownership of her “consent” according to the specific terms that comprise the “Consent Form”

- Thereupon, any other party having a need to “use” Alice’s Consent Form asset would have to obtain, within the blockchain technology framework, Alice’s “counter-signature” to unlock – or mutually activate – the scope of the consent to cover the other’s party’s specified “use” thereof.

- The successful cross-execution of each use would then be entered as a valid new entry in the ongoing state of Alice’s “Consent Asset”

In the scenario, the core new empowerment advantage to Alice is that instead of executing the original Consent Form whereupon that Form is then, in effect, coopted by a series of authorized administrators, record=-keepers and investigators – i.e., “co-opted” in the sense of the original doc simply being copied and filed as necessary throughout the file-keeping systems of the circle of researchers without Alice having specific knowledge of the disbursement of the asset past her original execution – in the smartcontract / blockchain ledger scenario, Alice would be called upon to execute a counter-key transaction each time the consent asset needed to be invoked by a researcher or whomever.

This, of course, would be a rather radical empowerment of Alice – and it might be argued that after executing the “original” Consent Alice wouldn’t want to be bothered with all the subsequent downstream counter-sig’s – but, hey, empowerment has consequences J

Hope this makes some sense as to the model I’m postulating.

Best, ann vroom

*From:* James Hazard [mailto:james.g.hazard@gmail.com] *Sent:* Saturday, July 30, 2016 4:19 PM *To:* John Wunderlich *Cc:* M AV ; dg-bsc@kantarainitiative.org *Subject:* Re: [DG-BSC] Use Case updated

This is great! I'll digest and fork.

Do you have a suggested name for:

i) Reseach Subject Substitute Decision-Maker and

ii) Local Investigator

Is the Local Investigator more or less what I meant by Clinician? Or an additional Role?

On Sat, Jul 30, 2016 at 2:11 PM, John Wunderlich wrote:

To distinguish from other contexts where terms could be confused, perhaps the following (blue for differences, red for deletions):

1. Research Subject

1. Person who is the subject of the Research Data (could be observations, samples, test results, self assessments, etc) and who is presumptively the person that gives or withholds consent

2. The role of SubjectAgent is inappropriate in this context I think

2. Research Subject Substitute Decision Maker

1. Person who, if the Research Subject is incapable of giving consent, acts in the interests of the Research Subject and provides or withholds consent.

3. Consent Recipient (The study sponsor in my use case).

4. Local Investigator (The study team members that have access to the health record, the data subject & de-identifies data but are not providing or responsible for treatment or health services)

5. Clinician

6. Physician

7. Research Data Controller (the entity accountable for the research data - probably the study sponsor)

8. Research Data Custodian (the entity responsible to the Research Data Controller - often times a study sponsor will use a CRO - clinical research organization to do the actual work)

9. Research Data Access Custodian (prepending Research to term already used)

10. Research Data Recipient (prepending Research to term already used)

On Jul 30, 2016, at 12:44, James Hazard wrote:

In line with Ann's comment, I've made a rough list of roles for a Consent. It is mostly self-explanatory. If you mouseover the text you will see the name of each component, hence the naming scheme. Click on source for the structure. Basically, it imagines a Consent being created from a form and a list of participants in roles. The list of roles (with versions) can serve for the life of the relationship, and each document can be made by referencing it.

I experimented with a hash "ID", with privacy preservation in mind. The hash could be used in support of or instead of personal info. The hash is primitive - once I had some rough info for the participants I zipped the list and put the zipped list into IPFS. Each participant has a "ID.Hash" consisting of that hash and their name. As I said, rough.

Based on "Health Research Context", I put the files under "HRC" and only noticed the coincidence afterwards. Any political inferences are your own.

http://source.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/DG-BSC/HRC/Demo/Consent/0.md

On Sat, Jul 30, 2016 at 10:35 AM, M AV wrote:

Great use case write up!

In thinking about it, starts to seem to me that there are actually two things going on in terms of transaction tracking via the smart contract/immutable ledger technology.

First is “Alice”’s consent form – that is a document event like, say a stock ownership certificate, and with regard to that, perhaps the ledger-ing has more to do with accounting for the parties that participate in that contract of consent – for example, if the sponsoring drug company is acquired by another corporate entity there would be a substitution of parties in the chain of participants that would appear in the record as a change event to the original consent contract creation event.

Second is Alice’s data – that, seems to me, is a somewhat entirely different thing insofar as it entails an inventory of objects – e.g, various clinical measurements taken at perhaps various chronological points – that could be variously accessed by various parties at various times in the life and framework of the consent.

I guess I just have an intuition that the first aspect – the consent qua thing – is the more amenable use case; and, certainly, the data use tracking is the more intriguing but is sort of mind-blowing in terms of the complexity of even just defining “data” as a thing for the purposes of an implementation of some sort within the smart contract/ledger technology.

Just some thoughts. J

Best, ann vroom

*From:* dg-bsc-bounces@kantarainitiative.org [mailto: dg-bsc-bounces@kantarainitiative.org] *On Behalf Of *John Wunderlich *Sent:* Friday, July 29, 2016 3:45 PM *To:* dg-bsc@kantarainitiative.org *Subject:* [DG-BSC] Use Case updated

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+i...

Sincerely, John Wunderlich @PrivacyCDN

Call: +1 (647) 669-4749 eMail: john@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@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

--

@commonaccord

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.

--

@commonaccord

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc