DURI Strategic Roadmap 2022/2023

Brainstorming and Planning Document

Goal

Define the deliverables that DURI will develop and disseminate starting in 2022.

Contribution Guidelines

1. Please use the designated template below to propose new ideas for the 2022/2023 DURI Roadmap.
2. It is ok to add ideas that are not fully fleshed out. The purpose of this document is to brainstorm and iterate on ideas. We welcome and encourage you to add any proposals/topics that come to mind.
3. If you would like to make comments/suggestions to the text of an already proposed deliverable, please do so in suggestion mode (this mode is available via the drop-down in the top right corner - click the pencil. Please DO NOT write over the proposal or other suggestions/comments.
4. If you would like to declare your interest in participating in a proposed topic/deliverable, please add your name to the “+1” list.

-----------------------------------------------------------------------------------------------------

Template (copy and paste as needed)

Proposed Deliverable Name/Topic: <Add name/topic here>

Standard:

Proposed By: <Add your name here>

Proposal based on which discussions: <Plenary, connect, Work Stream discussions, Driver Project input?>

Collaborating Workstreams:

Driver Projects:

Has a use case been identified (detail below in description) Y/N?

Description: <Please describe the proposed deliverable/topic to explore. For example, what are the gaps in this space? Why is this deliverable needed?>

+1: <If you are not the proposer and you support this deliverable, please add your name here>

--------------------------------------------------------------------------------------------------------------

Document Contents

Goal

Contribution Guidelines

Template (copy and paste as needed)

Proposed Deliverable Name/Topic: <Add name/topic here>

General Thoughts for DURI 2022

New Proposals

DUO Proposals

Proposed Deliverable Name/Topic: Shortened Description Column for DUO

Proposed Deliverable Name/Topic: Common clauses for Data use/Data Access Agreements

Proposed Deliverable Name/Topic: Imaging Data Codes

Proposed Deliverable Name/Topic: Data access request approval by Data Use profile (rather than individual datasets)

Proposed Deliverable Name/Topic: Standard Data use agreement/Data use consent/DAA

Proposed Deliverable Name/Topic: DUO for non human non controlled access datasets and/or samples

Proposed Deliverable Name/Topic: DUO for non-controlled access datasets (benefit sharing, per Danny Park)

Proposed Deliverable Name/Topic: Capacity to automate share of data based on multiple DUO codes to be stored and considered per individual, rather than per dataset.

MRCG Proposals

Proposed Deliverable Name/Topic: Clarifying and Updating MRCG

Passports Proposals

Proposed Deliverable Name/Topic: Collecting detailed Passports use cases and implementers requirements

Proposed Deliverable Name/Topic: Passports v1.2

Proposed Deliverable Name/Topic: Passports v2.0

Proposed Deliverable Name/Topic:  Passports v1.2 and v2.0 communication workshop

Proposed Deliverable Name/Topic: Additional Passports Implementations

Proposed Deliverable Name/Topic: DUO Passports connector

Cross DURI sub-group Proposals

Proposed Deliverable Name/Topic: DURI Gap analysis

Proposed Deliverable Name/Topic: Integrating DURI standards with other standards organizations/obtaining certification from other standards organizations

Proposed Deliverable Name/Topic: Improving Documentation

Previous 2020 Roadmap Deliverables (completed and incomplete)

Passports

DUO

MRCG

General Thoughts for DURI 2022

We would like to ask the question “How do we think about implementations across the whole landscape of GA4GH including Work Streams and Driver Projects?”.

Can we visualize current implementations across that landscape, with each implementation across the pathway per driver project.

It would not work to conduct a gap analysis by each Work Stream without knowing what the implementer is doing with any other Work Stream or standard.

Could we instead conduct a gap analysis per implementer, across the lifecycle that GA4GH defines and identify where the missing parts/pieces are?

Then, we can then more easily identify if we are are facilitating anything and ensure that we don’t produce standards that no one uses.

Aim to produce a matrix of implementers as columns and standards as rows, then identify gaps by column or row and what is the same?

This could lead to talking to implementers and asking why are you not using this standard and why?

New Proposals

1. DUO Proposals

Proposed Deliverable Name/Topic: Shortened Description Column for DUO

Standard: DUO

Proposed By: Jonathan Lawson

Proposal based on which discussions: Specific use case discussions

Collaborating Workstreams:

Driver Projects: Australian Genomics, Google

Has a use case been identified (detail below in description) Y/N? Yes

Description: shorthand definition for UI purposes. We have clinical use cases, millions of patients and calls connected across multiple countries and accessing their own medical records. DUO codes could be a way to give control to a patient to donate their data to science, we need short codes that are coherent enough for people to understand and be able to process this on their mobile device for example. More details here: https://github.com/EBISPOT/DUO/issues/112 

+1: <If you are not the proposer and you support this deliverable, please add your name here>

Proposed Deliverable Name/Topic: Common clauses for Data use/Data Access Agreements

Standard: DUO

Proposed By: Jonathan Lawson

Proposal based on which discussions: Work Stream Discussions

Collaborating Workstreams: REWS

Driver Projects:

Has a use case been identified (detail below in description) Y/N? Yes

Description: Use case: Broad Institute negotiating own touch points in data access agreements.

+1: <If you are not the proposer and you support this deliverable, please add your name here>

Proposed Deliverable Name/Topic: Sample Submission Codes

Standard: DUO

Proposed By: Jonathan Lawson

Proposal based on which discussions: Work Stream Discussions

Collaborating Workstreams:

Driver Projects:

Has a use case been identified (detail below in description) Y/N? Yes

Description: Developing a way to standardise the way a repository accepts data, stores data and allows it to be searched, how do we get DUO attached to those? We have seen instances already where Institutes have already adapted DUO codes to incoming samples so that the whole process can be streamlined and standardised. The use case specifically is Biobanks using DUO codes to describe use permissions on samples. Is that appropriate? Do we need a separate ontology for samples given a sample can be depleted but data cannot. Therefore this would involve adding some guidance around this process, considering the balance between individual’s data rights and the public’s benefit being a litigative issue in the US.

Use case: biobanks who have reached out asking questions about DUO but we also know PMs with biobanks in order to deposit samples at biobanks already started using DUO to describe use permissions on samples. Is that appropriate? Should DUO need more terms, separate ontology for samples?

+1: Alice Mann, Melanie Courtot

Proposed Deliverable Name/Topic: Imaging Data Codes

Standard: DUO

Proposed By: Jonathan Lawson

Proposal based on which discussions: Work Stream Discussions

Collaborating Workstreams:

Driver Projects:

Has a use case been identified (detail below in description) Y/N? Yes

Description: Adapting DUO for standardizing the way imaging data is managed

+1: Alice Mann

Proposed Deliverable Name/Topic: Data access request approval by Data Use profile (rather than individual datasets)

Standard: DUO

Proposed By: Jonathan Lawson

Proposal based on which discussions: Work Stream Discussions

Collaborating Workstreams: REWS

Driver Projects: Wellcome Sanger Institute?

Has a use case been identified (detail below in description) Y/N? Yes (Sanger, Sarion?)

Description: 

+1: Alice Mann

Proposed Deliverable Name/Topic: Standard Data use agreement/Data use consent/DAA^[a]

Standard: DUO

Proposed By: Jonathan Lawson

Proposal based on which discussions: Work Stream Discussions

Collaborating Workstreams: 

Driver Projects:

Has a use case been identified (detail below in description) Y/N?

Description: 

+1: <If you are not the proposer and you support this deliverable, please add your name here>

Proposed Deliverable Name/Topic: DUO for non human non controlled access datasets and/or samples^[b]

Standard: DUO

Proposed By: Melanie Courtot

Proposal based on which discussions: Work Stream Discussions

Collaborating Workstreams: REWS

Driver Projects:

Has a use case been identified (detail below in description) Y/N?

Description: Several use cases from Chris Hunter and Danny Park about using DUO in different contexts

+1: <If you are not the proposer and you support this deliverable, please add your name here>

jlawson@broadinstitute.orgshould we add https://duos.broadinstitute.org/data_sharing_language_tool?

Proposed Deliverable Name/Topic: DUO for non-controlled access datasets (benefit sharing, per Danny Park)

Standard: DUO

Proposed By: 

Proposal based on which discussions: Work Stream Discussions

Collaborating Workstreams: 

Driver Projects:

Has a use case been identified (detail below in description) Y/N?

Description: 

+1: <If you are not the proposer and you support this deliverable, please add your name here>

Proposed Deliverable Name/Topic: Capacity to automate share of data based on multiple DUO codes to be stored and considered per individual, rather than per dataset.

Standard: DUO

Proposed By: Andrew Patterson, Kylie Davies.

Proposal based on which discussions: NAGIM Prototypers (Australia)

Collaborating Workstreams: 

Driver Projects: AGHA

Has a use case been identified (detail below in description) Y/N?

Description: Is it possible to store DUO codes alongside a patient record (multiple if needed) and share virtual datasets with individual records selected and deselected according to consent? As part of NAGIM prototyping exercise in Australia this discussion point was raised and explored with a simple (non-func) prototype developed by Dr Andrew Patterson for ease of understanding.

+1: <If you are not the proposer and you support this deliverable, please add your name here>

2. MRCG Proposals

Proposed Deliverable Name/Topic: Clarifying and Updating MRCG

Standard: MRCG

Proposed By: Jonathan Lawson

Proposal based on which discussions: Work Stream Discussions

Collaborating Workstreams: REWS

Driver Projects:

Has a use case been identified (detail below in description) Y/N?

Description: Does this standard now sit in REWS or DURI? ^[c][d]Update documentation and add information. MC proposes to host MRCG under GH repository and have shared access.

+1: Alice Mann, Melanie Courtot

3. Passports Proposals

Proposed Deliverable Name/Topic: Collecting detailed Passports use cases and implementers requirements

Standard: Passports

Proposed By: Alice Mann

Proposal based on which discussions: Work Stream Discussions

Collaborating Workstreams: 

Driver Projects:

Has a use case been identified (detail below in description) Y/N? NA

Description: In working on Passports v1.2 it was discussed that having a record of detailed use cases should be the starting point for the development of standards. This will enable us to assess requirements and deliver a solution based on solving those requirements. We could engage with DPs and implementers to obtain detailed use cases. This has been started but we could share these more widely, and also add more detail, for example adding schemas of flow in each use cases.

Use cases already collected are detailed here.

+1: Kylie Davies<If you are not the proposer and you support this deliverable, please add your name here>

Proposed Deliverable Name/Topic: Passports v1.2

Standard: Passports

Proposed By: Passports Technical working group as detailed in these minutes 

Proposal based on which discussions: Feedback on DRS + Passports integration in the FASP groups, identifying some ambiguity in Passports v1.0 specification and ensuring interoperability between two slightly variable implementations/use cases at NIH and ELIXIR.

Collaborating Workstreams: Data Security

Driver Projects: ELIXIR, NIH, Australian Genomics, DNAStack

Has a use case been identified (detail below in description) Y/N? Yes use cases are identified here

Description: Passports version 1.2 will add Token Exchange endpoint for releasing all Passport Visas in a signed token separated from other personal information.

+1: <If you are not the proposer and you support this deliverable, please add your name here>

Proposed Deliverable Name/Topic: Passports v2.0

Standard: Passports

Proposed By: Passports Technical working group as detailed in these minutes 

Proposal based on which discussions: Feedback on DRS + Passports integration in the FASP groups, identifying some ambiguity in Passports v1.0 specification and ensuring interoperability between two slightly variable implementations/use cases at NIH and ELIXIR

Collaborating Workstreams: Data Security

Driver Projects: ELIXIR, NIH, Australian Genomics, DNAStack

Has a use case been identified (detail below in description) Y/N? Yes use cases are identified here

Description: Passports version 2.0 will define work-order token with limited permissions for computational workflows

+1: <If you are not the proposer and you support this deliverable, please add your name here>

Proposed Deliverable Name/Topic:  Passports v1.2 communication workshops

Standard: Passports

Proposed By: Alice Mann, Susan Fairley

Proposal based on which discussions: Work Stream, Implementer and secretariat discussions

Collaborating Workstreams: Data Security

Driver Projects:

Has a use case been identified (detail below in description) Y/N?

Description: Many people have already expressed an interest in implementing passports and are waiting for the progress on v1.2 and v2.0. We need to communicate this out to wider teams to ensure that the direction works for their use cases.

I propose a workshop or possibly two workshops. These could happen at April 2022 connect, where we summarise the progress on Passports v1.2 but also by giving enough context as to what motivated this change and the migration story. We can then explain the technical direction, along with a comparison of how this differs from v1.0.

We can also ask Driver Projects to present their use cases, perhaps in a second workshop to ensure we have time to collect their thoughts on the proposed direction of Passports v1.2.

Then we should hold a similar workshop on v2.0 because the new product approval process, which v2.0 will need to go through will require collaboration and communication of new standards or major changes.

+1: <If you are not the proposer and you support this deliverable, please add your name here>

Proposed Deliverable Name/Topic: Additional Passports Implementations

Standard: Passports

Proposed By: Tommi Nyrönen

Proposal based on which discussions: Work Stream Discussions

Collaborating Workstreams: 

Driver Projects:

Has a use case been identified (detail below in description) Y/N?

Description: Once we have identified the direction of the new Passports versions (see above for v1.2 and v2.0), we could aim to support further implementations of Passports (at the same time as collecting use cases for informing future version development). This could form outreach, building on an initial survey that was sent to Driver Projects summarized here. We could extend this externally, out of GA4GH and then plan how to support interested groups to implement Passports.  

4. Cross DURI sub-group Proposals

Proposed Deliverable Name/Topic: DURI Gap analysis

Standard: All

Proposed By: Jaime Guidry Auvril  

Proposal based on which discussions: Work Stream Discussions

Collaborating Workstreams: 

Driver Projects:

Has a use case been identified (detail below in description) Y/N?

Description: We would have some mature standards and some still evolving but all central to GA4GH’s strategic goals. To understand better what the future directions could be for these standards but also what new standards DURI could propose, we would like to conduct a gap analysis of the space that DURI operates in. This would involve creating a matrix, perhaps of functionality of each standard and those implementers who are interested in this/using this particular functionality. This could identify areas that are not addressed by DURI standards also.

+1: <If you are not the proposer and you support this deliverable, please add your name here>

Proposed Deliverable Name/Topic: Integrating DURI standards with other standards organizations/obtaining certification from other standards organizations

Standard: Passports

Proposed By: Tommi Nyronen

Proposal based on which discussions: Work Stream Discussions

Collaborating Workstreams: 

Driver Projects:

Has a use case been identified (detail below in description) Y/N?

Description: IEEE or ISO certification of DUO or Passports could be explored.

+1: <If you are not the proposer and you support this deliverable, please add your name here>

Proposed Deliverable Name/Topic: Improving Documentation

Standard: cross-Standards

Proposed By: Alice Mann

Proposal based on which discussions: Work Stream Discussions

Collaborating Workstreams: 

Driver Projects:

Has a use case been identified (detail below in description) Y/N?

Description: this has been mentioned in various discussions. GA4GH will have technical writing support for this but it may be something we want to define specifically and our requirements here, which would ultimately add implementation.

+1: <If you are not the proposer and you support this deliverable, please add your name here>

Previous 2020 Roadmap Deliverables (completed and incomplete)

Passports

DUO

MRCG