Integration with Scout data at Genomic Medicine Center
Karolinska,
Stockholm
PatientMatcher was developed as a standalone software with the aim of
providing an easy-to-administer MME server for any research institute or
clinical laboratory wanting to pursue a connection to the MME network as
an independent node. The application does not have a graphical user
interface (GUI) and patient data entry is achieved by handling incoming
HTTP POST requests containing authentication tokens as well as patient
data information. The instance of PatientMatcher hosted at GMCK contains
an integration with Scout, the browser-based decision support software
platform used to display and analyze WGS analyses from RD cases. These
cases include mostly patients from the three collaborating clinical
diagnostic laboratories at the Karolinska University Hospital: The
Center for Inherited Metabolic Diseases, the Department of Clinical
Genetics and the Department of Immunology and Transfusion Medicine.
These patients, analyzed either as singletons, trios or larger family
structures, present symptoms such as intellectual disabilities, inborn
errors of metabolism, mitochondrial and neuromuscular diseases, primary
immune deficiencies as well as connective tissues and skeletal diseases,
among other disorders(Stranneheim et al., 2021). In the current setup
Scout and PatientMatcher are distinct software instances residing on a
single server, but depending on local IT infrastructure they can, if
needed, be installed on different servers as they communicate via REST
APIs. On the Scout portal, the MME integration feature is visible by all
users. Access to the functionality is however granted to designated
users authorized to submit cases to the MME network. A typical
interpretation of a clinical case using Scout involves reviewing
variants available for the affected individual(s) of a case with the
goal of identifying one or a few candidates responsible for a specific
phenotype. Phenotypes in Scout can be assigned at the case and the
individual level as a list of HPO terms and/or OMIM diagnoses
(https://omim.org/). The requirements to submit a case to
PatientMatcher is that the Scout case should have up to three variants
“pinned” as possible causatives and/or its phenotype should be
described (by HPO and/or OMIM terms). It is noteworthy that since Scout
diagnoses are currently only represented by OMIM terms, at the moment it
is not possible to submit from this platform patients described by the
Orphanet (https://www.orpha.net/consor/cgi-bin/index.php) or
Decipher (https://www.deciphergenomics.org/) ontologies. As shown
in Figure 1, gender might be optionally assigned to a patient to be
submitted to the MME.
As regulations concerning genomic data sharing diverge depending on
national legislation (Phillips, 2018), and even though initiatives like
the EU’s General Data Protection Regulation (GDPR) exist to harmonize
the rules for data processing and sharing across borders in Europe and
internationally (Bonomi et al., 2020), data controllers might not feel
at ease disclosing the specific candidate variant(s) for a certain case
(Molnár‐Gábor and O Korbel, 2020). For this reason, we have included the
option in Scout to describe MME patient’s genotype features at the
variant level (at the specific variant genotype level) or at the more
generic gene level (only at the candidate gene level). These two options
are illustrated by the last two lines in the patient’s submission form
of Figure 1.
The Scout user responsible for submitting a patient to MME network
automatically becomes its contact person and will be notified if the
submitted case is positively matched. The case data is stored in the
database indefinitely and is subjected to internal and external queries,
but can be reviewed (Figure 2), modified and eventually removed at any
moment by the users.
MME nodes connected to PatientMatcher are displayed and can be searched
independently for patients similar to the query case (external
matching). Alternatively, similar patients can be also retrieved from
the list of other Scout patients in PatientMatcher (internal matching)
(Figure 3).
Both “active matches” (Scout patient has initiated the search and a
matching patient has been found in a connected node or in
PatientMatcher) and “passive matches” (an external party has initiated
the matching and the Scout patient is among the results in
PatientMatcher) are displayed in dedicated tabs named “Global Matches”
and “Local matches”, respectively displaying matching results for a
patient against other nodes or other Scout patients (Figure 4).