DICOM Connector Admin Guide

Introduction

This guide provides Site Administrators with instructions for configuring and managing the DICOM Connector service that uploads data from scanners and PACS systems to Flywheel. This covers system setup, user guidance, and troubleshooting for inbound data transfers.

Prerequisites

To complete the tasks in this guide, you need:

• Site Admin role in Flywheel
• Network access to scanner and PACS systems
• Knowledge of your institution's imaging infrastructure

Configure Scanner Integration

Determine Scanner Console Fields

Each scanner manufacturer uses different fields for routing information. The field used is configurable per site and typically includes Patient Comments, Additional Info, or similar fields. Check with your institution's Flywheel Site Admin to determine the specific field configured for each scanner at your site.

Establish Site Routing Standards

Create consistent routing patterns for your institution:

1. Group Organization: Define how departments or research units map to Flywheel Groups
2. Project Naming: Establish naming conventions for studies (e.g., study-parkinsons-2024)
3. Subject Identifiers: Specify format requirements (e.g., sub-001, patient-abc123)
4. Session Naming: Define session patterns (e.g., ses-baseline, ses-followup-6mo)

Example routing structure:

1
2

fw://neurology/parkinsons-longitudinal/sub-001/ses-baseline
fw://radiology/emergency-trauma/case-20241201/ses-initial

Configure Upload Policies

Opt-out Configuration (Recommended)

When to use: Most research and clinical environments where data loss risk should be minimized.

How it works:

• All scans upload to Flywheel by default
• Users enter an opt-out string at the scanner console to prevent upload
• Reduces training requirements and risk of missed data

Setup considerations:

• Define clear opt-out string (e.g., NOFW, NO-UPLOAD)
• Train scanner operators on when and how to use opt-out
• Document opt-out procedures for different scanner types

Opt-in Configuration

When to use: Highly sensitive environments or pilot implementations where upload control is critical.

How it works:

• Scans upload only when users enter an opt-in string
• Requires active decision for each scanning session
• Provides maximum control over data flow

Setup considerations:

• Define clear opt-in string (e.g., UPLOAD, FW-YES)
• Ensure consistent user training and compliance
• Monitor for missed uploads due to user error

Understanding Deployment Options

Flywheel manages all DICOM Connector deployment, configuration, and maintenance. Understanding deployment options helps you plan infrastructure, security, and network requirements.

Edge Device Deployment

The DICOM Connector runs on customer-managed infrastructure at your facility:

Infrastructure Requirements:

• On-premises VM or dedicated hardware
• Typical resources: 4 CPU and 16 GB RAM
• Static IP address for the Connector
• Network access to DICOM devices and scanners

Network Security:

• DICOM communication stays on your controlled intranet
• Only outbound HTTPS traffic to Flywheel Core traverses the public internet
• No inbound internet connections required
• Firewall must allow outbound HTTPS to Flywheel

Connector Types:

• Supports both PULL and PUSH connectors
• Required deployment model for PULL connectors

When to Choose:

• PULL connector is needed for your workflow
• Strict network isolation is required
• On-premises infrastructure is readily available
• DICOM devices cannot use public internet connections

In-Cluster Deployment

The DICOM Connector runs as a service within Flywheel infrastructure:

Infrastructure Requirements:

• No customer infrastructure needed
• Fully managed by Flywheel
• Static IP addresses for DICOM devices only

Network Security:

• Uses mutual TLS (mTLS) for secure DICOM communication over public internet
• Only outbound connections required from customer network
• Certificate-based authentication for all DICOM traffic
• Customers typically provide their own certificates (public or private)

Connector Types:

• Supports PUSH connectors only
• PULL connectors cannot be deployed in-cluster

When to Choose:

• PUSH connector meets workflow requirements
• Reducing infrastructure deployment costs is a priority
• Fully managed cloud deployment is preferred
• mTLS security meets your requirements

Deployment Decision Factors

Work with Flywheel to determine the appropriate deployment model:

• Connector Type: PULL requires edge device; PUSH supports both options
• Infrastructure: Whether you can provide on-premises resources
• Security Requirements: Network isolation vs. mTLS over internet
• Operational Model: Local management vs. fully managed service
• Cost Considerations: Infrastructure costs vs. service-based pricing

See the Deployment Planning Guide for comprehensive guidance.

Choosing Between PUSH and PULL Connectors

The connector type affects network architecture, security requirements, and operational workflows.

PULL Connector

The Connector actively queries DICOM devices to retrieve data:

Operational Characteristics:

• Connector initiates all communication
• Queries devices at scheduled intervals
• Retrieves data using DICOM FIND and MOVE operations

Network Requirements:

• Connector must reach DICOM devices (scanner or PACS)
• Outbound connections from Connector to devices
• Static IP addresses for all DICOM devices

Deployment:

• Must be deployed as edge device on-premises
• Must be within same network boundary as DICOM devices
• Cannot be deployed in-cluster

Best For:

• Direct scanner connections
• Small PACS systems
• Environments where outbound firewall rules are easier to manage

PUSH Connector

The Connector receives data sent from DICOM devices:

Operational Characteristics:

• Scanner or PACS initiates communication
• Sends data directly to Connector via DICOM C-STORE
• Connector monitors for received data

Network Requirements:

• DICOM devices must reach Connector
• Inbound connections to Connector (edge) or outbound mTLS connections (in-cluster)
• Static IP addresses for all DICOM devices

Deployment:

• Supports both edge device and in-cluster deployment
• In-cluster requires mTLS for security

Best For:

• PACS integrations
• Enterprise DICOM routing workflows
• Environments where in-cluster deployment is desired

Selection Criteria

Flywheel works with you to determine the appropriate connector type based on:

• Network topology and firewall capabilities
• Whether devices can initiate outbound connections
• DICOM infrastructure (scanner-direct vs. PACS-based)
• Deployment model preferences (edge vs. in-cluster)
• Security requirements and policies

Static IP Address Requirements

Work with your network team to ensure all DICOM devices have static IP assignments before deployment.

Operational Configuration Options

Flywheel configures operational parameters during deployment. Understanding these options helps you plan workflows and communicate requirements.

Working Hours Restrictions

The Connector can be configured to upload data only during specific time windows:

Purpose:

• Bandwidth management during business hours
• Compliance with data transfer timing requirements
• Network load balancing

How It Works:

• Specify time window in 24-hour format (e.g., 18:00 to 06:00)
• Connector pauses uploads outside the configured window
• Monitoring and querying continue, but uploads are deferred

Use Cases:

• Limit uploads to overnight hours to preserve daytime bandwidth
• Comply with policies restricting data transfers to specific times
• Coordinate with other network-intensive operations

Acquisition Delays

Configurable wait time between series discovery and upload:

Purpose:

• Ensure series are fully complete before transfer
• Prevent partial uploads of in-progress acquisitions
• Account for slow or delayed series completion

How It Works:

• Connector waits specified duration after detecting series completion
• Allows additional time for slow-writing scanners
• Reduces risk of uploading incomplete data

Use Cases:

• Scanners with slow disk writes or network connections
• Multi-part series that complete in stages
• Conservative approach to ensure completeness

Grace Periods

Time to keep references for data that has disappeared from source:

Purpose:

• Prevent re-upload of intentionally deleted data
• Handle temporary unavailability of source data
• Maintain state consistency

How It Works:

• Default: 7 days
• Connector remembers "vanished" data for configured period
• Does not re-upload data that reappears within grace period

Use Cases:

• Prevent duplicate uploads if data is temporarily moved
• Handle PACS maintenance or reorganization
• Avoid re-processing deleted test data

Monitoring Intervals

Configurable timing for various Connector operations:

Sleep Time:

• Time between checks for new data
• Typical: 60 seconds
• Affects how quickly new data is discovered

Query Time Threshold:

• Maximum query time before health concern
• Typical: 10 minutes
• Affects health monitoring and alerting

Reap Time Threshold:

• Maximum processing time before health concern
• Typical: 1 hour
• Affects health monitoring and alerting

Bandwidth Management Strategies

Combine operational options for effective bandwidth management:

Strategy 1: Overnight Uploads Only

• Configure working hours for evening/night uploads
• Preserves daytime bandwidth for clinical operations
• Suitable for non-urgent research data

Strategy 2: Conservative Completion

• Use acquisition delays to ensure series completeness
• Reduces partial uploads that consume bandwidth twice
• Suitable for unreliable network connections

Strategy 3: Batch Processing

• Combine working hours with longer sleep times
• Reduces frequency of queries and transfers
• Suitable for environments with many small studies

Work with Flywheel to configure operational parameters that match your bandwidth constraints and workflow requirements.

User Training and Documentation

Create Site-Specific Guides

Develop documentation tailored to your scanners and policies:

1. Scanner-Specific Instructions: Screenshots and step-by-step guides for each scanner model
2. Routing String Examples: Real examples using your institution's group and project names
3. Quick Reference Cards: Laminated cards for placement near scanner consoles
4. Troubleshooting Flowcharts: Common issues and resolution steps

Training Program Components

Initial Training:

• Overview of DICOM Connector purpose and benefits
• Hands-on practice with routing string entry
• Understanding of opt-in/opt-out policies
• Data verification procedures in Flywheel

Ongoing Education:

• Regular refreshers on routing procedures
• Updates when policies or systems change
• Best practices sharing between operators

Monitor System Performance

Upload Success Monitoring

Regular checks to ensure proper system operation:

Daily Monitoring:

• Check for data in Unknown Group or Unsorted Projects
• Review recent uploads for correct routing
• Verify expected scanning sessions have appeared
• Assess data organization quality

Weekly Analysis:

• Review upload success rates by scanner
• Identify patterns in routing errors
• Check for incomplete series or missing acquisitions
• Analyze working hours effectiveness (if configured)

Monthly Review:

• Evaluate overall system health trends
• Review bandwidth usage patterns
• Assess effectiveness of operational configurations
• Plan adjustments based on observed patterns

Operational Metrics

Understanding key performance indicators:

Upload Latency:

• Time from series completion to Flywheel upload
• Affected by monitoring intervals, delays, and working hours
• Longer for configurations with conservative completion settings

Series Completeness:

• Percentage of complete vs. partial series uploads
• Higher with appropriate acquisition delays
• Lower may indicate network issues or timing problems

Routing Accuracy:

• Percentage of uploads to correct vs. default locations
• Reflects user training effectiveness
• Improves with clear documentation and examples

Working Hours Impact:

• Volume of uploads during vs. outside configured hours
• Deferred uploads queued for next allowed window
• Monitor queue size during restricted periods

Troubleshooting Common Issues

Data Not Uploading

Symptoms: Scans complete but do not appear in Flywheel

Diagnostic steps:

1. Verify network connectivity between scanner and Flywheel
2. Check scanner console configuration for correct routing field
3. Confirm opt-in string was entered if required

Resolution:

• Test network connectivity and firewall settings
• Verify scanner configuration matches site standards
• Retrain users on proper console field usage
• Contact Flywheel Support for additional assistance with reviewing Flywheel connector logs and configuration

Data Appearing in Wrong Location

Symptoms: Data uploads but appears in Unknown Group or Unsorted Projects

Common causes:

• Missing fw:// prefix in routing string
• Typos in group, project, or subject names
• Use of incorrect console field for routing

Resolution:

1. Review routing string format with users
2. Provide updated examples of valid routing strings
3. Consider implementing routing string validation
4. Move misplaced data to correct locations

Incomplete Data Uploads

Symptoms: Some acquisitions from a session upload while others do not

Diagnostic steps:

1. Check for network interruptions during transfer
2. Review scan completion timing and series detection

Resolution:

• Investigate network stability and bandwidth
• Adjust DICOM Connector timing parameters if needed
• Contact Flywheel Support for additional assistance with Flywheel connector logs and configuration

Metadata Extraction Issues

Symptoms: Data uploads but metadata fields are empty, incorrect, or not as expected

Common causes:

• Custom metadata extraction patterns not matching DICOM data format
• DICOM tags missing or empty in source data
• Incorrect tag selection for institution's scanners
• Variations in DICOM tag formats across different scanner models

Diagnostic steps:

1. Verify DICOM tags contain expected values using DICOM viewer
2. Check for variations in DICOM tag formats across different scanners
3. Confirm routing field contains properly formatted routing string
4. Review uploaded data to identify patterns in missing or incorrect metadata

Resolution:

• Work with Flywheel to revise metadata extraction patterns
• Provide sample DICOM files from affected scanners for pattern testing
• Update scanner console field selection if current field is unreliable
• Consider alternative DICOM tags that are more consistently populated

Edge Device Connectivity Issues

Symptoms: Edge device Connector cannot reach scanners, PACS, or cannot upload to Flywheel Core

Common causes:

• Network connectivity issues between Connector and DICOM devices
• Firewall blocking required connections
• Incorrect static IP configuration
• DICOM devices missing Connector IP in their allowlists
• DNS resolution failures

Diagnostic steps:

1. Verify network connectivity from Connector to DICOM devices (ping, traceroute)
2. Confirm firewall allows outbound HTTPS to Flywheel Core
3. Check that Connector can resolve Flywheel hostnames
4. Verify Connector has correct static IP configuration
5. Confirm DICOM devices have Connector IP in their allowlists

Resolution:

• Work with network team to verify connectivity and firewall rules
• Update firewall rules to allow required connections
• Verify and correct static IP configuration
• Add Connector IP to DICOM device allowlists
• Contact Flywheel Support for assistance with Connector-side diagnostics and logs

Series Grouping Issues

Symptoms: Multiple DICOM series grouped into single Flywheel acquisition when they should be separate, or vice versa

Common causes:

• Multiple series with identical SeriesDescription but different purposes
• Scanner creates multiple series for same logical acquisition
• Default grouping behavior does not match workflow requirements

Diagnostic steps:

1. Examine DICOM metadata for affected series (SeriesDescription, SeriesInstanceUID, AcquisitionNumber)
2. Determine if grouping behavior is appropriate for workflow
3. Review whether scanner manufacturer uses non-standard series numbering
4. Check if multiple unrelated series share the same description

Resolution:

• For acceptable grouping: No action needed, behavior is by design
• For incorrect grouping: Work with Flywheel on custom configuration options
• Consider acquisition naming strategies (series number prefixing) to distinguish grouped series
• See Hierarchy Mapping Guide for explanation of grouping behavior

Data Organization Maintenance

Regular Cleanup Tasks

Daily:

• Review Unknown Group and Unsorted Projects for mis-routed data
• Move data to correct locations when possible

Weekly:

• Update user training materials based on common errors
• Review and clean up abandoned or test sessions

Monthly:

• Audit group and project organization
• Archive or delete obsolete test data
• Update documentation based on system changes

Security and Compliance

Network Security

Firewall Configuration:

• For edge deployments: Block all inbound internet traffic to Connector
• Allow only outbound HTTPS from Connector to Flywheel Core
• Restrict inbound DICOM traffic to authorized devices or networks
• Implement network segmentation to isolate Connector from unrelated systems
• Regular security audits of DICOM network infrastructure

Static IP Management:

• Maintain documentation of all DICOM device IP addresses
• Coordinate IP changes with Flywheel before implementation
• Monitor for unauthorized IP addresses attempting DICOM communication
• Regularly audit IP-based access controls

mTLS Considerations (In-Cluster Deployments):

• Ensure certificates are obtained and managed securely
• Coordinate certificate renewals with Flywheel
• Monitor certificate expiration dates
• Test connectivity after certificate changes

Data Privacy

De-identification:

• Configure anonymization rules (de-identification profiles) appropriate for your institution
• Anonymization occurs before data leaves your network (when configured at Connector level)
• Test de-identification rules with sample data before production
• Regularly audit anonymization effectiveness

PHI Protection:

• Ensure routing strings do not contain protected health information (PHI)
• Train users to use coded identifiers, not patient names
• Monitor uploaded data for unintended PHI exposure
• Establish procedures for handling accidental PHI uploads

Network Boundaries:

• Ensure Connector cannot be accessed from unauthorized networks
• For edge deployments, restrict DICOM traffic to medical imaging networks
• Implement network segmentation between DICOM and general networks
• Regular review of network access controls

System Updates and Maintenance

Planned Maintenance

• Test routing functionality after system updates
• Verify network connectivity following infrastructure changes
• Update user documentation when system behavior changes

Related Resources

• Deployment Planning Guide - Comprehensive deployment option guidance
• User Guide - Scanner operator instructions
• 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
• Naming Acquisitions for Classification - Classification best practices