Skip to content

DICOM Push Connectivity Requirements

This page explains what your imaging device — or a network appliance in front of it — must be able to do in order to send DICOM data to Flywheel using DICOM Push. DICOM Push secures every connection with mutual TLS (mTLS), so use this page to confirm feasibility with your IT team before setup begins.

Applies to Flywheel-hosted DICOM Push

These requirements apply to DICOM Push, the Flywheel-hosted DICOM receiver introduced in Flywheel 22.2, which receives DICOM over the public internet and secures it with mutual TLS. For an overview, see the DICOM Connector.

Mutual TLS, in plain language

Mutual TLS (you may see it written mTLS or two-way TLS) uses the same certificate technology that secures every HTTPS website. The only difference from normal HTTPS is that both ends present a certificate to prove who they are: Flywheel proves it is Flywheel, and your side proves it is an authorized device.

So the real question for your IT team is not "do we support some exotic protocol." It is "can our device, or something in front of it, present a client certificate when it connects to Flywheel."

You do not need the device itself to support mutual TLS

The most important point

This capability does not have to live in the imaging device itself. Many modalities and PACS cannot present a client certificate — or cannot do TLS for DICOM at all. That is fine: you can place a network appliance (a TLS-terminating proxy or DICOM gateway) in front of the device, and it handles the secure connection to Flywheel on the device's behalf. The device keeps sending DICOM to that appliance on your local network exactly as it does today.

What the sending side must be able to do

This applies to the device or the appliance that actually connects to Flywheel:

  • Make an outbound, TLS-encrypted DICOM connection to the Flywheel connector address and port that Flywheel provides — that is, "secure DICOM" or "DICOM over TLS," not plain unencrypted DICOM.
  • Present a client certificate during that connection (this is the "mutual" part), and hold the matching private key.
  • Send the studies as a standard DICOM C-STORE over that secured connection.
  • Use the agreed Application Entity Title (AET) that Flywheel registers for the device.

Questions to ask your IT team

Use these questions to confirm that mutual TLS is possible in your environment:

  1. Can our imaging device or PACS send DICOM to an external destination over a TLS-encrypted connection (sometimes called "secure DICOM" or "DICOM TLS")?
  2. If so, can it present a client certificate — that is, mutual or two-way TLS, not just verifying the server's certificate? This is the specific capability that is less common.
  3. If the device cannot do that itself, do we have (or can we deploy) a TLS-terminating proxy or DICOM gateway in front of it that can present a client certificate to an outside service? Terms your IT team may recognize: reverse proxy, TLS gateway, stunnel, or a DICOM router or connectivity appliance.
  4. Can we obtain or generate a client certificate and private key for whichever endpoint will make the connection to Flywheel?
  5. Will our firewall allow that endpoint to make an outbound connection to Flywheel's connector address and port?

What you provide to Flywheel

  • Provide to Flywheel: the public certificate, the hostname or IP that will make the connection (as Flywheel sees it — your public or egress address if you use NAT), and the AET.
  • Keep private, never send: the private key. It stays on the device or appliance.

Using a network appliance in front of the device

If a proxy or gateway makes the connection on the device's behalf, the certificate, hostname or IP, and AET you register with Flywheel are those of the appliance that makes the connection — not the device sitting behind it.