DICOM in Teleradiology: How the Standard Enables Remote Image Reading

DICOM is the technical standard that makes teleradiology possible — it defines how medical images are formatted, packaged with patient and study metadata, transmitted across networks, and rendered in viewers regardless of which manufacturer made the modality or which platform reads the study.

For an IT director or radiology informatics team evaluating a teleradiology platform, the operational questions are protocol-level: which DICOM transmission method does the platform use, how does the modality worklist propagate across hospital boundaries, how do studies get routed when a single radiology group reads for multiple sites, what happens when transfer syntaxes don’t match between source and destination, and how do reports come back to the originating EHR.

This guide covers each of those mechanics. It’s the technical layer beneath the teleradiology workflow—not generic DICOM education, nor the operational view of how a study moves through the workflow. For those, see the teleradiology hub and the DICOM standard guide.

Why DICOM matters specifically for teleradiology

Teleradiology relies on DICOM because every step in moving a study from the originating site to the radiologist and back relies on DICOM-defined behaviors — image format, network transfer, metadata association, and report packaging.

The teleradiology workflow has four points where the standard matters operationally. At the modality, DICOM defines the file format that the scanner outputs. On the wire, DICOM defines either the legacy DIMSE network protocol (C-STORE, C-FIND, C-MOVE) or the modern web protocol (DICOMweb — WADO-RS, QIDO-RS, STOW-RS) used to transmit the study. In the radiologist’s viewer, DICOM defines how pixel data is decompressed, how windowing presets are applied, and how priors are matched to the current study. On the report return, DICOM Structured Reporting (SR) optionally encodes the radiologist’s findings as structured DICOM objects rather than free text.

Without the standard, none of this works across site boundaries. A radiologist in one city reading studies acquired in another would need a separate viewer and integration for each modality vendor and each originating PACS. DICOM is what collapses that fragmentation into a single interoperable layer.

The DICOM transmission workflow described here enables the teleradiology benefits that make remote interpretation operationally viable at scale.

DIMSE vs DICOMweb: two protocols, two architectures

Teleradiology image transmission uses one of two DICOM network protocols: classic DIMSE (the original DICOM network services — C-STORE, C-FIND, C-MOVE) or DICOMweb (the modern RESTful web services — WADO-RS, QIDO-RS, STOW-RS). The choice between them determines almost everything else about how the platform is deployed.

Classic DIMSE was designed in the early 1990s for hospital LANs. It assumes both endpoints are on the same trusted network, communicates over TCP port 104 (or 11112), and requires explicit DICOM Application Entity Title configuration on both sides. For teleradiology, DIMSE means VPN tunnels between the originating hospital and the radiology group, with a DICOM listener on the radiology group’s side accepting C-STORE pushes from each connected hospital.

DICOMweb is RESTful HTTP. Studies move over HTTPS, authentication uses standard web mechanisms (OAuth, API keys, signed URLs), and the protocol is firewall-friendly because it rides standard port 443. For cloud-native teleradiology platforms, DICOMweb is the default — it eliminates the need for a VPN tunnel, simplifies multi-tenant routing, and supports browser-based, zero-footprint viewers without any thick-client middleware.

When each makes sense in a teleradiology setup

Scenario	DIMSE (C-STORE / C-FIND / C-MOVE)	DICOMweb (STOW-RS / QIDO-RS / WADO-RS)
Originating site connection	VPN tunnel between hospital and radiology group	HTTPS over public internet
Firewall posture	Custom port 104/11112 must be opened	Standard port 443 — no firewall changes
Authentication	AE Title + IP whitelist	OAuth, API keys, signed URLs
Best for	Legacy on-premise PACS, high-bandwidth dedicated links	Cloud teleradiology, multi-site networks, browser-based viewers
Failure mode	VPN drops mid-transfer, AE Title misconfiguration, port blocking	Network latency, OAuth token expiry, payload size limits
Multi-site scaling	Each hospital needs its own VPN tunnel and AE config	Single endpoint, tenant-aware routing

Most cloud-native teleradiology platforms now run in a hybrid mode: a small DICOM gateway at the originating site speaks classic DIMSE to the local PACS and modalities, then translates to DICOMweb for transmission to the cloud. This isolates the legacy DIMSE complexity within the hospital firewall while giving the radiologist the benefits of cloud-native systems.

DICOMweb in detail: WADO-RS, QIDO-RS, STOW-RS

DICOMweb is not a single protocol — it’s three RESTful services that map to the three things teleradiology needs to do with images: store, search, and retrieve. Each service is a separate HTTP endpoint with its own purpose.

STOW-RS — store over the web

STOW-RS handles study upload. The originating site (or its DICOM gateway) sends an HTTP POST containing one or more DICOM instances to a STOW-RS endpoint on the teleradiology platform. The platform validates the payload, stores the studies, and returns a status response. This is the DICOMweb equivalent of classic C-STORE, except over HTTPS and without VPN dependency.

QIDO-RS — query over the web

QIDO-RS handles search. A radiologist’s worklist queries a QIDO-RS endpoint to find studies matching specific criteria — patient ID, study date, modality, accession number, or any other DICOM tag. The endpoint returns a JSON or DICOM-formatted result set. For teleradiology, this is what populates the radiologist’s worklist when they log in.

WADO-RS — retrieve over the web

WADO-RS handles study retrieval. When the radiologist clicks a study in the worklist, the viewer makes WADO-RS calls to pull the study’s DICOM instances, frames, or metadata. WADO-RS supports partial retrieval — the viewer can request a single frame or a single instance rather than the whole study, which matters for large studies on slower connections.

Together, the three services cover the complete teleradiology cycle: STOW-RS to get the study to the platform, QIDO-RS to surface it on the radiologist’s worklist, WADO-RS to render it in the viewer. Modern platforms expose all three; older systems often expose only WADO-URI (the predecessor to WADO-RS) and require workarounds for the other operations.

Modality worklist across site boundaries

DICOM Modality Worklist (MWL) is the service that tells a modality which patient is being scanned and which order the scan is fulfilling. In single-site radiology, MWL is straightforward — the RIS publishes the worklist, and the modality queries it. In teleradiology, MWL gets complicated because the worklist crosses organizational boundaries.

Three patterns are common.

In the most common pattern, the originating site keeps its own MWL — the local RIS publishes worklist items to the local modalities, scanning happens normally, and the resulting study is then routed to the teleradiology platform. The teleradiology side only sees finished studies, not pending orders. This is the simplest model and works for nearly all common teleradiology setups.

In the second pattern, used when the teleradiology partner is providing primary radiology services (not just overflow), the teleradiology platform’s worklist is the authoritative source. Modalities at the originating site query the teleradiology platform’s MWL endpoint over a secure channel. This is rarer and operationally more complex because it requires the originating site to trust an external system for order-of-record.

In the third pattern, used by enterprise health systems with multiple imaging sites and a centralized teleradiology arm, a federated MWL service aggregates worklist items from each site’s local RIS and presents a unified view to the radiologist. This is the architecture most large IDNs converge on once the operational complexity of running several disconnected teleradiology setups becomes unmanageable.

For a teleradiology platform buyer, the right question is which pattern the platform supports natively and which require custom integration work. Custom integration adds months to deployment timelines.

DICOM gateways and routing rules

A DICOM gateway sits at the originating site and decides what happens to each study after acquisition — store it locally, route it to a teleradiology partner, route it to a specific subspecialty radiologist, send it to multiple destinations, or delay it until a condition is met.

Routing rules are the configuration layer that drives those decisions. Common rule types in production teleradiology setups include:

• Modality-based routing — chest CTs go to one radiology group, MSK MRIs go to another, mammography goes to a breast subspecialist.
• Time-based routing — studies acquired between 6pm and 7am go to the Nighthawk partner; daytime studies stay in-house.
• Priority-based routing — studies flagged STAT or with specific clinical indicators are pushed to the front of a priority queue rather than the standard FIFO worklist.
• Subspecialty-based routing — studies tagged with specific body parts or clinical indications route to subspecialists who hold the relevant credentials.
• Multi-destination routing — the same study is simultaneously stored in the local PACS and sent to the teleradiology platform, ensuring continuity if either system is unavailable.

Routing rules are typically expressed as a small DSL or rule table inside the DICOM gateway. Modern platforms increasingly include a graphical rule builder; older systems require manual configuration through DICOM AE Title definitions and file-based rule scripts. The complexity adds up — a teleradiology setup serving five hospitals with four subspecialty partners and two priority tiers can easily have 40+ routing rules to maintain.

Transfer syntax negotiation: when source and destination disagree

DICOM transfer syntax defines how the pixel data inside a DICOM instance is encoded and compressed. When the originating modality and the teleradiology platform support different transfer syntaxes, the protocol has to negotiate — and that negotiation can fail in ways that silently break the workflow.

A modality might output JPEG 2000 lossless. A teleradiology platform might expect Explicit VR Little Endian (uncompressed). When a C-STORE association opens, both sides exchange their supported syntaxes, and a common syntax has to be agreed upon before the transfer proceeds. If there is no overlap, the transfer fails.

Three failure modes are common in production teleradiology:

• The originating site sends a transfer syntax that the cloud platform doesn’t decode natively, and the platform stores the study, but the viewer can’t render it. The radiologist opens the study and sees a blank window.
• The originating site uses a proprietary or vendor-specific compression that’s technically DICOM-conformant but not widely supported. The study is stored, the viewer renders it incorrectly (wrong colors, missing frames), and the radiologist doesn’t realize the rendering is wrong until it surfaces in a discrepancy.
• The originating site sends Big Endian (rare but possible from older modalities) to a platform that only supports Little Endian. The transfer succeeds, but pixel values are byte-swapped, making the image visually correct but quantitatively wrong — measurement tools return incorrect values.

The defensive practice is to standardize on a small set of transfer syntaxes at the gateway — typically Explicit VR Little Endian for uncompressed, JPEG Lossless for compressed — and transcode anything else at ingest. This adds CPU overhead at the gateway but eliminates the silent-failure modes downstream.

Compression and bandwidth: lossless vs lossy in teleradiology

Teleradiology platforms support both lossless and lossy DICOM compression — the choice is regulatory, clinical, and operational, not just technical.

Lossless compression (JPEG-LS, JPEG 2000 Lossless, RLE) reduces file size by 30–60% with no loss of pixel data. Decompressed images are bit-identical to the original. Lossless is the safe default for teleradiology and the only legally defensible choice for primary diagnosis in most jurisdictions — the radiologist is reading the same data the modality acquired.

Lossy compression (JPEG, JPEG 2000 Lossy) reduces file size 5x to 20x by discarding pixel data the algorithm classifies as visually unimportant. For mammography and CT in particular, regulatory bodies (FDA, MHRA, equivalents) restrict primary diagnosis from lossy-compressed images. For non-diagnostic uses — clinical reference, secondary review, patient consultations — lossy is acceptable and dramatically reduces transmission time.

In teleradiology setups with bandwidth-constrained originating sites, the practical pattern is two-tier compression: studies are transmitted losslessly to the cloud archive, then the viewer streams a lossy-compressed preview for the first frame so the radiologist can start reviewing while the full lossless study finishes downloading in the background. Modern WADO-RS implementations support this via the Accept-Encoding header: the viewer requests a specific quality level for the initial frames and full quality for subsequent retrievals.

DICOM Structured Reporting (SR) for report return

DICOM Structured Reporting (SR) is an alternative to free-text reports that encodes the radiologist’s findings as structured DICOM objects — coded terminology for findings, measurements with units, and references to specific image regions.

In a typical teleradiology setup, the report return path uses HL7 ORU messages or FHIR DiagnosticReport resources. SR is a third option that preserves more clinical structure than free text but is supported less consistently across EHRs. Where it does work — radiation oncology workflows, specific cardiology reads, structured measurement protocols — it produces reports that downstream systems can parse without the need for natural language processing.

For most teleradiology workflows in 2026, the realistic choice is HL7 ORU for the textual report plus optional DICOM Presentation State (GSPS) objects for the radiologist’s annotations on the images. Pure DICOM SR remains a future-state architecture for most setups.

How Medicai handles DICOM in its teleradiology workflow

Medicai’s platform uses DICOMweb (WADO-RS, QIDO-RS, STOW-RS) as the primary transmission protocol and runs an on-premise DICOM gateway at originating sites that translates local DIMSE to cloud DICOMweb.

The gateway approach addresses the mixed-environment reality most customers encounter. The originating site retains its existing modalities and on-premises PACS, which speak the classic DIMSE. The gateway accepts C-STORE pushes from those modalities, transcodes the transfer syntax to a standardized format, applies any configured routing rules, and forwards the studies to the cloud via DICOMweb. The radiologist on the cloud side never sees the DIMSE complexity — they get a unified web-based worklist that aggregates studies from every connected site.

Transfer syntax normalization at the gateway is the operational detail that prevents most silent-failure modes — studies arrive at the cloud archive in a known, viewer-supported syntax regardless of what the originating modality emitted. Routing rules are configured per-tenant through a graphical rule builder rather than file-based scripts.

For full architectural depth on cloud PACS integration, see the cloud PACS commercial page on the main site.

Frequently asked questions about DICOM teleradiology

Does DICOM support teleradiology?

Yes — DICOM is the underlying standard that enables teleradiology. It defines the image format, the network protocols (DIMSE and DICOMweb) used to transmit studies between sites, and the metadata structure that keeps each study connected to its patient and clinical context.

What’s the difference between DIMSE and DICOMweb?

DIMSE is the classic DICOM network protocol from the early 1990s — it runs over TCP on dedicated ports and assumes a trusted network. DICOMweb is the modern RESTful equivalent — it runs over HTTPS on standard port 443 and works across the open internet without VPN tunnels. Most modern cloud teleradiology platforms use DICOMweb.

What are WADO-RS, QIDO-RS, and STOW-RS?

They are the three RESTful services that make up DICOMweb. STOW-RS uploads studies to a server, QIDO-RS searches for studies matching specific criteria, and WADO-RS retrieves study data for viewing. Together, they cover the complete cycle of moving a study through a teleradiology workflow.

How does the DICOM modality worklist work in teleradiology?

In most teleradiology setups, the originating site’s RIS publishes its own modality worklist to local scanners, and the teleradiology platform only sees finished studies. When the teleradiology partner is the primary radiology service, the platform may publish the worklist instead, and modalities query the platform directly. Federated worklist services aggregate across multiple sites in larger deployments.

What is a DICOM gateway?

A DICOM gateway is a software component that sits at the originating site and routes DICOM studies based on configurable rules. It accepts studies from local modalities and PACS using DIMSE, applies routing logic (by modality, time, priority, or subspecialty), and forwards studies to teleradiology platforms or cloud archives — typically translating to DICOMweb in the process.

Should teleradiology use lossy or lossless DICOM compression?

Lossless compression is the safe default and the only legally defensible choice for primary diagnosis in most jurisdictions. Lossy compression is acceptable for non-diagnostic uses, such as clinical reference or patient consultations. Many teleradiology platforms send a lossy preview of the first frame for fast initial review and stream the full lossless study in the background.

Can DICOM transfer syntax mismatches cause problems?

Yes — transfer syntax mismatches between the originating modality and the teleradiology platform can cause silent rendering failures, byte-order errors that produce visually correct but quantitatively wrong images, and unsupported syntax errors that block transfers entirely. Standardizing on a small set of transfer syntaxes at the gateway, with transcoding at ingest, prevents most of these failures.

Is DICOM Structured Reporting (SR) used in teleradiology?

DICOM SR is supported by most teleradiology platforms but used inconsistently. Most workflows still rely on HL7 ORU messages or FHIR DiagnosticReport for the textual report, with optional DICOM Presentation State (GSPS) objects carrying the radiologist’s annotations. Pure SR is more common in specific structured-measurement workflows like radiation oncology than in general radiology.

Where DICOM in teleradiology is heading

Three trends are reshaping the protocol layer over the next few years. DICOMweb is steadily replacing classic DIMSE as the primary transmission protocol — most cloud-native platforms have already made the switch, and on-premise PACS vendors are adding DICOMweb support to their existing DIMSE stacks. AI-driven routing is moving beyond simple rule-based gateways toward platforms that learn which radiologist reads each modality fastest, which subspecialty assignments yield the lowest discrepancy rates, and how to dynamically balance worklist load. And structured reporting is gaining ground in jurisdictions with strong reimbursement incentives for structured data — slowly, but in the direction of more SR adoption rather than less.

For the broader picture of where DICOM teleradiology infrastructure is going, see the future of teleradiology.