Commit ea56b80a authored by taco@waag.org's avatar taco@waag.org
Browse files

details stefano

parent b59a85fd
Title: Geneconsent - Dynamic Informed Consent in a genetic Datacommons
Title: First steps towards a Biocommons
Author: Taco van Dijk
# *Geneconsent* - Dynamic Informed Consent in a genetic Datacommons
# First steps towards a Biocommons
## Introduction
This article is about what we learned during the development of the GeneConsent prototype that might apply for future Datacommons projects at Waag.
The GeneConsent prototype interactively demonstrates [Dynamic Informed Consent](https://waag.org/en/article/waag-dutch-design-week-2020-donor-codicil-your-data) in the context of genetic data. We tried to bite our teeth on a very specific use case about eye melanoma research. To illustrate the complexity of what we were dealing with, the following pictures show many of the things that happen with our data just in our eye melanoma case;
The GeneConsent prototype interactively demonstrates a flavour of [Dynamic Informed Consent](https://waag.org/en/article/waag-dutch-design-week-2020-donor-codicil-your-data) in the context of genetic data. We worked on a very specific use case about eye melanoma research. To illustrate the complexity of what we were dealing with, the following pictures show many of the things that happen with our data just in our eye melanoma case;
<img src="eye_melanoma_1.png" alt="drawing" width="300" style="display:block;margin-left: auto;margin-right:auto;"/>
......@@ -15,11 +15,11 @@ The GeneConsent prototype interactively demonstrates [Dynamic Informed Consent](
<img src="eye_melanoma_2.png" alt="drawing" width="500" style="display:block;margin-left: auto;margin-right:auto;"/>
2\. The donor sends a bio sample (genetic material) to the Researcher, and fills out a form with phenotypical information (things like gender, age etc) that are needed to conduct the research. The researcher is repsonsible for persisting this sensitive data.
2\. The donor sends a bio sample (genetic material) to the Researcher, and fills out a form with phenotypical information (things like gender, age etc) that are needed to conduct the research. The researcher is responsible for saving and guarding this sensitive data.
<img src="eye_melanoma_3.png" alt="drawing" width="500" style="display:block;margin-left: auto;margin-right:auto;"/>
3\. The researcher send a bio sample to a third party lab that conducts the genetic sequencing. For this it stores the bio sample in a bio vault (think refrigerator). It conducts the sequencing and the result is binary array data. A copy of this file is returned to the Researcher.
3\. The researcher sends a bio sample to a third party lab that conducts the genetic sequencing. For this it stores the bio sample in a bio vault (think refrigerator). It conducts the sequencing and the result is binary array data. A copy of this file is returned to the Researcher.
<img src="eye_melanoma_4.png" alt="drawing" width="500" style="display:block;margin-left: auto;margin-right:auto;"/>
......@@ -49,14 +49,14 @@ I changed my mental model to view 'data ownership' along the following heuristic
## Dynamic informed consent
The Geneconsent prototype is a demonstration of a system that tries to facilitate Dynamic Informed Consent, but since this pretty young, how do we understand the idea after doing this project?
The Geneconsent prototype is a demonstration of a system that tries to facilitate Dynamic-informed consent, but since this is pretty young, how do we understand the idea after doing this project?
Clearly 'dynamic informed consent' is just 'informed consent' with the word dynamic put in front of it. But before we go to that word, we first need to understand informed consent.
The [iConsent guidelines](https://i-consentproject.eu/project-guidelines-now-available/) provides a great checklist about informed consent in a clinical context like our use case in Genecoop;
<img src="Screenshot2022-04-04at153239.png" alt="drawing" width="450" style="display:block;margin-left: auto;margin-right:auto;"/>
To paraphrase the checklist, it seems wise to view informed consent as a co-creation process where the consent procedure is designed together with a group of people that are representative of the people who need to understand everything involved to an agree where the consent can be considered informed. We think that in the case of a data commons the 'I' in the acronym also means being complete and clear about what the consequences of a consent mean in terms data storage, access, handling, sharing and so forth.
To paraphrase the checklist, it seems wise to view informed consent as a co-creation process where the consent procedure is designed together with a group of people that are representative of the people who need to understand everything involved to a degree where the consent can be considered informed. We think that in the case of a data commons the 'I' in the acronym also means being complete and clear about what the consequences of a consent mean in terms of data storage, access, handling, sharing and so forth.
Now that we have a better understanding of informed consent we can continue unpacking. With 'dynamic' we mean a mechanism that enables responsible sharing and reuse of data where the people who are subject of that data are kept in the loop. Researchers can look for data that was already collected in earlier studies, but a mechanism always provides a recurring informed consent when appropriate.
......@@ -104,10 +104,10 @@ Verifiable Data Registry is a term that comes from [Verifiable Credentials](http
<img src="vc_drawing.png" alt="drawing" width="400" style="float:left"/>
To frame above picture in the case of our demonstrator. The consent service is the Issuer that issues a credential (on behalf of the donor) that contains the exact information that was seen by the donor giving consent, but in a machine readable way. The researcher that originally sent the invitation can put this credential as the Holder in his wallet. With this credential the researcher can ask for permission to the Verifier (a separate data vault) to access or write data according to the terms set in the agreement. The data vault can check with the consent service to validate the claims made in the agreement.
In the case of our demonstrator, the consent service is the Issuer that issues a credential (on behalf of the donor) that contains the exact information that was seen by the donor giving consent, but in a machine readable way. The researcher that originally sent the invitation can put this credential as the Holder in his wallet. With this credential the researcher can ask for permission to the Verifier (a separate data vault) to access or write data according to the terms set in the agreement. The data vault can check with the consent service to validate the claims made in the agreement.
The question came up during research, why use VC and not [IRMA](https://irma.app/docs/what-is-irma/) / [Attribute based credentials](https://privacybydesign.foundation/irma-explanation/#why) in this case? Although very similar, attribute based credentials are a specific flavour of verifiable credentials where you can get access without giving up your entire identity. For example; I as the Holder can proof with the 18+ credential (Issued by the city) to the Store owner (Verifier) that i'm old enough to buy a bottle of alcohol. So you protect the privacy of the Holder by selectively disclosing only the attributes needed for the interaction.
The question came up during research, why use VC and not [IRMA](https://irma.app/docs/what-is-irma/) / [Attribute based credentials](https://privacybydesign.foundation/irma-explanation/#why) in this case? Although very similar, attribute based credentials are a specific flavour of verifiable credentials where you can get access without giving up your entire identity. For example; I as the Holder can prove with the 18+ credential (Issued by the city) to the Store owner (Verifier) that i'm old enough to buy a bottle of alcohol. So you protect the privacy of the Holder by selectively disclosing only the attributes needed for the interaction.
In our case the Holder is the researcher, we don't necessarily need to protect their privacy in this case, it's the other way around, we want complete verifiable information about the researcher, it's mainly the donor whose privacy we want to protect. So in this case we felt Verifiable Credentials were more appropriate.
......@@ -155,7 +155,7 @@ Each signed agreement will appear in the 'Answered' list of the researcher, who
<img src="Screenshot2022-04-08at113524.png" alt="run analysis" width="500" style="display:block;margin-left: auto;margin-right:auto;"/>
And since the agreement is in the form of a verfiable credential, the agreement is machine readable, ready to be used in a SSI context. So also outside of the consent service the researcher can present this verifiable credential in order to proof having been given consent for the particular access operation(s) as agreed upon in the verifiable credential.
And since the agreement is in the form of a verfiable credential, the agreement is machine readable, ready to be used in a SSI context. So also outside of the consent service the researcher can present this verifiable credential in order to prove having been given consent for the particular access operation(s) as agreed upon in the verifiable credential.
<img src="Screenshot2022-04-08at113810.png" alt="credential" width="500" style="display:block;margin-left: auto;margin-right:auto;"/>
......@@ -173,16 +173,16 @@ For our demonstrator we investigated sawtooth since integrations were being deve
<img src="Screenshot2022-04-08at115923.png" alt="apiroom" width="500" style="display:block;margin-left: auto;margin-right:auto;"/>
But in the end we just settled on postgres for logging for the time being. In future development we would also like to investigate further into [immudb](https://immudb.io), which has matured since.
But in the end we just settled on our relational database for logging for the time being. In future development we would also like to investigate further into [immudb](https://immudb.io), which has matured since.
## Do we really want this level of control?
A question that came up during the research is, why try to control and register everything at all? You can't protect the data with it anyway, once you share data it's no longer under your control, it's free. And while yes this is true, it's hard to prove from an audit log that someone broke your trust and did something that wasn't agreed. But you can turn around the burden of proof, where data handling parties are asked to proof that they rightfully received access to the data according to some agreement under consent. We think an audit log can help with that. Also we think that clear and verifiable agreements leave less room for negligence, mistakes and misunderstandings, thereby increasing trust between parties.
A question that came up during the research is, why try to control and register everything at all? You can't protect the data with it anyway, once you share data it's no longer under your control, it's free. And while yes this is true, it's hard to prove from an audit log that someone broke your trust and did something that wasn't agreed. But you can turn around the burden of proof, where data handling parties are asked to prove that they rightfully received access to the data according to some agreement under consent. We think an audit log can help with that. Also we think that clear and verifiable agreements leave less room for negligence, mistakes and misunderstandings, thereby increasing trust between parties.
## Future challenges
Although we think it's very nice that the complete information that is presented to the donor is represented in the credential, we still need to do more on the side of the recommended co-creation steps to see if the information transfer during the consent procedure is sufficient. I-Consent seems to provide great tools that we want to dive in to, the first one on my list being the 'teach-back' method.
Although we think it is very nice that the complete information that is presented to the donor is represented in the credential, we still need to do more on the side of the recommended co-creation steps to see if the information transfer during the consent procedure is sufficient. I-Consent seems to provide great tools that we want to dive in to, the first one on my list being the 'teach-back' method.
As mentioned earlier the end goal is to create a distributed network of datasources where all parties involved can responsibly share, create, find and reuse according to FAIR principles.
The demonstrator doesn't yet show any facilities for finding or discovering (new) data. But we do have ideas about this that we want to develop further. We want to design and develop a decentralized distributed catalog using semantic web technology similar to what we did with the Verifiable Credentials for the consent. This way the data can stay in all it's different shapes and forms and places, but it is necessary to syndicate uniform metadata about everything that is available from these sources.
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment