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.
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. ☺ 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<mailto: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.
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 <av_m@hotmail.com> 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
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 <james.g.hazard@gmail.com> 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 <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 <av_m@hotmail.com <mailto:av_m@hotmail.com>> 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> [mailto: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 <mailto: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... <http://kantarainitiative.org/confluence/display/BSC/Trust+and+verification+in+a+health+research+context>
Sincerely, John Wunderlich @PrivacyCDN
Call: +1 (647) 669-4749 <tel:%2B1%20%28647%29%20669-4749> eMail: john@wunderlich.ca <mailto: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 <mailto:DG-BSC@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/dg-bsc <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.
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 <john@wunderlich.ca> 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 <james.g.hazard@gmail.com> 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.
On Sat, Jul 30, 2016 at 10:35 AM, M AV <av_m@hotmail.com> 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
A couple more thoughts (thank goodness, you-all are doing the heavy lifting ☺ … 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 ☺ 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 <john@wunderlich.ca> Cc: M AV <av_m@hotmail.com>; 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 <john@wunderlich.ca<mailto:john@wunderlich.ca>> 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 <james.g.hazard@gmail.com<mailto:james.g.hazard@gmail.com>> 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 <av_m@hotmail.com<mailto:av_m@hotmail.com>> 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. ☺ Best, ann vroom From: dg-bsc-bounces@kantarainitiative.org<mailto:dg-bsc-bounces@kantarainitiative.org> [mailto: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<mailto: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<tel:%2B1%20%28647%29%20669-4749> eMail: john@wunderlich.ca<mailto: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<mailto: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
Ann - I share your analysis. I think that UMA and friends are probably more important to achieving that than "blockchains" (here used in its technical meaning), though the energy of "blochchain" (here used in its loose sense) may drive the transition. My guess is that fiduciaries will hold the info (banks seem best positioned though perhaps not the most agile). Fiduciaries can rely on reputation (and its more muscular forms - regulation and law suits) to enforce consensus against other fiduciaries, so lighter-weight, privacy-preserving technologies can be used (IPFS, Interledger, git, etc.). John - I have integrated (or in any event attempt to integrate) your comments. I added an Investigator into the model, and otherwise did the changes as a patch - http://source.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/DG-BSC/HRC/Demo/Consent/v01-JW.md Still rough. Ready for more. On Sat, Jul 30, 2016 at 6:51 PM, M AV <av_m@hotmail.com> 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 <john@wunderlich.ca> *Cc:* M AV <av_m@hotmail.com>; 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 <john@wunderlich.ca> 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 <james.g.hazard@gmail.com> 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.
On Sat, Jul 30, 2016 at 10:35 AM, M AV <av_m@hotmail.com> 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
-- @commonaccord
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 <av_m@hotmail.com> 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 <john@wunderlich.ca> *Cc:* M AV <av_m@hotmail.com>; 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 <john@wunderlich.ca> 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 <james.g.hazard@gmail.com> 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.
On Sat, Jul 30, 2016 at 10:35 AM, M AV <av_m@hotmail.com> 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
Jim; 1. Substitute Decision Maker is a named role in the legislation here, but is also a good brute force definition of the role itself. So Research Subject Substitute Decision Maker is the minimal effective definition of the role, at least in my world. The title could be reduced to Substitute Decision Maker or an equivalent phrase. I avoid the word agent because a) it is used so many different ways that it begs description, and b) there is a health privacy specific definition for ‘agent’ of a ‘health information custodian’ here. 2. Local Investigator, using your phrasing, would “Person directly providing or supervision treatment or advice related to this *Study *as opposed to the *Consent*. As a Clinician, it appears to presuppose that the primary purpose of their role is care and treatment of the patient. The Local Investigator (who might be dual hatted as the Clinician) has a primary role responsibility to the integrity of the study. To be clear, if the requirements of the roles conflict, patient safety wins and no-one disputes that. Nonetheless the roles have different orientations. PS. More on Study v Consent: The study is being done in the interests of, and at the behest of the Research Data Controller. That could be a local person doing a chart review seeking a publication or degree, an academic/government cohort study for the health system or, as is the case here, a multinational drug company seeking ROI on an investment. The study is being done in the controller’s interest. The consent is an attempt to allow the subject some power in the relationship, so it’s the closest artefact that we have to an expression of their interest. It’s a weak reed in that sense, and hopefully recording the consent and the data transfer in an accessible log may go a little farther down the path of redressing that power imbalance. Sincerely, John Wunderlich @PrivacyCDN Call: +1 (647) 669-4749 eMail: john@wunderlich.ca On 30 July 2016 at 16:19, James Hazard <james.g.hazard@gmail.com> wrote:
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 <john@wunderlich.ca> 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 <james.g.hazard@gmail.com> 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.
On Sat, Jul 30, 2016 at 10:35 AM, M AV <av_m@hotmail.com> 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
-- 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.
John - (semi-inline comments) I did a patch with your comment on the role of the Local Investigator - as I understood it - http://source.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/DG-BSC/HRC/Demo/Consent/v02-JW.md
1. Substitute Decision Maker No problem with a context-specific name such as "Research Subject Substitute Decision Maker." The name works by inheritance, so can be used for our form, and changed for any fork.
I avoid the word agent because a) it is used so many different ways that it begs description, and b) there is a health privacy specific definition for ‘agent’ of a ‘health information custodian’ here. "Agent" is a word that we will have to come to grips with, though we can finesse it when it is inconvenient. In law it is inescapable - a fundamental idea, across both common law and civil law systems. Whatever one calls the relationship in a particular context (e.g., partner, employee, trustee, guardian, officer, subsidiary, even spouse) the concept of "agency" looms and informs. Contrary to some of what has been said, "agency" does not have a precise, fixed meaning, and any definition will be wrong in some contexts. That's why there are codification efforts and why agreements often address it, shaping, disclaiming, etc. I understand that the term "agent" carries negative freight in medical contexts, so we can avoid it or paper it over. But medical work intersects with institutions and life, so agency is part of the context. My preference in architecting a base to medical research consents (and everything else) is to see them in a context of < medical consents < consents < agreements < receipts < signatures. This ties in with discussion of payments, fintech, blockchain, which is also about management of receipts and signatures. It also ties in with discussion of "law", which suffers from silo-ed thinking.
2. Local Investigator, using your phrasing, would “Person directly providing or supervision treatment or advice related to this *Study *as opposed to the *Consent*. I've taken a shot at translating this to a patch.
The consent is an attempt to allow the subject some power in the relationship, so it’s the closest artefact that we have to an expression of their interest. My guess is that contextualizing individual consents in the flow of consents and agreements can make a big difference. There are a lot of paradigms - class action law suits are the most legal, but wisdom of the crowd, collective action, open source are more general. GDPR is a hammer
collectively held by a powerful constituency that is determined to act. And the Kantara community has enabling technologies, so the hammer can hit nails.
On Sat, Jul 30, 2016 at 9:40 PM, John Wunderlich <john@wunderlich.ca> wrote:
Jim;
1. Substitute Decision Maker is a named role in the legislation here, but is also a good brute force definition of the role itself. So Research Subject Substitute Decision Maker is the minimal effective definition of the role, at least in my world. The title could be reduced to Substitute Decision Maker or an equivalent phrase. I avoid the word agent because a) it is used so many different ways that it begs description, and b) there is a health privacy specific definition for ‘agent’ of a ‘health information custodian’ here.
2. Local Investigator, using your phrasing, would “Person directly providing or supervision treatment or advice related to this *Study *as opposed to the *Consent*. As a Clinician, it appears to presuppose that the primary purpose of their role is care and treatment of the patient. The Local Investigator (who might be dual hatted as the Clinician) has a primary role responsibility to the integrity of the study. To be clear, if the requirements of the roles conflict, patient safety wins and no-one disputes that. Nonetheless the roles have different orientations.
PS. More on Study v Consent: The study is being done in the interests of, and at the behest of the Research Data Controller. That could be a local person doing a chart review seeking a publication or degree, an academic/government cohort study for the health system or, as is the case here, a multinational drug company seeking ROI on an investment. The study is being done in the controller’s interest. The consent is an attempt to allow the subject some power in the relationship, so it’s the closest artefact that we have to an expression of their interest. It’s a weak reed in that sense, and hopefully recording the consent and the data transfer in an accessible log may go a little farther down the path of redressing that power imbalance.
Sincerely, John Wunderlich @PrivacyCDN
Call: +1 (647) 669-4749 eMail: john@wunderlich.ca
On 30 July 2016 at 16:19, James Hazard <james.g.hazard@gmail.com> wrote:
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 <john@wunderlich.ca> 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 <james.g.hazard@gmail.com> 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.
On Sat, Jul 30, 2016 at 10:35 AM, M AV <av_m@hotmail.com> 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
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
participants (4)
-
j stollman -
James Hazard -
John Wunderlich -
M AV