DICOM Router

The Challenge

Telemedicine providers and medium-sized medical facilities struggle to connect imaging devices to modern infrastructure. Legacy DICOM systems are expensive ($50K+), vendor-locked, monolithic, and require extensive customization. Teams need a lightweight router that receives DICOM files from scanners, intelligently routes them to cloud storage (AWS S3, MinIO), triggers AI processing pipelines, and archives to other DICOM systems—without buying a full enterprise PACS they don't need.

Built as a pragmatic toolkit for the growing telemedicine market. Smaller clinics and telemedicine platforms need DICOM routing capability but can't justify expensive commercial PACS licenses. They want to leverage cloud services, connect AI processors, and scale to multiple imaging devices without deployment complexity. The system needs to handle real-world DICOM variety (different modalities, vendors, edge cases) while remaining simple enough to self-host.

Key Constraints

• Support standard DICOM C-STORE receiver for imaging devices
• Route files to multiple destinations: DICOM servers, AWS S3, MinIO, local storage
• Configurable rules: match by AE Title (calling entity), modality (CT, MR, etc.), and custom tags
• AI integration: send files to AI processors with callback webhooks and result tag-based routing
• Query existing PACS: C-FIND/C-MOVE support to retrieve images from external systems
• Web-based management: rule configuration, job tracking, destination health monitoring
• HIPAA compliance: full audit trail of all operations, user authentication, encrypted secrets
• Browser-based viewing: DICOMweb integration with OHIF Viewer for radiologist access
• Production-ready: graceful shutdown, connection pooling, panic recovery, race condition-free

Our Approach

Built a single Go binary that combines SCP receiver (DICOM C-STORE), routing engine, multi-destination dispatcher, retry worker, web UI, REST API, and DICOMweb support. PostgreSQL stores state (jobs, rules, destinations, audit logs). Go's concurrency model handles multiple simultaneous connections. Templ templates with HTMX provide lightweight interactive web UI without JavaScript bloat.

Key Technical Decisions

• Single binary in Go - type safety, fast execution, minimal resource footprint, easy to deploy
• Templ + HTMX over React - server-side rendering reduces complexity, HTMX for interactivity without heavy framework
• PostgreSQL for state - proper transactional guarantees, ACID compliance for audit logs, built-in connection pooling
• Rule-based routing with AET/Modality/Tags - covers 95% of real-world routing needs without requiring custom plugins
• Callback-based AI integration - AI processors run async, return results via webhook, enables long-running ML workloads
• C-FIND/C-MOVE SCU support - bridges to existing PACS, supports query and retrieve workflows without reimplementation
• DICOMweb (QIDO-RS, WADO-RS) - standard HTTP/JSON interface enables OHIF viewer integration and third-party tools
• Structured logging (slog) - production debugging, no external logging infrastructure required

Timeline: Iterative development over multiple phases. Core routing (4-6 weeks), Web UI (2-3 weeks), AI integration (3-4 weeks), DICOMweb (2-3 weeks), production hardening (ongoing)

Implementation

System Architecture

Single Go binary combines SCP server (obd-dicom library for DICOM handling), routing engine with rule evaluation, multi-destination dispatcher (goroutines with channels), retry worker, Gin web framework with REST API, Templ templates for server-rendered UI, PostgreSQL for persistent state (pgx driver, sqlc for type-safe queries). SCP receiver handles C-STORE protocol, parses DICOM files, stores atomically to disk with temp file pattern. Router evaluates rules in priority order, matches by AET pattern (*wildcard support), modality, and tag conditions. Dispatcher sends to destinations: DICOM (C-STORE SCU), S3/MinIO (native clients with secret encryption), file system (directory copy with date organization). Retry worker uses exponential backoff (30s, 1m, 5m, 15m, 30m) for failed jobs. C-FIND SCP receives queries, searches local PostgreSQL index. C-MOVE SCP handles retrieve requests. C-FIND/C-MOVE SCU clients query external PACS and retrieve studies. DICOMweb layer implements QIDO-RS (query via HTTP) and WADO-RS (retrieve metadata and frames). OHIF Viewer integrated on same server, launched with StudyInstanceUID. Web UI built with Templ (server-side templates), HTMX for interactive components (rules editor, destination testing), Alpine.js for lightweight client interactivity, Tailwind CSS for responsive design. PostgreSQL stores jobs (with per-destination status), routing rules, destinations (config + health status), AI processors, audit logs (7-year retention for HIPAA). User auth via JWT sessions with bcrypt-hashed passwords. Settings encrypted in DB (AES-256-GCM). Structured logging via slog for production debugging. Docker container runs single binary, mounts PostgreSQL connection, configurable via env vars. Nginx reverse proxy in front for TLS termination and connection multiplexing. Graceful shutdown on SIGTERM waits for in-flight jobs. Race detector passes in CI. Built and tested on Go 1.23+.

Technology Stack

Results & Impact

• Eliminated need for expensive enterprise PACS for telemedicine providers ($50K+ licensing → self-hosted toolkit)
• Enables clinics to integrate modern cloud workflows with legacy DICOM equipment immediately
• Supports AI integration without replacing DICOM infrastructure—processors plugged in via callbacks
• Provides standard DICOM/DICOMweb interfaces—compatible with any modern medical imaging tool
• Full audit trail for HIPAA compliance—every operation logged with user context and timestamps
• Browser-based DICOM viewing via OHIF Viewer—radiologists access studies through secure web interface
• Query existing PACS systems (C-FIND/C-MOVE)—bridges to legacy systems when needed
• Scales from single clinic with one scanner to telemedicine network with dozens of devices across locations

What We Learned

• DICOM is complex but standard - 3000+ page spec, but respecting protocol pays off in compatibility. Real-world testing with different vendors essential.
• Rule-based routing sufficient - initially designed for plugin system, but AET + Modality + Tags covers real-world requirements without added complexity.
• Go's concurrency is powerful - goroutines and channels handle multiple SCP connections elegantly. Proper testing with race detector essential.
• Lightweight UI wins - Templ + HTMX proved significantly lighter and more maintainable than React for this use case. Server-side rendering fits healthcare workflows.
• Audit logging from day one - HIPAA requirements drove logging architecture early. Building it in from start much easier than retrofitting.
• PostgreSQL flexibility - structured data (rules, jobs) mixed with semi-structured (DICOM metadata, S3 configs). JSONB and hstore proved valuable.
• AI callbacks beat polling - asynchronous webhook-based integration cleaner than polling AI services. Simplifies long-running ML workloads.
• Test with real data - synthetic DICOM files don't expose edge cases (legacy formats, vendor quirks, multi-frame images). Real hospital samples essential.
• DICOMweb bridges to modern - HTTP/JSON interface via QIDO-RS/WADO-RS opens door to web-based tools. OHIF viewer integration game-changer for remote radiologists.