DICOM Connector Deployment Planning Guide
Introduction
This guide helps you understand deployment options and prepare for DICOM Connector implementation. Use this information when planning your deployment with Flywheel.
Flywheel manages all aspects of DICOM Connector deployment, configuration, and maintenance. Your role is to provide infrastructure (for edge deployments), network access, and collaborate on configuration decisions.
Deployment Decision Framework
Step 1: Determine Connector Type Requirement
The connector type fundamentally determines your deployment options.
Do you need PULL or PUSH?
Choose PULL if:
- You need to query and retrieve data from scanners or PACS
 - Your DICOM devices cannot send data outbound
 - You require direct control over query timing and frequency
 - You have direct network access to DICOM devices
 
Choose PUSH if:
- Your scanners or PACS can send data to an endpoint
 - You want devices to initiate transfers
 - You prefer event-driven data flow
 - Your workflow is PACS-based
 
Impact on Deployment:
- PULL connectors require edge device deployment (on-premises)
 - PUSH connectors support both edge device and in-cluster deployment
 
Step 2: Evaluate Deployment Model Options
If you selected PUSH connector, you have two deployment options. If you selected PULL, skip to Step 3 (edge device deployment).
Edge Device Deployment
What You Provide:
- On-premises VM or dedicated hardware
 - Typical resources: 4 CPU and 16 GB RAM
 - Static IP address for the Connector
 - Network access between Connector and DICOM devices
 - Physical or network security for the Connector
 
Network Requirements:
- Outbound HTTPS to Flywheel Core (port 443)
 - Outbound SSH (port 22) for Flywheel maintenance
 - Inbound SSH from Flywheel IP addresses (for remote management and maintenance)
 - Inbound DICOM connections from authorized devices only
 - Firewall rules allowing required connections
 
Security Characteristics:
- DICOM traffic stays on your intranet
 - Physical network isolation for DICOM communication
 - Only HTTPS traffic traverses public internet
 - Traditional security model
 
Best For:
- Organizations with existing on-premises infrastructure
 - Strict network isolation requirements
 - Environments where internet exposure is prohibited
 - PULL connector requirements
 
In-Cluster Deployment (PUSH Only)
What You Provide:
- Static IP addresses for DICOM devices
 - Certificates for mutual TLS (typically customer-provided)
 - Network configuration to allow outbound connections
 
Network Requirements:
- Outbound connections from DICOM devices to Flywheel (HTTPS with mTLS)
 - No inbound internet connections required
 - Firewall rules allowing outbound HTTPS connections
 
Security Characteristics:
- Certificate-based mutual authentication
 - All DICOM traffic encrypted with mTLS
 - No on-premises infrastructure required
 - Modern security model over public internet
 
Best For:
- Organizations minimizing infrastructure deployment
 - Fully managed cloud service preference
 - mTLS security meets compliance requirements
 - PUSH connector workflows
 
Step 3: Assess Security Requirements
Review your organization's security policies against deployment requirements.
Network Security Policies
Questions to Consider:
- Can DICOM devices send traffic over the public internet with mTLS encryption?
 - Do you have policies requiring complete network isolation for medical imaging traffic?
 - Can you obtain and manage certificates for mTLS?
 - What firewall rules can be implemented for outbound HTTPS traffic?
 
Edge Device Requirements:
- No inbound internet traffic to Connector (critical)
 - Outbound HTTPS traffic to Flywheel Core
 - Inbound DICOM traffic from authorized devices only
 - Network segmentation from unrelated systems
 
In-Cluster Requirements:
- Outbound HTTPS traffic with mTLS from DICOM devices
 - Certificate management and renewal processes
 - IP address allowlisting
 
Data Privacy Requirements
Questions to Consider:
- When must data be de-identified (before leaving network vs. after upload)?
 - What level of de-identification is required?
 - Are there specific compliance frameworks you must meet?
 
Both Deployment Models Support:
- De-identification before data leaves your network (configured at Connector)
 - De-identification after upload to Flywheel
 - Customizable de-identification profiles
 
Step 4: Plan Infrastructure Resources
For Edge Device Deployment
Hardware or VM Requirements:
- 4 CPU cores (minimum)
 - 16 GB RAM (minimum)
 - 100 GB storage for temporary data processing
 - Static IP address
 - Network interface for DICOM network
 - Network interface for internet connection (can be same interface)
 
Network Infrastructure:
- Ability to reach all DICOM devices (scanners, PACS)
 - Outbound internet connectivity to Flywheel
 - Firewall capability for outbound HTTPS rules
 
Access Requirements:
- SSH access for Flywheel installation, configuration, and maintenance
 - Ability to coordinate firewall changes (including SSH allowlist for Flywheel IPs)
 - Network connectivity for remote management
 
For In-Cluster Deployment
Minimal Infrastructure:
- Static IP addresses for all DICOM devices
 - Certificate management capability
 - Firewall coordination for outbound rules
 
Certificate Requirements:
- Obtain certificates (public or private)
 - Coordinate with Flywheel for deployment
 - Plan renewal processes
 
Static IP Address Requirements
Critical Requirement: All devices participating in DICOM communication must have static IP addresses.
Why Static IPs Are Required
The DIMSE protocol fundamentally requires static IP addresses for all participating devices:
- DICOM nodes use IP addresses as a primary authentication mechanism
 - DICOM nodes maintain allowlists of authorized IP addresses
 - Dynamic IPs create security risks if reassigned to unauthorized devices
 - IP changes cause communication failures without warning
 - Even with mTLS, connections are rejected if IP is not on allowlist
 
Planning Considerations
Before Deployment:
- Document all DICOM device IP addresses
 - Document Connector IP address (required for both edge and in-cluster deployments)
 - Ensure IP addresses are statically assigned (not DHCP)
 - Plan for IP address documentation maintenance
 - Coordinate with network team for any changes
 
Devices Requiring Static IPs:
- All scanners sending to or queried by Connector
 - All PACS systems involved in data flow
 - The Connector itself (required for both edge device and in-cluster deployments)
 
Network Topology Assessment
Current Network Architecture
Document Your Environment:
- Network diagram showing DICOM devices, networks, and internet connectivity
 - Firewall locations and policies
 - VLAN segmentation for medical imaging
 - Internet gateway and proxy configuration
 
Firewall Planning
For Edge Device Deployment
Inbound Rules (from DICOM network to Connector):
- Allow DICOM traffic from authorized device IPs only
 - Block all other inbound DICOM traffic
 - Implement network segmentation
 
Outbound Rules (from Connector to internet):
- Allow HTTPS to Flywheel Core (port 443)
 - Allow outbound SSH (port 22) for Flywheel maintenance
 - Block all other outbound traffic (optional, for security)
 
Internet Rules (from internet to Connector):
- Block all inbound connections except SSH for Flywheel maintenance
 - Allow inbound SSH from Flywheel IP addresses only (for remote management and maintenance)
 
For In-Cluster Deployment
Outbound Rules (from DICOM devices to internet):
- Allow HTTPS to Flywheel (port 443)
 - mTLS secured connections
 
No Inbound Rules Required:
- All traffic is outbound from customer network
 
Bandwidth Considerations
Upload Volume Estimation:
- Average study size: 50-500 MB (varies by modality)
 - Number of studies per day
 - Total daily upload volume
 
Bandwidth Planning:
- Account for concurrent uploads
 - Consider working hours restrictions if needed
 - Plan for peak usage periods
 
Example Calculations:
- 100 studies/day × 200 MB average = 20 GB/day
 - Over 8-hour working day = 2.5 GB/hour = ~5.5 Mbps sustained
 - Consider 2-3x multiplier for peak periods
 
Preparation Checklist
Information Gathering Phase
- [ ] Identify all scanners and PACS systems sending data to Flywheel
 - [ ] Document current DICOM network architecture
 - [ ] List all DICOM device IP addresses and AE Titles
 - [ ] Identify current firewall locations and policies
 - [ ] Determine available bandwidth for uploads
 - [ ] Review security and compliance requirements
 - [ ] Assess available on-premises infrastructure (if considering edge deployment)
 
Decision Phase
- [ ] Determine connector type requirement (PULL or PUSH)
 - [ ] Choose deployment model (edge device or in-cluster)
 - [ ] Confirm security requirements can be met
 - [ ] Validate firewall rules can be implemented
 - [ ] Plan certificate management (if in-cluster)
 - [ ] Decide on de-identification requirements
 
Resource Planning Phase
For Edge Device:
- [ ] Provision VM or hardware meeting resource requirements
 - [ ] Assign static IP address to Connector
 - [ ] Plan network connectivity to DICOM devices
 - [ ] Plan internet connectivity for outbound HTTPS
 - [ ] Coordinate SSH access for Flywheel (request Flywheel IP addresses for allowlist)
 
For In-Cluster:
- [ ] Obtain or plan to obtain certificates
 - [ ] Coordinate outbound firewall rule changes
 - [ ] Document DICOM device static IPs
 
Pre-Deployment Phase
- [ ] Finalize network diagram with planned Connector placement
 - [ ] Document all static IP addresses
 - [ ] Prepare firewall change requests
 - [ ] Coordinate certificate provisioning (if applicable)
 - [ ] Identify test scanner for initial validation
 - [ ] Plan training for scanner operators
 - [ ] Establish communication channels with Flywheel
 
Coordination with Flywheel
Information to Provide:
- Connector type preference (PULL or PUSH)
 - Deployment model preference (edge or in-cluster)
 - Network topology diagram
 - List of DICOM devices (IPs and AE Titles)
 - Firewall capabilities and constraints
 - Certificate details (if in-cluster)
 - De-identification requirements
 - Bandwidth constraints or working hours needs
 - Flywheel IP addresses for SSH access allowlist (edge device deployment)
 
Next Steps
After completing your planning assessment:
- Document Decisions: Capture your deployment model, connector type, and key requirements
 - Gather Required Information: Complete the preparation checklist
 - Engage Flywheel: Schedule planning discussion with Flywheel team
 - Coordinate Resources: Begin provisioning infrastructure or certificates as needed
 - Plan Testing: Identify test scanner and validation approach
 
Related Resources
- DICOM Connector Overview - Feature overview and key concepts
 - Infrastructure Reference - Detailed infrastructure and networking specifications
 - Hierarchy Mapping Guide - How DICOM maps to Flywheel hierarchy
 - Metadata Extraction Guide - Metadata processing mechanics
 - Advanced Configuration Guide - Advanced metadata extraction and configuration
 - Admin Guide - Ongoing management and operations
 - User Guide - Scanner operator instructions