logo

DICOM router and mini PACS

Your scanner is an island.
This is the bridge.

One application on one PC in your centre. It receives from every scanner, keeps the studies, sends the worklist back to the consoles so nobody retypes a patient, prints film, and delivers each study wherever your rules say. It is sold on its own and needs nothing else from us.

Ask about your scannersThe whole platform
What it is
To install
One application
Runs on
Windows, macOS, Linux
Needs the rest of RadioLens
No
Your database
SQLite, PostgreSQL or MySQL
Viewer included
Yes, in any browser
Read from the source on 12 September 2026.
10
DICOM services it answers
From echo and store to film printing
15
Image formats it reads
Including JPEG-LS and JPEG 2000
2
Kinds of destination
A DICOM machine, or a web endpoint
1
Application to install
No sidecars, no separate services

What it replaces

A name typed at the console, and a disc carried down a corridor.

A scanner with nothing in front of it produces images and a problem. The radiographer types the patient’s name at the console, so it is spelled a little differently from the one at the front desk. The study stays on the machine until somebody burns it. The centre finds out a scan happened when the patient asks where the report is.

The router ends all of that at once. The scheduled patient arrives on the console by itself. The images arrive in storage by themselves. And where each study goes afterwards is a rule you write, not a decision somebody has to remember to make.

One bridge, many destinations. What changes between centres is the rules, not the software.

One bridge · rules decide where each study goes
CTMRX-rayRouterrules, in priority ordermodality · accession · sourceYour own archivekeep it on siteA PACS you ownany DICOM nodeAn HTTP endpointa reading serviceIf a destination is downit queues, and the queue survives a restartA study can go to more than one place. Network failures retry for as long as it takes.A study is never dropped for a reason that might fix itself.

Three products, one binary

Most centres buy one of these. It happens to be all three.

  • It can be your archive

    Point every scanner at it and keep your studies there. It receives, indexes, finds, retrieves, prints film, and answers the storage commitment a modality asks for before it erases its own copy.

  • It can be your bridge

    Rules in priority order decide where each study goes: your own storage, a system you already own, a remote reading service, or a web endpoint. A study can go to more than one place.

  • It can be your worklist

    It serves the scheduled patient to the scanner's own console, so the radiographer picks the name from a list instead of typing it. Wrong names are the largest single cause of studies nobody can bill.

The part that matters at 2am

A study is never dropped for a reason that might fix itself.

Every router forwards studies. The difference shows up on the day the link to the destination drops, the machine is restarted, or the power goes while a study is in flight.

Here the queue is written to disk, not held in memory, so it survives all three. Anything caught mid-transfer is recovered when the application starts again. Failures are sorted into the kind that might clear, which are retried indefinitely, and the kind that never will, which are set aside after three attempts so a person can see them instead of a loop hiding them.

The housekeeping obeys the same rule. When the disk fills, old studies are cleared to make room, and a study that still has a delivery pending is never one of them.

When delivery fails
The queue lives
In a database on disk
After a power cut
It picks up where it stopped
A network failure
Retried for as long as it takes
An impossible delivery
Set aside after three tries
Studies awaiting delivery
Are never deleted to free space

What you get on day one

An operator console, not a configuration file.

It also drains what it is sending before it shuts down, rather than dropping studies on the way out.

Where it belongs

On your own network, behind a VPN. We will say why.

Most vendors would describe this product as secure and move on. The honest position is that it is built to sit inside a trusted network, and it should be deployed that way.

Traffic between the scanners and the router is not encrypted. The listener accepts a connection from any machine that speaks to it, which is deliberate, because refusing unknown equipment is the most common reason a router fails to work with a scanner nobody documented. The viewer it serves has no login.

None of that is a problem on a hospital network you control, which is where it is designed to live and where we install it. It would be a problem on a public address, so we do not put it there, and we help you set up remote access properly instead.

Be clear about this
Connections encrypted
No
Checks which machine is calling
No
Login on the built-in web server
No
Safe to expose to the internet
No
Where it should sit
Inside your network
We would rather you read this here than find it later.

Straight answers

The questions centres ask

What does it actually run on?
One ordinary PC at your site. It is a single application with nothing else to install and no separate services to keep alive. It sits in the system tray, starts with the machine, and updates itself over a signed channel. There are builds for Windows including 32-bit, for macOS on both chip families, and for Linux.
Will it talk to our scanners?
It implements the classical DICOM services a modality expects: echo, store, find, move and get, the modality worklist, procedure step reporting, storage commitment and film printing. The listener deliberately accepts whatever a machine offers rather than refusing anything it has not been told about in advance.
Can it replace the archive we are paying for?
For a lot of centres, yes. It stores studies, lets you query and retrieve them, serves them to a browser, prints film, and answers storage commitment so a scanner will trust it enough to delete its local copy. Ask us to test it against your own equipment before you decide.
What happens when a destination is down?
The study queues. The queue lives in a database on disk, so it survives a restart and a power cut, and anything caught mid-transfer is picked up again when the machine comes back. A failure that might clear on its own is retried indefinitely. A failure that never will, such as a format the destination cannot accept, is set aside after three attempts so it is visible rather than looping forever.
Can it compress our studies?
It reads every common format, including JPEG-LS and JPEG 2000. It can only produce uncompressed, deflated, JPEG baseline and RLE lossless, so those are the formats it can convert into on the way through. We would rather tell you that now than have a rule fail in your department.
Do we need a viewer licence for every PC?
No. A viewer is built into the application and served over your network, so any browser on site can open a study with nothing installed. It does stack, multi-planar reconstruction, maximum intensity projection, 3D volume and PET/CT, with the usual measurement tools.
Is it secure enough to expose to the internet?
No, and you should not. It is built for a trusted network: connections are not encrypted, the listener does not check which machine is calling, and the built-in web server has no login. Put it on your own network behind a VPN and we will help you set that up. We would rather be blunt about this than sell you a word like hardened.
How is it priced?
It is sold on its own, separately from the rest of RadioLens, and you can run it with no teleradiology at all. Ask for a quote with the number of scanners and where you want studies delivered.

Next step

Send us your scanner list

Make and model is enough. We will tell you what connects, where your studies could go, and what it would cost to stop anyone typing a patient's name twice.

Request a demoThe whole platform