Skip to content

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

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

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:

  • Check for data in Unknown Group or Unsorted Projects
  • Review upload success rates by scanner
  • Assess data organization quality

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

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

  • Implement encrypted communication between scanners and Flywheel
  • Configure appropriate firewall rules for DICOM traffic
  • Regular security audits of DICOM network infrastructure

Data Privacy

  • Configure anonymization rules (de-identification profiles) appropriate for your institution
  • Ensure routing strings do not contain protected health information (PHI)
  • Monitor uploaded data for unintended PHI exposure

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