Skip to content

DICOM Connector Infrastructure Reference

Introduction

This document provides technical specifications for DICOM Connector deployment architectures, networking requirements, and infrastructure considerations. For information about how DICOM data is processed, mapped, and organized, see the Hierarchy Mapping Guide, Metadata Extraction Guide, and Advanced Configuration Guide.

Deployment Architectures

The DICOM Connector supports two deployment models, each with distinct security characteristics and infrastructure requirements.

Edge Device Deployment

In edge device deployment, the DICOM Connector runs on customer-managed infrastructure at the imaging facility:

Network Architecture:

  • DIMSE Communication: Occurs entirely within the customer's controlled intranet
  • HTTPS Communication: Only secure HTTPS traffic traverses the public internet to reach Flywheel Core
  • Security Model: Leverages existing network security controls for DICOM traffic

Infrastructure:

  • Deployment Location: On-premises VM or dedicated hardware
  • Resource Requirements: Typically 4 CPU and 16 GB RAM
  • Management: Customer provides infrastructure, Flywheel manages software

Security Characteristics:

  • DIMSE protocol (generally insecure) never exposed to public internet
  • Minimal attack surface for DICOM communication
  • Relies on physical network isolation for DICOM security
  • HTTPS communication uses OAuth and TLS for authentication and encryption

Network Security Requirements

Proper firewall configuration is critical for edge device deployments:

  • No Inbound Internet Traffic: The Connector must not accept connections from the public internet
  • Outbound Internet Only: Configure firewalls to allow only outbound HTTPS traffic to Flywheel Core
  • Internal Network Boundaries: Restrict inbound DICOM traffic to only authorized DICOM devices or networks
  • Network Segmentation: Ensure the Connector is isolated from unrelated systems on your intranet

Without proper network boundaries, unauthorized systems could potentially send DICOM data to the Connector or interfere with operations.

Supported Connector Types:

  • Edge device deployment supports both PULL and PUSH connector types
  • PULL connectors require this deployment model (cannot be deployed in-cluster)

Network Topology:

flowchart TB
    subgraph customer["Customer Network"]
        subgraph dicom["DICOM Network"]
            scanner1["Scanner 1<br/>(Static IP)"]
            scanner2["Scanner 2<br/>(Static IP)"]
            pacs["PACS<br/>(Static IP)"]
        end

        connector["DICOM Connector<br/>(Edge Device - Static IP)"]
    end

    subgraph flywheel["Flywheel Infrastructure"]
        core["Flywheel Core"]
    end

    scanner1 -.-> connector
    scanner2 -.-> connector
    pacs -.-> connector
    connector -.->|"HTTPS Upload<br/>(Outbound through Firewall)"| core

    style customer fill:#e8f5e9
    style dicom fill:#c8e6c9
    style flywheel fill:#f3e5f5
    style scanner1 fill:#fff
    style scanner2 fill:#fff
    style pacs fill:#fff
    style connector fill:#fff
    style core fill:#fff

In edge device deployment, the Connector sits at the network boundary with access to DICOM devices and outbound internet connectivity. All DICOM devices and the Connector require static IP addresses. DICOM traffic remains within the customer network while only HTTPS upload traffic traverses the firewall to Flywheel Core.

In-Cluster Deployment

In in-cluster deployment, the DICOM Connector runs as a service within the Flywheel infrastructure:

Network Architecture:

  • DIMSE Communication: Secured with mutual TLS (mTLS) over the public internet
  • HTTPS Communication: Internal communication within Flywheel cluster
  • Security Model: Certificate-based authentication and encryption for all DICOM traffic

Infrastructure:

  • Deployment Location: Flywheel-managed Kubernetes cluster
  • Resource Requirements: Managed entirely by Flywheel
  • Management: Flywheel manages all infrastructure and software

Security Characteristics:

  • mTLS provides machine-to-machine authentication for DICOM communication
  • Both client and server authenticate using X.509 certificates
  • All DICOM traffic encrypted in transit
  • Eliminates need for dedicated on-premises infrastructure
  • Only outbound traffic required from customer network

Supported Connector Types:

  • In-cluster deployment only supports PUSH connector type
  • Customer DICOM devices send data outbound to Flywheel (no inbound internet traffic required)
  • PULL connectors cannot be deployed in-cluster (require on-premises deployment)

Static IP Address Requirements

DICOM communication requires static IP addresses for all participating devices:

Why Static IPs Are Required:

  • DIMSE Authentication: The DIMSE protocol uses IP addresses as a primary mechanism for machine authentication
  • Security Risk: Dynamic IP addresses create security vulnerabilities if previously-assigned addresses are reassigned to unauthorized devices
  • Reliability: IP address changes can cause DICOM communication failures without warning
  • Access Control: DICOM nodes maintain allowlists of authorized IP addresses

Security Implications:

  • If a DICOM device IP changes, it may not be able to send or receive data
  • If an unauthorized device receives a previously-assigned DICOM IP, it could potentially send or receive DICOM data
  • With mTLS, IP address reassignment risks are mitigated by certificate validation, but transfers are still rejected if the IP is not on the allowlist

Requirements:

  • All DICOM devices (scanners, PACS, Connectors) must have static IP addresses
  • IP addresses must be documented and maintained in DICOM node configuration
  • Network changes affecting DICOM device IPs require coordination with Flywheel

Mutual TLS (mTLS) Overview

Mutual TLS addresses the security limitations of the traditional DIMSE protocol:

What mTLS Provides:

  • Mutual Authentication: Both endpoints verify each other's identity using certificates (in addition to IP-based authentication)
  • Encryption in Transit: All DICOM communication is encrypted
  • Certificate Validation: X.509 certificates ensure only authorized systems can connect
  • Enhanced Security: Mitigates IP address reassignment risks through certificate-based authentication

Certificate Management:

  • Customers typically obtain and provide their own certificates (public or private)
  • Flywheel deploys and configures provided certificates
  • Customers configure DICOM devices to use appropriate certificates

Use Cases:

  • Enables secure DICOM communication over public internet
  • Allows in-cluster deployment without edge device
  • Supports remote imaging facilities without VPN requirements
  • Eliminates need for inbound internet traffic to customer network

Deployment Comparison

Aspect Edge Device In-Cluster
DICOM Security Network isolation mTLS encryption
Infrastructure Customer-managed Flywheel-managed
Network Requirements On-premises access Public internet + mTLS
Traffic Direction Outbound only to Flywheel Outbound only to Flywheel
Connector Types PULL or PUSH PUSH only
Initial Deployment Hardware/VM setup Configuration only
Ongoing Maintenance Customer provides access Fully managed by Flywheel
Cost Model Infrastructure + management Service-based

Connector Types Technical Details

The DICOM Connector implements two distinct operational modes for data acquisition.

PULL Connector Architecture

The PULL connector actively queries DICOM nodes to discover and retrieve data:

DICOM Operations:

  • C-FIND (FIND-SCU): Queries DICOM node for available studies and series
  • C-MOVE (MOVE-SCU): Requests transfer of specific series to the Connector

Operational Flow:

  1. Connector sends C-FIND request to DICOM node at configured intervals
  2. DICOM node returns list of available studies and series
  3. Connector compares results with previous state to identify new data
  4. Connector sends C-MOVE request for new complete series
  5. DICOM node transfers requested data to Connector
  6. Connector processes and uploads to Flywheel Core

Network Requirements:

  • Connector must be able to initiate TCP connections to DICOM node
  • Requires DICOM node host, port, and Application Entity Title (AE Title)
  • Connector must be configured as known AE Title on DICOM node

Configuration Parameters:

  • Source DICOM node connection details
  • Query intervals and timing parameters
  • Series completion detection logic

Deployment Requirement:

  • PULL connectors must be deployed as edge devices on-premises
  • Must be within the same network boundary as source DICOM devices
  • Cannot be deployed in-cluster (requires direct network access to DICOM devices)

Network Flow Diagram:

flowchart LR
    subgraph customer["Customer Network"]
        scanner["Scanner/PACS"]
        connector["DICOM Connector<br/>(Edge Device Only)"]
    end

    subgraph flywheel["Flywheel Infrastructure"]
        core["Flywheel Core"]
    end

    connector -->|"DICOM C-FIND / C-MOVE"| scanner
    connector -.->|"HTTPS Upload<br/>(Outbound through Firewall)"| core

    style customer fill:#e8f5e9
    style flywheel fill:#f3e5f5
    style scanner fill:#fff
    style connector fill:#fff
    style core fill:#fff

In PULL deployment, the Connector initiates queries to the scanner/PACS and retrieves data within the customer network. The Connector then uploads via HTTPS through the customer's firewall to Flywheel Core. PULL connectors require edge device deployment.

PUSH Connector Architecture

The PUSH connector receives data sent directly from DICOM devices:

DICOM Operations:

  • C-STORE (SCP): Receives DICOM objects sent from scanner or PACS
  • Uses embedded DICOM receiver to accept incoming data

Operational Flow:

  1. Scanner or PACS sends DICOM data via C-STORE to Connector receiver
  2. Connector receiver stores and indexes received data
  3. Connector monitors receiver at configured intervals
  4. Connector identifies new complete studies in receiver
  5. Connector retrieves data from receiver and processes
  6. Connector uploads to Flywheel Core

Network Requirements:

  • Scanner or PACS must be able to initiate TCP connections to Connector
  • Connector endpoint (host, port, AE Title) configured on scanner or PACS
  • For edge deployment: Firewall rules allow inbound DICOM traffic to Connector
  • For in-cluster deployment: Outbound mTLS connections from scanner to Flywheel

Configuration Parameters:

  • Receiver endpoint details
  • Scanner or PACS authorized AE Titles
  • Monitoring intervals for receiver

Deployment Flexibility:

  • PUSH connectors support both edge device and in-cluster deployment
  • Edge deployment: Traditional on-premises receiver
  • In-cluster deployment: mTLS-secured receiver in Flywheel infrastructure

Network Flow Diagrams:

flowchart LR
    subgraph customer["Customer Network"]
        scanner["Scanner/PACS"]
        connector["DICOM Connector<br/>(Edge Device)"]
    end

    subgraph flywheel["Flywheel Infrastructure"]
        core["Flywheel Core"]
    end

    scanner -->|"DICOM C-STORE"| connector
    connector -.->|"HTTPS Upload<br/>(Outbound through Firewall)"| core

    style customer fill:#e8f5e9
    style flywheel fill:#f3e5f5
    style scanner fill:#fff
    style connector fill:#fff
    style core fill:#fff

In edge device PUSH deployment, the scanner sends DICOM data to the Connector within the customer network. The Connector then uploads via HTTPS through the customer's firewall to Flywheel Core.

flowchart LR
    subgraph customer["Customer Network"]
        scanner["Scanner/PACS"]
    end

    subgraph flywheel["Flywheel Infrastructure"]
        connector["DICOM Connector<br/>(In-Cluster)"]
        core["Flywheel Core"]
    end

    scanner -.->|"DICOM over mTLS<br/>(Outbound through Firewall)"| connector
    connector -->|"HTTPS Upload"| core

    style customer fill:#e8f5e9
    style flywheel fill:#f3e5f5
    style scanner fill:#fff
    style connector fill:#fff
    style core fill:#fff

In in-cluster PUSH deployment, the scanner sends DICOM data over mTLS through the customer's firewall to the Connector in Flywheel infrastructure. Only outbound connections are required from the customer network.

Connector Type Selection

Flywheel determines the appropriate connector type based on:

  • Network Topology: Which device can initiate connections
  • DICOM Infrastructure: Scanner-direct vs. PACS-based workflows
  • Security Requirements: Inbound vs. outbound firewall rules
  • Operational Preferences: Push-based vs. pull-based data flow
  • Deployment Model: Whether in-cluster deployment is desired

Both connector types support identical data processing, metadata extraction, and upload capabilities once data is acquired.