Deploying DICOM Applications

There are several issues to consider when deploying a Merge DICOM Java toolkit based application. These include deciding which Merge files are needed for your application, how to set important configuration options to reduce problems in the field, and how to deal with potential UN VR problems. The following sections describe these issues in further detail.



Merge DICOM Java toolkit Required Files

There are a limited number of files required by Merge DICOM applications. These files are described in the following table.

File Description and Use
merge.ini Merge DICOM initialization file. This file contains logging information and pathnames for the other configuration files.
mergecom.pro Merge DICOM system profile. This file contains general run-time configuration options.
mergecom.app Merge DICOM application profile. This file contains configuration information about the services supported by the Merge DICOM application and information about remote DICOM applications.
mergecom.srv Merge DICOM services file. This file contains information about the services supported by Merge DICOM toolkit.
mrgcom3.msg Merge DICOM message information file. This file contains validation information for DICOM messages. This file is required for attribute set validation and for DICOMDIR handling.
mrgcom3.dct Merge DICOM data dictionary file. See the Merge DICOM database manual (Database.pdf) for information on how to add private data element definitions to the dictionary.
mcw.jar The Merge DICOM toolkit package.
mc3adv_win.dll, mc3adv_win64.dll, libmc3adv_lx.so, libmc3adv_lx64.so, libmc3adv_sol.so, libmc3adv_solx86.so or libmc3adv_osx64.dylib The native Merge DICOM C Toolkit Dynamic Library for 32-bit Windows, 64-bit Windows, 32-bit Linux, 64-bit Linux, 32-bit Solaris (on Sparc and Intel x86) or 64-bit Mac OS X platforms, respectively.

If the native libraries do not reside in the current working directory for your application or in a directory that is part of the %PATH% environment variable (on Windows platforms) or $LD_LIBRARY_PATH (on Unix/Linux-like platforms), you can specify a directory by setting the mc3adv.library.path system property on the command line for the JVM:

-Dmc3adv.library.path=directory/for/native/libraries

Configuration Options

The majority of Merge DICOM toolkit's configuration options can be used to solve interoperability problems in the field. There are some options, however, that should be set before deploying a Merge DICOM application to help reduce potential problems. These options are listed in the following table with descriptions of how they can be set.

Configuration Option Description
ACCEPT_ANY_APPLICATION_TITLE When set to NO, Merge DICOM toolkit will check that the Application Entity title sent in an association request matches one of the registered application titles for the SCP. When there is no match, the association will be automatically rejected. Setting this option to YES will eliminate some association negotiation problems in the field for SCP applications.
ACCEPT_ANY_HOSTNAME When set to NO, Merge DICOM toolkit will attempt to resolve the IP address of the SCU application into a hostname. If this resolution cannot be done, the association will automatically be rejected. Setting this option to YES will reduce configuration problems in the field for SCP applications.
EXPORT_UN_VR_TO_MEDIA Setting this option to YES will cause UN VR attributes to be included when writing DICOM Part 10 format files. See the following sections for a further discussion of UN VR.
EXPORT_UN_VR_TO_NETWORK Setting this option to YES will cause UN VR attributes to be included when sending messages over the network. See the following sections for a further discussion of UN VR.
IMPLEMENTATION_CLASS_UID The Implementation Class UID is used to identify in a unique manner a specific class of implementation. PS3.7 of DICOM states: "(The Implementation Class UID) is intended to provide respective (each network node knows the other’s implementation identity) and non-ambiguous identification in the event of communication problems encountered between two nodes." PS3.7 of DICOM further defines how this UID should be defined: "different equipment of the same type or product line (but having different serial numbers) shall use the same Implementation Class UID if they share the same implementation environment (i.e., software)."
IMPLEMENTATION_VERSION The Implementation Version is intended to distinguish between software versions of an implementation. It should be set to the version of the application.


UN VR

DICOM Supplement 14, Unknown Value Representation, became a part of the DICOM standard on June 3, 1997. This supplement added a new value representation, UN, to the DICOM standard. It was developed to fix two related holes in the DICOM standard:

The need for this supplement is mainly for use in archive systems. An archive will typically want to preserve the private attributes contained within a message for later use. There also may be a need to add support for new image objects with new VRs to an archive system without having to change the software.

Unfortunately, the method that Supplement 14 specifies for encoding UN value representation attributes is typically not compatible with older DICOM implementations. Versions previous to 2.2.2 of the Merge DICOM toolkit do not parse these attributes properly. The MCassociation read method will fail and the association will be aborted if a UN VR attribute is received. This has obviously caused a variety of interoperability problems in the field.

The typical DICOM scenario where UN VR can cause a DICOM communication failure is the following: a modality exports a series of images to a PACS or archive system via the DICOM storage service class. The images were encoded in the implicit VR little endian transfer syntax and contain multiple private attributes. Later, a DICOM workstation decided to retrieve the images from the archive or PACS system. The workstation does not yet support UN VR, however, the PACS or archive system does. The workstation uses the DICOM query/retrieve service class to retrieve the series of images. When the images are exported to the workstation with an explicit VR transfer syntax, the workstation fails to parse the first image received when it encounters the first UN VR attribute, and the association is automatically aborted by the workstation.

We have added several methods to solve this interoperability problem through the Merge DICOM toolkit’s configuration files. For SCU systems that are exporting UN VR tags to systems that cannot handle them, the following can be done:

With the help of these options, most UN VR problems in the field can be fixed simply by changing configuration values with the Merge DICOM toolkit.


DICOM Unique Identifiers (UIDs)

UIDs provide the capability to identify many different types of items. The purpose of UIDs are to guarantee the uniqueness of the these different types of items. DICOM uses UIDs to uniquely identify items such as SOP classes, image instances and network negotiation parameters. Part 5, Section 9 along with Annexes B and C of the DICOM Standard discusses how UIDs are composed, encoded and registered.

Summary of UID Composition

A UID is composed of a number of numeric values as defined by ISO 8824. The following is a typical example of a UID:

    1.2.840.10008.2.45.1.12345

A UID is composed of two parts: a <root> and a <suffix> and has the following form:

    UID = <root>.<suffix>

where <root> is assigned by a registration authority (e.g. ANSI) with the distinguishing component being the organization ID. The <root> portion of the UID uniquely identifies an organization while the <suffix> portion is used to uniquely identify a specific object within the scope of the organization. While the <root> component of the UID stays constant, the <suffix> portion will change in a manner that will provide uniqueness for objects that need UIDs. Note: this implies that the organization is responsible for maintaining the uniqueness of the <suffix>.

For example, using the UID above, <root> = 1.2.840.10008 and <suffix> = 2.45.1.12345. Where the organization ID portion of the <root> (10008) distinguishes organizations from each other.

Note: The above example is typical for UIDs obtained by ANSI during the time when the DICOM standard was first released. The organization ID of 10008 has actually been assigned to NEMA and is used as part of the <root> for DICOM standard UIDs such as SOP Classes, Transfer Syntaxes, etc. For example, vendors creating images need to obtain their own organization ID and cannot use 10008.

For future UIDs, ISO has developed a joint relationship with CCITT and has changed the <root> structure. Therefore, new UIDs from ANSI will no longer be of the form 1.2.840.xxxxx. but are currently assigned using the form, <root> = 2.16.840.1.10008. Where, of course, 10008 is the organization ID.

Obtaining a UID

The <root> portion of the UID should be registered by an organization that guarantees global uniqueness. The American National Standards Institute (ANSI) is the registration authority for the United States. Other national registration authorities exist for nations throughout the world such as IBN in Belgium, AFNOR in France, BSI in Great Britain, DIN in Germany, and COSIRA in Canada.

ANSI is the registration authority for the US for organization names (i.e., <root>) under the global registration process established by the International Standards Organization (ISO) and the International Telecommunication Union (ITU). ANSI’s registration service conforms to ITU X.660 and ISO/IEC 9834-1. The ANSI organization name registration service assigns one name component to the hierarchy defined by ITU and ISO/IEC.

More information on the registration process (forms, fees, etc.) can be obtained from ANSI's website: http://www.ansi.org.


Copyright © 2023 Merge Healthcare Solutions Inc. All Rights Reserved.