Error reading DICOM SR produced by syngo.via

[afe]

Hi,

I have DCMTK version 3.6.1 compiled from source, and I am trying to read a DICOM SR produced using syngo.via.

When I am trying to read this file using dsrdump, I have this error:

W: GraphicData (0070,0022) VM != 2-2n in SCOORD content item
W: No GraphicData for SCOORD content item
W: Reading invalid/incomplete content item SCOORD "1.1.8.1.2.1"
E: Reading content item SCOORD "1.1.8.1.2.1" (Invalid Value)
E: Reading content item CODE "1.1.8.1.2" (Invalid Value)
E: Reading content item CONTAINER "1.1.8.1" (Invalid Value)
E: Reading content item CONTAINER "1.1.8" (Invalid Value)
E: Reading content item CONTAINER "1.1" (Invalid Value)
F: dsrdump: error (Invalid Value) parsing file: SR.dcm

When I look at this file with dcmdump, here's what I have for this tag:

(0070,0022) FL 31.709696\-164.21815\445.5 # 12, 3 GraphicData

The SR is available in my public Dropbox folder here: http://dl.dropbox.com/u/3770904/SR.dcm

Can someone explain what is happening?

[J. Riesmeier]

The first warning in your log contains the answer: The value multiplicity of the GraphicData element is wrong. This is what the DICOM standard specifies:

Code: Select all

An ordered set of (column,row) pairs that
denote positions in an image specified with
sub-pixel resolution such that the origin at the
TLHC of the TLHC pixel is 0.0\0.0, the BRHC
of the TLHC pixel is 1.0\1.0, and the BRHC of
the BRHC pixel is Columns\Rows.

So, the DICOM file violates the requirements of the DICOM standard. A value multiplicity of 3 is not allowed since you always need two numeric values for each coordinate (x and y).
If Siemens wanted to specify a POINT in 3D space, they should use the "new" value type SCOORD3D! Maybe, you should contact Siemens regarding this issue.

[afe]

For some reason, it never occurred to me that Siemens DICOM-compliant product can have a bug!

Thank you for your reply. I will email Siemens. I wonder what is their turnaround time!

[J. Riesmeier]

Then you are a lucky man I've collected many SR documents from many different vendors over the last 12 years or so and most of them contained one or more bugs. Of course this is not a representative figure since we usually get SR documents when something went wrong, but it's really amazing to see what can be done in a wrong way and how these bugs get into product releases.

Btw, in order to parse such incorrectly encoded SR documents you could try one or more of the "error handling" options of dsrdump:

Code: Select all

  error handling:
    -Er  --unknown-relationship  accept unknown/missing relationship type
    -Ev  --invalid-item-value    accept invalid content item value
                                 (e.g. violation of VR or VM definition)
    -Ec  --ignore-constraints    ignore relationship content constraints
    -Ee  --ignore-item-errors    do not abort on content item errors, just warn
                                 (e.g. missing value type specific attributes)
    -Ei  --skip-invalid-items    skip invalid content items (incl. sub-tree)

[afe]

Thanks for the suggestion, I will give it a try. Meanwhile, I emailed our Siemens contacts, we'll see what happens and when ...

On a related note, can you suggest *any* publicly available DICOM SR viewer?

I have learned about DICOM SR relatively recently. From reading the papers, the idea sounds really good, but I have doubts about its practicality and availability of robust implementations. If someone would like to implement support of DICOM SR in a tool, it is not clear how to go about verifying that the implementation is correct, without reference tools/implementations (so far, DCMTK seems to be the best bet in this regard).

[J. Riesmeier]

On a related note, can you suggest *any* publicly available DICOM SR viewer?

Unfortunately, I can't. Of course, there are a couple of general purpose DICOM SR viewers like the one that is part of DICOMscope, which is basically using the HTML output of dsr2html. However, the output might not be appropriate for many less text-based reports.

Btw, I wrote my doctoral thesis on the visualization of structured medical reports (using the example of DICOM SR), but this is in German language ...

I have learned about DICOM SR relatively recently. From reading the papers, the idea sounds really good, but I have doubts about its practicality and availability of robust implementations.

A good starting point for DICOM SR is of course the book from David Clunie. It is already more than 10 years old but still quite interesting to read.

As far as I can say, DICOM SR is currently mainly used for the exchange of structured data between machines, i.e. not so much for human readable reports. Of course, its practical usage depends on the clinical environment.

If someone would like to implement support of DICOM SR in a tool, it is not clear how to go about verifying that the implementation is correct, without reference tools/implementations (so far, DCMTK seems to be the best bet in this regard).

There are no reference implementations, that's right. But this is true for all DICOM services and objects. Even though we sometimes claim that the DCMTK started as one of the first two reference implementations of the standard back in 1993, the term "officially supported/commissioned prototype implementation" is probably more appropriate.

Nevertheless, DCMTK is used by many companies and organizations all over the world either for testing or product development. This is also true for the SR part of DCMTK. In fact, many software prototypes that are shown at IHE connectathons are based on it. This is evident when it comes to visualization because the HTML rendering of our toolkit is easy to recognize

And, when we started back in the year 2000 with the implementation of the SR module for DCMTK there were only one or two sample documents from David Clunie. As I wrote in my last posting, I collected a large number of DICOM SR documents over the years and adapted our imlementation to cover all bugs that I'm aware of. Also the various error handling options are a result of this experience.

The bottom line is: I guess it wouldn't be the worst idea to use the SR implementation from DCMTK either for testing or for development. If you use it for software development, it might make sense to use a different implementation for testing, e.g. a validation tool like DVT or Clunie's dciodvfy / Pixelmed tools. Also dcm4che has some SR implementation as far as I know ...