Where images go: the imaging chain after the detector
Draw the path of an image and its patient data from order to archive in any department, name the role of each system, and say which parts the service engineer owns and which belong to hospital IT or the PACS vendor.
The machine does not end at the detector
Ten years ago many imaging rooms still ended at a film processor. Today almost every modality ends in a network socket. The radiologist does not judge the scanner by its tube current or its coil; he judges it by whether the images of the right patient appear on his screen a minute after the scan. If they do not, the clinic calls the service engineer, because from their side the machine is broken.
That is why the modality engineer has to understand the chain after the detector, even when most of it belongs to someone else. You do not need to administer the hospital's servers. You need to know what each box does, what it expects from your machine, and how to prove where the chain is broken. An engineer who can say 'the scanner sent the study at 10:42, the archive accepted it, the problem is between the archive and the viewer' saves a day of argument between three departments.
This lesson draws the map. The next lessons fill in the details: DICOM itself (lesson 2), the network underneath (lesson 3), worklist and patient data (lesson 4), workstations and archives (lesson 5) and a fault-finding sequence for the whole chain (lesson 6).
The systems on the map
Start with the patient, not with the scanner. A doctor orders an examination. The order lives in the hospital information system (HIS) or, more often for imaging, in the radiology information system (RIS). The RIS schedules the examination, gives it an accession number and holds the patient's demographic data: name, ID, date of birth, sex.
The RIS publishes the scheduled examinations as a modality worklist. The modality, or its acquisition workstation, asks the worklist server for today's patients, and the radiographer picks the patient from a list instead of typing the name. This one step removes most typing errors, and lesson 4 explains why it matters for patient safety.
The modality acquires the images. On many systems a separate acquisition or console computer reconstructs or processes them and keeps them in a local database for a while. From there the images are sent to the PACS (picture archiving and communication system): an image manager that indexes them, an archive that stores them on disks or other media, and often a long-term or off-site copy.
Doctors look at the images on viewing workstations or web viewers that query the PACS. Specialist post-processing workstations (3D, cardiac, perfusion, mammography review) may receive copies directly from the modality or pull them from the PACS. Some studies still go to film or paper through a DICOM printer, and some go to patients on CD or USB media.
Around all of this sits the hospital network: cables, switches, routers, firewalls, address servers and the people who run them.
- HIS / RIS: orders, scheduling, patient demographics, reports.
- Worklist server: usually part of the RIS or a broker; gives the modality the list of scheduled patients.
- Modality and its console or acquisition workstation: acquires, processes and sends images.
- PACS: image manager, archive, and the database that indexes studies.
- Viewers and post-processing workstations: display, measure, reconstruct.
- DICOM printers and media writers: film, paper, CD/DVD/USB for patients.
- Network: the path between all of them, owned by hospital IT.
Two languages: DICOM and HL7
Two families of standards carry most of the traffic. DICOM (Digital Imaging and Communications in Medicine) is the standard for images and everything about them: the image file format, the patient and study information inside it, and the network services that send, query, retrieve, schedule and print. It is maintained by the DICOM Standards Committee and published by NEMA as a multi-part document, PS3.
HL7 is the family of standards that hospital information systems use to exchange orders, admissions, results and reports. When a patient is admitted, an HL7 message tells the RIS; when a radiologist signs a report, an HL7 message may carry it back to the HIS. Newer systems also use HL7 FHIR web interfaces.
The rule of thumb for an engineer: the modality talks DICOM. It almost never talks HL7 itself. The translation between the HL7 world (orders) and the DICOM world (worklist) happens in the RIS or in an interface engine or broker. If patient names are wrong in the worklist, the fault may be in an HL7 interface the modality never sees.
To make the pieces work together in a predictable way, the IHE (Integrating the Healthcare Enterprise) initiative publishes integration profiles. The Scheduled Workflow profile (SWF, now with an updated version SWF.b) describes the normal path of an order, worklist, acquisition, performed-procedure reporting and storage, and which system plays which role. When a tender or a contract says 'IHE Scheduled Workflow compliant', it means the vendors have committed to that pattern.
What you own, what IT owns, what the PACS vendor owns
Most arguments in imaging IT are not technical. They are about who is responsible. Settle that at the start of a contract or an installation, in writing if you can, and you will spend less time on the phone later.
The modality engineer usually owns the modality and its console: the DICOM configuration of the modality (its own AE title, IP settings as agreed with IT, the list of destinations), the local image database, the acquisition workstation hardware, and any vendor-supplied workstation that comes with the system. You prove that your machine sends correctly and accepts what it should.
Hospital IT usually owns the network: cabling beyond the room, switches, VLANs, firewalls, DHCP and DNS, address allocation, domain policies, internet access and remote-access rules. They also own the general-purpose PCs, unless a PC is part of a medical device. The PACS and RIS are often owned by a separate vendor under its own contract, with hospital IT as the local administrator.
The grey zones cause the trouble: who may change the IP address of a console, who adds a new destination in the PACS, who may install antivirus on the acquisition PC, who restores a workstation after a disk failure. A short written table of who does what, kept with the site documentation, prevents most of these fights.
Never change something on a system you do not own without agreement. Changing a PACS setting to make your scanner work can break three other scanners. Asking IT for a change with a clear, specific request is faster in the long run than doing it yourself.
The site record: draw it once, use it forever
On every site you look after, draw the chain once and keep it with the service documentation. It does not need to be pretty. A sheet with boxes, arrows, names and settings is enough. The next time images go missing, you will know what to test instead of guessing.
Record the settings you configured and the date. When something stops working, the first question is always 'what changed?', and you cannot answer it without a record of how things were. Many cases in this course were solved by comparing today's settings with the record, not by clever diagnosis.
- Each node: name, role, location, owner, contact.
- For each DICOM node: AE title, IP address, port, services used (store, worklist, print and so on).
- Network: socket and switch port if known, VLAN, whether the address is static or reserved.
- Which destinations the modality sends to automatically, and in what order.
- Who to call for the RIS, the PACS and the network, with contract or ticket references.
- Date of the last change and who made it.
Where the chain usually breaks
From experience across many sites, the chain breaks in a few predictable places. The local disk of the modality fills up with studies that were never sent, and the console slows down or refuses to start the next series. Someone in IT changes an address, a switch, a cable or a firewall rule, and the modality is not told. A destination is reconfigured on the PACS side after an upgrade. A certificate or a time-limited licence on a workstation expires. A character set does not match and patient names arrive as unreadable symbols.
Notice that none of these is a broken detector or a failed board. They are configuration, capacity and communication. That is good news: they are cheap to check if you know where to look, and the rest of this course shows you where.
| Part | What it does | How it fails | |
|---|---|---|---|
| 01 | RIS / HIS | Holds orders, schedules exams, owns patient demographics | Interface stops, orders not published, wrong or duplicate patient records |
| 02 | Worklist server or broker | Turns orders into a DICOM worklist for the modality | Empty list, filter mismatch, wrong character set, service down |
| 03 | Modality console / acquisition PC | Acquires, processes, stores locally and sends images | Disk full of unsent studies, lost network settings after restore |
| 04 | PACS image manager and database | Accepts, indexes and serves studies | Unknown AE title refused, database errors, storage full |
| 05 | Archive storage | Keeps images on disk arrays, tape or cloud copies | Failed disks in RAID, full volumes, broken off-site copy |
| 06 | Viewing and post-processing workstations | Display, review, 3D and specialist analysis | Expired certificate or licence, local database full, auto-deletion |
| 07 | DICOM printer / media writer | Film, paper or CD/USB output for clinicians and patients | Port blocked, wrong AE title, unsupported film size or format |
| 08 | Switches, cabling and sockets | Physical path between all nodes | Wrong speed negotiated, bad patch cord, port moved to another VLAN |
| 09 | Firewall, router, DHCP, DNS | Control and route traffic, give addresses and names | Rule blocks the DICOM port, address changed or duplicated |
The console stopped between series, and nothing said why
A GE CT scanner finished a scan and then simply did not move on to the next series. There was no clear error message, and the radiographer thought the scanner had frozen. The engineer looked at the local storage first and found the disk almost full. For weeks, studies had not been sent to the PACS reliably, nobody had noticed, and they had not been removed from the scanner's own database. Once old studies were checked as present in the archive and cleared from the local database, the scanner worked normally. The department then agreed a simple rule: at the end of each shift, check that every study has reached the PACS before anything is deleted locally.
The modality's local disk is the first buffer in the chain. If sending fails silently, the problem shows up later as a 'frozen scanner'. Check the send queue and local storage early, and never delete a study until it is confirmed in the archive.
Three CT workstations stopped talking on the same day
On several GE CT systems, images stopped going from the radiographer's workstation to the radiologist's workstation, all at once. Sending to the PACS still worked, so the network and the scanners were clearly fine. The common factor was time: something had expired. The connection between the workstations used a security certificate, and its validity period had ended. Once the certificate was renewed through the proper channel, the transfer came back. Colleagues mentioned a similar event when a time-limited database licence on a reading workstation ran out.
When several systems fail together on one day and nothing was changed, think of dates: certificates, licences and passwords that expire. Record their expiry dates in the site record.
The address changed, and nobody told the modality
In one department, images from the X-ray radiographer's workstation regularly stopped reaching the doctor's workstation. Each time the cause was in the network: the DHCP server had been changed, or it handed the same address to two devices. The local IT staff said they had no access to the DHCP server themselves. On another occasion an IT technician needed a free port, unplugged the doctor's workstation from the switch and plugged in his own PC. The lasting fix was to agree fixed addresses for medical devices with IT and write them into the site record.
Imaging devices need stable, agreed addresses. Who may change the network, and how the modality side is told, is part of the service agreement, not an afterthought.
On-site checklist
- Draw the chain for the site: RIS, worklist, modality, PACS, viewers, printers, network.
- For each DICOM node record AE title, IP address, port and services.
- Write down who owns each node and who to call.
- Agree in writing who may change addresses, destinations and security software.
- Check the modality's send queue and free local disk space at every visit.
- Record expiry dates of certificates and time-limited licences you know of.
- Never delete a local study until it is confirmed in the archive.