Medical image exchange between organizations happens constantly: a trauma transfer whose CT needs to arrive before the ambulance, priors requested for tomorrow’s comparison read, a referral heading to a subspecialist with three studies attached. Radiology has needed inter-organizational transfer for as long as PACS has existed, and the ways it happens in 2026 span thirty years of technology, sometimes inside the same hospital on the same day.
Four patterns are in use today. This post walks through them, looks at how the newest one is priced, and describes a fifth: studies moving directly between two organizations’ integration engines, with nothing in the middle holding a copy.
Four ways medical images move between organizations today
Physical media. The CD (now sometimes a USB stick) still rides with patients between facilities every day, decades after everyone agreed it should not. Its persistence tells you the network options are hard enough that a physical disc remains competitive. The failure modes are familiar: unreadable at the destination, a viewer that will not launch, the disc that never made it to the reading room, re-scans because importing was slower than re-imaging. When a disc gets re-burned and couriered, the transfer cost is measured in hours of clinical delay.
C-STORE over a VPN. Where two organizations exchange imaging regularly, the classic answer is a site-to-site tunnel with modalities or PACS pushing studies across it. Once running, it is fast and invisible. Getting it running is the same network project HL7 interfaces suffer, with imaging-sized MTU and address quirks on top, and it recurs per partner. Every new imaging relationship is a new tunnel through two security reviews and two firewall queues.
DICOM over TLS. The standard’s TLS profiles wrap the association itself, so studies can cross the internet without a VPN: exchange certificates, open one port to known peers, done. We wrote the practical guide to DICOM over TLS in Mirth Connect, and it remains the right tool for a stable, well-managed pair of endpoints. Its costs are certificate lifecycle across two organizations, static addressing, a listening port with an allowlist to maintain, and no discoverability at all. Each new partner is a bilateral certificate exchange. Solid for the partner you already have, and real friction for the partner you get next month.
Cloud image exchange. The last decade’s answer. Both organizations subscribe to an exchange platform, the sender uploads (or the platform’s edge appliance auto-forwards), and the receiver is notified and pulls into PACS. Setup is easy, the workflows are polished, and a large network of already-connected organizations is the product’s real asset. Two properties of the model get less scrutiny than they should, and they are the subject of the next section.
What per-study pricing does to image exchange costs
Cloud exchanges typically bill per study moved, on top of subscriptions, sometimes with tiers and commitments. It sounds small until you notice what it scales with. The bill tracks how often your clinicians need a study moved, not what it costs to move it.
A trauma center forwarding studies for every transfer, a group doing thousands of second reads, an imaging center distributing priors: their transfer counts are a function of patient care, and under per-study pricing so is their invoice. The incentive follows. When each act of sharing carries a fee, organizations ration it. They narrow which studies qualify, batch what should be immediate, or keep burning discs for the cases that don’t justify the charge. A fee on every transfer discourages transfers, applied to a workflow that exists because transfers are clinically necessary.
The per-study unit also has nothing to do with the work done. A two-image chest film and a two-thousand-slice CT are one study each. Pricing by data moved, the way bandwidth is priced everywhere else, at least charges for the resource consumed.
The second property is the copy. The platform’s cloud holds your studies in the middle: convenient for redelivery, and also a third place PHI now lives, governed by another BAA, another retention schedule, and another breach-notification chain. For imaging volumes, “our patients’ studies also reside on a vendor’s cloud” is a material line in any security review, and it is easy to stop seeing it once the workflow is routine.
Neither property is an accusation. The platforms are useful and the copy is disclosed. Both are consequences of the architecture, a metered intermediary, and not of imaging itself. Change the architecture and both go away.
Direct exchange: engines, agreements, no middleman
OpenShare moves studies directly between two organizations’ integration engines. The platform handles the introduction and the authorization, and the pixels take the shortest path.
The relationship layer is the same agreement model used for HL7: find the partner in the directory, form an agreement, grant access to a specific imaging channel. The connect wizard will build the channel for you as a managed channel if you want it to. Local systems keep speaking plain DICOM to the engine they already know, and the modality pushing to your engine neither knows nor cares that the destination is another organization.
The transfer layer is where the architecture pays off:
- No inbound network changes. Each engine’s plugin dials outbound, so there is no VPN, port forward, or firewall exception on either side.
- End-to-end encrypted, no intermediate copy. Studies travel end-to-end encrypted from engine to engine. OpenShare coordinates the connection but cannot read the traffic, and no copy of the study rests anywhere between sender and receiver. Where organizations can reach each other directly, the pixels flow peer to peer. Where they cannot, an encrypted relay forwards traffic it cannot decrypt.
- Billed like bandwidth, not like utilization. Transfer is billed by the gigabyte moved, with direct peer-to-peer transfer at a lower rate than relayed transfer, and there is no per-study charge. A free-tier organization is not billed for transfers with a paid partner; the paid side carries the connection. The bill tracks data volume, not how many times a clinician needed a study moved. Environments with a strict no-third-party posture can disable the relay and run direct-only.
Engine-level details matter in imaging, so the short version of ours: studies pass through with pixel data byte for byte, in their original transfer syntax, never re-encoded. Studies carrying vendor-private elements that trip up conventional engine DICOM handling process cleanly. When a local leg needs securing too, the connectors speak standard DICOM TLS to any conforming system. Any received study can be opened in the browser’s DICOM viewer straight from the message browser.
A free OpenShare account covers running your own servers. The plugin installs into an existing Mirth Connect or OIE engine, or the installer ships OIE with it included. Send a test study between two of your own sites first, from grant to viewable study. For the wider integration picture around imaging, see EHR and PACS integration, or talk to our imaging integration team.
Choosing a medical image exchange approach
- A stable high-volume pair with an existing VPN that works? Keep it. Working infrastructure needs a reason to be replaced, and “it is old” is not one.
- One well-run partner relationship over the internet? DICOM over TLS remains excellent, certificates and all.
- You need a large pre-connected network today and the per-study economics have not hurt yet? The cloud exchanges are mature. Go in with the copy and the pricing model priced into the decision.
- New partner relationships, growing volume, or a hard look at where PHI copies live? Direct exchange: the speed of the VPN, the setup weight of none of it, and a bill priced on data moved rather than a toll on every study.