**3. Results**

#### *3.1. Overview of Scoped Review*

Based on our keyword search we selected 306 unique articles out of which 27 dealt with MTBs and were kept for further review. Next, two papers were discarded because their full texts were not available. From the remaining 25 publications, we excluded another 13 since they did not describe IT support in MTBs, which resulted in a total of twelve articles for our review. For details see Supplementary File 1.

#### *3.2. Details about Interviewees*

We conducted the first round of interviews with a total of 18 participants at nine different university hospitals to determine all requirements for an MTB software tool based on cBioPortal. Up to four participants were interviewed simultaneously at each site. Representatives of the following disciplines were involved: oncology (10), pathology (4), systems medicine/systems biology (2), bioinformatics (1) and human genetics (1).

The second round of interviews discussed and evaluated the requirements identified in the first round in detail with a total of 16 participants at the same university hospitals as above. Up to three participants were interviewed simultaneously at each site. Representatives of the following disciplines were present: oncology (7), pathology (4), systems medicine/systems biology (2), bioinformatics (1), human genetics (1) and urology (1).

#### *3.3. Requirements from the First Round of Interviews and Screenshot Mockups*

During the first round of interviews, a total of 49 requirements with up to seven potential options for implementation each were surveyed (see Supplementary File 7). Ten requirements either already implemented in cBioPortal or out of scope of our Use Case were dropped prior to the second round of interviews. This included features to:


A platform to discuss individual mutations across hospitals, for example in the context of a forum, is outside the scope of MIRACUM's Use Case 3 and was, therefore, not included in the second round of interviews either.

The choice of the file format to be used for the import of the mutation data into cBioPortal was made independently of the interviews by all use case members (MAF: "mutation annotation format"). In addition, a feature to permanently hide mutations in a specific sample in cBioPortal was denied since this filtering should be done by MIRACUM-Pipe [7] only.

In preparation for the second round of interviews, we created a total of 54 screenshot mockups demonstrating almost all surveyed requirements and their respective options (see Supplementary File 8).

#### *3.4. Consolidated Requirements from the Second Round of Interviews*

Below we provide a rough overview of the consolidated requirements we surveyed during the second round of interviews. For a list and detailed description of all final requirements and their respective options see Supplementary File 9.

#### 3.4.1. Improving Patient Case Analysis

Since case analysis in personalized medicine relies on various information such as details about the patient or—in case of MTBs—the underlying tumor, cBioPortal should provide those by integrating various information and knowledge sources in a single tool. Therefore, the participants requested, amongs<sup>t</sup> others, clinical patient data to be stored in cBioPortal. Displaying sample metadata and their subsequent analysis was also requested. This includes, for example, the type and location of a biopsy as well as the exact specifications of the sequencer used.

Furthermore, cBioPortal seems to lack important (calculated) values for its usage in molecular tumor boards. Ranging from the tumor mutational burden (see Figure 2A) up to values that indicate the pathogenicity of individual mutations (see Figure 2C). Mutations are automatically annotated with the latter by the MIRACUM-Pipe [7] and this information should be displayed in cBioPortal. We also discovered potential improvements for already existing features in cBioPortal, like the visualization of copy number variations (see Figure 2E).

**Figure 2.** Collage demonstrating some requirements for the case analysis. This collage is a synthesis of di fferent screenshot mockups, which exemplarily illustrates some requirements for individual case analysis: ( **A**) A visual representation of the tumor mutational burden relative to the expected range of the corresponding tumor entity using a box plot. (**B**) Integration of data from the JAX Clinical Knowledgebase (JAX-CKB) via annotation and pop-up. ( **C**) Classification of pathogenicity as an example of data extension in the mutation table of the patient view. ( **D**) Tool for an entity-specific display of how often a certain mutation was found and classified as relevant for the therapy recommendation at the partner sites. If necessary, the contact data may be used to exchange experiences. (**E**) Extension of the table with copy number variation (CNV) data by the exact number of copies. Example data adopted from the public cBioPortal (https://cbioportal.org) and JAX-CKB knowledgebase [20].

Since the interviewees also use numerous di fferent databases when evaluating a patient case, the integration of additional knowledgebases is highly desired. In this context, the JAX Clinical

Knowledgebase [20,21] was mentioned explicitly and considered to be beneficial when integrated (see Figure 2B).

Besides that, the visualization of molecular pathways can be an important tool that links individual mutations to molecular function and pathway in the search for a therapy option.

In order to improve cooperation, there were requests for a central service to (automatically) report a mutation that has led to a therapy recommendation before. If other participating hospitals similarly identify this mutation in one of their samples, it should be highlighted and contact details should be displayed (see Figure 2D) for detailed, personal exchange of expertise.

3.4.2. Supporting the Development and Recording of a Therapy Recommendation

Once the patient's data has been reviewed, the members of the molecular tumor board determine—if possible—the potentially relevant mutations for a therapy recommendation based on their previous analysis. This selection should be recorded in cBioPortal (see Figure 3A) and serve as the basis of the following features.

**Figure 3.** Collage demonstrating some requirements for the development and recording of a therapy recommendation. This collage depicts image sections from the screenshot mockups we created based on the original interface of cBioPortal: ( **A**) Checkboxes and text fields in the mutation table of the patient view to mark potentially relevant mutations for the therapy recommendation. (**B**) Search functionality with automatic parameter transfer to find previous patient cases with a mutation pattern similar to that of the current patient. ( **C**) Extension of OncoKB's information to cover the European Medicines Agency's (EMA) approval status of a given drug. ( **D**) Summary of already entered components of the therapy recommendation for the current patient. (**E**) Option to record follow-up data for the current patient. Example data adopted from the public cBioPortal (https://cbioportal.org) and OncoKB [16].

This set of relevant mutations is used to search for similar patient cases that have been analyzed in the local hospital before. A search should be comprehensively parameterizable and values from the current patient case (e.g., tumor entity, relevant mutations, etc.) should be automatically applied (see Figure 3B). The interviewees considered the gathering of information related to therapy recommendations for previous patients as the main goal of this functionality. This requirement was complemented by the need to document follow-up data (see Figure 3E). Therefore, details on the progression status of similar patient cases can be reviewed and included in the evaluation of the current case more easily.

Building on this, further information on a possible therapy approach is required. In addition to the already available functions in cBioPortal provided by OncoKB [16], the interviewees requested a way to easily query the approval status of a drug in their respective country (in the case of MIRACUM: Germany) (see Figure 3C).

Since, according to the participants, some therapy components (e.g., a drug) are only available in the context of (pre-) clinical studies, integration of clinical trial databases such as ClinicalTrials.gov [22] were requested. The interviewees expect a more e fficient search for suitable studies through the automatic transfer of relevant search parameters, which are taken from the cBioPortal data record.

Once a patient case has been prepared based on its individual data, it will be presented and discussed during a meeting of the MTB in order to jointly develop a therapy recommendation. There was no consensus as to what extent cBioPortal must support such a presentation. Some considered an automatically generated set of slides with individualized content as helpful. Others preferred to use the cBioPortal graphical user interface itself during the presentation with an option to hide irrelevant content. However, some interviewees also considered such assistance to be completely unnecessary.

After a therapy recommendation has been decided upon within the MTB, it must be recorded in detail in cBioPortal. Besides information on the therapy itself (e.g., the name of a drug), the molecular and clinical rationale for the recommendation needs to be documented, too. As a justification, the mutations earlier classified as relevant or the tumor mutational burden (TMB) may be referenced.

To submit the results of the MTB to the client (e.g., the treating physician), the interviewees requested a function to generate a PDF report. Besides the actual therapy recommendation, this report should also contain extracts from the consulted databases and thus also be used to archive the current state of knowledge that led to the decisions made.

#### 3.4.3. Requirements for IT Infrastructure

In order to integrate cBioPortal in the various clinical system landscapes, a standardized application programming interface (API) like FHIR (Fast Healthcare Interoperability Resources [23]) should be used by the respective components of the hospital information system to feed a local cBioPortal instance with various and comprehensive data (e.g., clinical data). In addition, the information, which is created or altered within cBioPortal, should be accessible via this interface for export into the local hospital information system.

The existing user system in cBioPortal must be extended by a comprehensive and flexible user and rights management. Of course, only authenticated and authorized users should be permitted to use the cBioPortal instance for an MTB at all. Furthermore, it should be possible to "freeze" a therapy recommendation made by the molecular tumor board and to allow subsequent changes only for certain users and only in a reproducible way. This implies that all alterations to the data records in cBioPortal can be traced, thus guaranteeing their integrity and authenticity.

In addition, some sites indicated that patient data may be stored in a pseudonymized manner if this becomes necessary for legal reasons (like it is done in the public available cBioPortal instance hosted by the Memorial Sloan Kettering Cancer Center). Of course, in this case, it must be guaranteed that the data can be reassigned to the patient at the end. For this purpose, an identification code assigned to the patient by the hospital information system could be used for pseudonymization.
