Summary

In our previous work ( L. Wiel et al. Human Mutation, 2017 ) we observed that the presence of pathogenic missense variants at an aligned homologous domain position is often paired with the absence of population variation, and vice versa. We realised that this type of information could be of great benefit to genetic diagnostics, and that it would therefore be helpful to have an easy-to-use platform that could provide access to this wealth of information without the need for a bioinformatics intermediary.

The MetaDome platform is a further extension of our framework that maps population variation and known pathogenic mutations onto “meta-domains”. MetaDome takes as input a gene of interest and allows the user to select the preferred transcript. Using this information, MetaDome provides protein domain and pathogenic variant annotation, and generates a ‘tolerance landscape’ for the gene’s protein, which visualises regional tolerance to normal genetic variation. Furthermore, MetaDome uses homologous protein domain relationships to aggregate population-based and pathogenic variants found across the genome that are aligned to the same position in the domain of the gene of interest. The use of these annotations can improve the interpretation of genetic variation.

Software architecture of MetaDome

MetaDome is primarily developed in Python and makes use of the Flask framework for the web server and communication between the front end, the back end, and the database. The software architecture follows the domain-driven design paradigm. The code is open source and can be found in our GitHub repository. Detailed instructions on how to deploy the MetaDome platform are also provided there. To ensure MetaDome can be deployed in any environment, the full stack is containerised with Docker Compose: the Flask application, a PostgreSQL database, a Celery task queue for asynchronous retrieval, a Redis result store, a RabbitMQ broker and a mail container.

The visualisation layer of the MetaDome platform is a fully interactive and responsive HTML web page generated partially by the Flask framework, while navigation and styling are provided using the CSS framework Bulma. The visualisation of all data is performed using JavaScript, which relies heavily on the D3 framework.

GRCh37 and GRCh38 are held as parallel, independently indexed datasets in one database, and the assembly is selected at the web and database interaction layer, so every visualisation, endpoint and export follows the assembly the user has chosen. GRCh38 is the default, and GRCh37 remains available for compatibility with clinical sequencing data anchored to it.

Datasets of population and disease-causing genetic variation

Population variation is obtained from the Genome Aggregation Database (gnomAD). MetaDome uses the VCF file and selects all synonymous and missense variants that meet the PASS filter criteria. The two assemblies draw on different gnomAD releases, because recent releases cover GRCh38 only, so the GRCh37 build stays on the last gnomAD release that covered GRCh37. For disease-causing missense variants, the VCF file from the public archive of clinically relevant variants (ClinVar) is used for both assemblies, taking the variants classified Pathogenic and those classified Likely pathogenic.

A mapping between the world of genomics and proteomics

MetaDome features a PostgreSQL relational database in which a complete mapping between genomic and protein positions is stored together with domain region annotation. The mapping is regenerated by a standalone Python pipeline, orchestrated through a Pixi environment that pins every tool and dependency, and run independently for each assembly, each against the GENCODE Basic set for that assembly and the UniProtKB/Swiss-Prot databank. GENCODE coding sequences are re-translated and must reproduce the distributed protein sequence, with in-frame length and a terminal stop codon enforced. Each translation is then matched to Swiss-Prot canonical and isoform sequences with protein-protein BLAST, from BLAST+, retaining only pairs that are identical over the full length of both sequences, which is stricter than matching on identifiers and stricter than local sequence identity alone. For all others, only the existence of the transcript is registered in the database.

Because the two sequences are identical, no alignment between them is needed: residue n of the translation is residue n of the Swiss-Prot entry. For each nucleotide a mapping is then made between the genomic position and the protein position, recorded on the transcript's own strand and separately for each assembly, and stored in the database. As only the protein-coding information of a gene is needed for MetaDome, each mapping represents part of a codon. Each mapping is linked to a gene translation and a Swiss-Prot entry.

Each Swiss-Prot sequence in the database is then annotated for Pfam-A protein domains, using pfam_scan on HMMER, applying the Pfam gathering thresholds and clan competition, so that a single family is reported where several families of one clan match the same region. InterPro annotations are inherited from the per-protein cross-references that UniProt provides, rather than being computed here.

Database construction is split into two stages. The first writes a standardised tabular file per assembly, holding every per-residue mapping between transcript, protein and Pfam domain together with the corresponding genomic positions. That file is the canonical mapping resource and can be used on its own, without the MetaDome platform. The second stage is a batch loader that ingests it into the production database. Keeping the two apart means the mappings can be regenerated and audited independently of the platform, and the platform can be reloaded from an existing tabular resource without re-running the alignments. Both stage outputs are published, and are listed, with the exact release versions behind the current build, on the Data page.

Composing a meta-domain

Meta-domains are sets of Pfam domain instances in the human proteome that share a family annotation, and across which variation can be aggregated when a family has at least two human instances. For each family, the Swiss-Prot sequences of its instances are aligned against the Pfam HMM with HMMER, producing a Stockholm alignment whose consensus columns define equivalent positions across homologues.

In MetaDome 2019 this aggregation was performed at query time, by retrieving the relevant alignment and mapping each aligned column back to its genomic positions on demand. The consensus positions and their per-residue genomic links are now pre-computed when the database is built and stored as relational entries, so aggregation of gnomAD and ClinVar variation at a position is served from indexed lookups. Consensus positions are stored for every family annotated in the human proteome, and aggregation applies to those with two or more instances. The Stockholm alignments are intermediate build artefacts and are not retained, because the stored table carries the same positional correspondence.

Computing genetic tolerance and generating a tolerance landscape

We use the non-synonymous-over-synonymous ratio to quantify genetic tolerance in our Tolerance Landscape visualisation. In our setting, this score is based on single-nucleotide missense and synonymous variants (SNVs) from gnomAD in a protein-coding region. This score is corrected for the sequence composition of the protein-coding region based on the total possible missense and synonymous SNVs. The generation of a Tolerance Landscape is the result of computing this ratio in a sliding window of 21 residues across the entirety of the protein of interest (for example, ten residues to the left and right of each residue).