The Matchmaker Exchange API: automating patient matching through the exchange of structured phenotypic and genotypic profiles

Abstract

Despite the increasing prevalence of clinical sequencing, the difficulty of identifying additional affected families is a key obstacle to solving many rare diseases. There may only be a handful of similar patients worldwide, and their data may be stored in diverse clinical and research databases. Computational methods are necessary to enable finding similar patients across the growing number of patient repositories and registries. We present the Matchmaker Exchange Application Programming Interface (MME API), a protocol and data format for exchanging phenotype and genotype profiles to enable matchmaking among patient databases, facilitate the identification of additional cohorts, and increase the rate with which rare diseases can be researched and diagnosed. We designed the API to be straightforward and flexible in order to simplify its adoption on a large number of data types and workflows. We also provide a public test data set, curated from the literature, to facilitate implementation of the API and development of new matching algorithms. The initial version of the API has been successfully implemented by three members of the Matchmaker Exchange and was immediately able to reproduce previously identified matches and generate several new leads currently being validated. The API is available at https://github.com/ga4gh/mme-apis.

Keywords: GA4GH; HPO; Matchmaker Exchange; genomic API; patient matchmaking; rare disease.

Figure 1

Overview of the matchmaking process, in which 1) Alice deposits case P1 into Matchmaker A; 2) sometime later, Bob deposits a similar case P2 into Matchmaker B; 3a) Matchmaker B then sends a match request with a description of P2 to Matchmaker A and 3b) receives a match response with a description of similar patients (including P1) from Matchmaker A; 4) Matchmaker A informs Alice and Matchmaker B informs Bob of the P1-P2 match; and 5) Alice and Bob communicate if the match warrants further investigation.

Figure 2

An example match request and response, based on a patient description in (Hood et al., 2012). A) The HTTP header of the POST request to a matchmaker at b.org, serving the API from base URL. The Accept header specifies that the response should conform to version 1.0 of the MME API. The X-Auth-Token header is set to the secret token that b.org provided the querier to authenticate match requests. B) An example request body, describing a particular patient with Floating-Harbor Syndrome (additional features omitted for brevity). C) The HTTP header of a successful matchmaking response, indicated by the 200 OK status code. The Content-Type header specifies that the response conforms to version 1.1 of the MME API, which is backwards compatible with the version 1.0 query. D) An example response body, containing a list of matching cases and corresponding match scores (patient details and additional matches omitted for brevity). E) The HTTP header and body of a failed matchmaking response, in which the server does not support the API version of the query (version 1.0), and responds with an appropriate message, a Content-Type containing the latest API version supported by the server, and a list of all supported API versions (optional).