In the last blog posts in this series I talked about network, addressing issues and incompatible filetypes as well as transfer syntaxes. This post deals with errors that might occur doing the actual DICOM information transfer, i.e. after the DICOM connection (Association) has been successfully established.
When an Association is accepted by the server (SCP), which is indicated by the “Associate_Accept” transaction, the DICOM client (SCU) will issue the DICOM command, which is determined by the negotiated SOP Class. For example, imagine that a device proposes to exchange CT images and it is “OK-ed” by the SCP, the SCU will issue the C_Store command with the CT image file. The receiver will interpret the command, then discard that, and take the file and likely archive it in the case of a C_Store. It could also update a database so it can find it and/or reply to a DICOM query about its location.
If the SCP is a transient device such as a DICOM router, it will pass it on to its destination. Each DICOM command is returned with a corresponding Response, for example, a C-Store Request will result in a C_Store Response, the same applies for queries, moves, etc. The response has a status code associated with the transaction; hopefully it will be “success,” which is identified with the code “0000.” In case there is an error, the status code will contain the appropriate error code other than “0000.” These codes are standardized by the DICOM standard, i.e. there are codes defined for the most frequent errors and warnings.
Here are some of the common errors that you might see:
· Resource issues – Imagine that you are sending a set of images to a destination with limited resources, such as a workstation with limited disk space. In the case that the destination cannot receive any more data files, it will indicate that in the status code A700, meaning “out of resources.” To resolve this issue, one would either go to the destination to free up more resources or send the information to another destination. The reason this error occurs is that one does not know in advance how many files are going to be sent, as there is no indication in the Association negotiation to say how many images are to be transferred. The resource issue does not have to be related to the required archive space, it could also be space for additional tables in the database or other resource restrictions.
· Processing errors – The receiver reports errors when processing the information; for example, it might need to update several database tables upon receipt and archiving, and might have a problem as the images cannot be uniquely identified due to duplicate or missing identifiers. Not every receiving system implements the same set of criteria determining this error condition, some of them will actually accept the information and report “success” while quarantining the data file and flagging it as “Unverified” or “Broken.” This is done so that a physician might still be able to view them and could report on them, while awaiting resolution of let’s say the complete patient’s name and/or other demographic information. We’ll spend another post on the most common issues causing the Unverified status.
· Warnings – A server might also give back a “warning,” its status code typically will start with a hex “B,” an example would be a print server sending back a warning that the number of sheets is getting low in a supply magazine. Another example could be a server telling a SCU that it modified or “coerced” one or more data elements in the header, as needed to make it unique or based on a patient update or merge. Most applications ignore these messages.
· Pending – A “pending” status return message is not an error condition, but an indication to the client that the server is processing the request and will send more replies. This is common for a query response that has multiple matches. This non-successful completion is part of a normal behavior.
How would a client behave when it receives an error? Each device could have a different reaction, some might just continue with what they are doing and log the error, some might stop and notify the user, and some might retry for a configurable number of times with configurable intervals. If a device is following the DICOM standard guidelines, it should specify its behavior in its conformance statement under the section “SOP Specific conformance” for that particular SOP Class. Therefore, check that resource, noting almost all of the DICOM conformance statements can be found on-line. Make sure though that when you look at these conformance statements, that you have the right software version matching your device.
These types of errors are somewhat unpredictable and typically are caused by data information errors or inconsistency, unlike the errors that are caused by file type or transfer syntax errors. As mentioned earlier, it is possible that a server still acknowledges the information transfer to be successful, even if there is an issue to allow a physician to access the incomplete data, such as is common in the case of emergency where the patient cannot be identified at time of patient registration. These most common causes for these so called “Unverified” studies is going to be discussed in our next post.
For additional resources on this topic, you can use “www.otpedia.com,” which has a definition of the most common DICOM terms, or the DICOM textbook which is available either as a printed text or e-book, or, attend our on-line or face-to-face training seminars on PACS/DICOM.