Receiving DICOM from a hospital over the internet

Do you build software for radiology or imaging — a cloud PACS, an AI diagnostic platform, a teleradiology service? You’ll eventually need to receive DICOM studies from a hospital’s own equipment: a CT scanner, an MRI console, or the hospital’s PACS itself. That’s straightforward on a hospital’s internal network. It gets harder once the sender and your service sit on different networks, talking over the public internet.

This article covers what’s different, and the two practical ways to bridge the gap.

Why hospital-to-internet DICOM is a different problem

DICOM was designed for a LAN. The core transfer protocol, C-STORE (part of the DIMSE message set), assumes both sides can open a direct TCP connection — scanner to PACS, PACS to workstation. That connection lives inside a hospital’s private network, usually unencrypted, on port 104 or 11112.

Send that same C-STORE traffic across the internet and three problems show up immediately:

1. No encryption by default. Plain DICOM has no required transport security. Sending patient imaging data over the public internet in the clear is not something you can ship.
2. No authentication beyond an AE title. A DICOM Application Entity (AE) title is a self-declared 16-character name — nothing stops a sender from claiming to be one it isn’t.
3. Firewalls and NAT. Hospitals don’t open inbound ports to arbitrary internet hosts, and most cloud services don’t want a hospital’s IT department punching holes in their firewall either.

None of these are DICOM problems exactly. They’re the reason a hospital’s radiology department and your cloud service can’t just point a C-STORE association at each other and expect it to work safely.

Two ways to bridge the gap

1. Run DICOM software inside the hospital

Some vendors ship an on-premises component — a small server or appliance that lives inside the hospital’s network, receives C-STORE traffic locally, and forwards it out over HTTPS. This works.

But it means you’re now shipping and supporting software on someone else’s network. That’s OS patches, firewall exceptions, a support contact on the hospital’s IT team, and a deployment for every new site. For a platform onboarding many hospitals, that overhead compounds fast.

2. Terminate the DICOM connection at the edge, over mTLS

The alternative is to expose a public-internet-facing DICOM endpoint that accepts inbound connections directly from the hospital’s scanner or PACS, with no on-premises component required. It translates each instance into a standard web request as it arrives.

This is only safe if the connection itself is authenticated and encrypted end to end. Mutual TLS (mTLS) is the mechanism for that. Each sending device holds a client certificate, the server holds its own certificate, and both sides verify each other before any DICOM data moves. See our breakdown of mutual TLS for DICOM connections for how that works in detail, or compare this model with site-to-site VPN tunnels.

Once the connection is authenticated, the incoming DICOM instances need to reach your infrastructure in a format your team can actually build against. That’s where DICOMweb STOW-RS comes in — a standard HTTP-based way to receive DICOM instances as a multipart/related POST, instead of a raw DIMSE association. See how C-STORE differs from DICOMweb STOW-RS for the comparison.

Dicomly implements this second approach. Hospitals and their scanners connect over mTLS to a public DICOM endpoint. Your service receives each study as a real-time STOW-RS HTTPS POST — no per-hospital appliance, no DICOM protocol stack on your side.

What this changes for your architecture

If you’re receiving DICOM this way, your service only ever needs to speak HTTP. You accept a standard HTTPS request the same way you’d accept a webhook from any other API. You don’t parse DIMSE associations, manage AE title tables, or run a PACS-facing listener yourself. The DICOM-specific handshake (association negotiation, C-STORE, transfer syntax negotiation) happens on the DICOM side of the bridge, before your service is ever involved.

That’s a meaningful simplification if your core product isn’t a DICOM stack — it’s whatever you do with the imaging data once you have it.

Where to go from here

If you’re evaluating how to receive DICOM from hospitals without building or hosting a DICOM listener yourself, request early access. Or read the quickstart to see the full flow end to end.