Teleradiology sounds like a staffing solution: hire a radiologist somewhere else, plug them into your workflow, and studies get read. For the team building the platform underneath that arrangement, staffing is the easy part. Teleradiology stays a workflow and infrastructure problem for as long as a study has to move between two locations, two networks, and sometimes two organizations before anyone looks at it. Get that wrong and the staffing decision never gets to matter.
What a Teleradiology Study Actually Sends Over the Wire
A study does not travel as one file. It travels as a set of DICOM instances: individual images plus the metadata attached to each one. A routine two-view chest X-ray is two instances, while a cross-sectional CT or MRI is typically hundreds of slices in a single study. A trauma or whole-body protocol runs heavier still, and the priors pulled in for comparison mean a single reading session can involve several studies moving at once.
That volume is why teleradiology is a network problem before it is a viewing problem. A site with a fast, stable connection barely notices it. A mobile clinic, a rural facility, or a site on a shared or metered connection notices immediately, because the transfer itself becomes the bottleneck a reader is waiting on.
Compression is the lever that makes any of this practical over a constrained connection. A study can move three ways: uncompressed and exactly as acquired, compressed losslessly so every pixel value reconstructs exactly, or compressed lossy so the file shrinks further at the cost of some fidelity. Lossless is the safer default for a primary diagnostic read, because nothing about the image data itself changes. Lossy has its place in preview, triage, or referral workflows, but a platform that defaults to it for the actual read trades bandwidth for the fidelity a signed report depends on.
Routing Rules and Prefetch
The acquiring modality pushes a finished study into the archive with a DICOM store operation. From there, getting the right study to the right remote reader is a retrieval problem, and DICOM defines it specifically. The Query/Retrieve service class works through three DIMSE operations, and the difference between two of them decides how much configuration a new reading location costs you.
- C-FIND matches studies against keys like patient, study date, or accession number, and the archive returns a response for each match.
- C-GET has the archive send the matched instances back over the same association the request arrived on, with the storage roles reversed for the transfer.
- C-MOVE has the archive send them on a separate association, to a destination application entity named in the request. An archive that does not recognize that destination refuses the move.
A platform that implements C-FIND and stops there looks identical to a complete one until someone tries to pull a study that is not already sitting locally. Prefetch is where that difference shows up first. A remote reader opening a current study needs the relevant priors already staged, not queried and retrieved mid-read while a case is waiting. A useful prefetch window is scoped by date range, modality, and body part, so a chest series pulls chest priors instead of every unrelated exam in the patient record.
Routing rules and reading priority are two different layers, and they are easy to conflate. Routing decides where a study lands: which archive, which site, which storage tier. Priority decides what a reader sees first, and that belongs to the worklist. A stroke or trauma study jumping ahead of routine reads is worklist behavior, so ask about it there rather than assuming a routing rule covers it.
Why the Remote Viewer Has to Match the One On-Site
None of the routing matters if the study looks different once it lands. A remote reader needs the same calibrated grayscale, the same window and level controls, and the same measurement tools available in the department itself. A diagnostic call made on a degraded rendering is not the same diagnostic call. The requirement for a diagnostic-grade DICOM viewer gets harder for teleradiology, because the platform has no visibility into the monitor, network, or room the remote reader is working from.
That parity extends past rendering into layout. A reader gets used to a specific hanging protocol, with priors and current study arranged side by side in a consistent order. They lose time and consistency if the remote environment presents the same study differently every time. The viewer does not have to be the same software installed locally, but it has to produce the same diagnostic output wherever it runs.
Worklist Assignment Across Sites and Time Zones
A single-site reading worklist is a queue. A teleradiology worklist has to route work to the right reader across multiple acquiring sites, multiple reading locations, and often multiple time zones, without someone manually reassigning cases as a shift ends. Subspecialty matters here too: a neuro study belongs in front of a reader credentialed to read it, not the first available person in line.
That means the worklist has to carry enough metadata to route correctly on its own: modality, body part, priority, and site of origin. It also has to keep working as coverage hands off from one region to the next. A group covering three time zones with a single overnight reader depends on that handoff happening at a fixed time, not on someone remembering to reroute cases before they log off.
Where Teleradiology Breaks: Offline and Low-Bandwidth Failure Modes
Most teleradiology architecture assumes the network is there. It usually is. The failure mode that matters is what happens on the days it is not. Platforms built for a fixed reading room quietly fall apart once they are asked to work at a mobile clinic, a rural site, or any location with an unreliable connection.
Full disconnection is the easy case to design for, because it is binary: local or nothing. A degraded connection is harder, because the system has to decide what still works at reduced bandwidth instead of failing outright. A remote reader on a weak connection needs a study to keep loading, even slowly, rather than timing out entirely. The platform also needs to tell a slow retrieve apart from a failed one instead of treating both the same way.
An acquiring site that goes offline mid-study cannot afford to lose the exam or stall the workflow waiting on connectivity. It needs to keep acquiring, store the study locally, and sync once the connection comes back. That is a specific architectural commitment, and it is worth checking which vendors have actually made it.
EBM mAIn PACS® offers that shape of deployment. Its point-of-care pages describe acquiring, viewing and reporting at the site itself, on a system that works offline and syncs when connected. EPS Pi, the edge appliance, is listed with a DICOM server, storage and routing, worklist, reporting, and local backup via USB. UDE, the iPad diagnostic workstation, is listed with offline-capable workflows.
The Audit and Attribution Trail a Signed Report Needs
A signed report crossing an organizational boundary needs more than a correct read. It needs a record of who accessed the study, from where, when, and whose credentials produced the final report. A teleradiology deployment is, by definition, a system where the reader and the record are not in the same building.
The IHE profile written for that is Audit Trail and Node Authentication, or ATNA. It specifies “the foundational elements needed by all forms of secure systems: node authentication, user authentication, event logging (audit), and telecommunications encryption.” IHE also notes that many other profiles require or recommend grouping with ATNA actors as part of their security considerations. HIPAA’s audit control standard reaches the same place from the regulatory side, requiring mechanisms that record and examine activity in systems that contain or use electronic protected health information.
In practice that means logging specific events, not just a login: who queried a study, who retrieved it, who opened it in the viewer, and who signed the final report. Each of those needs a timestamp and an identity attached. A gap in any one of those steps is a gap in whether the organization can answer who read a given study. That matters as much for a routine audit as it does for an incident.
For a partner building or licensing a teleradiology workflow, this is not a feature to bolt on after the routing and viewing work is done. It has to be part of the architecture from the first study that crosses a site boundary. Reconstructing an audit trail after the fact is a much harder problem than logging it as it happens.
What This Means for Your Evaluation
Follow a study through this pipeline and the vendor questions get specific fast.
- Is prefetch automatic, or does a remote reader wait on a manual retrieve?
- Does the remote viewer render the same calibrated grayscale and carry the same measurement tools as the on-site one, on whatever device the reader is using?
- Does the worklist reassign across sites and time zones without someone doing it by hand?
- What happens to the acquiring site and the remote reader when the connection drops, as a specific testable behavior rather than a reassurance?
- Is every access to a study logged well enough to reconstruct who read what, and when?
Every one of those is testable before anything gets signed. Push a study across a throttled link. Pull the connection at the acquiring site mid-exam, then open the log and see whether it tells you who did what. An architecture that only holds together on a good day will show that in an afternoon of testing, rather than during a live reading shift with a case waiting.
EBM mAIn PACS® answers the offline half of that list. Its native DICOM services cover C-STORE, Query/Retrieve, MWL and Storage Commitment, and its solutions pages list reading rooms and remote access as separate care settings. The cross-site worklist questions above are still worth putting to any vendor, this one included.