dicom-gateway

A configurable DICOM gateway written in Rust, bridging DIMSE and DICOMWeb transports, including TLS handling. Designed to run as a Windows Service or a Linux systemd service.

Features

Frontends (inbound)

Frontend	Protocol	TLS
DIMSE SCP	C-FIND, C-GET, C-MOVE, C-STORE, C-ECHO	DICOM-TLS (PS3.15)
DICOMWeb HTTP	QIDO-RS, WADO-RS, STOW-RS	HTTPS

Additional Frontend

Frontend	Protocol	TLS
FHIR R4 HTTP	Patient, ImagingStudy (read + search)	HTTPS (shared with DICOMWeb)

The FHIR R4 frontend is only available with the Local Archive backend. It mounts alongside the DICOMWeb HTTP server (same port, same TLS) and allows querying DICOM information via FHIR. Retrieval can then be performed via DICOM (DIMSE or DICOMweb). The ImagingStudy.endpoint parameter points to the DICOMweb endpoint.

Backends (outbound)

Backend	Protocol	TLS
DICOMWeb	QIDO-RS, WADO-RS, STOW-RS	HTTPS via URL scheme
DIMSE SCU	C-FIND, C-GET, C-STORE	DICOM-TLS (PS3.15)

Additional Backend

Backend	Protocol	TLS
Local Archive	SQLite + filesystem	—
FHIR	Patient, ImagingStudy (search, create, update)	HTTPS

The local archive allows the DICOM gateway to work as a DICOM archive which can be access via DICOM DIMSE, DICOMweb and FHIR (for querying only).

For the "Local Archive" backend, the DIMSE SCP and DICOMWeb/FHIR (http) frontends can all run simultaneously (frontend.mode = "both") and share the same TLS certificate. See "Operation mapping" below.

Operation mapping

Inbound	Outbound
C-FIND	QIDO-RS query / Local Archive lookup
C-GET	WADO-RS retrieve / Local Archive read
C-MOVE	SEND-RS or WADO-RS / Local Archive read → C-STORE SCU to move destination
C-STORE	STOW-RS store / Local Archive write
C-ECHO	Check /health endpoint (fallback: make HEAD request)
QIDO-RS	C-FIND / Local Archive lookup
WADO-RS	C-GET or C-MOVE / Local Archive read
STOW-RS	C-STORE / Local Archive write
SEND-RS	C-MOVE
DELETE (non-standard)	Local Archive delete (archive backend only, [archive] allow_delete)

---

Documentation

• User Manual — installation, configuration reference, use cases, TLS, authentication
• DICOM Conformance Statement
• OpenAPI specification — DICOMweb HTTP frontend (QIDO-RS, WADO-RS, STOW-RS)
• arc42 documentation — goals, constraints, building blocks, decisions, risks, glossary

---

Authentication

Optional JWT Bearer token authentication can be enabled via the [auth] config section. When present, it is enforced on the DICOMWeb and FHIR HTTP frontends (Authorization: Bearer) and on the DIMSE SCP frontend (PS3.7 User Identity Negotiation, type 5). Validated tokens are transparently forwarded to the backend. Tokens are generated by the dicom-gateway-config GUI; only their SHA-256 hash is stored.

---

FHIR Server / Integration

When the archive backend is active, a small FHIR server frontend can expose stored DICOM data via Patient and ImagingStudy resources. It is possible to subscribe to these resources for updates via a rest-hook.

The archive backend can also connect to a FHIR server and create/update Patient and ImagingStudy resources there, along with an optional OAuth authentication.

---

Configuration

The gateway is configured via a TOML file (default: config.toml). Run with --config /path/to/config.toml.

See doc/manual/03_configuration_reference.md for the full key reference, TLS options, and C-MOVE destination setup.

---

Building & Installation

See INSTALL.md for build instructions, systemd and Windows Service setup, and how to run interactively.

Authors

Original Author:

Christof Schadt (christof dot schadt at mailbox dot org)

Icon

Icon by Freepik - Flaticon