DICOM Conformance Statement

[update 24 March 2023: latest HRZ softwarecan be found on HRZ website - www.hrzkit.com]

During the process of writing the DICOM Conformance Statement of DICOMIZER 5.0 I realized its been on my task list for more than two years! Its a complicated documented to write but two years ... that's a personal record.

So, what's the thing with this document, the DICOM Conformance Statement (aka DCS). Is it important? Is it mandatory to have one for your DICOM application? Why, When and How to read it? When to write one?

This is from the DICOM Standard:

"By comparing the Conformance Statements from two different implementations, a knowledgeable user should be able to determine whether and to what extent communications might be supported between the two implementations."

And of course the key here is "a knowledgeable user" ha ha!

DICOM Conformance Statement is a very technical document that describes (and some would even go further and say specifies) the DICOM capabilities of a product, a system, software or medical device.

There are two reasons to open the DCS:
1. To evaluate a product, before a purchase for example and,
2. When something goes wrong (maybe because you skipped #1 above).

There's a reason for this chapter position, very deep into the DICOM Tutorial. In order to be able to use the information in the DICOM Conformance Statement one has to have substantial experience and profound understanding of the DICOM standard and its fine details.

Lets take an example. You have a system that produces PDF reports and you want to attach them to the imaging studies in your PACS so when opening the study from the PACS workstation the images and the reports can be reviewed together. That's a nobel goal indeed.


So you purchase DICOMIZER (he he) but when you click Send there's an error saying one or more files were not stored. And indeed, from time to time, I get such emails and the first thing I ask for is the log file (DICOMIZER has a log called LastSend.log that records the log from the last send operation). The log file says that one of the SOP Classes was rejected. At this point I ask for the model of their PACS and if they have its DCS and when I get the DCS I quickly  scan through it to the section that lists the supported storage SOP Classes and look for "Encapsulated PDF Storage (The SOP Class UID is 1.2.840.10008.5.1.4.1.1.104.1). If I find it I verify that the PACS supports it as SCP. From the problem description I expect to find out that it doesn't.

The DCS exists to stop such things from happening, i.e. to be used in advance, during the evaluation phase. That's why every commercial product that claims conformance to the DICOM standard should have a DCS and if it doesn't have one, well that's an issue to consider. So DICOMIZER 5, at last, after almost two years, has one and you can download it right now from this link: DICOMIZER DICOM Conformance Statement.

By now, I hope you're convinced that the DICOM Conformance Statement is important because it enables potential customers to evaluate the DICOM implementation of products from different vendors and decide if they integrate properly together. If you are a vendor I hope you are convinced that providing your customers with such document is professionally the right thing to do.

As a vendor, my advise is to start writing the DCS as early as possible because it will help you with your product design. The process of writing the DCS is an essential part of your product external interfaces design. The DCS should be ready for your testing team when they come to verify the product DICOM compliance. For sure you'd like them to verify that the DICOM implementation is performing according to its documentation.

Lets go over this document quickly together. All DICOM Conformance Statements look alike. That's because DICOM went into a lot of effort to provide templates for it in the second part of the DICOM Standard which is actually the first part that defines anything. I think this indicates how important this document was to the people that wrote the standard.

Before diving deeper into the document itself, its important to mention another important document that takes takes interoperability much much further. I mean the IHE integration statement. IHE went way forward and took interoperability and standards utilization to its extreme. While DICOM has so many options that it requires dozens of pages to describe your implementation for it, the IHE technical framework documents on the other hand are so much more detailed that in order to claim conformance to IHE integration profiles, 3 pages document is just right. All it takes is to say something like "My application implements the Imaging Modality Actor from the Scheduled Workflow Integration Profile".

The Overview

The first section in every DCS should be an overview that describes the application and then presents a table with network services and another table with media services. After reading the overview one should be able to answer questions like:

1. What is this application? A PACS? A Workstation? An Imaging Modality? A Modality Worklist Server?
2. What services it provides and use? Storage? Q/R? MWL? MPPS?

Here's the network services table from DICOMIZER's DCS:

DICOMIZER Network Services

So a knowledgeable user looks at this table and says:

1. I can C-ECHO to it and also send C-ECHO from it.
2. It can send Queries using C-FIND and also Retrieve using C-MOVE but only using the Study Root Model so I have to verify that my PACS supports this (it usually does). I can probably use it to search for and view studies stored in my PACS. 
3. It uses Modality Worklist and Modality Performed Procedure Step as SCU so it might be an Imaging Modality.

Reading through the overview text confirms that its an Imaging Modality Workstation.

The Data Flow Diagrams

After going through the overview, the data flow diagrams should repeat pretty much the same information. They usually look very similar because that's the way they should look and if they don't look like in the standard, that's a hazardous sign. so, when writing a DCS don't be creative with the data flow diagram please.

The data flow diagrams should describe the services from the overview in a graphical manner. The circles on the left describe the actions taken on the application side and the circles on the right, beyond the DICOM Standard Interface Boundary describe what is expected from the DICOM AE on the other side. The arrows crossing the DICOM Standard Interface are pointing from the Association initiator to the association responder.

DICOMIZER Data Flow Diagram

When you review the diagrams just make sure they make sense and that you can figure out what goes on. If it doesn't make sense, that's a problem.

At this point, I usually stop reading and start searching for specifics answers. What kind of answers? For example, what SOP Classes are supported. If we go back to the PDF example, you can tell from reading the DCS if a system can store a DICOM Encapsulated PDF. How you do this? Read on.

Supported SOP Classes

The  details of the DICOM Conformance Statement is inside the "Real World Activity" sections. The real world activity associated with DICOM PDF is the Storage (Unfortunately the standard don't have a clear specification to answer questions like "Can this application display PDF's, or only store them?"). Look for the storage activity and in it there's a table of supported presentation contexts and in it there's a list or a reference to a list with all SOP classes. In DICOMIZER's case DICOM Encapsulated PDF SOP Class is included in this list (table 3-6) and is supported as SCU, meaning the application sends DICOM PDF's, see section 3.2.1.3.6 Activity – Send Images) and as SCP (meaning the application can receive it, see section 3.2.1.4.1 Activity – Store Images). BTW, the network section of the DCS is divided into Association Initiation and Association Acceptance and inside each one are the relevant real world activities.

Query Attributes

Another interesting question is what tags are supported for query meaning what tags are used for searches. This is very important for the Query/Retrieve Service and for the Modality Worklist Service. Some modalities would not display any results for MWL Query unless all the tags they expect are included in the C-FIND response. By reviewing their DCS you should be able to determine the list of tags they expect and verify that your Worklist Manager supports them as well.

To answer a question like "What tags can I search on" you should locate the "Query" or "Search" activity and look into the SOP Specific Conformance section in it where there should be a table detailing the exact tags that are supported for matching. Look in section 3.2.1.3.2.3 in DICOMIZER's DCS for an example.

RZDCX DICOM Conformance

This post can easily grow to the magnitude of a DCS but it won't. From here, I advise you to grab couple of DCS documents and scan through them, look at the diagrams and try to answer questions. If you work in an organization that have a PACS and Imaging Modalities, you can take your PACS DCS and one of the Imaging Modalities DCS and work on both to find out how well can they work together. If you have an integration issue, try to figure out why from the documents.

As you probably know, DICOMIZER is using RZDCX DICOM Library for the DICOM implementation. Toolkits are not DICOM Application Entities and therefore are not required to have a DICOM Conformance Statement. Instead, RZDCX Documenation has a section that details the DICOM Conformance information for every API call. Check it in this link: RZDCX DICOM Conformance Statement. 

RZDCX Documentation is created using Doxygen.