Thursday, August 20, 2015

Top ten DICOM Do’s and Don’ts-part 2.

When configuring a modality, view station, or PACS, many might be tempted to leave its default
factory configuration as-is, however, that might be a big mistake as it can impact your workflow, create current or future incompatibilities, or violate what would be considered “best practices.” After my initial list (see link), here are some additional tips:

1.       Configure MPPS – I typically do an informal poll of my students in our DICOM training and ask how many of them use MPPS, and the response is that about 20% of the audience use it, another 20% tried it but had issues, 20% did not want to bother and 40% had no clue what I was talking about. The people that did not want to bother are often service engineers setting up a new modality, and did not have access to the destination of the MPPS to configure it and did not want to wait for the local IT and/or PACS service engineer to coordinate this feature as it requires additional work and testing. The people who use MPPS are typically enthusiastic about it as it eliminates additional steps in the workflow, in particular the need for a technologist to check image count at the PACS, or closing the exam at the RIS, or making changes to the procedure manually at the RIS, instead of relying on the MPPS to convey that information electronically. There is a minority, which I estimate might be 20%, where the MPPS workflow does not quite match the current workflow, mostly for specific modalities, such as an ultrasound where you want to be able to complete a study on another modality, which could be challenging, but again, these are exceptions. For the vast majority of the cases, MPPS is underutilized and using it could have an impact on your data integrity and your efficiency. Therefore I strongly recommend considering to configure MPPS “on” at your modalities, PACS and RIS.

2.       Configure Storage Commitment (STC) – This is another workflow enabling DICOM capability that is often turned off. One of the reasons it is not always used is identical to the reason for not using MPPS, as it might be too much trouble to set up by the service engineer, or that it caused issues, which can often be traced back to not configuring it correctly. STC hands off the responsibility of archiving a DICOM object, in most cases the images, to a PACS archive, for example. It could also be used very effectively to hand off the responsibility from a PACS to cloud storage or to an enterprise archive and/or VNA. A problem when using STC occurs when it is configured at a modality and not configured at the destination, e.g. PACS. Because the sending device does not allow images to be automatically deleted from its local storage unless a storage commit acknowledgement has been received, its local storage might get full at a certain point, thus preventing new acquisitions. If this happens, the short-cut is to configure STC to be “off.” This could potentially lead to images being lost due to the lack of a handshake, or require a technologist to manually check whether all of the images actually made it to the destination, which is again extra work and subject to human error. There is one more configuration parameter that is related to the STC that specifies if the Storage Commitment request and response is processed on the same DICOM Association or a different one. The DICOM protocol allows for either option, requiring the configuration of the sender and receiver to match behaviors.

3.       Switch off promiscuous behavior by a receiver – In the context of networking, being configured as promiscuous means that a device will talk with anyone who happens to use its IP address and port number. Some devices are only promiscuous for certain features, for example, a PACS might allow someone to query its database but not allow a device to retrieve images unless it is configured to do so. I would argue that best practices require that any device that wants to communicate with a PACS system, for example, must be configured accordingly. If a new “strange” modality for example wants to exchange information with a device, it is not allowed to do so unless it is added to its DICOM tables. The reason people use the promiscuous mode is again that it is easy and less work as additions and changes do not have to be updated in the configuration files. However, being strict on who is allowed access is good security practice.

4.       Create only DICOM compliant exchange media – When burning a CD with patient images or copying a study to a flash drive, make absolutely sure that you create a DICOM compliant medium. Using a file copy command will not do that as there are very specific requirements about the encoding of the images (Using the Explicit VR Little Endian Transfer Syntax for most use cases) and the presence of a directory (DICOMDIR). Some vendors even provide the option to create a proprietary format of an image that can only be viewed with the embedded viewer on the CD, which is useless in case these need to be imported into another PACS system, so, never do that. Your best bet is to use an after-market CD reader and writer program, which is typically more user friendly than what is provided by the PACS, but is also much more careful about creating DICOM compliant CD’s. And in the case that someone created a non-compliant CD, these after-market systems often can read the proprietary formats as well.

5.       Use compression only for specific use cases – Compression can be applied at a modality, a gateway, or archive. Lossless compression at a long-term archive definitely makes sense as it reduces the amount of storage needed by a factor of at least 2, and often 3, using lossless compression. Compression at the modality makes sense for ultrasound, especially for cardiology echo when several series can be acquired that otherwise would result in large studies requiring a lot of storage and potentially slow transmission over the network. Lossy compression could compress the files sizes by 10 to 15 to 1. For angio and cardiology X-ray, it also makes sense to use compression as a typical study could contain up to 10 runs. The DICOM standard allows for quite a list of different compression schemes, but I suggest sticking to the basic JPEG for lossy and lossless compression as its implementation is widespread and incompatibility issues are relatively rare. For endoscopy and surgery, the file encoding is part of the file as the cameras that capture the images already have converted the data to an MPEG file. One needs to make sure that MPEG is supported by the receiver in addition to the correct MPEG version (MPEG-2 or MPEG-4).

6.       Use PDF instead of Secondary Capture – When scanning documents into the PACS, or when capturing a screen such as from a bone densitometry device, most systems create a bitmap as a Secondary Capture DICOM object. These objects can be quite large. Using a PDF is a much better choice because of its efficient encoding. DICOM specifies a so-called encapsulated PDF SOP Class, which basically wraps a pdf file with a DICOM header. You need to make sure that the receiver can support these, but many of them do today. This is another example of a more efficient use of your bandwidth and storage.

In conclusion, several of these will definitely facilitate a better workflow; it makes sense to follow these rules when installing new devices or even go back and make some changes to their configurations. Again, I am sure there are more tips, and would love to hear from you so I can expand this list for the DICOM community to use. If some of this goes a little bit beyond your understanding of the DICOM domain, you might want to check our core DICOM web-based training or face to face training in Dallas, which will go over these subjects in great detail.