Advancing GA4GH products with the updated Product Development and Approval Process

21 Aug 2024

Learn how the revised Product Development and Approval Process fosters consensus around GA4GH products through cooperation, consultation, and clear decision-making.

The Product Development and Approval Process of the Global Alliance for Genomics and Health (GA4GH) has undergone a significant update.

Approved by the GA4GH Product Steering Committee in 2023, the updated process — which applies to all GA4GH Work Streams other than Regulatory & Ethics — continues to ensure GA4GH products reflect broad consultation and consensus, both within GA4GH and with the wider genomics and health community.

Notably, the revised process includes clearly defined Problem Statements, explicit guidelines for appeals and required implementations, clearer processes around product updates, and new pre-planning and study phases before product development begins. 

“The updated GA4GH Product Development and Approval Process aims to gauge community needs and avoid duplication of effort,” said Susan Fairley, the previous Chief Standards Officer (CSO) of GA4GH who spearheaded this initiative. “With this revised process, GA4GH hopes to strengthen measures for gathering feedback, building consensus, and communicating decisions at every step of product development. If you miss a meeting, for example, there should be no surprises.”

Voting rules have also been refined: now, Product Steering Committee members can delegate a nominee with the relevant domain knowledge to cast a vote on their behalf. More than half of the Product Steering Committee must vote, and at least 60% of those votes must be in support of the proposal for it to be approved.

Efforts to revamp the product approval process began after a 2021 survey indicated that the community sought improvements. Under Fairley’s leadership, GA4GH gathered extensive feedback and studied the processes of other standards development organisations. The new Product Development and Approval Process incorporates findings from that review.

Here, we walk you through the updated Product Development and Approval Process, explaining the steps necessary to take a new product or version from idea to approval. (Note that this article is for explanatory purposes only; all GA4GH contributors and participants must adhere to the actual text of the Product Development and Approval Process.)

So you want to build a new GA4GH product…

Let’s say you’ve hit a roadblock in your work. You spot a standards-sized gap in the world of phenotyping or pharmacogenomics or data federation, and think, “GA4GH should do something about this.”

The Product Development and Approval Process is your guide to going through the process. 

The process is guided by several core principles: cooperation and consultation are essential; products should be designed to work seamlessly together; and all efforts must align with the GA4GH Code of Ethics and Community Conduct. It’s crucial to note that at any point, parties can agree to stop development. Even if an idea is explored and then set aside, it’s considered a valuable part of the process.

All 33 points in the process combine into one continuous flow, with many points referring back to previous ones. Be sure to review the entire Product Development and Approval Process before proposing a new idea. 

For the purpose of this basic introduction, we explain the process in five sections: pre-planning, study, development, approval, and updates.

Pre-planning

When someone has an idea for a potential GA4GH product, the first step is pre-planning. Start here if you want to:

• create a new product;
• update an existing product;
• share a problem that a product may help solve;
• bring an externally-developed resource into the GA4GH product suite.

Pre-planning involves assessing the basics, such as: who is interested? Does this group duplicate efforts in the existing structure of GA4GH? Would any legal barriers prevent GA4GH from getting involved?

Interested individuals work with GA4GH staff to find their ideal home, whether in an existing GA4GH group or by assembling a new group. Once the group represents sufficiently broad geographic and domain areas, it can move into a study phase.

Study

During its study phase, the group assesses the existing landscape, determining whether and how GA4GH can address the need under discussion.

Group members consult a broad swath of relevant people and institutions, including the GA4GH Regulatory & Ethics and Data Security Work Streams. Then they produce the following outputs:

• landscape analysis;
• use cases;
• potential adopters;
• Problem Statement.

They also assemble a Product Review Committee (PRC), which consists of three people with appropriate domain knowledge who are not part of the development work. The Product Review Committee considers the study outputs and determines whether to send them to the GA4GH Product Steering Committee (PSC). If so, that committee votes to decide whether GA4GH should pursue product development.

The Product Review Committee forms much earlier in the updated Product Development and Approval Process than it did under the previous process. By introducing outside experts before development starts, GA4GH contributors receive useful feedback and can address potential roadblocks promptly.

The same three members of the Product Review Committee follow the product throughout its life cycle, from study through development, approval, and updates.

Development

Once the Product Steering Committee approves the Problem Statement for development, interested individuals can start working on drafting a technical product, developing tools, or writing frameworks.

The development team — which at this stage often formalises as a product development team within a GA4GH Work Stream — conducts broad community engagement to ground the work in real-world use cases. Team members review progress periodically and meet annually with their Product Review Committee.

Development teams must produce the following outputs, in addition to the product specification itself:

• decision record;
• at least two documented implementations, one of which is openly accessible to independent groups;
• documented feedback from pilot adopters;
• road map from approval to adoption.

Approval

After the development team decides the required outputs are ready, a product can enter the approval phase.

First, the product undergoes an open for comment period. The public, the Product Steering Committee, and anyone who previously noted an interest have at least one month to comment on the group’s outputs. 

Once the product group has made revisions based on the public comments, the Product Review Committee, Regulatory & Ethics Work Stream, and Data Security Work Stream provide their feedback to the product group. After another round of revisions, these same three groups decide whether to move the product forward in the process.

If everyone agrees, the product goes to the Product Steering Committee to determine if the content of the product is acceptable. A subset of the committee (including, if necessary, delegates chosen for their domain knowledge) may cast their online ballots over a period of two weeks. If at least 60% of the PSC casts an affirmative ballot, the product is brought to the full Product Steering Committee for a live “due-diligence vote” to ensure the Product Development and Approval Process was followed.

With a “yes” vote at this stage, the product or major version update becomes an official GA4GH product.

Updates

The revised Product Development and Approval Process also includes new procedures for making updates to existing products.

When a group decides its product requires an update, members can take one of three paths: 

• urgent fix;
• continued development;
• scope or breaking change.

The Product Review Committee approves which path a product team should take.

Urgent fixes result in a fast-tracked patch release. Let’s say you notice a small bug, or a time-sensitive error in documentation recently approved by the Product Steering Committee. The product group should notify the Product Review Committee (PRC) immediately of the issue then start working on a fix. The PRC decides whether the fix is appropriate and  ready to be released as a patch.

Continued development results in a minor version release. Examples include fixing trivial problems, clarifying meaning, and adding new tags or terms that fall within the remit that the Product Steering Committee already approved. (No breaking changes are allowed in this path.) Most product maintenance falls under continued development. After the Product Review Committee has reviewed the change, and the public has had one month to comment, an approved minor version can be released.

Scope or breaking changes result in a major version release. Such changes may break backwards compatibility for people already using the product, add significant new features, or take the product in a new direction. To pursue a scope or breaking change, return to study and follow the steps for a new product idea.

Getting help

 Do you want additional information or have a specific question related to your situation? GA4GH staff are here to help. Get in touch!