Skip to main content

Application Deployment Guide

This guide walks you through creating, configuring, deploying, and monitoring an application in the Siemens Healthineers Frontier Developer Portal.

Each step follows the same structure:

  1. Purpose – Why this step matters
  2. Prerequisites – What you need before starting
  3. Actions – Step-by-step instructions
  4. Result – What happens after completion
  5. Impact on later steps – Dependencies and downstream effects
  6. Screenshot + Caption – Action-focused visual reference

📋 Deployment Steps​

  1. Create a new application
  2. Configure general settings
  3. Define data selection rules
  4. Upload the processing unit
  5. Add UI, JSON schema, and viewer layout
  6. Deploy and monitor the application
  7. Run your first case
  8. Monitor logs & metrics
  9. Troubleshooting & Best Practices

Before You Begin​

Purpose
Ensure all assets, credentials, and decisions are in place before you start.

Prerequisites

  • Frontier Developer Portal access with app creation permissions (teamplay Institution + Frontier Developer Portal license + User role "Frontier Developer Portal" assigned).
  • A prepared ZIP package (Windows) or Docker image (Linux).
  • Terms & Conditions and User Manuals (PDF format).
  • An application icon (round, 82px x 82px, png)
  • Knowledge of resource requirements (CPU, RAM, GPU) and mount paths.
  • For container-based apps: ability to use Docker to push images.

Actions

  • Gather all required artifacts into a single project folder (zip) or a Linux Docker Container.
  • Confirm you have environment access (Cloud or On-Prem).

Result You can complete the workflow without needing to pause for missing files or decisions.

Impact on later steps Missing documents or unclear requirements will block deployment or cause configuration rework.

important

Confirm the application type (Research vs. Commercial) before starting.

caution

Application is released for clinical use, which is not intended for clinical use.

danger

Functionality, which is not developed with the necessary quality, is applied for clinical use.

tip

Be very careful, when you want to create an application of application type "commercial", which is intended for clinical use: Be aware that you and/or your organization need to develop such application with necessary care, following all necessary steps demanded by standards and laws. Provide an about box with all needed information and be ready to deal with complaints from users. Select application type "Commercial" only, if you are sure to have done all needed actions.

Screenshot + Caption
Applications Overview
Applications overview showing existing entries and metadata.

Open the Applications Overview​

Purpose
Access the dashboard where all applications are listed and managed.

Prerequisites

  • Valid login to the Frontier Developer Portal.

Actions

  1. In the top navigation, click Applications.
  2. Review the columns:
    • Name, Unique ID, Created by/at, Updated by/at, Type (Research or Commercial).
  3. Open an existing application for editing

Result You see all applications you have permission to manage and which you can open for editing.

Impact on later steps This is your entry point for creating, configuring, and monitoring apps.

Screenshot + Caption
Applications Overview
Click Applications to see all app entries and their metadata.

Create a New Application​

Purpose
Register a new application entry to begin configuration.

Prerequisites

  • Decision on application type:
    • Research – Not for clinical use; may use generic research T&Cs.
    • Commercial – Clinical; requires validated documentation.
    • Commercial - Clinical; requires a dedicated activation by the Partner Manager

Actions

  1. In Applications, click Add new (top right).
  2. Enter the Application Name.
  3. Select the Application Type.
  4. Click Create.

Result A new application entry is added and you are redirected to its configuration tabs.

Impact on later steps

  • Application type determines required legal documentation, e.g. About Box
  • Results created by research apps will get automatically the "Not for clinical use" banner, suffix to the image comment and series description and additionally the caution will be burned in generated DICOM images.

Screenshot + Caption
Create New Application
Enter name, choose type, and click Create to start configuration.

Configure General Settings​

Purpose
Set deployment targets, runtime limits, and upload mandatory documentation.

Prerequisites

  • Application entry created.
  • Terms & Conditions, icon and manuals ready (for Commercial apps).
  • CPU, RAM, and runtime requirements defined.

Actions

  1. Open the General tab in the left menu.
  2. Under Deployment Options, choose:
    • Cloud (AI Rad Companion)
    • On Premise (syngo.via, Syngo Carbon)
  3. In Runtime Properties, configure:
    • Max Memory (GB)
    • Max CPU Cores
    • Application Timeout (seconds)
  4. Upload:
    • Application Icon (optional)
    • Terms & Conditions (required for deployment)
    • Manuals (required for Commercial)

Result The app’s general configuration is saved; legal requirements are met.

Impact on later steps

  • Missing T&Cs will block deployment in the Deploy wizard.
  • Runtime limits are enforced at execution.
tip

Use realistic timeout values — too short may cause unnecessary failures, too long can block resources.

Screenshot + Caption
General Settings
Select deployment targets and configure runtime limits.

Upload Docs
Upload Terms & Conditions and manuals.

Completed General Tab
Example: completed General tab with all required fields.

Define Data Selection Rules​

Purpose
Specify which DICOM studies or series are routed to your app.

Prerequisites

  • Knowledge of supported SOP Class UIDs.
  • Criteria for selecting the right series (description, instance count, etc.).

Actions

  1. Open Data Selection Rules in the left menu.
  2. Set Supported SOP Class UIDs.
  3. Configure Series Selector:
    • Match on series description, instance count, or latest series.
  4. (Optional) Add a Study Selector for additional filtering.

Result Only matching studies/series are sent to your application.

Impact on later steps

  • Too strict → No data for testing.
  • Too loose → Unintended data routed.

[!NOTE]
Start with broad filters for initial testing, then tighten them for production.

Screenshot + Caption
Data Selection Rules
Define SOP Class UIDs and filter criteria to control data flow.

Upload the Processing Unit​

Purpose
Provide the runtime component (ZIP for Windows or Docker image for Linux) that executes your app.

Prerequisites

  • Built ZIP or container image.
  • For containers: Docker client installed and able to push images.

Upload a ZIP Package (Windows)​

Actions

  1. Choose ZipFile as upload type.
  2. Select the .zip file.
  3. Choose the executable inside the ZIP.
  4. Set arguments using tokens, e.g.: 
    -inputDir {InputDirectory} \
    -resultDir {ResultDirectory} \
    -configDir {ConfigDirectory} \
    -logDir {LogDirectory}
  5. Click Save.

Result

  • Windows-based processing unit is registered.

Impact on later steps

  • Paths must be resolved from tokens at runtime.

Screenshot + Caption
Processing unit upload (zip)

Upload a Container Image (Linux)​

Actions

  1. Set arguments using tokens and absolute folder paths, e.g.: 
    -/mnt/input
    -/mnt/output
    -/mnt/config
    -/mnt/log
  2. Choose ContainerImage as upload type.
  3. Get the temporary registry credentials from the portal.
  4. Push your image: 
    docker tag myimage:latest <registry>/<image-tag>
    docker login <registry> -u <username> -p <token>
    docker push <registry>/<image-tag>

Result

  • Linux container image is uploaded and linked to your app.

Impact on later steps

  • none

Screenshot + Caption

Add UI, JSON Schema, and Viewer Layout​

Purpose
Define the application’s Configuration UI and Confirmation UI.

Prerequisites

  • JSON schema for Configuration UI.
  • Optional: Confirmation UI viewer layout definition for result visualization.

Actions

  1. Open the UI Configuration tab.
  2. Upload the JSON Schema describing input parameters.
  3. Test the UI:
    • Preview fields and default values.
    • Ensure alignment with your processing unit’s argument parser.
  4. (Optional) Configure a Viewer Layout for DICOM result visualization.

Result End users can configure the application before execution; results are displayed with intended layout.

Impact on later steps

  • Incorrect schema will prevent the UI from loading.
  • Missing layout will fall back to default viewer behavior.
note

JSON schema must match your application’s expected parameters exactly — mismatches cause runtime errors.

Screenshot + Caption
UI Config
Upload JSON schema and optional viewer layout.

Deploy and Monitor the Application​

Purpose
Make the application available for execution in the selected environment and track usage.

Prerequisites

  • All configuration steps (1–6) completed.
  • Required documents (T&Cs, manuals) uploaded.

Actions

  1. Open the Deploy tab.
  2. Create a new deployment
  3. Select suitable application configuration, processing unit, UI and provide additional metadata
  4. Click Deploy.

Result Application is live and can process data according to its configuration.

Impact on later steps

  • Application can now be tested
important

Only deployed applications are visible to users of your institution only.

Screenshot + Caption
Deploy App
Deploy the application and monitor execution metrics.

Run your first case​

Purpose
Verify that the deployed application processes a real DICOM case end-to-end.

Prerequisites

  • Application successfully deployed to the target environment (Step 7 completed).
  • Access to teamplay DICOM Hub or relevant DICOM sending system.
  • Example DICOM file available for upload.

Actions

  1. Open teamplay DICOM Hub.
  2. Upload an example DICOM image and select your deployed application (e.g., AIRCResearch lab32 WEU) as the target application during upload.
  3. Verify the uploaded study appears in All Studies.
  4. Send the study to your deployed application.
  5. Monitor the Queued list until the case moves to Completed.
  6. Check the results in teamplay DICOM Hub.

Result

  • The case is processed, and the result is returned to the sending system (e.g., rotated image, AI result, etc.).

Impact on later steps

  • Confirms that the deployment is functional before wider release.
  • Identifies any configuration or connectivity issues early.

Screenshot + Caption
Upload test image
Upload the example DICOM image to teamplay DICOM Hub.

Send test image
Send the uploaded study to your deployed application.

Case processing
Case in queue awaiting processing.

Case finished processing
Processing completed successfully.

Result distributed
Results available in teamplay DICOM Hub.

Monitor Logs & Metrics​

Purpose
Access application logs and performance metrics to verify correct execution and troubleshoot issues.

Prerequisites

  • At least one completed case processed by the application (Step 9 completed).
  • Appropriate permissions in the Developer Portal to view logs.

Actions

  1. In the Developer Portal, go to the Deployments tab for your application.
  2. Locate the deployment entry for your target environment.
  3. Click the deployment’s action button and select Application Logs.
  4. Review logs for errors, warnings, or unexpected behavior.
  5. Use the Monitoring section to view execution counts, success/failure rates, and performance metrics.

Result

  • Logs confirm whether the application ran as expected.
  • Performance metrics provide insights into runtime behavior.

Impact on later steps

  • Early detection of issues allows for faster resolution.
  • Metrics support performance optimization and scaling decisions.
important

For Open Apps deployments, logs must be retrieved directly from the system or via SRS. Developer Portal logging is currently only available for AIRC Research cloud deployments.

Screenshot + Caption
Access application logs
Open the application logs for a specific deployment.

View application logs
Detailed application logs for troubleshooting.

Troubleshooting & Best Practices​

Common Issues​

Application not receiving data​

Cause: Data selection rules too strict.
Fix: Loosen SOP Class UID or description filters in Step 4.

Mount path errors​

Cause: Token mismatch or incorrect container path.
Fix: Verify mount paths in Step 6 match your application’s CLI arguments.

Deployment blocked​

Cause: Missing Terms & Conditions or manuals.
Fix: Upload required documents in Step 3.

Best Practices​

  1. Consistent Mount Paths
    Always use /mnt/input, /mnt/result, /mnt/log for predictable behavior.

  2. Version Control
    Tag your container images with semantic versions (1.0.0) to track changes.

  3. Test Broad, Deploy Narrow
    Start with wide data selection rules for testing; narrow them for production.

  4. Document Runtime Limits
    Record CPU, RAM, and timeout values in your project documentation.

  5. Use Monitoring Proactively
    Review execution logs weekly to catch issues early.

tip

Store all JSON schemas, viewer layouts, and mount path configs in the same Git repository as your processing unit for easier change tracking.

Screenshot + Caption
Monitoring
Use monitoring to track executions and debug failures.