gms | German Medical Science

Introduction (incl. Objective / Requirements): For the last five years, we have designed and developed the IT backbone of the German Cancer Consortium (DKTK), comprised of more than 20 institutions and teaching hospitals [1]. Our software is designed to connect ten different sites of the consortium, supporting data sharing and collaboration, while keeping clinical data management and data sovereignty in the hands of each clinical institution [2]. To this end, the architecture is a combination of both centrally and locally operated services [3]. As their name implies, centrally operated services are provided once within the consortium on dedicated servers and are, thus, easy to monitor, maintain and update. Local services, however, are operated at each participating sites and are not accessible by a central IT team [2]. In this report, we share our experiences in deploying DKTK "bridgeheads" at ten German university hospitals.

State of the art (related Work & short commings): Software deployment often requires extensive user intervention; the necessity to install and configure each software component individually (Java, application server, database, system libraries...) is time-consuming. With increased maturity of virtualisation technology, new approaches (like Docker [4]) are suitable alternatives to deploy software as appliances. However, these technologies are often not available on Windows-based servers.

Concept: A survey about the clinical IT landscape revealed Microsoft Windows Server as the dominating operating system across all sites, ruling out Unix-/Linux-based approaches such as Docker. After initial experiences with manual software installations, we found the process to be too error-prone. Thus, we designed a new approach: 1) Removal of unnecessary manual installation steps and overall automation of the installation process and 2) enabling local administrators to update bridgehead software without intervention by a central IT team are required.

Implementation: Software on DKTK bridgeheads is deployed using Microsoft Software Installer (.msi, [5]) packages created with Caphyon's commercial Advanced Installer (ADVI, [6]). The installation process is structured and customized. The executables are built with specific targets (test and productive) in mind and hosted in a central file repository in order to support subsequent updates.

Lessons Learned: Despite a working installation package, bridgehead installations continue to require installation dates to be scheduled with local administrators. This is because no site is like the other (in regards to infrastructure, regulations, and personnel) and every single software deployment is unique. Individual challenges (most commonly network communication and remote administration) and solutions for each site need to be considered. Without sufficient personnel and effective organisational support, even seemingly trivial technical problems can turn into severe issues. Moreover, mere distribution of software is not sufficient, as technicians/clinicians need assistance with setup and configuration. Regular update cycles are a good method to keep in contact with site personnel and in effect build trust over time. In conclusion, architects of research networks are well-advised to focus not only on development of their architectureís components but should also consider the rollout to each partner site as a significant challenge.

Die Autoren geben an, dass kein Interessenkonflikt besteht.

Die Autoren geben an, dass kein Ethikvotum erforderlich ist.