Advanced Medical Imaging

Teleradiology & PACS a Winning Combination

BUSINESS AREAS PACS TELERAD DICOM SCALE ABILITY UPGRADE ABILITY COST EFFECTIVE IMPROVED CARE REVENUE GENERATING

DICOM Conformance

 To claim compliance to the DICOM standard, a manufacturer must provide a DICOM Conformance Statement for each type of equipment. The conformance statement is a standardized way of identifying the specific DICOM capabilities of the equipment. While it often looks complex and intimidating, once you understand the essential elements of comparing conformance statements, you will see that it really isn’t that difficult.

An understanding of some DICOM basics is needed before going on to learn to compare conformance statements. Two main concepts are presented here: DICOM Service Object Pair (SOP) Classes and the roles of Service Class User (SCU) and Service Class Provider (SCP). After covering these concepts, we will look at a portion of conformance statements from two sample pieces of equipment and compare them for DICOM compatibility.

DICOM Conformance Statements

Dicom Conformance Statements for products below are curently available:

• PACS/DX ScanStation and DVCStation with NetSend
• ViewStation (Stand Alone)
• PACS/DX Image Server
• PACS/DX TeleRouter
• ViewStation with NetSend 

Comparing DICOM Conformance Statements - Simplified

DICOM SOP Classes

DICOM capabilities are all expressed as Service-Object Pair Classes. This is DICOM jargon for saying that a given capability, such as storage of CT images, relates to both an object (the CT image) and the service (storage). What’s important is that all DICOM SOP Classes are identified by a unique identifier (UID) and name. SOP Class names and UIDs are just a way of clearly identifying each DICOM capability, that’s all.

DICOM Service Classes are names given to group SOP Classes together for convenience. The following contains the DICOM Service Classes that we will be concerned with. (The differences in the Query/Retrieve SOP Classes, e.g. Patient Root vs. Study Root, are rather minor, but beyond the scope of this document.)

These abbreviations for image types are used throughout:
CR Computed Radiography
CT Computed Tomography
US Ultrasound
MR Magnetic Resonance
NM Nuclear Medicine
SC Secondary Capture

Roles: Service Class User (SCU) and Service Class Provider

Perhaps no part of the DICOM terminology is more confusing than the terms Service Class User and Service Class Provider. If you will think of DICOM as a client/server model, think of the SCU as the client and the SCP as the server. The SCU (or client) requests some service from the SCP (or server). In DICOM, however, the roles SCP and SCU refer to the specific service being provided at the time and not to the overall architecture. A DICOM entity commonly acts in several service class roles either as user or as provider, and often in both. The SOP class defines the actions of the SCU and the SCP. Let’s examine briefly how the SCU and SCP interact in each service class.

Verification Service Class SCP/SCU Roles
The Verification Service Class is simply a means of determining whether a DICOM entity is active and can be reached on the network. The SCU requests this verification and the SCP, if active, provides a response. No other data is exchanged.
Storage Service Class SCP/SCU Roles
Each of the Storage SOP Classes handle only one particular image (or other object) type. The use of the term “Storage” is perhaps unfortunate. “Send” would perhaps be a better name. When the SCU requests that an image be stored, it is really only requesting that the SCP receive the image. The SCP does not guarantee any duration or safety of storage, but merely accepts the image from the sender. In real life, there usually is some duration of storage implied, possibly even some archiving, but that is up to the manufacturer.

Query/Retrieve Service Class SCP/SCU Roles
The Query/Retrieve Service Class provides two distinct services: Find and move, hence the name Query/Retrieve. In the case of a find request, the SCU requests information (such as patient name, study ID, etc.) about images that the provider has available. The SCP then responds with any of the requested information that it has.

In the case of a move request, the SCU is asking that certain images be moved from the SCP to some destination. Although it is typical that the SCU requests the images to be sent from the SCP back to the SCU (basic retrieve operation), it is also common for the SCU to request that the images be sent to a third entity. Note that the move SCP must also be an SCU of the Storage Service Class to send the image to the destination.

The Conformance Statement

All DICOM conformance statements are laid out in a standard way. When comparing conformance statements, there is only one essential section of every conformance statement that we are interested in: Application Entity (AE) Specifications. “AE” is the DICOM term for the unit that the conformance statement describes. The AE Specifications section is normally near the beginning of the document, just after the introduction and definition of terms. It consists of one or more tables that list the supported SOP Classes under the role of SCP or SCU. For each specification, look for the AE Title, the DICOM Service class, and the role. (They are underlined in the first example.) Below is a sample of the AE Specifications section from a DICOM conformance statement:

This portion of the conformance statement is often all you need to compare statements for interoperability and it is all that we will look at in this exercise. There are other aspects of DICOM given in a conformance statement, but they seldom add much to what we are trying to accomplish.

What does this sample show us? It shows us that this particular DICOM AE, called Image Server, is a Verification SCP, a Storage SCP for the six image types listed, a Query/Retrieve SCP for patient and study root, and a Storage SCU for the same six image types. (Remember that to be a Retrieve SCP, an AE must also be a Storage SCU.)

Comparing Conformance Statements

The key point to remember is that we compare each DICOM entity by SOP Class and role. For a given SOP Class, one entity must be an SCP and the other must be an SCU.

Another set of sample specifications is shown below.

Now, let’s compare Image Server conformance to ViewStation.

Are they compatible for the Verification SOP Class?
No, they are both SCPs of the Verification SOP Class, and neither one is an SCU. (This is a contrived example just to illustrate the point. In real life, you will not likely encounter a viewer that is a Verification SCP without being an SCU.)

Are they compatible for the Query/Retrieve SOP Classes?
Yes, for the Patient Root Find and Move SOP Classes they are, but not for the Study Root SOP Classes. Image Server will act as an SCP and ViewStation will act as an SCU.

Are they compatible for the Storage SOP Classes?
Yes, for the five image types listed for ViewStation, but not for the NM Image Storage SOP Class, which ViewStation doesn’t support.

A simple chart illustrates the compatibility of Image Server and ViewStation.

Done!

That’s it! It’s really that simple. Armed with this information, we have some assurance that these two DICOM entities can accomplish the following tasks: ViewStation can query Image Server to see what images are available, it can request retrieval of images, and Image Server can send any of five types of images to ViewStation. That is the extent of their compatibility. There are no guarantees that things will work the way the customer wants them to, but this is what should work, from a DICOM point-of-view.

A Final Word of Caution

Don’t consider the DICOM Conformance Statement to be the final authority of whether given equipment will work together or not. To be honest, conformance statements often leave a lot to be desired. Additionally, there are other aspects of operation that are not covered in the conformance statement that often has a significant effect on the users.

Conformance statements tell you quickly the DICOM capabilities of given equipment in a way that allows for easy comparison at a very basic level. With a conformance statement you can easily spot incompatible equipment. It gets a little trickier with equipment that should be compatible, but this is only the first step in making that determination. This comparison will help you identify equipment to meet the needs of the customer, but further review and most often, actual testing, is required to be certain that the equipment will work as desired.
Formal conformance review and other assistance is available from the System Support Group. Please contact us for more information.


Additional Sources of Information

The DICOM Standard itself is available from:
National Electrical Manufacturers Association
1300 North 17th Street, Suite 1847
Rosslyn, VA 22209
(703) 841-3200

A very good DICOM Training class is provided by:
Merge Technologies
1126 S. 70th Street
Milwaukee, WI 53214-3151
(414) 475-4300