Use of model organism and disease databases to support matchmaking for human disease gene discovery

Abstract

The Matchmaker Exchange application programming interface (API) allows searching a patient's genotypic or phenotypic profiles across clinical sites, for the purposes of cohort discovery and variant disease causal validation. This API can be used not only to search for matching patients, but also to match against public disease and model organism data. This public disease data enable matching known diseases and variant-phenotype associations using phenotype semantic similarity algorithms developed by the Monarch Initiative. The model data can provide additional evidence to aid diagnosis, suggest relevant models for disease mechanism and treatment exploration, and identify collaborators across the translational divide. The Monarch Initiative provides an implementation of this API for searching multiple integrated sources of data that contextualize the knowledge about any given patient or patient family into the greater biomedical knowledge landscape. While this corpus of data can aid diagnosis, it is also the beginning of research to improve understanding of rare human diseases.

Keywords: Matchmaker Exchange; informatics; model systems; ontology; phenotype; rare disease.

Figure 1. Example of a patient annotation to a subset of the Human Phenotype Ontology (HPO)

A hypothetical patient is annotated with two phenotypes, ‘Generalized amyotrophy’ and ‘Contractures of the joints of the lower limbs’ (annotations are indicated using dashed lines). Phenotypes can be described at different levels of granularity or specificity (more general terms are shown near the top of the figure). Any individual patient can be assigned any number of HPO terms.

Figure 2. Monarch in the MME Landscape

The MME API is used to facilitate discovery of patient B in a remote patient MME database, for a particular patient A that exhibits matching phenotypic features. The same clinical site can connect to Monarch to discover a range of models (for example, mouse and zebrafish) and other aggregated diseases and variants associated with similar phenotype profiles. Note the diagram only shows a subset of the many phenotypic knowledge sources feeding into the Monarch platform.

Figure 3. Patient matching against known diseases and model organisms

This figure illustrates matching from a patient to both a human disease and a mouse gene, using synthetic data. The center blue box represents the phenotypic profile of the undiagnosed disease patient encoded using HPO. The left yellow portion of the figure shows the closest matching known disease to this patient, where the disease information comes from public sources annotated with HPO by Monarch. On the right is a matching animal model, described using terms from the Mammalian Phenotype ontology (MPO). The green portions of the diagram shows the commonality between the matched phenotype terms both within species (left) and across species (right). Note that there are missing phenotypes in Disease D or Model M, another reason why comparison against the largest possible corpus is warranted. Patient A is based on a known undiagnosed disease patient that was solved based on phenotypic similarity to mouse and interactome data.

Figure 4. Visualizing patient similarities to known diseases and model organisms

An Undiagnosed Disease Program patient's phenotypes are on the left and match against the best genetic models in mice. The darker the square, the more in common the phenotypes are between the patient and the matched profile. Mouse models are shown here for comparison purposes. Note that a mouse mutant in the ortholog of STIM1 has 3 matching phenotypes with the patient's profile and when combined with exome analysis assisted the diagnosis of this patient. MME implementations of Phenogrid would enable comparison of input patient profiles against other patients accessible through MME protocols as well as known diseases and models.

Figure 5. Monarch Architecture in the context of some other Global Alliance APIs

such as the genotype-to-phenotype (G2P) API. The GA4GH APIs are implemented as a layer on top of our own REST services, which are backed by a SciGraph/Neo4J graph database.