Getting Started

In this chapter we will explain the basic life-cycle and execution model of a "Frontier Fusion" prototype along with the main things to consider when developing it. If you'd rather directly start coding, please directly go to the first tutorial Python based prototype

Basic principle

Overview

The high-level execution model of a processing prototype is simple: It will be started by the respective runtime environment (AIRC Research or OpenApps) and load input data from a specified directory. After the input data is processed it will store the results in another directory and terminate.

The runtime environment will ensure that the configured directories are created and populated with the correct data before the prototype is executed. In the same sense it will collect the results, store them in a persistent storage and trigger downstream processing (e.g. sending to a DICOM node).

The prototype itself needs to support the possibility to pass the concrete directories as command line arguments. Details on the directories and command line parameters are given below.

Requirements for a prototype

The prototype to onboard must fulfill the following technical criteria:

• Needs to be a Windows executable (Linux is "in the making"...)
• Can be distributed as a self-contained "XCOPY deployable" ZIP file. This in particular means that all required libraries can be distributed within a single ZIP file. No system wide installation is required.
• Offer the possibility to pass the following directories as command line arguments:

Argument	Description	Mandatory?	Token
Input directory	The prototype needs to read its input data from this directory. Before the prototype is started, the infrastructure will provide all input data in this directory.	Yes	{InputDirectory}
Result directory	The prototype needs to store its results/output data in this directory. Prototype needs to terminate afterwards. Afterwards the infrastructure will pick up the data in this folder and make it persistent.	Yes	{ResultDirectory}
Configuration directory	Infrastructure will provide any configuration data in this folder before the prototype is triggered. This configuration data can typically be modified by the user using a provided configuration UI. The configuration UI can be developed together with the prototype or a generic configuration UI can be used.	No	{ConfigDirectory}
Log directory	The prototype needs to provide its log data into this directory. The infrastructure will further process it and ensure it is made available to the developer through developer portal (for AIRC Research deployment) or through syngo mechanisms (for OpenApps deployment).	No	{LogDirectory}
Intermediate storage directory	This is a special folder: Some prototypes require to be performed multiple times, for instance if a user interaction happens in between. Based on the user interaction, a reprocessing of the data is required. Prototypes which support this kind of reprocessing need to understand the concept of "intermediate storage directory". During the first run, they need to store appropriate data in this folder such that during the second run they can identify that this is a reprocessing of the same case. The content of this directory is treated by the framework as a black box and is deleted after results have been found in the results folder.	No	{IntermediateDirectory}
Share directory	To access the results generated by protype outside of AIRC and OpenApps, the prototype can share files via teamplay Data Lake. In order to share files, the user must have a valid data contract with teamplay Data Lake. Afterwards, the sharing needs to be enabled in the General configuration of the prototype and a valid data contract name must be specified. All the files stored in this directory are then shared via teamplay Data Lake.	No	{ShareDirectory}

note

Apart from the fact that the prototype needs to support these command line arguments, there are no further restrictions on their naming. The actual command line will be defined during the onboarding process, as described below. This gives the developer the freedom to choose whatever names the arguments need to have and assign the corresponding values using the tokens from the table above. Using this indirection even allows for onboarding existing prototypes where the source code is not available or cannot be modified as long as they are reading such command line arguments.

Runtime Environments

Developer portal currently supports two runtime environments - AI-Rad Companion Research (edge/cloud) and syngo.Via (as Open Apps). In the following section we provide some technical details about both deployment targets.

AI-Rad Companion Research

AI-Rad Companion (AIRC) Research is derived from the AI-Rad Companion product, an AI-powered solution that supports image-based clinical decision-making by post-processing medical images using AI algorithms. These algorithms provide annotations, quantifications, findings, and more. The solution can operate either in the cloud or on-premises (edge).

The algorithms are hosted within "Clinical Extensions." AIRC Research shares the same architecture as the product and reuses many of its components. The main difference lies in the intended use—AIRC Research is designed for prototype Clinical Extensions that are not for clinical use. AIRC Research (as well as AIRC product) is hosted on the teamplay digital health platform. This platform ensures connectivity with hospital infrastructure and provides services such as authentication, authorization, and entitlement management.

AIRC Deployment

An application created via the developer portal is registered as a prototype clinical extension. Technically, a clinical extension consists of two Docker containers—a processing unit container and a web backend (BE) container—along with a manifest file that includes details such as routing rules (which define the types of data the extension can process). During the deployment phase, the portal builds the container images and the manifest, then onboards the extension to the selected AIRC deployment instance.

AIRC Runtime

Once the application (clinical extension) is deployed and enabled (by default, newly onboarded extensions are disabled and need to be manually enabled in the configuration UI for each institution), it is ready to process incoming DICOM series.

The DICOM series is sent from the hospital (PACS or modality) and routed by teamplay to AIRC Research. The AIRC core services (also called the AIRC engine) determine which extension(s) can process the data based on the routing rules. The processing containers of the selected extensions are then started, executing the hosted algorithm(s).

The container created by the developer portal also includes a component called the "Extension Wrapper," which connects to the AIRC engine. This component populates the local container filesystem with data (input DICOM series and current configuration) and initiates the algorithm. Once the algorithm finishes, it sends the result data back to the AIRC engine.

If the confirmation UI is enabled, the results can be reviewed and either confirmed or rejected in the AIRC web application. Once confirmed—or if no confirmation UI is used—the AIRC engine sends the results back to the hospital infrastructure via teamplay.

The processing unit logs, including the standard errors, algorithm output, and any associated log files, are collected and accessible via the Developer Portal.

syngo.VIA - Open Apps

syngo.via is advanced imaging software designed for visualization and diagnostic analysis. From an architectural point of view, it is a client-server solution, where both the server and clients run within the hospital network.

It supports the installation of third-party extensions via the Open Apps infrastructure. These extensions can be downloaded from a marketplace or installed from an installation file. Technically, the extensions are Win32 applications, optionally with a GUI. The Open Apps infrastructure manages the application lifecycle and data transfer, which occurs through the file system.

There are two modes in which the Open Apps extensions can be executed, and for a given application, either or both modes can be configured:

• Interactive: The user manually starts the application for a selected study. Optional pre-processing is triggered, and the application's GUI opens. The user interacts with the GUI, and after completing the workflow, the application is closed, and the results are saved.
• Non-interactive: The application is configured to start automatically when data (DICOM study) matching predefined criteria is imported into the system. The results are saved with the same study.

Open Apps Deployment

If Open Apps deployment is selected, the Developer Portal will create an installation file for the application ("OAF" file.) This file can be manually downloaded and installed on a syngo.VIA system. Note that both interactive and non-interactive modes are configured.

Open Apps Runtime

When the application is started, Open Apps infrastructure creates the folder structure in a special directory called "context folder". The input folder is filled with the input DICOM images and the application is started. In the interactive mode the content of the application window is forwarded to the client via remote desktop protocol. After the application is closed, the result data ( if accepted ) are copied from the result folder to the syngo.VIA storage.

Processing only prototypes

This kind of prototypes is the only one currently supported. It needs to fulfil the abovementioned requirements. Results can be viewed with a generic viewing components provided by us. Furthermore it is possible to configure a generic configuration UI which fulfils basic configuration requirements for the prototype (see Using generic configuration).

Prototypes with a custom UI

Currently not supported. In a later version, the upload of a custom UI will be supported.

Future outlook

In addition to the uploaded executable there will be possibilities to directly upload the prototype as a container image. There are currently some limitations in deploying containers to the open apps environment. As soon as these are fixed, we will offer container onboarding.

Another topic is additional deployments. We are working on a standalone deployment variant. However, this is still work in progress.