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.
