**4. Discussion**

Due to the huge amount of data produced by NGS technologies, the growing number of clinical studies and released targeted therapies to address treatment of cancer, new tools are required to identify relevant molecular alterations and matching therapy options for individual patients. The present paper outlines which of those are essential and which functionalities exactly have to be provided to support processes in MTBs. To our knowledge, there is no comparable work so far tackling this issue from the point of view of participants in MTBs.

#### *4.1. Results and Future Work*

We worked out a requirements specification for the software supporting the processes in an MTB based on the open source project cBioPortal, an integrated database, which allows to visualize clinical parameters and molecular findings of individual patients in the context of current knowledge about cancer diseases. It turned out that the screenshot mockups we had created prior to the second round of interviews played an important role in the further requirements analysis. They allowed us to describe the di fferent requirements and their potential options identified in the first round of interviews briefly and succinctly and thus to quickly start a discussion in the second round. They may also serve as blueprints for the future implementation of the requirements as it was the case with the integration of the Genome Aggregation Database (gnomAD [24]), where our mockups served as inspiration for the core cBioPortal development [25].

This conversation with the participants turned out to be the most important part of this work at all, as on the one hand questions that occurred could be resolved immediately and on the other hand, requirements that had not ye<sup>t</sup> been considered by neither the interviewees nor us came to light by intensive discussions. Therefore, we could finally identify 24 requirements that were not ye<sup>t</sup> integrated into cBioPortal at the time of the survey. Some of them have been proposed to the community of cBioPortal with requests for comments (RFC) filed by other users or even have been implemented before the finalization of this paper [25–32]. RFCs are publicly available documents everyone can create with proposals for new features in cBioPortal that often also include descriptions of a potential way to implement these. They are an important step in the development of new functionalities in cBioPortal and help to involve the community in the process of implementation. This demonstrates, how important those requirements—even outside of an MTB context—seem to be for the future of cBioPortal.

Besides that, some of our requirements identified are also met by tools not directly associated with cBioPortal, like MatchMiner [33] published by the Dana–Farber Cancer Institute. This tool, which has recently been prototypically integrated in cBioPortal [34], o ffers a service to match clinical trials to a patient case. At the moment, all studies have to be cured manually, so to use this feature to prepare MTBs in Germany, the ongoing challenge of an automatic import from databases like ClinicalTrials.gov [22] still remains to be resolved.

For the future we plan to integrate cBioPortal in the hospital information systems (HIS) of our partner sites. This means the cBioPortal instance imports clinical data related to patients that have been registered for the MTB directly from the corresponding electronic health record (EHR). This data comprises at least age, gender and tumor entity and ideally also recent diagnoses and therapy attempts as well as data from cancer registries. The sequencing data is automatically processed by the MIRACUM-Pipe [7] under parameter control, including alignment, variant calling, annotation and analyses, in order to finally be passed directly to the cBioPortal instance.

In addition to the import of existing data into cBioPortal, users also need to add persistent information to patient cases in cBioPortal to mark relevant mutations in a patient's sample or to finally document the therapy recommendation. Since we are in ongoing contact with the main developers of cBioPortal, who finally determine which new features are merged into their project and provide future maintenance of them, we identified a considerable conflict with this requirement: cBioPortal's primary focus is to support research in form of a read-only data warehouse. Therefore, the main developers stressed, that having direct write access by the user is currently not intended. A solution for this problem would be to place a hyperlink in cBioPortal to an input mask not hosted in cBioPortal itself, where the user can enter the data (e.g., the therapy recommendation). This form forwards the data to the patient's EHR in the HIS via a standardized application programming interface (API) like FHIR [23], which is supported by most modern systems of an EHR (e.g., MEONA [35]). In order to make this data available again in cBioPortal, an (automatic) import must take place on a regular basis (e.g., twice daily). Thus, the data warehouse concept of cBioPortal would remain and no user write access in cBioPortal itself is necessary.

We also discussed another problem we came across: the rigid process to import mutation data into cBioPortal. At the moment, there is no way to (dynamically) import additional annotation data on individual mutations without fundamental changes to the backend, which would be necessary for the integration of the demanded scores and similar. The team in Use Case 3 of the MIRACUM consortium responsible for the implementation already took the first steps and submitted a request for comments

to the community to address this problem. This request deals with a flexible integration of further mutation data by means of an additional database column with the data stored in JavaScript object notation (JSON) format [36].

In general, it is necessary to store data in a structured manner rather than in free text in order to achieve a high grade of automation during import. For example, the International Classification of Diseases for Oncology (ICD-O) can be used to encode the tumor entity, the German Federal Ministry of Health has stated in its announcement [37]. The use of a standardized ontology, such as that provided by OncoTree [38], can also be useful.

However, not only technical hurdles have to be tackled, but also legal ones. For example, when integrating further databases, particular attention must be paid to licensing as some restrict use to research purposes only. For example, even though the JAX Clinical Knowledgebase (JAX-CKB) was developed "to support clinical decision-making" [21], in the disclaimer of their website they allow usage "only for research and educational purposes" [20]. Use Case 3 of the MIRACUM consortium currently uses cBioPortal in clinical research. However, if it is used outside of a research context in the future, of course, this and also existing laws and regulations must be taken into account during the development, as well. Besides compliance with data protection regulations [39,40] and the Medical Devices Act [41], this is a very broad field.

As for future works, the implementation of the collected requirements must address these problems and find viable ways in close coordination with the main developers and the community around cBioPortal. This is the only way to integrate the features into the project permanently and to ensure their further maintenance and support.

## *4.2. Related Work*

We came across two related works taking place in Germany. Halfmann et al. report that they developed a tool that aims to support the preparation process of a molecular tumor board as well as the presentation of a patient case during a meeting [12]. A video published by them demonstrates how di fferent tools, including cBioPortal, can be combined in a single user interface [42]. Among other requirements, they discovered, like we did, that a function "to search for comparable local cases" [12] is demanded by clinical experts.

Fegeler et al. also describe a software solution for the support of molecular tumor boards. In addition to the option of planning and managing the processes in an MTB, they also describe an integrated video conferencing system. They plan to integrate cBioPortal and knowledge databases, to support the development of a therapy recommendation [13].
