Product Approval Questionnaire

Emerging (information) technologies have broader implications to society that developers, scientists and practitioners alike must build proactively into product design. The purpose of this questionnaire is to provide an overview of the technical deliverable (e.g. standard, API etc.) making its way through the Global Alliance for Genomics and Health (GA4GH)  product development process. Additionally, it is the starting point for identifying, and devising strategies to address security, regulatory and ethical issues that may be present at both the initial proposal and final deliverable. This should be completed in collaboration/partnership with specified members of the Regulatory and Ethics Work Stream (REWS) and the Data Security Work Stream (DSWS). A report should be produced that highlights any identified concerns (differentiating between ‘action points’ and ‘considerations’) and what will be done/has been done to alleviate them.

You should complete the questionnaire within 4-6 weeks prior to the planned proposal. ‘Product Information’ and Section 1 should be undertaken 4-6 weeks prior to planned proposal approval and a report relating to Section 2 should be provided 4-6 weeks prior to planned final approval.

Your answers to this questionnaire will be reviewed within 2 weeks. The Security section will be assessed by the identified DSWS reviewer and the Regulatory and Ethics sections will be assessed by REWS representatives.

Completing this questionnaire is the responsibility of the Work Stream and/or Working Group Lead(s) developing the product. However, it is strongly recommended that you schedule a meeting with the DSWS and the REWS members specified above to go through the following questions together. Failure to organise this meeting may result in delays to the product development process due to asynchronous communication.

Security Contact: [security reviewer]:

Tom Connor

Jaime Delgado

Regulatory and Ethics Contact: rews-coordinator@ga4gh.org 

Section 1: Product Proposal

This section should be completed within 4-6 weeks prior to planned approval vote at the product proposal stage to allow for sufficient time for changes to be made).^[1] Please complete ALL of the following sections: ‘Product Information’ (including ‘Data Use’), ‘Security Review’ and ‘Regulatory and Ethics Review’ (including ‘Equity, Diversity and Inclusion’).

Where issues are identified in the process of completing the questionnaire you should describe proactive strategies in your answers that you will take to ensure these are resolved. Some of the questions may not apply to your product - please confer with the security and regulatory and ethics representatives to identify these.

Please remember to track these in the tracking spreadsheet which will be required prior to final approval of the deliverable. Action Points’ refer to issues that must be addressed, whereas ‘Considerations’ are suggested changes that require acknowledgement, but not necessarily change.

Tracking Spreadsheet URL: Experiments-Metadata_Tracking Feedback from Product Approval Questionnaire

Arranging a meeting between the DSWS and REWS contacts provided above will help you in answering the following questions.

1.1 Product Information: 

Please use this section to provide information about your product before moving onto the specific security, regulatory and ethical parts of this questionnaire. This covers general information and data use (all of which will help inform the later sections).  

1. Work Stream name: Discovery

2. Product name: Experiments Metadata Checklist

3. Name(s) of product development leads (point(s) of contact): David Bujold, Peter Woollard

4. Link to Steering Committee proposal presentation:
   This is the original presentation to the steering committee when the study group became officialized: https://docs.google.com/presentation/d/11_ecDykGcvKSN0rgbsaSnnQ1HQEHqMgkj3WapY6YD9M/edit

5. Timeline of Product Completion:

Please indicate any specific milestones planned in the product development process if there are planned steps towards the final product:

Milestone 1: Landscape assessment completed - A survey of existing Experiments Metadata schemas used by Driver Projects and external resources was carried out during the initial phase of the Study Group, including a dedicated scoping session.

✅ Status: Completed in the first 18 months of the group.

Milestone 2: Development and refinement of the proposed specification - A draft properties dictionary has been developed, informed by stakeholder needs and community input. Iterative feedback was gathered through discussions across GA4GH Work Streams and Driver Projects.

✅ Status: Completed; the Experiments Metadata Checklist version 1, including Core and Identifier Properties, is complete, and  is now entering the formal Product Approval process.

Future Plans, upon Product Approval:

Milestone 3: Schema implementation and alignment - Implementation of the schema structure is underway, with alignment to existing GA4GH frameworks and methods proposed in the DaMaSC study group.^[a]

🔄 Status: In progress; timing dependent on DaMaSC group outputs, with ongoing coordination.

Milestone 4: Public Comment and broader implementer engagement - Following internal review, the specification will be opened for Public Comment. Outreach to early implementers is planned to gather adoption feedback and support pilot use cases.

📅 Target Date: Q3 2025

Beyond: Future extensions to the schema are anticipated to support additional experiment types such as array-based assays and proteomics. These will be informed by emerging needs and further community contributions.

6. Product Type:

Identification of product may help the reviewers ascertain what parts of the questionnaire may, or may not be relevant/applicable. 

        Category: Technical Specification

• API
• Data Model or Ontology
• Protocol
• File Format

Category: Policy Framework

• Policy Framework

Category: Resource

• Guide
• Technical Toolkit
• Ongoing Project

See Product Roadmap Taxonomy-Strategic Roadmap 2020for descriptions of these types.

7. Purpose of the product:

Please describe the intended purpose of this product in lay terms.

Metadata describing -omics experiments is crucial to make sense of results made available to the community. For instance, a CRAM document provides results of a sequencing experiment, but one needs to understand whether the data is from a whole genome sequencing experiment, RNA-Seq, ATAC-Seq, etc. Here we're aiming to establish a minimal checklist to characterise -omics datasets. The goal is not to organise full recipes to make an experiment reproducible, but rather to provide enough information to understand what the experiment is about.

This study group has engaged multiple Driver Projects and external initiatives to understand 1) their needs as it relates to experiments metadata and 2) existing work/standards that they have been using to address those needs. From this process, it is clear that while there are multiple existing standards, they do not have enough reach to facilitate interoperability. It is also evident that the development of a completely new metadata checklist is not what is needed from GA4GH. With this in mind, our study group would like to build/improve upon existing work being done at the ENA while engaging other genomics data initiatives such as CanDIG, IHEC/EpiShare, H3Africa, IGVF, FAIRtracks, etc. to incorporate elements that encapsulate a larger, multi-projects representative pool of needs. The aim would be to develop the ENA checklist with an international lens and engage groups with existing standards, who have agreed to adopt the final product, in the development process.

In the first phase, we aim to recommend an organised list (a checklist) of properties that need to be captured by high throughput sequencing methods. It shall be making use of relevant ontologies as much as possible, over sets of controlled vocabulary. To simplify the scope, we will initially focus only on -Seq experiments, and leave out other methods such as genotyping arrays. Usage

Next, by contributing to and following output from the DaMaSC study group, we will organise the identified properties following proposed schemas and specifications. This will ensure that this study group’s output is extensible to adapt to the needs of particular projects, and experimental methods that have not yet been covered.

8. Use Cases:

Please provide a list of use cases you can see this product being used for. Include a list of requirements if applicable -- what problem does the product solve? How does it solve that problem? Providing this evidence is a requirement for the product to continue through the development and review process and be approved at the Steering Committee.

The objectives pursued by the study group are the following:

• Improve the understanding of available data. Typically, genomic data files contain very little information about the experiment that generated the results, often resulting in some information being stored in file names and paths. More structured organisations will have their own method of storing that information, but analysing data from multiple providers can still be a challenge because of the differences in what’s being captured, and how that metadata is captured and structured. Proposing a standard that is backed by multiple stakeholders within GA4GH’s driver projects can help at that level.
  

• Improve the discovery of genomic experiments. A standardised way of organising the properties and ontologies for genomic experiments means it becomes easier to implement search tools that can communicate across multiple databases.
  

• Help new initiatives to better capture their experiments metadata, by providing guidelines on the right way to do so.
  

• Provide a dictionary of experiment properties to be supported by other GA4GH standards. Standardising a set of properties to describe experiments will enable other GA4GH standards to build over. For example, a Beacon API search could allow one to identify datasets available in a network that match the desired experimental conditions. (e.g. I’m only interested in bulk RNA-Seq datasets run on mRNA), and one could think of an extension to Phenopackets that could list experiments being conducted on a biosample.
  

• Obtain details on potential experimental biases that may characterise a dataset. A whole genome sequencing raw dataset is being made available online. A researcher wants to know which instrument was used to generate it, knowing that each instrument and sequencing techniques have their own biases that may affect results.

Various Driver Projects and other organisations have expressed needs at this level:

• The International Human Epigenome Consortium (IHEC), supported by the EpiShare Driver Project, is composed of multiple initiatives across the globe that produce reference epigenomes, in other words, biological samples that are characterised across multiple epigenetic assays. In order to release a “gold standard” dataset that includes data from all member groups, significant efforts had to be put in place to curate the metadata about the experiments. That’s because it’s not sufficient to label, for instance, a dataset as being generated by bulk RNA-Seq. Other information such as the molecule being used, the library preparation strategy and other information are crucial to understand the observed results from the different labs. (Are we targeting total RNA? Long non-coding RNA? Messenger RNA?). As an additional example, if a data provider makes ChIP-Seq datasets available, more details need to be provided to make sense of the data, answering questions such as “Which antibody was used in the immunoprecipitation reaction?”.
  

• The CanDIG Driver Project in Canada supports the Marathon of Hope Cancer Centre Network (MoHCCN) by developing a federated platform for sharing data across collaborators in Canadian research teams and beyond. Member research groups, affiliated to a hospital in the network, will generate genomic and transcriptomic data to be shared amongst them, and to other research teams applying for access. CanDIG is building a data discovery tool to search available experiments across the federation. With data being generated by different sequencing centres across the country, having a standardised set of experimental metadata fields will allow us to more consistently ingest and store MOHCCN data. Following that, it makes it easier to build search mechanisms within CanDIG to discover the data from all nodes.

• The Impact of Genomic Variation on Function (IGVF) Consortium is an international project that intends to develop a framework for systematically understanding the effects of genomic variation on genome function and how these effects shape phenotypes. The Data Administrative Coordination Center (DACC) is tasked with development of the data model that would allow representation of various types of assays and samples guided by the FAIR principles. Interoperability and collaboration with other consortia (GREGoR, ClinGen, CAVA, HPRC) is important, and in order to facilitate this collaboration a common minimal data model representing experiments is desired.

• The H3Africa Driver Project is a consortium of research projects that have collected demographic, phenotype and genotype data for thousands of participants across Africa to study several different diseases. H3ABioNet works with the H3Africa projects to submit their data to the public repositories, such as the EGA. H3ABioNet has developed the H3Africa Data and Biospecimen Catalogue for the public to search metadata about the datasets and biospecimens and then request access via the DBAC. The metadata includes information about the projects/studies as well as about the participants and biospecimens and data that has been generated (genotype, WGS, RNASeq, etc). They’re looking to identify relevant data models and map data elements to those, and determine how to represent the data in a way that’s compatible with other large scale efforts. This is also to ensure that potential data users can easily identify for which and how many samples specific omics data are available for access.

• Aligning metadata standards in the sequencing experiment domain, would particularly help interoperability (aspect of FAIR). The European Nucleotide Archive (ENA) is currently improving the coverage and depth of the sequencing experiment metadata and collaborative work with GA4GH would be a mutual benefit.

• ENA has also had some engagement with the other INSDC partners (NCBI-GenBank and DDBJ), EGA and also the Genome Standards Consortium(GSC).  Talking with industry e.g. pharma, LIMS suppliers and even data harmonisers, there was some interest in what the public domain can propose: as there seems to be no standout standard. So overall this is a serendipitously well timed opportunity.

• The metadata needs to cover the gamut of experiment types from environmental (e.g. metabarcoding), WGS to human transcriptomics sequencing. Some of this may be out of scope for GA4GH. Currently the ENA sequence experiment templates(checklists) have been drafted, with some iterations but more input/changes from different perspectives would certainly help.

• FAIRification of genome sequence annotations (tracks) is an initiative for a new working group in the Research Data Alliance (RDA), building on earlier work from the FAIRtracks project, a collaboration between ELIXIR Norway, ELIXIR Spain and EMBL-EBI. The aim is to provide a minimal metadata schema and related tools to combine heterogeneous primary data sources into a secondary consolidated metadata collection optimised for discovery and reuse in accordance with the FAIR principles. The scope is limited to data files that contain reference genome coordinates, but this still covers a large variety of experiment and data types. Due to the large variety of experiment types, the project is pragmatically dependent on adopting minimised versions of metadata schemas standardised by external bodies such as the GA4GH. The outputs from the Experimental Metadata study group are therefore of particular interest.

9. Audience:

Name the target audience(s)/public(s) for which the product is intended. Who are the product's clients and customers?

Any genomics data producer that shares the results of their experiments with others, at any scale, from a collection of a few experiments generated by a single lab, up to international large-scale consortia.

1.2 Data Use:

This section includes questions that are relevant for both the DSWS and REWS review.

1. Describe the information and sort of data, or data storage that will be used/applied in this product, if any?

Experiment metadata is data to describe the way a sequencing experiment was conducted, to facilitate reusability of genomic datasets. It will contain information on how a biological sample was prepared to be used in a sequencer, and details on the sequencing run itself. Some example properties include information on the sequencing instrument (“Illumina NovaSeq X”), or the molecule that was used in the sequencing library preparation (“messenger RNA”). It does not target metadata property that, if made publicly available, would enable one to connect the data to any single experiment done (e.g. information about participants or their biosamples).

2. How long do you intend to keep this data for, or intend data gathered by this tool to be kept for?

We do not store any data, but rather work on a specification that people will use to organise their data.

3. Please indicate data classification(s) of data connected with the product:

• Public
• Confidential
• Personally Identifiable Information (PII)
• Personal Health Information (PHI)
• Other(s) - specify

4. Will the product require documentations such as data subject consents, data access agreements, and /or other legal agreements?

1. If so, have you included a disclaimer for implementers? (this could include the issue, and the disclosure that it is the implenters’ responsibility to take measures to mitigate against possible risks.)

No

5. Will use of the product need review, approval and/or oversight by a data access committee?

1. If so, please explain

No, this kind of information is usually publicly available as it describes a genomic experiment, rather than a participant or their biological samples. Moreover, experiments results themselves are not part of this effort.

6. Are there disposal procedures for this data?

No, as the data is not confidential or personally identifiable, there is no such procedure.

7. Does the product limit access to data? (i.e. is it open access, controlled access etc?)

1. What authentication and authorization mechanisms are provided or specified?

None

2. Does the product rely on or work with GA4GH Passports and/or GA4GH Authentication and Authorization Infrastructure?

No

3. Describe the access allowed for parties such as data subjects, researchers, clinician, or funders:

Data access repositories and data producers alike usually make this metadata fully accessible to understand the nature of the data being offered.

4. Describe how the authority is governed or controlled by stakeholders, data controllers, or users:

Does not apply

8. If you identified data with any restrictions as being used, then please answer the following questions:

Does not apply

5. Please explain how the data will be processed (i.e. collected, used, stored, shared, etc.).
6. By using this product, what privacy, anonymity, or confidentiality issues might arise in the processing of this data?
7. Is the data authorised for transfer or extraction in bulk? Or is the data to be used and processed in place only for specific authorised purposes?
8. Please describe any mechanisms in place to restrict data use (e.g. policy, regulatory, or technical controls).

1.3 Security Questions

Firstly, please make sure that your product complies or enables compliance with the following GA4GH and DSWS Policies. In the case of specifications, protocols, and file formats, much of the operational responsibility for compliance will fall to implementers and operators of your product, but it is nevertheless necessary for you to ensure that the product has no problems that might make it difficult to comply with the policies:

Data Privacy and Security Policy | Data Security Infrastructure Policy

1.3.1 Risk Identification

Identify risks to confidentiality, integrity, and availability that arise through the implementation and operation of your product.

The specific risks will depend greatly on the product type.

For APIs, protocols, and associated web UIs, the key risks are common to all web applications and APIs. Most of these should be handled through generally applicable security policy and practice, though some added risk can arise from the particulars of the API definition or in the coding and implementation of the API.

For data models, ontologies, and file formats, there may sometimes be no security risks that arise if the product strictly describes pure data representation. However, security issues can arise. Features such as filtering or query logic may risk implementation errors that allow injection attacks. Data fields designating ownership, data classification, clearance levels, or other access-control-related metadata may allow abuse.

For policy frameworks and resources, security considerations may need to be baked into the product itself, depending on the domain. But there may not be any security risks that must be identified in this questionnaire.

References:

• 2.1 Risk Assessment in the Data Security Infrastructure policy
• OWASP API Security Top 10 
• OWASP Top 10 Web Application Security Risks

Table 1 Instructions:
List the risks and threats that apply to your product. The table is pre-populated with a number of risks to most software services in operation. Add or remove rows as appropriate to the context of the product.

Table 1: Risks

1.3.2 Risk Analysis & Countermeasures

This section intends to undertake risk analysis and identify countermeasures that should be taken.

For each of the risks identified in Table 1, specify the countermeasures (or design choices), if any, that will be used to mitigate or eliminate the risk.

Table 2: Countermeasures

1.4 Regulatory and Ethics Questions:

Ma'n Zawati and Jessica Seegobin from REWS met with the product team leads and Beatrice Amos on July 14

The purpose of this section is to identify any regulatory and ethical implications your deliverable may have

Firstly, please make sure that your product complies with the following GA4GH and REWS Policies (This will also be assessed by the identified REWS reviewers):

Copyright Policy | Framework for Responsible Sharing of Genomic and Health Related Data | Add Future IP Policy 

1. Referring to the policies above, what elements, if any, will you need to consider when creating your product?

Copyright Policy: None

Framework for Responsible Sharing of Genomic and Health Related Data:
Transparency
Engagement
Data Quality
Sustainability
Education and Training
Accessibility and Dissemination

2. Will use of the product need ethics review, approval or oversight?

No ethics review, approval, or oversight is anticipated for the use of this product. The Experiments Metadata specification is designed to standardize the description of experimental protocols and technical metadata. It does not include any personally identifiable or clinical data, and its intended use does not involve direct interaction with research participants or patient data that would trigger ethics oversight.

1. If so, please explain:

3. Will the product be used to influence clinical decision making by health professionals or patients (for example, a diagnostic or a prescription)?

No. The Experiments Metadata product is not intended for direct clinical use and will not be used to inform diagnostic decisions, prescriptions, or other clinical actions. Its purpose is to support the structured documentation of experimental protocols and technical metadata, primarily for research and interoperability purposes.

2. In what ways might the product have any effects in relation to confidentiality and/or privacy?

No. The product is not expected to have any direct effects on confidentiality or privacy. It does not include or require the use of personally identifiable information or patient-level data. As a metadata standard describing experimental methods and procedures, it operates at a technical level and is not designed to handle sensitive individual data.

3. What risks are there that uncertainty/misunderstanding of results could be exacerbated due to the product?

The Experiments Metadata product is designed to improve clarity and consistency in the documentation of experimental protocols and technical procedures. As such, it is very unlikely to directly contribute to misunderstanding of scientific results.

However, there is a minor risk that if the metadata is incomplete, improperly applied, or misunderstood (e.g., by non-technical users), it could lead to incorrect assumptions about the nature or quality of the experiment being described. This is particularly relevant in cases where experimental context (e.g., protocol versions, reagent details, or instrumentation settings) influences data interpretation.

To mitigate this, the product includes clear documentation, structured fields, and usage examples to guide implementers. Continued engagement with users and feedback from adopters will also support refinement and clarity over time.

1. Does your product affect the ability to return results? If so, how do you plan to address this, in relation to the return of results policy? 

No.It is not involved in the generation, interpretation, or communication of individual-level research or clinical results. Instead, it focuses on capturing structured metadata about experimental protocols and procedures. As such, it falls outside the scope of GA4GH’s return of results policy.

4. Could the product be required to obtain regulatory approval from a government agency before it can be used in some jurisdiction? (for ex. from the FDA in the U.S.)

No

5. Is the product intended to respond to specific regulatory issues, e.g., the GDPR’s broad notion of personal data?^[2] If so, have other regulatory environments been considered?

No, the Experiments Metadata product is not intended to address specific regulatory issues such as those outlined in the GDPR. The product is designed to capture technical and procedural metadata about experimental methods, and it does not include or require the handling of personal data. As such, regulatory considerations related to personal data protection (e.g., GDPR, HIPAA) are not directly applicable.

That said, the product has been developed with general awareness of data governance principles and aims to support responsible data sharing by promoting transparency and reproducibility in experimental documentation.

6. Could the product be used in ways that undermine public trust in the GA4GH or the genomics data sharing community? (Yes/No/Don’t Know + Explain)

No. The Experiments Metadata product is a technical standard intended to improve the transparency, consistency, and interoperability of experimental method documentation. It does not handle personal or clinical data, and its use is unlikely to directly impact public trust.

As with any standard, misuse or misrepresentation (e.g., using the specification to imply endorsement of poor-quality or non-reproducible research) could raise concerns. To mitigate this, GA4GH will continue to promote appropriate use, provide clear documentation, and encourage community engagement and feedback throughout the product lifecycle.

7. If you identify any other relevant legal, regulatory or ethical considerations then please outline these below:

1.4.1 Equity, Diversity and Inclusion (EDI)

A definition of EDI can be found here.

1. How might the product potentially limit participation or collaboration of researchers in research groups who have not adopted the product?

No way anticipated. Currently, research groups often face challenges in sharing and harmonising experimental metadata due to the diversity of formats and descriptions in use. The Experiments Metadata product aims to improve this by providing a common, interoperable framework that makes collaboration and data integration much easier.

The main potential downside for non-adopters is that they may be at a disadvantage compared to those using the standard, who can share and interpret metadata more efficiently. Researchers unfamiliar with the new checklist may need to invest some time learning the standard and related tools, but this is expected to be a manageable and typical part of ongoing professional development within the field.

2.    GA4GH is a global org, how does your proposed product currently engage a global audience?

Our group includes collaborators and maintains active communication with potential adopters worldwide, including regions such as the US, EU, Australia, and Japan. We are committed to ongoing outreach throughout the product’s development, approval, and rollout phases. The Experiments Metadata product addresses a universal need for standardized, interoperable descriptions of experimental protocols, which is relevant across all geographical boundaries.

We recognize that different jurisdictions may face unique challenges in adopting new data standards. To support broad adoption, we have developed open-source tools, clear documentation, and community resources designed to make implementation as accessible and straightforward as possible.

1. If it is limited/ does not - what would need to change to achieve that?

Meetings are open to everyone, Driver Projects participants and beyond, and consistent efforts are being made to attract newcomers to the initiative. Newcomers are constantly being welcome to present on their project and how it could bring a contribution to this initiative.

3. What assumptions about resource availability (such as computing power, sequencing technologies, money, time, etc) will be made during the products design and development?

The design and development of the Experiments Metadata product assume that potential adopters generally have access to adequate computational resources, including high-speed computing clusters or cloud infrastructure, as well as sufficient funding to support these operations. Many adopters already manage sizable databases and infrastructure to host and serve experimental and genomic metadata, so we expect that the additional resource demands for implementing this standard will align with their typical operating budgets and update cycles.

At the same time, we have ensured that the metadata checklist and associated tools can be implemented efficiently on personal computing devices for smaller or medium-scale datasets, enabling broader accessibility for individual researchers or smaller labs. We also recognise variability in resource availability globally and strive to keep the product lightweight and modular, minimising barriers to adoption regardless of computing environment or budget constraints.

Throughout the development process, we will continue to engage with the community to identify and address any resource-related challenges, ensuring the product remains practical and sustainable across diverse settings.

2. How will these be weighed against competing concerns such as moving the field forward, responding to cutting-edge use cases, etc?

As this is a metadata checklist, time investment from involved parties will be the most needed resource.

4. Identify the ways that implementation may require significant time, resources, or deep GA4GH knowledge that could present a barrier to lower resourced projects and initiatives?

As with any new standard or technology, there is an initial investment of time and resources required to understand, implement, and integrate the Experiments Metadata product into existing workflows. This includes becoming familiar with the checklist, adapting current data management systems, and potentially developing or extending software tools to support the standard.

We anticipate that larger projects - such as major databases, tool developers, and publishers - will adopt and build upon the reference implementations, creating an ecosystem of tools and resources that will make adoption easier for others. However, until these supporting tools and integrations become more widespread and mature, lower-resourced projects may face challenges in prioritising the adoption of this standard due to limited technical capacity or competing demands.

Moreover, some familiarity with GA4GH frameworks and terminology could be beneficial for smooth implementation, which may present an additional learning curve for smaller initiatives without dedicated bioinformatics or standards expertise.

In order to make this effort progress, people will need to invest time to review proposed solutions, evaluate their own project needs, and contribute concrete proposals that help improve the product. This collaborative input is essential to ensure the standard evolves in ways that are practical and valuable across diverse use cases.

To mitigate these barriers, we plan to provide clear documentation, user-friendly tools, and community support aimed at lowering the technical threshold for adoption. As the product matures and gains normative status, we expect adoption will become more accessible and attractive across a wider range of resource settings.

5.  If this is a revision to an existing standard, are prior versions interoperable with this version? For example, where organisations do not have the infrastructure for a newer version, can they still rely on the old version to be interoperable with existing standards, or the newer version at other organisations?

This is the first version of the specification.

6. What are the implications, if any, for fair attribution?

The successful accomplishment of this product will improve FAIR attribution of available genomics datasets, as it will improve those datasets reusability in all data analysis efforts, across collaborators and for the community at large.

7.  Looking at your product, the product's audience and your role in building, disseminating or making decisions about your product: How might your product further perpetuate disadvantage or inequalities for vulnerable or underrepresented groups?^[3] [i.e. Could identify people as part of a disadvantaged minority’, may exclude groups from being able to implement].^[4]

1. What strategies could you implement to reduce these barriers?

No, it will encourage better inclusion, as it will improve data reuse for all data scientists.

Section 2: Product Approval

This section requires you to produce finalised evidence that the issues identified in Section 1 have been addressed for approval. This is important as it helps keep track of changes to the product, and ensures that when reviewing the product prior to planned approval that it is clearly shown the suggestions made have been integrated or taken into consideration. The completed revisions evidenced should be provided to REWS and DSWS members 2-3 months prior to when you plan to seek approval at the Steering Committee in the form of the spreadsheet provided below.

Please also highlight to the DSWS and REWS team if any additional elements of the deliverable have been added since ‘Section 1’ was completed. It is important that         Section 1 questions are applied to significant changes as additional risks may be identified that may impact their assessment.

Please also provide a layperson description of your product that could be used in its publication, if approved:

The Experiments Metadata product is a standardized way to describe the details of scientific experiments, especially those related to genetics and genomics. It provides a common language and format that researchers and organizations can use to share and understand information about how experiments were conducted, what methods were used, and the key data involved.

By creating this shared framework, the product helps scientists collaborate more easily, compare results across studies, and build upon each other’s work more effectively. This ultimately accelerates discoveries and improves the quality and reliability of research in genetics and related fields.

Link to product: https://github.com/ga4gh/experiments-metadata