Learn how GA4GH helps expand responsible genomic data use to benefit human health.
Learn how GA4GH helps expand responsible genomic data use to benefit human health.
Our Strategic Road Map defines strategies, standards, and policy frameworks to support responsible global use of genomic and related health data.
Discover how a meeting of 50 leaders in genomics and medicine led to an alliance uniting more than 5,000 individuals and organisations to benefit human health.
GA4GH Inc. is a not-for-profit organisation that supports the global GA4GH community.
To guide our collaborative, globe-spanning alliance, GA4GH relies on a Standards Steering Committee and an Executive Committee.
The Funders Forum brings together organisations that offer both financial support and strategic guidance.
The EDI Advisory Group responds to issues raised in the GA4GH community, finding equitable, inclusive ways to build products that benefit diverse groups.
Distributed across four Host Institutions, our staff team supports the mission and operations of GA4GH.
Curious who we are? Meet the people and organisations across six continents who make up GA4GH.
More than 500 organisations connected to genomics — in healthcare, research, patient advocacy, industry, and beyond — have signed onto the mission and vision of GA4GH as Organisational Members.
These core Organisational Members are genomic data initiatives that have committed resources to guide GA4GH work and pilot our products.
This subset of Organisational Members whose networks or infrastructure align with GA4GH priorities has made a long-term commitment to engaging with our community.
Local and national organisations assign experts to spend at least 30% of their time building GA4GH products.
Anyone working in genomics and related fields is invited to participate in our inclusive community by creating and using new products.
Wondering what GA4GH does? Learn how we find and overcome challenges to expanding responsible genomic data use for the benefit of human health.
Study Groups define needs. Participants survey the landscape of the genomics and health community and determine whether GA4GH can help.
Work Streams create products. Community members join together to develop technical standards, policy frameworks, and policy tools that overcome hurdles to international genomic data use.
GIF solves problems. Organisations in the forum pilot GA4GH products in real-world situations. Along the way, they troubleshoot products, suggest updates, and flag additional needs.
NIF finds challenges and opportunities in genomics at a global scale. National programmes meet to share best practices, avoid incompatabilities, and help translate genomics into benefits for human health.
Communities of Interest find challenges and opportunities in areas such as rare disease, cancer, and infectious disease. Participants pinpoint real-world problems that would benefit from broad data use.
See all our products — always free and open-source. Do you work on cloud genomics, data discovery, user access, data security or regulatory policy and ethics? Need to represent genomic, phenotypic, or clinical data? We’ve got a solution for you.
All GA4GH standards, frameworks, and tools follow the Product Development and Approval Process before being officially adopted.
Learn how other organisations have implemented GA4GH products to solve real-world problems.
Help us transform the future of genomic data use! See how GA4GH can benefit you — whether you’re using our products, writing our standards, subscribing to a newsletter, or more.
Help create new global standards and frameworks for responsible genomic data use.
Align your organisation with the GA4GH mission and vision.
Solve your real-world data problems with support from this valuable network of global institutions.
Work with like-minded groups committed to better data use in areas like rare disease, cancer, and infectious disease.
Share your thoughts on all GA4GH products currently open for public comment.
Solve real problems by aligning your organisation with the world’s genomics standards. We offer software dvelopers both customisable and out-of-the-box solutions to help you get started.
Learn more about upcoming GA4GH events. See reports and recordings from our past events.
Speak directly to the global genomics and health community while supporting GA4GH strategy.
Be the first to hear about the latest GA4GH products, upcoming meetings, new initiatives, and more.
Questions? We would love to hear from you.
Read news, stories, and insights from the forefront of genomic and clinical data use.
Attend an upcoming GA4GH event, or view meeting reports from past events.
See new projects, updates, and calls for support from the Work Streams.
Read academic papers coauthored by GA4GH contributors.
Listen to our podcast OmicsXchange, featuring discussions from leaders in the world of genomics, health, and data sharing.
Check out our videos, then subscribe to our YouTube channel for more content.
View the latest GA4GH updates, Genomics and Health News, Implementation Notes, GDPR Briefs, and more.
Discover all things GA4GH: explore our news, events, videos, podcasts, announcements, publications, and newsletters.
All GA4GH standards, frameworks, and tools must pass through an approval process before being adopted as an official GA4GH product.
The Product Development and Approval Process lays out the steps to create an official GA4GH product. This process, set out by the Standards Steering Committee, ensures that GA4GH products are fit for purpose and meet the needs of the genomics and health community. Learn more in our explainer.
As outputs from early steps are used in later steps, the process should be reviewed in full before commencing work. To guide contributors through product development, we provide links to the overarching principles and to different phases of the process — pre-planning, study, development, approval, and updates.
1. For products that originated outside of GA4GH (e.g. BED), check if there is any potential conflict with GA4GH policies, for example, relating to IP. Existing IP, or other factors, may prevent GA4GH from being able to adopt a product.
1.1 “Products that originated outside of GA4GH” is intended to cover cases like BED, where a product has been established, but where for whatever reason, the maintenance and development of the product would be aided by that work taking place in GA4GH.
1.2 Decision-makers: the decision should be made jointly by a) those interested in the product, b) GA4GH staff, and c) experts called on by GA4GH staff. In the case of disagreement, the final decision is with GA4GH staff.
1.3 Criteria: is there anything in the history of the product that would make it incompatible with GA4GH policies? This could be incompatibility with the IP policy, ethical frameworks, or some other consideration. (Checklists can be developed by relevant groups to aid review, but those making the decision should be cognisant that checklists cannot be exhaustive for all circumstances and that active consideration of issues beyond any checklists is required.)
2. Does a group already exist within GA4GH with interests closely aligned to this topic? This might be a group that developed a previous version of the product, a broader Work Stream, or a group formed for some other purpose but whose interests are similar.
2.1 Decision-makers: a) those interested in the new topic, b) the leaders of the existing group (if any), and c) GA4GH staff: in the case of disagreement, the final decision is with GA4GH staff.
2.2 Criteria: The decision should consider current group membership (that it be broad and with interests aligned to the product under consideration) and level of activity (that the group be active and engaged). Is there an existing group that is a natural fit with the product or topic being considered, and that has the appropriate knowledge and level of engagement to consider the topic?
3. Having engaged with an existing group, is there interest in the topic and support for taking the new topic forward? Further, if there is support, would this work develop a new product or update an existing one? For a new product, is there interest in the group entering a study phase or forming a new Study Group to look at the topic?
3.1 Decision-makers: this should be based on a consensus opinion from the existing group, expressed by the group leads.
3.2 Criteria: based on immediately and easily available information (without in-depth study), does the topic, in the group’s opinion, merit further work? Does the group support either commencing study preparatory to a new product or updating an existing product?
4. In the absence of an existing group that fits the topic well, as defined under point 2, the group should work with GA4GH staff to develop an outreach strategy. This should aim to contact individuals or groups likely to have a shared interest. This should extend beyond those already involved in GA4GH and actively seek people in a range of geographic locations and working in different contexts (i.e. research, clinic), to the fullest extent possible.
5. Has the outreach strategy under point 4 been successful enough to proceed? Has it been possible to gather an appropriate set of people to consider forming a Study Group and, if so, do they wish to proceed to form a Study Group on this topic?
5.1 Decision-makers: GA4GH staff will decide if a suitable group has been formed to consider Study Group formation. If not, outreach work can continue, or the topic can be retired. If an appropriate set of people has been convened (as judged by GA4GH staff), those people should decide through consensus if a Study Group should be formed, with the decision voiced by the group’s leaders.
5.2 Criteria: GA4GH staff should consider the breadth of geographic and domain areas represented in the group. There should be groups from at least two continents represented. More than one organisation, project, or platform of a given type should be represented (similar to requiring at least two Driver Projects). If, in the context of the product, there are collaborative efforts (i.e. Terra on a Google platform, funded by the U.S. National Institutes of Health and built by the Broad Institute of MIT and Harvard), those links could be considered as a single entity, and efforts made to seek input from additional entities across ecosystems. In deciding to form a Study Group, those gathered should consider if, based on immediately and easily available information (without in-depth study), the topic merits further study?
6.1 Study Group/phase:
6.1.1 The aim is to investigate if a product (of broad utility) is needed, could be developed, and would fulfil a need not met by any existing efforts.
6.1.2 Successful exploration of a topic leading to a decision not to proceed is a valid and worthwhile outcome for a Study Group/phase.
6.1.3 The date of Study Group/phase formation should be recorded by GA4GH staff.
6.1.4 The group should identify leads and who is responsible for ensuring key decisions are communicated.
6.1.5 Study Group/phase activities include:
126.96.36.199 broad outreach effort (work with GA4GH Communications team)
188.8.131.52 stakeholder engagement
184.108.40.206 Regulatory & Ethics and Data Security: hold an initial meeting with representatives of these Work Streams to complete the combined Regulatory & Ethics and Data Security questionnaire (noting that it may not be possible to fully complete the questionnaire until later in the development process). Tracking of issues should commence.
220.127.116.11 Consider the existing landscape: what products already exist and, if a new product were developed, how would it interoperate?
6.1.6 Study Group/phase outputs include:
18.104.22.168 landscape analysis
22.214.171.124 use cases with acceptance criteria (and whose use cases they are)
126.96.36.199 list of potential adopters who have expressed interest
188.8.131.52 “Problem Statement” defining the topic and stating what will be in and out of scope.
6.1.7 Study Groups or study phases may point to outputs from other groups (inside or outside of GA4GH), as appropriate.
6.1.8 Reuse is strongly encouraged.
6.1.9 Where there are existing efforts in the area, the study should speak to how the new group will relate to those efforts (ideally working with them) and also draw in new participants, if there is a lack of broad representation in those existing efforts.
6.1.10 The outputs of the study need to be sufficient to satisfy the PRC and Standards Steering Committee (SSC) of the case for working on the product. Where that case will be obvious to those groups, work should be minimal.
6.2 Product Review Committee (PRC)
6.2.1 The PRC exists to provide expert review of the product and to give feedback at some stages of the development process.
6.2.2 The PRC should consist of three people with appropriate domain knowledge who are not part of development work. Further, the PRC composition should:
184.108.40.206 include at least one person who has been heavily involved in GA4GH for more than a year in another Work Stream; preference to be given to a leader from another Work Stream. However, suitable leads can nominate another person who is not a Work Stream Lead with appropriate knowledge for this role.
220.127.116.11 include at least one person who does not have close involvement in GA4GH.
18.104.22.168 fill the third and final place on the PRC by considering the other two members of the PRC and seeking to bring balance to the committee. Breadth of representation (including geographic) and representation of users/adopters should be considered. The third place makes no requirement for direct involvement in GA4GH, although someone who is directly involved can fill this role.
6.2.3 An attempt should be made to have broad representation in the PRC.
6.2.4 Conflicts of interest must be declared and satisfactorily addressed by all members, referring to applicable GA4GH policies (which might include the Code of Ethics and Community Conduct, conflict of interest guidelines, and additional documentation).
6.2.5 GA4GH staff should work with the Study Group/phase to identify potential PRC members. In case of disagreement, the Executive Committee will be consulted. Final decision on PRC membership will be with GA4GH staff.
7.1 The Study Group/phase must consult existing adopters of the product, obtaining responses from a cross-section of existing adopters.
7.2 The views of existing adopters should form an additional output, alongside those listed under point 6.
7.3 Documentation from previous versions of the product can (and should) be reused.
7.3.1 Differences should be highlighted (git diff or similar is acceptable).
7.3.2 A paragraph of text should be supplied explaining why the changes are needed.
7.3.3 The previous PRC should be reconvened if at all possible.
7.3.4 New documentation should be kept to an absolute minimum but should demonstrate why the new work merits attention.
8.1 The Study Group/phase should include consultation with existing adopters in its outputs.
8.2 The landscape analysis may be brief and focus on existing use of the product.
8.3 The group should state if the intention is to consolidate or further develop the product. This should be made clear in the Problem Statement.
8.4 Existing documentation can be used in the initial submission to the PRC (point 10), assuming it is aligned with the requirements of GA4GH processes and provides the necessary information required by the PRC.
8.5 Documentation can be kept to a minimum but should be clear on the utility of the product (which may be obvious) and why it should be adopted by GA4GH.
9.1 Decision-makers: group consensus expressed by the group leaders
9.2 Criteria: is the Study Group/phase satisfied that the outputs are ready to proceed to the next steps of the process? Does the Study Group/phase feel that more work is required? Does the Study Group/phase feel that work should cease? The group should consider if the outputs are sufficient to clearly demonstrate to those not closely involved in the work that the decision-making criteria have been met. If work has stalled, can the group determine actions likely to remove the block?
9.3 For groups that have run for over a year as a Study Group/phase, GA4GH staff will initiate a meeting between the group leadership and the PRC. This is repeated annually for the duration of the Study Group/phase.
9.3.1 Decision-makers: PRC, Study Group/phase, and GA4GH staff jointly, and in event of disagreement, final decision with GA4GH staff
9.3.2 Criteria: should the work proceed to next steps, continue as a Study Group/phase, or cease? Are the outputs ready for next steps? Is there a clear plan of actionable steps to progress work? Has the work stalled irretrievably? Has it been concluded that the topic should not be pursued?
9.4 For groups where work has been rejected by the PRC or SSC, the group should consider the feedback they have received throughout their work, as well as any feedback received on the presented outputs, and judge if further work should be attempted or if work should cease. The group may seek input from others to assist their decision-making. If a given product accumulates a further (second) rejection on presenting a revised version at the same stage (at either the PRC or SSC votes), work should cease and not proceed to development (unless the group leads can present a compelling case to the Executive Committee).
10.1 Outputs to be reviewed include:
10.1.1 landscape analysis
10.1.2 use cases (and whose use cases they are)
10.1.3 list of potential adopters who have expressed interest
10.1.4 Problem Statement defining the topic and stating clearly what will be in and out of scope
10.1.5 if the product is from outside GA4GH or an update to an existing product, a summary of the views of those who adopted the previous version of the product
10.2 Decision-makers: the PRC (with support from GA4GH staff to provide additional required information) can choose to support the outputs going forward to SSC or provide comments to the Study Group/phase, asking them to review.
10.3.1 Is there engagement from a varied cross-section of the community?
10.3.2 Is the problem, as stated, of broad interest and utility?
10.3.3 Is there a need for new work? Could existing products be used effectively?
10.3.4 Have any pre-development interoperation concerns been identified and clearly scoped?
10.3.5 Does the problem fit within GA4GH’s remit?
10.3.6 Is the Problem Statement in line with GA4GH’s decentralised and federated philosophy, where we avoid centralised infrastructure?
10.3.7 Is the Problem Statement clearly defined?
10.3.8 Does the content of the Problem Statement make sense?
10.3.9 Is it likely that the product will be adopted? Is it addressing a sufficiently important issue that stakeholders are likely to dedicate resources to development and adoption?
11.1 The Study Group/phase should present their work at a SSC meeting.
11.2 The materials generated for the PRC should be shared with the SSC at least two weeks before the meeting.
12.1 Following the Study Group/phase’s presentation to SSC, the SSC will be balloted to determine if the group should proceed to development work.
12.2 SSC members can:
12.2.1 choose to cast a vote themselves
12.2.2 ask a nominee to vote on their behalf
22.214.171.124 For example, a Driver Project Champion might ask a colleague on the same Driver Project with knowledge of the domain.
12.2.3 excuse themselves from the vote if they feel the topic is outside their expertise or they have a conflict of interest.
12.3 Of the cast votes, at least 60% must support progression for development work to proceed.
12.4 The ballot closes two weeks after the SSC presentation.
12.5 Votes must be cast by (or on behalf of) >50% of SSC members for the outcome to be valid and development work to proceed.
12.5.1 If this is not achieved, GA4GH staff should work with SSC members to understand the reasons members were unwilling to vote. Two weeks ahead of the next SSC call, GA4GH staff should then present a possible plan of action, which will be put to a vote of SSC members on that call; SSC members can vote for the plan or for the work to be discontinued.
12.6 If approved, a list should be made of all SSC members (or their delegates) who wish to be kept informed of development work.
12.7 The voting form should include space for a short amount of feedback (allowing those casting votes to express a reason for their decision, irrespective of if that is for or against the proposed product).
13. SSC subset/delegates decide if the Problem Statement should be taken through to development using the ballot process described under point 12.
13.1 Decision-makers: SSC members or their nominees
13.2 Criteria: same as for the PRC under point 10
14.1 Work commences on developing a product, as defined by the Problem Statement presented to the SSC.
14.2 The group should identify leads and who is responsible for ensuring key decisions are communicated (possibly the same individuals as before).
14.3 There is further broad communication, beyond existing GA4GH contributors, that the group is being set up (work with the GA4GH Communications team). This should include contacting specific key stakeholders.
14.4 Those intending to adopt the product, those who have already adopted the product, and SSC members who have registered an interest in the product should be kept informed about work. This should follow Best Practices and should include sharing decisions, in summary format (not full meeting minutes), in a timely manner.
14.5 Development work should be based on real use cases across multiple environments.
14.6 For products originating outside of GA4GH, this work may be limited to formalising documents ahead of public comment. That work should, however, align with GA4GH’s working methods.
14.7 The Regulatory & Ethics and Data Security combined questionnaire should be revisited, as necessary, as the product develops, continuing to track issues and their resolution.
14.8.1 decision record documenting the major decisions taken during development, and why they were taken
14.8.2 the product specification
126.96.36.199 There should be at least two implementations created by independent groups (i.e. not two implementations created by the same entity for two different projects). Ideally, the second implementation would be built from the specification to demonstrate a clear specification.
188.8.131.52 At least one of these implementations should be open. This can be a reference implementation and need not be in use for any purpose other than acting as a reference. Implementations produced by the GA4GH staff Tech Team can be used to fulfil this criteria, but no guarantee is made of the Tech Team being able to provide support.
184.108.40.206 Interoperability of these implementations should have been demonstrated.
220.127.116.11 In client server models (or any two-part system, including read and write), there should be both two client and two server implementations, operating in different systems.
18.104.22.168 Work Streams do not need to build the implementations. The intention is that these would be built by Driver Projects.
22.214.171.124 Implementation work should inform the development process.
126.96.36.199 In exceptional circumstances, where a second implementation cannot be taken forward and there is strong reason to believe benefits to the community are being blocked, a group can proceed without a second implementation but must clearly present the rationale for this decision. An example where this might apply could be file format compression encoders. In such a case, many decoders could be expected, but few anticipate implementing an encoder. As such, it might be judged appropriate to move forward with one encoder and two decoders. A decision should be made based on available information and in the best interests of the established user community. This is intended for exceptional circumstances only and is not the appropriate route in most cases.
14.8.4 documented feedback from adopters
14.8.5 a road map for taking the product forward from approval to adoption, identifying future work to support adoption
188.8.131.52 Examples of such activities could include: working with key stakeholders to support adoption; addressing specific blocks to adoption; developing documentation, outreach efforts, demonstrations of utility of the product; and more.
184.108.40.206 We should acknowledge that adoption should be driven by the community choosing freely, but should seek to remove impediments obstructing adoption, making adoption as accessible as possible.
15.1 Decision-makers: group consensus expressed by the group leaders
15.2 Criteria: is the development group satisfied that the outputs are ready to proceed to the next steps of the process? Does the development group feel that more work is required? Does the development group feel that work should cease? The group should consider if the outputs are sufficient to clearly demonstrate to those not closely involved in the work that the decision-making criteria have been met. If work has stalled, can the group determine actions likely to remove the block?
15.3 For groups that have run for over a year in development, GA4GH staff will initiate a meeting between the group leadership and the PRC. This is repeated annually for the duration of development.
15.3.1 Decision-makers: PRC, development group, and GA4GH staff jointly, and in event of disagreement, final decision with GA4GH staff
15.3.2 Criteria: should the work proceed to next steps, continue development, or cease? Are the outputs ready for next steps? Is there a clear plan of actionable steps to progress work? Has the work stalled irretrievably? Has it been concluded that the topic should not be pursued?
16. Open for comment:
16.1 Following a decision to proceed, taken by the development group, the development outputs should be made available for public comment. This is the opportunity for everyone to express an opinion on the content of the product.
16.2 The public comment announcement should be circulated widely, including to everyone associated with GA4GH.
16.3 This is also the period when SSC members (or their delegates) are invited to express their views on the product. Those who previously registered interest should be notified directly of the comment period.
16.4 The public comment period should be a minimum of one month.
16.5 The PRC should be consulted on when the public comment period should close.
16.6 Comments should respect the principles set by our Code of Ethics and Community Conduct.
17.1 Regulatory & Ethics and Data Security
17.1.1 The combined Regulatory & Ethics and Data Security questionnaire, and associated issue tracking, should be reviewed with representatives of the Regulatory & Ethics and Data Security Work Streams. This can include a meeting with those representatives or can be done via email, if appropriate.
17.2 PRC review
17.2.1 The PRC should review the outputs listed under point 14. For the implementations, the PRC should be satisfied that interoperation has been demonstrated and that at least two implementations exist, at least one of which is open. If only one implementation is put forward, the PRC should judge if the rationale for that decision is sound and in the best interests of the established user group.
17.3.1 Regulatory & Ethics and Data Security
17.3.2 PRC, with support from GA4GH staff to provide additional information — the PRC can approve, request minor revisions, request major revisions, or indicate that it believes there are fundamental flaws with the work.
17.4.1 Regulatory & Ethics and Data Security
220.127.116.11 Does the product meet the standards of ethics and security established by those Work Streams?
18.104.22.168 Does the delivered product answer the Problem Statement?
22.214.171.124 Is there evidence that the implementations are interoperable?
126.96.36.199 Have adopters been consulted and their views documented?
188.8.131.52 Is it clear what use cases the product serves?
184.108.40.206 Have issues of interoperability with other GA4GH products or products outside of GA4GH been addressed?
220.127.116.11 Is this a product of broad utility?
18.104.22.168 Is the decision-making reasonable?
22.214.171.124 Is there anything, in the reviewers’ expert opinion, that is a concern?
126.96.36.199 Is the work aligned with the wider GA4GH, and does it follow the recommendations of TASC?
188.8.131.52 Has thought been given to enabling adoption of the product? Has a road map for progressing from approval to adoption been provided? Will that road map lower barriers to adoption of the product and make adoption accessible to the community (while leaving members of the community free to make their own decisions on adoption)?
17.5 Meetings between the development leads and the PRC, Regulatory & Ethics, or Data Security should be arranged as is helpful to enable discussion and provide clarification. This is particularly useful where changes are requested by the PRC.
18. Following revisions, the PRC, Regulatory & Ethics Work Stream, and Data Security Work Stream make a decision on the product.
18.1 Decision-makers: primarily the PRC, with input from Regulatory & Ethics and Data Security on their reviews — the PRC can approve, withhold approval, or, if there has been substantial change since the public comment, ask for the work to undergo another round of public comment.
18.2 Criteria: as for the PRC under point 17, and in addition, have there been substantial changes since the last public comment period?
19. Development group and GA4GH staff review in event of PRC or SSC withholding approval. They should decide if the work returns to development or if it ceases.
19.1 The group members should consider the feedback they have received throughout their work, and any feedback received on the presented outputs, and judge if further work should be attempted or if work should cease. The group may seek input from others to assist its decision-making. If a given product accumulates a further (second) rejection on presenting a revised version at the same stage (at either the PRC or SSC votes), work should cease (unless the group leads can present a compelling case to the Executive Committee).
19.2 Decision-makers: development group and GA4GH staff — final decision with GA4GH staff
19.3 Criteria: Can the issues that prevented approval by the PRC or SSC be addressed through further development work? Can a plan of action be clearly established to do this?
20.1 The SSC will be balloted to determine if the content of the product is acceptable.
20.2 Documents generated for the PRC should be shared with SSC.
20.3 SSC members can:
20.3.1 choose to cast a vote themselves
20.3.2 ask a nominee (for example, a colleague on the same Driver Project with knowledge of the domain) to vote on their behalf
20.3.3 excuse themselves from the vote if they feel the topic is outside their expertise.
20.4 Of the cast votes, at least 60% must support progression for the product to be approved and move to the final SSC process review.
20.5 The ballot closes two weeks after documents have been shared.
20.6 Votes must be cast by (or on behalf of) >50% of SSC members for the outcome to be valid and the product to proceed.
20.6.1 If this is not achieved, GA4GH staff should work with SSC members to understand the reasons members were unwilling to vote. GA4GH staff should then present a possible plan of action, two weeks ahead of the next SSC call, which will be put to a vote of SSC members on that call; SSC members can vote for the plan or for the work to be discontinued.
20.7 If approved, the product should move to final process approval by the SSC.
20.8 The voting form should include space for a short amount of feedback (allowing those casting votes to express a reason for their decision, irrespective of if that is for or against the proposed product).
21. SSC subset/delegates decide if the product is acceptable using the process described under point 20.
21.1 Decision-makers: SSC members or their nominees
21.2 Criteria: same as for the PRC under point 17
22. Final presentation to SSC for approval that the product development has followed this Product Development and Approval Process
22.1 The following should be shared with SSC at least two weeks before the call where a vote is scheduled:
22.1.2 evidence of outreach
22.1.3 evidence that those who registered interest in the product were kept informed.
22.2 Decision-makers: SSC members
22.2.1 Members on the call can abstain or vote to approve or reject.
22.2.2 Of the cast votes, at least 60% must support approval for the product to be approved.
22.2.3 Votes must be cast by >50% of SSC members for the outcome to be valid and the product to be approved.
22.3 Criteria: based on the available documentation, are members satisfied that the process outlined in this document has been followed and that the process has been open, fair, and completed to a good standard?
23. When a product group/subgroup supports an update to an existing product, the group should take a decision as to what type of change is being considered.
23.1 Urgent fix: these should be relatively rare but could include bug fixes and time-sensitive changes. Examples could include small but significant errors in recently approved documentation, including items that are technically breaking changes. Such changes would be “in the spirit of” previously approved work and would not alter the scope of the product. Such changes would be justified by it being in the best interests of the community for such bugs to be remedied swiftly. Urgent fixes would result in a patch release.
23.2 Continued development: this would also be “in the spirit of” the previously approved product. These would exclude breaking changes. Examples could include: trivial fixes, clarifying changes (where meaning either was or was not previously agreed), adding new tags or terms that fit within the existing remit, and potentially adding new categories of tags or terms to support a new technology that clearly fits within the existing remit. This case should cover the bulk of maintenance work. Continued development would result in a minor version release.
23.3 Scope or breaking change: where the work is altering the scope of the previously approved product or will lead to breaking changes (which don’t meet the urgent criteria), this is the appropriate path. These are changes that would break backwards compatibility, add significant new features, and/or take the product in a new direction. Scope or breaking changes would result in a major version release. (Return to point 6.)
23.4 Decision-makers: the consensus opinion of the group, using the group’s decision-making process, and expressed by the leads
23.5 Criteria: which of the three cases described best fits the current issue? For a scope or breaking change, is the group interested in moving to a Study phase (explained in points 6 to 13) to explore the proposed topic? Is there broad consensus?
24. When a group has concluded that work is needed for an urgent fix, the following should happen:
24.1 The PRC should be notified immediately of the issue and informed that it will shortly be asked to look at a solution.
24.2 The group starts work on a fix (working publicly unless there is a security concern).
25. Are the PRC and subgroup in agreement on the fix?
25.1 Decision-makers: the subgroup, represented by their leads, and the PRC
25.2.1 Does the PRC agree that this is an appropriate use of the urgent fix mechanism?
25.2.3 Is the subgroup in agreement that the solution is needed and addresses the issue? Is there broad consensus?
25.3 In the event that PRC members are unavailable:
25.3.1 Two PRC members approving is sufficient.
25.3.2 If only one or no PRC members can respond, approval can be given by the Work Stream Leads for the relevant Work Stream, in place of the PRC. This should be exceptional but is intended to enable speed in recognition of urgent circumstances.
26. Review of urgent fixes: ideally, the fix is posted for public comment, in parallel with PRC review, for seven days. The PRC and subgroup leads can bypass this if the case is judged to be clear-cut, and it is felt that delaying for review is detrimental.
27. The PRC is asked to approve the urgent fix for release as a patch.
27.1 Decision-makers: the PRC — if members of the PRC are unavailable, two members are sufficient to approve. If only one or no members of the PRC are available, approval can be given by the Work Stream Leads for the relevant Work Stream, in place of the PRC. Work Stream Lead approval should be exceptional but is intended to enable speed in recognition of urgent circumstances.
27.2.1 Does this meet the description of an urgent fix?
27.2.2 Does the proposed solution address the issue?
27.3.3 Is the solution to the benefit of existing adopters?
28. For urgent fixes, where agreement cannot be reached, responsibility falls to the subgroup leads, supported by GA4GH staff, to understand the remaining issues and work to resolve them. Any additional parties who it is believed can assist in this work should be included. All parties should keep in mind the urgency of identifying a workable solution.
29. Where the group has decided that the continued development path is appropriate, the PRC is asked to review that decision. The group should supply the minimum necessary information to the PRC on the nature of ongoing work.
29.1 Decision-makers: the PRC
29.2 Criteria: does the work described by the group fit with the continued development track? Alternatively, is it likely to break backward compatibility or alter the scope of the product? For products previously released as “draft” or “trial,” the continued development track may be appropriate even for significant and/or breaking changes.
29.3 Enabling progress:
29.3.1 In many routine cases, this will be the obvious choice of track for maintenance of existing products. In these cases, the group can reasonably take work forward while the PRC is being consulted.
29.3.2 The PRC should be kept up to date on planned work, being informed as soon as possible that continued development work will be taking place.
29.3.3 Where PRC members are unresponsive, GA4GH staff should work to understand the nature of the issue preventing a response. GA4GH staff should also liaise with PRC members regarding their future availability (extended leave, sabbaticals, etc.). Where GA4GH staff are unable to get a response from a PRC member, or a PRC member has made it clear that they will be unavailable, a Work Stream Lead from the given Work Stream may take that PRC member’s place in approving the choice of track. Work Stream Leads should not routinely be used. Two PRC members (or substitutes) are sufficient for approval.
29.3.4 GA4GH staff should work to support a decision being made on the appropriateness of the choice of track within four weeks of the decision being made to pursue the continued development. This can be extended by a further two weeks if the PRC requires clarification from the subgroup on the planned work.
29.3.5 Presenting future work in blocks and at a high level is encouraged.
29.3.6 The PRC may give broad sign off for categories of work being taken forward by the group in future as continued development (for example, adding tags or terms to products that use these). Flexibility is granted to PRC members and subgroup leads in managing this, but should make sure that both the PRC and subgroup leads are clear about what the PRC considers to be in scope for this track.
30. Continued development work by the subgroup:
30.1 Ongoing consultation with existing adopters and other members of the community is encouraged.
30.2 Regulatory & Ethics and Data Security should be consulted as necessary if work touches on areas/topics previously flagged during product reviews by those Work Streams.
30.3 Work should be in line with Best Practices.
30.4 Work should continue practices previously established for the product, such as decision records and communicating development to interested parties, as in the development process (points 14 to 15).
30.5 There should be broad consensus in support of change.
31. A decision is made by the subgroup to consider a block of continued development work to be complete and ready for release as a minor version. The group may also decide to discontinue work.
31.1 Decision-makers: the subgroup, using their processes, expressed by their leads
31.2 Criteria: is there a consensus within the group that the continued development work is now satisfactory and makes a good candidate for a minor version release? Is more work needed? Would it be appropriate to suspend or discontinue work?
32. Public comment is opened on the candidate minor version release and the PRC review in parallel. The public comment and review period lasts for one month. For changes that consist solely of trivial fixes, and where both the subgroup and PRC have agreed that the changes are trivial and to the benefit of the community, the comment period may be reduced or omitted.
32.1 During the review and comment period, the subgroup should engage with feedback, making necessary amendments or providing justification for the existing choices.
33. Following completion of subgroup revisions in response to comment and review, the PRC is asked to approve the updated product as a minor version release.
33.1 Decision-makers: the PRC
33.2.1 Has there been appropriate consultation (for example, with Regulatory & Ethics and Data Security, existing adopters, platform providers)? This may not be necessary and applies only if the changes are such that the PRC believes such consultation would be beneficial. Queries can be resolved via email.
33.2.2 Are the updates sound and in keeping with the aims of the product?
33.2.3 Do the updates benefit the community?