Documentation

DINGO Public Docs

DINGO is a secure local web dashboard for planning, executing, verifying, and reporting DICOM migrations. These public docs focus on Docker deployment and day-to-day operator workflows.

Docker Deployment

DINGO Requirements

DINGO is recommended for Docker-based deployment. The container stack packages the web application, DCMTK tools, PostgreSQL, and persistent runtime folders into a repeatable local deployment.

Docker-first deployment Use the public Docker Hub repository and Docker Compose guidance for deployment. DINGO listens on port 4858 by default.

Host Environment

  • Docker Engine with the Docker Compose plugin.
  • Network access from the DINGO host to the Source PACS and Destination PACS.
  • Firewall rules that allow the DINGO web port and the required DICOM association traffic.
  • Persistent local or server-backed storage for DINGO data, logs, reports, and PostgreSQL.

Included In The Stack

  • DINGO web dashboard exposed on port 4858.
  • PostgreSQL service managed by Docker Compose.
  • DCMTK tools included inside the DINGO container.
  • Persistent volumes for configuration, operational logs, generated reports, and database files.

PACS Connectivity

  • Source PACS details for discovery and C-MOVE requests.
  • Destination PACS details for receiving studies and verification queries.
  • AE Titles, host names or IP addresses, and DICOM ports supplied by the PACS administrators.
  • Source PACS routing configured so C-MOVE requests can deliver studies to the Destination PACS.

Deployment Notes

  • Open DINGO at http://localhost:4858 after the stack starts.
  • Use Setup inside DINGO to configure PACS profiles, folders, notifications, and license activation.
  • Keep PostgreSQL private to the Docker network unless direct database access is intentionally required by the customer environment.
  • Back up persistent volumes before host maintenance or upgrades.

Lightweight Runtime

Minimal Hardware Footprint

DINGO has a small runtime footprint. The web dashboard, queue orchestration, verification workflow, and reporting tools are lightweight enough to run comfortably on modest local or virtual infrastructure.

The system can operate with very little CPU and RAM because it does not store image pixels inside the application database and does not perform diagnostic image processing. DINGO coordinates DICOM discovery, transfer requests, verification checks, reporting, and operator review.

Migration speed depends on the environment Throughput is usually driven by Source PACS performance, Destination PACS capacity, network speed, study size, study count, and selected parallelism rather than DINGO itself.
  • Use conservative parallelism first, then increase only when both PACS systems and the network can sustain it.
  • Monitor Jobs, Dashboard, and Performance Metrics during migration windows.
  • Scale the host according to the customer's migration window, operational monitoring needs, and report retention policy.

Workflow

Features And How To Migrate

DINGO organizes migration work into focused operational views. Operators move from setup, to discovery, to transfer, to verification, to issue review and final reporting.

01

Configure Setup And AE Profiles

Configure the customer's Source PACS and Destination PACS connection details, choose the active AE Profile, test connectivity, and activate the DINGO license.

02

Discover Candidate Studies

Run Candidate Search to query the Source PACS for the date range and metadata needed for migration planning, dashboards, verification, and reports.

03

Run C-MOVE Migration

Launch controlled migration jobs for unmigrated candidates or selected retry scopes. Use filters and parallel job settings to shape each migration batch.

04

Verify Destination Counts

Run Verification against the Destination PACS and compare destination study counts with discovered source metadata.

05

Review And Retry Issues

Use Review Issues to inspect partial, missing, or error studies and retry migration or verification for selected items.

06

Generate Reports

Create audit-ready HTML migration status reports with optional customer branding and bilingual report text.

Operational Features

  • Dashboard: health checks, progress totals, migration completion, verification completion, and active job visibility.
  • Performance Metrics: migration throughput, timing, outcomes, retry rates, and slow-study visibility.
  • Jobs: job history, launch parameters, progress, cancellation, retry actions, and log review.
  • Schedule Rules: controlled migration windows that allow or block migration work according to customer operating hours.
  • Telegram Notifications: configurable startup, job outcome, report, migration status, and performance update messages.
  • Help: in-app guidance and customer PACS setup document generation for the active AE Profile.

Operator Guide

User Guide

This guide summarizes the normal DINGO operator flow for a Docker deployment. It assumes the Docker stack is running and the operator can open the web dashboard.

1. Open Setup

Configure the active AE Profile, confirm the application paths, activate licensing, and test database, DCMTK, Source PACS, and Destination PACS connectivity.

2. Run Candidate Search

Select the study date range, query template, and optional splitting or parallelism settings. Review discovered candidate counts on the Dashboard.

3. Plan Migration Batches

Use Migration filters such as date range, modality, max studies, and scope to launch controlled batches. If needed, use Schedule Rules to keep migration inside approved windows.

4. Monitor Progress

Use Dashboard for current status, Jobs for detailed progress and logs, and Performance Metrics to understand throughput and timing.

5. Verify The Destination

Run Verification after migration batches to check destination counts. Use targeted verification scopes when rechecking known issues.

6. Resolve Exceptions

Use Review Issues to filter, inspect, select, and retry specific studies that need attention.

7. Produce Evidence

Generate migration status reports and retain the generated files according to the customer's operational requirements.

Alerts

Telegram Notifications

DINGO can send operational alerts to a Telegram chat so migration teams can follow job activity, report generation, and scheduled status summaries without keeping the dashboard open all the time.

Keep the bot token private The Telegram bot token lets systems send messages as your bot. Store it only in DINGO Setup and do not post it in chats, tickets, screenshots, or public documentation.

1. Create A Telegram Bot

Open Telegram and start a chat with @BotFather, Telegram's official bot for creating and managing bots. Send /newbot, choose a display name, then choose a bot username that ends in bot.

2. Copy The Bot Token

After the bot is created, BotFather returns a bot token. Copy it and save it securely. In DINGO, open Setup, go to Notification Channels, and paste the token into the Telegram Bot Token field.

3. Create A Group Chat

Create a Telegram group for the migration team, add the new bot to the group, and send a short test message in the group. A dedicated group keeps migration notifications separate from personal chats.

4. Get The Chat ID

Use Telegram's Bot API getUpdates method after sending a group message to the bot. Open https://api.telegram.org/bot<BOT_TOKEN>/getUpdates in a browser, replace <BOT_TOKEN> with your token, then look for the group chat id value in the response. Group chat IDs are often negative numbers.

5. Configure DINGO

Paste the Chat ID into DINGO's Telegram Chat ID field, enable Telegram Notifications, choose the alert events you want, then use Send Test Message to confirm DINGO can post to the group.

6. Run With Selected Alerts

Once the test message works, DINGO can send alerts automatically according to the events selected in Setup. You can change the event selection later without recreating the bot.

Available Alerts

  • DINGO Engine Started: confirms the DINGO service is running.
  • Job Completed: reports successful job completion and relevant job counts.
  • Job Failed: notifies the team when a job stops because of an error.
  • Job Cancelled: confirms an operator stopped a queued or running job.
  • Status Report Generated: sends a migration status report notification and can include the generated report attachment.
  • Scheduled Migration Status Updates: sends periodic migration totals, verification totals, attention counts, and active job progress.
  • Scheduled Performance Updates: sends periodic performance summaries for the selected reporting window.

For Telegram platform details, see Telegram's official Bot Features and getUpdates documentation.