GA4GH Data Use

Minutes and Actions 2021-2022

2017-2018 Minutes

2019-2020 Minutes

Table of Contents

Minutes and Actions 2021-2022

2017-2018 Minutes

2019-2020 Minutes

Meeting Protocols

List of Meetings

2021-05-19

2021-04-07

2021-02-24

2021-01-13

2021-##-## (TEMPLATE)

Meeting Protocols

• Please note that by participating in meetings, attendees agree to adhere to the GA4GH Standards of Professional Conduct.
• Meetings may be recorded for note-taking purposes. Recordings will be deleted within three months of the meeting taking place.
• This meeting is part of the Data Use and Researcher IDs Work Stream.  Minutes for the main Work Stream meetings can be found here.

List of Meetings

2021-05-19

Chairs: Jonathan Lawson (Broad), Melanie Courtot (EMBL-EBI)

Attendees “Name (Affiliation)”: Aina Jene, Asiyah Lin (NHGRI), Dylan Spalding, Emily Boja, Soichi Ogishima, Michele Mattioni, Nancy Mah, Vasiliki Rahimzadeh, Vivian Ota Wang, Katie Vance, Pinar Alper, Andre Paredes, Joe Flores-Toro, Francis Jeanson, Adrian Thorogood, Georg Philip Krog

Minutes:

Issue #111

• Due to GDPR in Europe the DAC (EGA: DATA Access Committee) should validate if the data requester/requesting institution has certain IT-security measures in place.
• Suggest this is important but not something DUO is looking to address and that it is on the side of DACs.Transfer of work to DACReS.

• Vivian: +1 there are people who would be on both committees (DUO and DaCRes)

• Scope of DACReS work is at the procedural level, incorporating issues of the process. Wouldn’t prescribe what security standards would be and how to achieve them. That level of granularity is beyond the scope of DACReS.
• This particular ticket and other terms, we may want to think about what is commonly suggested access agreements, we haven’t defined a group that would make a resource for this. Between use of data and DACReS.
• RDA put in place TRUST principles that apply to infrastructure that hosts data. Could be a starting point to think about.
• Not strong commitment to have this as DUO term, look for feedback from DACReS group and to look at groups that are looking at this.
• Passing it on to the DACReS group; eventually the DACReS/REWS will have guidance for data access and opens the road for deprecating DAC related terms we have.
• Does the GDPR require different IT security measures depending on the level of data security? If so, we need to describe the required IT security measures in a way that is tied to the data by using DUO codes.

• If there are multiple levels, we need multiple terms. Potential for this to get complex. For now we will pause on this.
• Nancy:  I don't think GDPR has a graded level of IT security

Issue #110

• Code for specific access settings. For example, some health data providers may prefer that the data is accessed only within an institutional setting or within a restricted access Trusted Research Environment
• This is a security issue as well, similar as GDPR level requirements. Bundle this with the question to DACReS.

Debrief for DUO Workshop

• Implementers attended as presenters and audience; H3Africa and EGA talked about how they assigned DUO codes to their datasets. 30+ implementers on the call was very engaging.
• Two tickets above came from this workshop.
• There were things that were broader scope: using DUO for biobanking and applying DUO to non controlled access data.
• One implementer offered to help with the Spanish translation; sent an early draft to them and they sent an updated version yesterday. Ask that Spanish speakers can have a check over it. Need to think about versioning and where and how we make these resources available.
• How do we sync the translations, do we bundle them or keep them separately. How could we make sure when an update is made in English, the right translation is made.
• There are procedures for back translations

• This was done for the Japanese translation. For the other ones (German, French) we did them parallel and merged.
• You don’t give original forms and back translations provide more confidence in the translation.

• We should be explicit that the english version is the authoritative one ^[a]
• Challenge around ambiguity, in a new language sometimes terms can be ambiguous in ways they aren’t in English.

• Cultural nuances of words used.

• Speak with Pablo Lapunzina with how to do this technically, and what worked for us, ensure we do back translation process and be explicit that the English is the source version.

• Jonathan to follow up with Aina Jene for the Spanish translation review.

• Georg: Knows of a tool that does translation based on a controlled syntax, they could look at syntax of DUO clauses and see if they fit in with controlled language they already have or they can develop one for that. His software automizes translation and can do version control. You would only need to make an amendment to the source (English) and software would port over in all other languages.

• Vivian: We can add this to the mix but they don’t capture nuances. May need to consider procedure with a combination of this.
• The developer would work with you to ensure the meaning is kept.
• Georg to share the link/contact to this translation service.^[b]

DUO Papers

• DUO reference paper, still waiting to hear back from Cell Genomics.
• The original draft of the paper had a lot of content, going into detail and strategy of implementations. Decided to temporarily remove those and have another paper that will feature all these implementations that folks have already written about. Content is in a new doc, before it is open to editing, we need to understand the format of the paper and know where we are submitting.

• Melanie and Jonathan to speak with the journal to understand formatting and structure. Afterwards, they will share with the group for open comments.

MRCG

• Working with Adrian Thorogood and Tiffany Boughtwood on this document; no significant updates so far but it matches DUO pre-February. Would like to update the terms a bit. There are limited changes so will share with Secretariat and this group soon.
• Implementation guidance, no specific plan to publish this but could be turned into an academic paper and to share insights for the work the group did. If there isn’t enough content, can add this to the implementation paper.
• Will add brief documentation to the new MRCG GitHub repo, where comments and tickets can be submitted. Will be online soon.
• In terms of what we choose to highlight in the MRCG, which historically has not included all DUO terms, only those most hopeful for groups that are looking to share data. Now that there is an NPOA as a modifier, would we want to remove from the guidance the text which would help someone put a POA only term in their consent form. Should we remove POA terms?

• Absence of information or explicit permission about population and ancestry, we need some sort of consent guidance that maps NPOA. Would require volunteers with more expertise to consider what the ethical considerations are.

• We can make an updated version open for comment in GitHub and people can submit tickets there.
• Possibly capturing release note or change log
• Moving forward see if we can publish standalone MRCG paper and if not merge in with implementation one

2021-04-07

Chairs: Jonathan Lawson (Broad), Melanie Courtot (EMBL-EBI)

Attendees “Name (Affiliation)”: Nancy Mah, Soichi Ogishima, Georg, Michele Mattioni, Dylan Spalding, Sarion Bowers, Emily Boja, Justina Chung

Meeting recording (Passcode: tZ=5iXr5)

Minutes:

• Updates to the Machine Readable Consent Guidance, https://drive.google.com/file/d/102_I0_phOGs9YSmPx7It9CSt1sHFJ87C/view

• Updated data use ontology with release in February. Not a lot of significant changes but a few where we clarify non-profit and non-commercial use and what that means, and hierarchy. Looking to bring clarity and translate to MRCG. Working with Adrian Thorogood for this, may bring to IRB lawyers to work on first draft. Looking at ~1 month turnaround.

• DUO Workshop (sign-up form)

• 28 people signed up. Diverse locations
• Looking to work with these projects and define what is unclear in implementing DUO, especially if you already have a consent form and looking to map to it.
• Gabby was conducting UX interviews. A lot of groups didn’t know where or how to start, but once they understood, they felt comfortable moving forward and doing it again. It’s an intuitive product once you are made aware of it. More effort needed in the introduction and user guidance.

• Soichi has already sent feedback to her for GEM-Japan
• Should have an update by the next meeting.
• Members encouraged to share the sign-up form to interested participants

• DUO Paper

• Submitted Feb 25, no news yet.
• Should we start an implementation paper? It would almost be like a reference implementation guide. It would cover scope, who is implementing it, step by step guide, formal examples of how people have done it etc.

• Pinar: +1; would be an interesting paper. In ELIXIR, DUO helps organize human data section (https://rdmkit.elixir-europe.org/human_data.html)
• Where could we submit this?

• Ask Angela to check with Orli for some guidance and if Cell Genomics would be interested.

• Translations

• How do we keep translation in sync and how do we automate processes? Still trying to figure these questions out.

2021-02-24

Chairs: Jonathan Lawson (Broad), Melanie Courtot (EMBL-EBI)

Attendees “Name (Affiliation)”: Vivian OTA WANG (NCI-NIH), Stephanie Dyke, Georg Philip Krog (Signatu AS), Pinar Alper (LCSB/ELIXIR Luxembourg), Francis Jeanson, Sarion Bowers (Sanger), Esther van Enckevort (UMCG), Nancy Mah (FH-IBMT), Asiyah Lin (NIH/NHGRI), Jean Muller (Strasbourg)

Full recording available here. Passcode: 318@#%HQ

Minutes:

DUO paper

• DUO paper almost ready to go, waiting for release to happen so that a screenshot can be updated.
• Anthony Philippakis is submitting a companion paper; it will be submitted to the journal tomorrow. It is a joint submission, we refer to the paper on ours and they refer to the DUO paper in theirs (similar to Passports paper)

• Clarify they are separate and other papers are examples?
• Maybe a statement that says GA4GH doesn't endorse any particular implementation.

• Justina to find an existing blanket statement to indicate for the above.

• No intention to set anyone apart - doesn’t bias anyone.

• When will the release be available? The file is here. Melanie has contacted the developer to push this through.

Governance policy

• Updated policy now available on GitHub.
• Encourage everyone to review
• The essence of policy is that change requests are vetted by the community and that going forward we want to make sure there is a strong consensus before adding new terms and more likely a willingness to deprecate terms not used. Want to move towards concise vocabulary.
• Timing for regular considerations/updates? Specification version dates are available, you don’t have to use the latest published one. We expect requests submitted publicly and discussed on a call, 2 weeks turnaround for rejections of any updates.

• Structured vs unstructured requests: Documentation and communication is in our roadmap, when we do prepare for a release, everyone is aware so we can work with people with any issues/requests before a release.
• Suggest annual basis, so when people go to it they know it isn’t stale and up to date. We depend on people to check the website on their own to check for updates. But if we set up a calendar year of when we look at this, people will know when updates would’ve been made (eg. website when they say “last updated..”)
• Everytime we do release, it is automatically updated here. It will always be the latest version.
• If we’re implementing this out and there are changes, will it glitch the system we are working on? Downstream potential consequences.

• Make versioning clear, refine this more. How can we make this more explicit?

• In GitHub, in the master drop-down, you can see branches and tags. Tags will show versions locked by the DUO team.
• Make visible to community, not everyone will go to GitHub site. Insider vs outsider knowledge.
• Need to think of an update in communications and documentation plan; do we want formal meeting to say this is the DUO as it stands, how do we communicate to the community this is the latest version.
• Could consider a regular release cycle.
• Use semantic versioning to clarify if they are additive or breaking, you only update the major version number of breaking and additive if just adding new terms.
• Create a ticket for the comments above regarding versioning

• Concerns over Github #45 re: GRU-CC:

• Stephanie: GRU-CC (000005) original Consent Code term is not replicable by GRU (0000042) + CC (0000043) - see Github issue #45. GRU (0000042) is for all research and the GRU component of GRU-CC (000005) is only for health/medical/biomedical purposes and other biological research, including the study of population origins or ancestry. Additionally, the -CC component of GRU-CC (000005) is not all clinical care as is CC(00000043), but actually a limited, more narrow permitted use of research data to inform the development of clinical resources.
• They don’t cover same things; big change of scope.
• Melanie: GRU-CC code did not disappear. Obsolete = does not get deleted, will retain access to term. What was agreed in the ticket is that we want GRU and CC not replacing GRU-CC. We would expect if someone sees GRU-CC is obsolete, you can use GRU, or CC modifier, or something else.
• Create new ticket about concerns with:

• Issue #45 GRU-CC moved to obsolete, as it is now replicable by GRU (0000042) + CC (0000043).

• Communication of GitHub resolutions to DUO mailing list and at meetings important to avoid problems discussed above

• Geo locations concerns

• Which resource should we use to represent restrictions to? Eg. ISO country codes.
• Should we promote geo location restrictions? Would this stigmatize communities? See ticket here.

• For us to highlight would be ethical thin ice..
• Datasets that are using this type of restriction and why? Are there use cases?
• Deprecate from DUO?
• Need to be able to specify there is transfer out of EU to set legal basis for transfer (raised by Georg and Pinar). Use cases specific to EU and non-EU. Are there other use cases?

• Not necessarily consent, just to specify the activity (transfer) and not the purpose (data use).

• We may want to source other examples of any existing in other consents
•  

2021-01-13

Chairs: Jonathan Lawson (Broad), Melanie Courtot (EMBL-EBI)

Attendees “Name (Affiliation)”: Tommi Nyrönen (ELIXIR), Jaime Guidry Auvil (NIH), Melanie Courtot (EMBL-EBI), Jonathan Lawson (Broad Institute), Stephanie Dyke (McGill University), Georg Philip Krog (Signatu), Adrian Dyens-Thorogood (University of Luxembourg), Sarion Bowers (Wellcome Sanger), Vanessa Vogel-Farley (University of Michigan), Gregory Rushton (Broad Institute), Sai Lakshmi Subramanian (Seven Bridges), Nancy Mah (FH-IBMT), Hayley Clissold (Wellcome Sanger), Amanjeev Sethi, Francis Jeanson, Justina Chung (GA4GH), Aina Jene (CRG), Pinar Alper (on phone as Appkata), binam (?) , Jamal Nasir, VIvian OTA WANG (NCI-NIH)

Minutes:

• Justina interim manager for DURI - welcome!
• Last call for last comments on https://github.com/EBISPOT/DUO/milestone/2 - tickets have been open for a long time and we will implement.
• Update on paper - under review by Orli @ Cell Genomics. Plan to circulate draft to the group ~ end January
• For the implementation paper, we are asking implementers to help complete the matrix here
• Adrian shared the revised DUO governance document

• discussion that requesting 2 implementations may be too strong. Clarification that there will be discretion/ discussion as needed - the intent is really to show usefulness (even if possibly future) across datasets than request esoteric terms. Adrian will clarify text.

• DUO and GDPR: what question are we trying to answer? Unclear to driver projects what DUO covers or not wrt GDPR.

• Suggestion to reword “is DUO use GDPR compliant” and merge with other 2 questions.
• Georg: GDPR defines use of standards in ISO, maybe of DUO in aiding compliance. That would require that DUO would ensure that following DUO would ensure you would be GDPR compliant. GDPR doesn’t exclude narrow certification scheme - doesn’t to encompass every bit of compliance that GDPR requires -> it could be smaller. Even if DUO described only set of research purposes, as long as those could be validated against GDPR there could be some sort of certification. Should certification be the aim? Instead could be “here is a standard to represent purposes” that can be used when organisation need to show they meet GDPR requirements.
• Georg: some data protection authorities accredit part of solutions eg purposes in different areas eg health. Eg French data protection authority does so. Georg encourages to engage in discussion with european DPAs.
• Adrian/Francis: DUO may help you comply and demonstrate compliance.

2021-##-## (TEMPLATE)

Chairs: Jonathan Lawson (Broad), Melanie Courtot (EMBL-EBI)

Attendees “Name (Affiliation)”: