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.

Top DICOM Configuration Do’s and Don’ts.

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.”

Here’s are some of the most important best practices.

1.       Set your SOP Class configuration at a modality to the new SOP Classes - Many modalities allow for images to be encoded as different SOP Classes, which are often configurable. The reason is that over the past 20 or so years, as DICOM matured, new versions of the initial SOP Classes were refined to solve problems caused by incomplete, vague and inconsistent data formats, and to facilitate new technology developments. One of the major changes was the increasing use of codes instead of text strings in the DICOM headers, e.g. for body parts and view codes to allow for better and more reliable pre-fetching and hanging protocols of prior studies. There is one caveat, i.e., one needs to make sure that the receiving system, e.g. PACS and/or workstation, also supports these new SOP Classes, otherwise one creates incompatibilities. Otherwise there is no reason NOT to use the latest and greatest SOP classes to provide better functionality and more information. To be specific, always configure any digital radiography unit with “DX for presentation” instead of the “CR,” any CT, MR, XA and RF always with the “enhanced” instead of the “regular” SOP Class and any tomosynthesis breast imaging unit with the “DBT,” instead of any of the Secondary Capture or, worse, CT objects.

2.       Set your Transfer Syntax configuration at modalities and PACS to Explicit VR Little Endian (ELE). Always configure a sender to send ELE and a receiver to accept the same in case there are multiple options for the Transfer Syntaxes being proposed as part of the DICOM negotiation. Explicit VR has the advantage that the Value Representation (VR) is explicitly specified as part of the DICOM header, which is “good practice.” The alternative encoding, Implicit VR, is the default transfer syntax, and could potentially be a source of problems if someone were to use that to create a CD without doing the conversion to Explicit VR (the DICOM media exchange format requires Explicit VR). Note that instead of Little Endian, you could also send images in Big Endian (BE) encoding, which is relatively rare. If you run into an old system that supports BE, which is common for Unix/Linux based modalities, make sure that LE is configured instead of BE as its sparse implementation could create compatibility or display issues later on.

3.       Use the “officially assigned” port number - Port 104 is probably the most used port number for DICOM connections, however because of certain system limitations, vendors have been using different ones such as port 5004, 6000, and others. A new DICOM port number, 11112, was assigned quite a while back by the IANA authority to the DICOM committee. Good practice would be to standardize on this port number to make it easy to manage ports at the network/router levels. I would not go back and change all of your existing port numbers but for every new device and/or upgrades, using 11112 is good practice.

4.       Use sensible AE title’s - With the increasing consolidations and mergers causing more image sharing, it is even more important to have non-duplicate AE-Titles, or, at a minimum have a system in place that allows for an easy identification of the source and destinations. An AE-Title of “WORKSTATION_14” is not as helpful as “BLR_ER_CTWSTN_05,” for example, which might indicate that this is workstation 05, connected to the CT, in the ER at Baylor Medical Center. This is another example of using “good practices.”

In conclusion, by configuring your imaging devices and PACS using good practices, one can be more efficient, facilitate a better workflow, and prevent issues down the line when having to migrate and/or pre-fetch these images. It makes sense to follow these rules when installing new devices or even go back and make some changes to their configurations. I listed the most important tips to configure your DICOM capability here, I am sure there are more, 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, which will go over these subjects in great detail.