1. Network Issues:
A well defined and managed network infrastructure is essential. Dynamic IP addressing is fine as long as the router does not re-assign them to a different address (e.g., when being re-booted or replaced).

A rather frequent occurrence is the incorrect setting of the switch (e.g., to half duplex or mismatching the device setting), especially when auto-negotiating is configured. Switch issues result in major performance issues and can only be made visible when using a network sniffer. Combined with “netscan” utilities to detect any IP addressing issues, these are essential tools to deal with these issues.

2. DICOM Header Issues:
The DICOM image header is generated through mapping RIS data, generation of the modality, and manual input by a user. Any of these sources can potentially generate incorrect and/or invalid data in the image header. Problems are, unfortunately, not always detected. For example, an incorrectly identified study might be archived in the PACS and get “lost,” only appearing when the data is migrated, which could be years later.

A header with an Institution ID exceeding the maximum length of that field might be stored by vendor A, while being rejected by vendor B as an invalid image when being migrated years later. Keeping tight tabs on these issues and validating images using appropriate tools is important.

3. Hanging Protocol Issues:
Hanging protocols not working is almost always related to incorrect header information or the wrong interpretation of the headers. A common mismatch is related to the way CR and DR systems organize their images into series. Some create a new series for each view (e.g., a Chest PA and LAT), and some group them together in a single series. Another frequent issue occurs when some modalities modify automatically series and study descriptions, not taking the values from the worklist, therefore causing those descriptions to not match the hanging protocol configurations at the view station. Sometimes additional QA steps are required, in addition to training of technologists.

4. CD import issues:
These issues almost always can be traced back to non-compliance with the DICOM standard and/or corresponding IHE profile. Frequent issues are: the absence of DICOM image files, because the vendor is only providing their proprietary format; a missing directory file; mismatch of the so-called meta-file header with the actual data content; incorrect transfer syntaxes, such as compression; and several others. In many cases, one can convert the images to an acceptable format that can be imported using additional tools. However, in some cases, it is impossible to read the proprietary information, causing a repeat exam.

5. SOP Class support:
Modalities are eager to support new functionality, represented by the use of new SOP Classes, as they contain more information and allow for better viewing and processing. The most common mismatches are due to non-support of the PACS for the enhanced CT, MRI SOP Classes and Structured reports, such as those generated by CAD devices and Ultrasound units for measurements. In most cases, a modality can be “defeatured” to fall back to an older SOP Class, or alternate encoding (e.g., burn in the CAD marks into a secondary capture). In some cases, one will be stuck with the proprietary information (e.g., MRI spectroscopy).

6. Transfer syntax support:
In addition to missing SOP Class support, PACS systems might not support the specific encoding (i.e., transfer syntaxes). Occasionally, a PACS system might mishandle a Big Endian encoding from an older modality, JPEG, or wavelet compression support. Many PACS systems do not (yet) support the MPEG files created by endoscopy and surgery exams. Upgrading your PACS and/or “downgrading” your modality is the only solution.

7. UID issues:
Some devices create “illegal” UIDs, because their algorithm sometimes creates empty values or subcomponents with leading zero’s. Most PACS systems will either refuse these images or quarantine them. Some modalities issue a new UID when an image is resent, which requires someone to delete these duplicates at the PACS. Some modalities re-use a UID, therefore requiring a PACS SA to fix those as well. There are no solutions except for keeping the vendors accountable to fix their software.

8. Modality Worklist (MWL) issues:
A worklist provided by the RIS, PACS, or broker, should match the studies to be performed at a modality, no more and no less. Some Modality worklist providers provide too much data (e.g., all of CR exams instead of only the ones for the ER), some provide not enough differentiation (e.g., only the bone-scans), and some provide not enough. Remedies are reconfiguring the modality worklist provider, interface engine, or sometimes changing the input data by the scheduling department.

9. Burned-in Data:
Many Ultrasound units and frame-grabber interfaces have the unfortunate side-effect that all of the information on the screen is captured, including the patient demographics. This can create major issues when the patient demographics are incorrect, which happens in most cases because a technologist forgets to select a new patient or makes an incorrect selection. Many users put an “X” over the incorrect text, with as serious risk that a receiving application might not support these overlays, presentation states, or even proprietary annotations. The only solution is to use “paintbrush” utilities.

10. Loss of annotations:
Many PACS systems still support proprietary solutions to store annotations. When displayed on the PACS workstations from the same vendor they appear, however, when displayed on another vendor’s workstation, such as used by a referring physician, night hawk service, or 3rd party web servers, they will disappear. The solution is to generate compatible overlays (some modalities and workstations have this option) and/or upgrade all of your devices to support the DICOM Softcopy Presentation State.