Digital Imaging and Communications in Medicine (DICOM)

7.3 Storage 135
C-Store bottlenecks
If you implement DICOM software that uses C-Store to send image series,
never interpret a single image store failure as a failure for the entire series.
A single image in a series can fail C-Store for many totally benign reasons
(for example, the image already exists at the destination) and it should not
stop the transmission of the remaining images.
More importantly, never interpret a C-Store failure for some images as an
excuse for halting any subsequent communications. We had this experience
with one CR device that was sending images to a digital archive. It
got stuck on one particular study with an incorrectly entered patient ID
(which was illegally blank). The destination archive recognized the ID
problem and refused to accept the study. Surprisingly enough, the CR unit
interpreted this single-study failure as a major disaster and stopped sending
all subsequent studies after the one that failed, even though the new
ones had absolutely correct patient IDs! In a short time, all unsent studies
queued on the CR, filled up its local hard drive, and the unit refused to
process any new patients.
This provides an excellent example of how a single minor problem, magnified
by very poor software design, bottlenecked the entire PACS workflow.
7.3.2
C-Store DIMSE
C-Store takes care of instructing the image-accepting AE on what needs to be
done. Just like C-Echo, C-Store has a request part (sent from the C-Store SCU)
and a response part (replied from the C-Store SCP). If we compare Table 26
to the C-Echo-Rq we studied earlier (see 7.2.2) we find a few new parameters,
which we describe below:
1. Priority: as the table suggests, priority can be low, medium (normal), or high.
Many other DIMSE messages include a priority field in their specifications,
but its support is optional and defaults to medium (0000). In reality, different
message priorities are almost never implemented by DICOM manufacturers,
and this is noted in their conformance statements. This makes
practical sense because maintaining a functional PACS network is much
more important than prioritizing messages, and any priority-assigning
mechanism only adds unnecessary complexity and unpredictability. Delays
in data acquisition, transmission, and retrieval, which are inevitable in any
real clinical environment, have a much stronger impact on any messaging
scheme than predefined message priorities. In short, SOP message priority
is rarely needed.