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.

 

 

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.