The Level 2 method for imaging IT: logs, reproduction, capture and ownership
Collect and line up logs from the modality, the PACS and the workstation, reproduce a transfer fault with a test object, decide when a short packet capture is justified, and know which changes are yours to make and which belong to another owner.
Where the general course ends
In DICOM, PACS and Networks for Service Engineers you learned the map of the image chain, the three values that identify a DICOM node, the main services, the bottom-up test ladder from link to test study, and a basic return to service. That method solves most calls: a wrong IP address, a node missing from the PACS list, a firewall rule, a full local disk. This course is about the calls that are left after it. Echo passes, the port is open, the test study arrives, and still the radiologist says that one series is missing every few days, or that a study appears under the wrong patient, or that the console slows down every afternoon.
Faults of this kind have two things in common. They live between systems, so no single log shows the whole story. And they are often intermittent or conditional: one object type, one destination, one time of day, one size of study. The Level 2 method is therefore about evidence. You collect it from every side at the same moment, you reproduce the condition on purpose, and when logs are not enough you look at the traffic itself. Only then do you change anything, and only on a system you are allowed to change.
Logs on three sides, lined up by time
Every system in the chain keeps some record. A modality console usually has a send queue or job list with a status per study, plus an application or DICOM log that service staff can read. A PACS keeps an association log: who called, with which calling and called AE title, what was proposed, what was accepted, how many objects were received and with which status. A reading workstation or viewer keeps its own import log and database. A RIS or interface engine logs worklist queries and HL7 messages. Some of these are visible to you, some only to the PACS administrator or the vendor. Ask for them; you do not need to own a system to request its log lines for a given minute.
The difficult part is lining them up. Check the clocks before you compare anything. A console that is four minutes fast and a PACS on the hospital time server will make a clean association look like two unrelated events. Write the offset down if you cannot correct it today. Then pick one failed study and follow it: the time it was queued, the time the association opened, the presentation contexts accepted, each object sent and the status returned, the time the association closed, and what the receiving side recorded for the same minute. Two logs that agree up to a point and then diverge show you where the break is.
Keep the raw material. Export or photograph the queue and the log before you retry, reboot or clear anything; many consoles overwrite their logs quickly, and a reboot can empty a queue that held the only copy of a study.
- Modality: send queue with job status, DICOM or network log, local database state, free disk space.
- PACS or archive: association log for the calling AE title and the minute, objects received, rejections with reason.
- Workstation or viewer: import log, database, routing or auto-fetch rules, licence and certificate status.
- RIS, broker or interface engine: worklist queries and responses, HL7 messages for the order and the patient.
- Network: switch port status and error counters, firewall log entries for the two addresses, from IT.
Describe the fault as a condition, then reproduce it
A Level 2 fault is rarely 'transfer does not work'. It is 'large CT series stop after a few hundred images', 'cine loops are refused, still images arrive', 'the first study of the morning is always late', 'only studies from the second radiographer's login fail'. Turn the complaint into a condition with as many parameters as you can: object type, size, destination, time, user, protocol, route. The parameters that change the outcome are the clues.
Then reproduce the condition with a test object you control. Use a fictional test patient agreed with the department, never a real patient's study re-sent 'to see what happens'. Send one small image, then a full series of the same type, then a different object type, to the same destination. Send the same study to a second destination. Each result removes suspects. If the small image passes and the large series fails, look at time-outs, disk space, PDU sizes and the network path under load. If one object type fails everywhere, look at SOP classes and transfer syntaxes. If everything fails to one destination only, that destination or its path is the suspect.
Substitution is the Level 2 engineer's strongest tool. A service laptop with a simple, well-known DICOM receiver or sender, configured with the same AE title, port and address details as the suspect node, tells you whether the fault follows the node or the path. Put the laptop on the same socket as the modality and send to the PACS: if that works, the network path and the PACS are fine for that object. Point the modality at the laptop: if the laptop receives cleanly, the modality's sending side is fine. Install nothing on the medical device itself to do this; the laptop is your instrument.
When and how to capture traffic
Logs show what each application thinks happened. A packet capture shows what actually crossed the wire. You need it when two logs contradict each other, when a vendor says 'we never received an association', when a connection drops mid-transfer without an error on either side, or when you suspect that a value in the association request is not what the configuration screen shows.
A capture on a hospital network contains patient data in clear text unless the link uses TLS. Treat it as a medical record. Agree it in writing with hospital IT, capture only the two addresses involved, for minutes rather than hours, store the file encrypted on a device you control, share it only through approved channels, and delete it when the case is closed, as agreed with IT. The easiest legal capture point is usually your own service laptop: as a substitute sender or receiver, or connected to a mirror port that IT configures on the switch. Do not install capture software on a modality console or a PACS server yourself.
Common analysers decode DICOM traffic and show the association request with its calling and called AE titles, the proposed presentation contexts, the accept or reject, and each command with its status. If the DICOM port is not the standard one, you may need to tell the analyser to decode that port as DICOM. Filter on the two IP addresses first. Look at the start of the association and at the end: most answers are in the first and last few packets. Lesson 2 shows how to read them.
What you may change, and who owns what
At Level 2 you will often know exactly what is wrong on a system that is not yours: a forwarding rule on the PACS, a firewall rule, a RIS mapping, a duplicate patient record. Knowing is not permission. The general course drew the ownership map; here is the rule that follows from it. You change the modality and the equipment you are contracted for, within the manufacturer's procedure for your level, after saving the current configuration. Everything else you request from its owner, in writing, with the evidence attached.
Some actions are never service tasks whoever owns the system: correcting patient demographics, moving images between patients or studies, merging or deleting patient records, deleting studies from an archive, changing compression or retention policies, disabling security software or certificate checks. They belong to authorised staff under the hospital's procedures, because they carry clinical and legal consequences. Your part is to show what is wrong, explain the risk and make sure the tools work.
Service access follows the same line. Use the accounts and remote-access routes you were given. Do not use passwords, service keys, licence files or option activations obtained any other way, and do not copy configuration or licence data from another unit. When the fix needs that access, hand over a package to the person who has it: affected studies with times, log extracts from both sides, the condition that reproduces the fault, what you excluded, and what you think is needed.
Write it down as you go
Imaging IT faults are argued about, often between three companies. Notes made at the time settle the argument: the time of each test, its exact result, the version of each software, the configuration before and after each change and who agreed it. Keep a simple running log on site. It will become the core of the report in lesson 8, and it protects you when someone later says your visit caused the problem.
Make one change at a time and test after each. If a change does not help, put the old value back before trying the next one. Two changes made together leave you unable to say which one fixed the fault, and the one that did nothing may have broken something you have not tested yet.
- Time and clock offset of each system.
- Software versions of modality, PACS, viewer and RIS.
- Each test: what was sent, from where, to where, result and status.
- Each change: old value, new value, who agreed, result.
Ping, port and echo all fine, and still nothing in the PACS
A Toshiba Aquilion 16 CT stopped sending studies to the hospital PACS, a server running eFilm-based software. It had worked that morning. The engineer checked the obvious first: ping from the CT to the server answered, a telnet test to the DICOM port connected, and DICOM echo from the CT console passed. The console itself was healthy, apart from a disc forgotten in its DVD drive. A colleague suggested the decisive test: send the same study from the CT to a different DICOM destination, here a post-processing workstation. That send worked. The fault therefore followed the receiving server, not the CT or the network. The engineers suspected the server software, possibly after an operating system update on the server, but the cause was never confirmed; the site decided to set up a second, independent DICOM receiver.
When every connection test passes, change one end. Sending the same study to another destination splits sender, path and receiver in one step and tells you whose log to read next.
A laptop that split client from server
A reading workstation running the eFilm PACS client kept failing to load studies, and the engineer was about to reinstall the client, moving from version 4.2.3 to an older 3.4. Before removing anything he wrote down every DICOM setting of the client. A colleague proposed a cheaper test first: install a simple free DICOM client on a laptop, enter the same AE title, port and server details, and connect it to the PACS. If the laptop worked, the fault lived in the workstation's client; if it failed in the same way, the server or its configuration was to blame. The colleague also warned that the client left a lot of registry residue after removal, which is why a clean record of the settings mattered.
Before reinstalling anything, substitute a known-good node with the same settings. It tells you which side to work on and saves the settings you would otherwise lose.
Thrown out every ten minutes
Users of an imaging workstation complained that the application logged them out about every ten minutes. Everyone had their own login, so the engineer first suspected a short session time-out in the configuration and looked for it there. Nothing was set that way. The pattern was too regular to be a crash, so he asked who else used the system and from where. It turned out that a third doctor was logging in with the first user's account from another computer, and each new login ended the other session. Giving each person their own account ended the problem.
A regular, repeatable symptom is a condition to be explained, not a fault to be patched. Ask who, where and when before changing settings.
On-site checklist
- Save queues and logs from every side before retrying or rebooting.
- Record clock offsets before comparing timestamps.
- Write the fault as a condition: object type, size, destination, time, user.
- Reproduce with a fictional test patient, never a real study.
- Use a service laptop as a substitute sender or receiver.
- Capture traffic only with written IT permission, briefly, and delete afterwards.
- Change only your systems, one change at a time, with old values recorded.