DICOM connectivity maturity model

The majority of the PACS installations do not use good practices. The main reason is a lack of
education and knowledge, both from the end-user (PACS administrator) side as well as from the vendor side. Service and support engineers typically want to be in-and-out and avoid any extra work and might not set up the more advanced features of your PACS. The same applies for any new modality connections; the company engineers will set up the bare minimum and not want to bother with any advanced capabilities, which will impact your workflow and operation.

Here are my recommendations for the most important good practices, organized in different steps, each representing an incremental maturity level.

1.      Use common sense AE Titles and standard ports – the DICOM AE-Title is a fixed application level address of your DICOM application. Most devices have one AE-Title, some have multiple (e.g. a PACS might have four, one for its archive, one for the image manager/database, one for the print server and one for the modality worklist provider). Use only upper case characters and the control character “_” (it is case sensitive), use easy to remember mnemonics (e.g. CT_ER), and prefix it with the facility code to make cross-enterprise connectivity easy (e.g. STJGNL for St. Joseph General hospital). Remember you only have 16 characters to encode these, so be creative.

The well-known DICOM port which many use is port 104, however, this might not always be available as some systems limit access to the lower number ranges. To prevent potential conflicts, stick to the “official” DICOM port number, which is assigned by the Internet Assigned Numbers Authority (IANA) as 11112.

2.      Standardize on a preferred Transfer Syntax  – Many modalities have the option to offer Explicit VR when they negotiate transferring images and other objects. Always select this option, don’t use Implicit VR unless you absolutely have to. Explicit VR requires a sender to specify the VR (data type) for all of its header attributes, which is useful for private data. In addition, if you ever want to exchange the images on an exchange media such as a CD, implicit VR could cause issues as it is not allowed on exchange media.

Avoid using Big Endian, which has become less of an issue as most modalities today use Little Endian Byte order, however, if there is an old modality which uses the Unix operating system (and therefore the Big Endian encoding), configure either the sender to only send Little Endian, or configure the receiver to accept only the Little Endian. The reason is that some viewers might not be able to view those, and, similar to the Implicit VR encoding, it is not allowed for exchange media.

Stay away from any proprietary compression encodings, i.e. that are non-DICOM standard, and use the standard JPEG lossless and lossy for your modalities and Wavelet Lossless and Lossy for long term archiving.

3.      Avoid any proprietary and raw image objects (SOP Classes) – There are two types of proprietary objects, the first type is easy to recognize as it carries a proprietary unique identification (UID), which means that they are easy to detect. Many PACS systems will refuse to archive them, and I have incompatibility issues with these if someone puts them on a CD for image exchange, for example, it is not uncommon for private CR objects to end up on CD’s. Other applications are the 3-D private ultrasound or angio/cardio applications. The second group of proprietary objects are the ones that are “standard” on the surface, i.e. it is a standard image object such as a CT or secondary capture, but under the cover it is really another object, which became popular with the onset of the new breast tomo-synthesis modalities. The latter created a lot of incompatibility issues, one vendor would be able to recognize that the CT image was really a mammography but anyone else would get really confused and hanging protocols as well as pre-fetching algorithms would fail.

With regard to archiving raw data, I come across institutions that archive their raw data for mammography images. The raw data is only used to run a CAD algorithm, and unless you are an academic institution and want to save this raw data to test future new CAD algorithms, this would more than double your mammography image storage requirements. Only keep the image data, and don’t archive the raw data.

4.      Archive only thick slices and enhanced “anything” image types (SOP Classes) – CT scanners are increasing their number of slices, a 64-slice is becoming more or less the standard. However for cardiac applications, one might have a 320- or even up to 640-slice detector. The number of thin slices can easily run into the thousands. These thin slices are great for 3D imaging as they allow access to “orthogonal” voxels, i.e. having identical resolution in any direction to allow for lossless MPR, and 3D rendering. However, these thin slices don’t really provide additional clinical information that can’t be seen by averaging multiple thin slices into thick slices and stacking them for review by the radiologist. Therefore, keep the thin slices for let’s say a month so you can do additional 3-D views if you wish, but only permanently store these reconstructed 3D’s with the thick, averaged slices and save multiple factors of storage.

The new CT’s, MR’s and also the angio and cardio (“anything”) modalities typically support two types of image formats, the traditional format, e.g. CT or MR image storage and the “enhanced” versions. The enhanced image headers are more comprehensive, have more information, are much more standard with regard to the different series extending them to multiple “dimensions” and information in the header uses standard encoding for most clinical terms. In short, the enhanced versions are a more complete standard encoding between multiple vendors. The hanging protocols are more robust based on elaborate header information. Last but not least, these objects are multiframe, which means that the protocol overhead to transfer a study is more effective as it happens in a single transaction instead of having to use thousands of transactions back and forth to exchange one of these studies.

5.      Use the DICOM workflow services, i.e. Storage Commitment, Modality Performed Procedure Step (MPPS) and Instance Availability (IA) – Almost any modality supports Storage Commitment to provide a secure “hands-off” between a modality and PACS. Using this prevents images from falling between the cracks and getting lost. The same applies for the hands-off between a PACS and VNA, or cloud storage. It is just a matter of configuring this feature. The same applies for using MPPS, use it where you can as it provides a hands-off between the modality and PACS allowing for studies to appear on a radiologist worklist as soon as they are available, and automating any updates caused by changes in the procedures. IA is even better for identifying that processing and/or reading can be done as a next step. Also make sure your PACS and VNA support the new IHE profile IOCM (Image Object Change Management) to synchronize any changes in patient demographics, which will save your PACS administrator a lot of extra work.

6.      Use Structured Reports instead of a screen capture for CT dose and Ultrasound measurements, and switch off embedded US annotations – It is easy for a radiologist to look at the CT screen containing the dose information and record that as part of the report (which has become standard practice), however, a digital interface to the reporting system would allow this information to be automatically captured, saving time, increasing accuracy, and having much more detailed information in these reports that can be used for quality reporting and improvement.

Use Structured Reports for measurements from your ultrasound instead of re-recording all these measurements which is time consuming and prone to errors. Using the true digital interface to a reporting system is much faster and more accurate.

Switch off embedded ultrasound annotations. There is absolutely no need to have the patient name “burned-in” the image data as the DICOM header has this information. Burned-in data is very hard to get rid of in case corrections have to be made to the name, or the data has to be anonymized for whatever reason.

In conclusion, none of these features are new, they are proven, established more than 5 years ago, available in pretty much all of the systems out there, and activating them is just a matter of configuration. If you do so, you will be able to provide a more robust and more efficient infrastructure to your medical imaging department. And, as an extra bonus, you could claim to be compliant with a certain level of DICOM connectivity maturity. 100 percent compliance might be hard, but I would argue that 80 percent compliance for each level would qualify.