About us
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.
At the GA4GH strategic planning meeting in Hinxton, UK, in May 2017, the community identified a need for a best practices guide to help steer the development and adoption of GA4GH products. This document establishes several best practices that, when adhered to, would allow products to be adopted into GA4GH’s ecosystem. It does not prescribe an in-depth and strict set of dos and don’ts. Each product comes with its own community and working practices. To enforce the same working practice over all products would be counterproductive and only increase the administrative burden of initiating new work or bringing external products into GA4GH.
A product can exist in one of the following states:
Products should be proposed and developed in response to the needs of the GA4GH Driver Projects or in response to a known need within the broader community for standards.
The initiation of new products is likely to occur when new Driver Projects are introduced to the Work Stream and work on underway products is completed. The need for a new product may also coincide with a documented community requirement. Initial prototyping and possible exploratory work may take place wherever those developing feel is appropriate.
The Work Stream Leads should remember that the aim will be to produce a small number of new specifications, with wide adoption, each year. Priorities should be reflected by requests for the desired “Product” from multiple sources, be they Driver Projects or others active in the Work Stream activities. The Driver Projects who have explicitly requested a product will be the source Driver Projects for that Product.
Suppose the Work Stream Leads would like to formally turn an initial prototype into a product to develop to completion. In that case, they can ask the Work Stream Manager to create a custom copy of the Product Proposal Template. This set of slides will then be used to inform the GA4GH Steering Committee of the new Product. This will:
There may be some amendments to the initial Product proposal. These could be in response to issues raised by the foundational Data Security Work Stream or by other Work Stream leads identifying a possible area of cooperation or scope enhancements.
The Product will be submitted for approval by arranging with the GA4GH staff team/relevant programme manager to make a copy of the GA4GH Product Approval Submission Form and then emailing GA4GH staff at info [at] ga4gh.org to notify them that the form has been completed.
The following bodies will review the submitted product:
The GA4GH staff team will notify the Standards Steering Committee that the product has been submitted.
A questionnaire will be provided featuring questions set by REWS. The GA4GH staff team will provide this questionnaire which should be filled in and passed as a link in the GA4GH Product Approval Submission Form.
The Product Review Committee will consist of three members, as detailed below, nominated by the submitter:
The choice of members will be approved by the Engineering Group, subject to any changes suggested by the GA4GH staff team. The review committee nominates a representative to communicate back to the GA4GH staff team (this is the technical Work Stream leader should no nominations be made). The review committee may give a response of “Accept,” “Reject,” or “Changes Requested.” All three members must agree unanimously for the committee to give a positive assessment. The committee should provide this response one month after the specification submission to be reviewed. PRC members must follow guidelines.
It is recommended that the relevant foundational Work Streams are contacted with any security, regulatory, or ethical concerns they may have during the development process. The reviews made at this stage are in addition to those performed during the proposed phase.
A positive assessment is confirmed when the GA4GH staff team receives confirmation from the representative of each reviewing body that the review body passes the Product. Requested upgrades will be communicated to the submitting Work Stream Managers if a review body does not pass the Product. An upgraded Product can be sent to the reviewers directly. This cycle can be repeated until the Product passes the review body requirements.
Once all three bodies have made positive assessments, the Product will be sent to the GA4GH Steering Committee for Approval. This must be done two weeks prior to the Steering Committee meeting at which it is to be assessed.
At the meeting itself, one Work Stream Lead will present the Product to the Steering Committee. The Work Stream lead in charge of the PRC may also be called upon to explain the PRC processes. If the Steering Committee votes to approve the Product, it will be deemed “Approved.” If the Steering Committee rejects the Product, it will indicate the reasons for the rejection and if the Product will require a complete resubmission through the approval process or if the issues are minor enough to allow the Product to be reconsidered in a single expedited review.
Specifications should follow the semantic versioning pattern of MAJOR.MINOR.PATCH, e.g. 2.1.1, as detailed at https://semver.org/. This is to communicate the severity of changes in a product to downstream users. MAJOR changes are considered breaking, e.g. changing a URL or renaming a field in a schema. A significantly enhanced feature set may also qualify as a major change. MINOR changes are considered as changes in functionality but not breaking, e.g. adding a new field to a schema. PATCH changes should be reserved for changes that do not change the contracts built within a product, e.g. expanding the size of a field in a schema.
Exceptions may be made where the product intentionally fits into an alternative versioning scheme dictated by the products’ target community. In this case, a clear schema for the versioning must be available, a link to the versioning schema provided in the Product Approval Form, and, if possible, the specification itself.
Minor and Patch updates to the Product may take place without the Product Review Committee being reconvened.
Approving a new major version requires a new product approval submission, again using the GA4GH Product Proposal Template. Once this process starts, the Product will be reviewed by the same bodies as for a first-time release.
In exceptional circumstances, an expedited review may take place for what should be a Major new version. The Standards Steering Committee will approve a Product directly. Consultation with the original PRC should take place for this to occur. The Standards Steering Committee must have no votes against the proposal for this approval to be granted.
The Product should be available in a public configuration management system that tracks requests for changes, authorship, and history. Submitting the specification to GitHub for tracking suffices. The repository should have at least three people assigned by Work Stream Leads capable of resolving product change requests subscribed and watching. Any issue or pull request should expect a response within a short time frame. Each person should be a GA4GH contributor, who agrees to the GA4GH IP policy (once finalised), and GA4GH Code of Conduct.
If a GitHub repository is used as the publish location, the GitHub user ga4gh-vc should be added as an owner or manager of the repository in question. This user is managed by the GA4GH staff team and will help ensure long-term oversight of the repository in question. A GA4GH staff-managed user with similar rights should be set up if a different version control system is used.
GA4GH paladins are a set of nominated people within the GA4GH community who ensure the smooth running of the Product according to the above best practices. Sets of paladins will be assigned a product/designation according to their background and knowledge. They will also be given commit ability to the product. This will only be used in extreme circumstances if product owners cannot be contacted. These people will be selected from the Engineering Committee members.
Products will be subject to a review by the Standards Steering Committee after the period of one year, if required. Typically the Standards Steering Committee will review a specification after five years.
GA4GH may endorse a specification developed by an external body if it deems it relevant. The criteria and process for this are in development.
Work Stream Leads wishing to retire a product from GA4GH can submit a request using the GA4GH Product Retirement Form detailing the reasons why. Once agreed, the product may be withdrawn. Any attribution or mention of GA4GH will be removed if appropriate. Products will be updated to point to their replacement if they have been superseded by a newer GA4GH Approved Product. GA4GH may choose to fork a product if the GA4GH staff team deem a need to.
The following GA4GH specifications existed before these Approval Procedures were implemented, so they may deviate from the requirements in this section:
Below are the recommendations made by GA4GH to ensure a robust specification is developed.
Each specification should be laid out in a document detailing the following:
The document should be presented in a human-readable format without the need to install a paid for third-party application or viewing outside of the browser. HTML output and PDF are acceptable formats so long as the source markup format used to generate the document is available e.g. Markdown, RST, HTML, LaTeX. In the case of Markdown and RST, GitHub provides automatic HTML generation features. We recommend using GitHub flavored Markdown (https://github.github.com/gfm/) and limiting the use of dynamic code within documentation.
GA4GH API specifications should use the following common end-points to convey information:
/service-info
The precise nature is to be determined
/error
The precise nature is to be determined
Each specification should have at least two associated implementations. These do not need to be officially maintained reference implementations. For a client-server model, there should be at least two servers implementing successfully with two clients. These are viewed as best efforts and viewed as a way to ensure a robust product is developed.
These implementations are not expected to be written or managed by Work Streams themselves. They are to be developed by the Driver Projects and the community. Ideally they would operate in the real-world environment, with real-world data, in which the developed standards aim to be used. Work Streams would facilitate interoperability testing between these implementations. This might result in updating specifications during the development process if the implementations highlight unforeseen circumstances.
GA4GH specifications should meet RFC 2119 on the use of keywords to indicate requirement levels.
GA4GH specifications should meet the requirements of the source Driver Projects which requested them, or have had some feedback from the community in which it is intended to be used. RFC 7282 is recommended for development teams to consider to guide the decision making process.
The submission should include a plan for publication to a journal or similar entity to allow for a citable reference to the product. Journals used for publication must be open access and not behind a firewall. In addition, GitHub repositories can be registered with Zenodo to mint DOIs (https://docs.github.com/en/repositories/archiving-a-github-repository/referencing-and-citing-content). This is not a requirement of GA4GH to do for all standards but is a way to generate a citable entity.
If the specification is required to interact with areas covered by other GA4GH standards, it must comply with those standards.
To enable a long-term contact for security flaws, an email address of security-notification [at] ga4gh.org has been set up. This email will be monitored by GA4GH staff and security members to allow for an incoming response to be directed to appropriate parties. Please feel free to use this email address in your specifications or websites if required.