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).