dsr2html not showing some information

[anibal]

Hi,

I talked to Marco about this while we were at the IHE Connectathon in Chicago earlier this month.

We noticed that dsr2html is not showing some data that's contained in the SR object (and that dsrdump shows) even though we use all the pertinent switches (like +C).

This is from my own bugzilla (BZ19733):

Code: Select all

What happened instead?    : The following descriptions/titles are missing... we
actually display only the numbers, but not there "title".

Example:
Cumulative Exposure Time                10.0 s
Scanning Length                         5.0 mm
Nominal Single Collimation Width        0.1 mm
Nominal Total Collimation Width         0.1 mm
Pitch Factor                            0.5 num
Number of X-Ray Sources                 1.0 num
CT X-Ray Source Parameters
Identification Number of the
X-ray Source
                                        1.0 num
KVP                                     120.0 kV
Maximum X-ray Tube Current              40.0 mA
Mean X-ray Tube Current                 20.0 mA

I do have access to the original SR file as well as a PDF document created by GE (the creator of the SR) showing how they display the SR.

I understand that GE can do a better job at displaying it since they're not a general SR display but I'm still concerned that some values found in the SR object are not displayed with dsr2html.

If you get back to me via email I can send you as attachment the files that I have available.

[anibal]

I just realized we had more information:

Code: Select all

Here is the output from dsr2html for the same fragment as above:

<u>10.0 s</u>
<u>5.0 mm</u>
<u>0.1 mm</u>
<u>0.1 mm</u>
<u>0.5 num</u>
<u>1.0 num</u>
<h4>CT X-Ray Source Parameters</h4>
<u>1.0 num</u>
<u>120.0 kV</u>
<u>40.0 mA</u>
<u>20.0 mA</u>
<u>0.3 s</u>
<h3>CT Dose</h3>
<u>1.71 mGy</u>
<u>1.0 mGy/mAs</u>
<u>1.0 mGy</u>
<u>0.86 mGycm</u>
</p>

And:

Code: Select all

Here is the snippet of dsrdump for the same data as above:

    <contains CONTAINER:(,,"CT Acquisition Parameter")=CONTINUOUS>
      <contains NUM:(,,"Cumulative Exposure Time")="10.0" (s,UCUM,"s")>
      <contains NUM:(,,"Scanning Length")="5.0" (mm,UCUM,"mm")>
      <contains NUM:(,,"Nominal Single Collimation Width")="0.1"
(mm,UCUM,"mm")>
      <contains NUM:(,,"Nominal Total Collimation Width")="0.1" (mm,UCUM,"mm")>
      <contains NUM:(,,"Pitch Factor")="0.5" (num,UCUM,"no units")>
      <contains NUM:(,,"Number of X-Ray Sources")="1.0" (num,UCUM,"no units")>
      <contains CONTAINER:(,,"CT X-Ray Source Parameters")=CONTINUOUS>
        <contains NUM:(,,"Identification Number of the X-ray Source")="1.0"
(num,UCUM,"no Units")>
        <contains NUM:(,,"KVP")="120.0" (kV,UCUM,"kV")>
        <contains NUM:(,,"Maximum X-ray Tube Current")="40.0" (mA,UCUM,"mA")>
        <contains NUM:(,,"Mean X-ray Tube Current")="20.0" (mA,UCUM,"mA")>
        <contains NUM:(,,"Exposure Time Per Rotation")="0.3" (s,UCUM,"s")>


The problem is that dsr2html does not includes the value of the "CodeMeaning"
tag for "ConceptCodeSequence".  None of the +C options to dsr2html seem to
enable the inclusion of these values.

[Jörg Riesmeier]

My first guess (without looking into the source code) would be that the enclosing Container has a value of "CONTINUOUS" for the Continuity of Content flag. So, dsr2html tries to render all child nodes as a continuous text and, therefore, omits the concept names.

In my opinion, dsr2xml with an appropriate stylesheet would be more appropriate for SR document rendering. The HTML output of dsr2html was mainly meant as a general purpose approach for the DICOMscope reference implementation (which started back in 2000).

Btw, I already updated the output of dsr2html for the next release, e.g. by supporting HTML 4.01 and XHTML 1.1 compliant output format.

[anibal]

We looked at dsr2xml, but the problem is that it is lacking the error handling
options that dsr2html has. With dsr2html, we use --ignore-constraints,
--ignore-item-errors and --skip-invalid-items.

I think we do have to support "broken" SR documents. For example, the sample SR that we have that dsr2html is missing those nodes cannot be processed with dsr2xml.

[Jörg Riesmeier]

We looked at dsr2xml, but the problem is that it is lacking the error handling options that dsr2html has.

This is on purpose since dsr2xml is intended for the conversion of SR documents into another format (XML) and not for rendering them - so basically, this process should be "lossless".

With dsr2html, we use --ignore-constraints, --ignore-item-errors and --skip-invalid-items.

I'm not sure whether this is a good idea. Originally, these options were introduced to process incorrectly encoded SR document - at the time when this implementation started, most sample documents were erroneous. Please bare in mind that the DICOM standard requires that "An SCP intending to display or otherwise render a Structured Report shall convey its full meaning in an unambiguous manner."

So these options are mainly useful for debugging purposes and not for a medical product. In my opinion you should at least display a warning to the user when rendering "broken documents".

[anibal]

With dsr2html, we use --ignore-constraints, --ignore-item-errors and --skip-invalid-items.

I'm not sure whether this is a good idea. Originally, these options were introduced to process incorrectly encoded SR document - at the time when this implementation started, most sample documents were erroneous. Please bare in mind that the DICOM standard requires that "An SCP intending to display or otherwise render a Structured Report shall convey its full meaning in an unambiguous manner."

So these options are mainly useful for debugging purposes and not for a medical product. In my opinion you should at least display a warning to the user when rendering "broken documents".

Jorg, remember that out there in the real world things are not so smooth. And I understand that you want to be compliant but if you also want to be useful then we have to give in in certain cases.

An alternative would be to be able to ignore errors in dsr2xml, and when using that option, exit with another error code if there was indeed a problem with the input object. If that's the case, it's up to the renderer (as you say) to display a warning to the effect that the original SR document was broken.

I'd rather have that than showing just one line to the user "Error rendering SR document.". What's the user supposed to do in this case? I think this is more serious than showing part of the document provided you also show a warning of some sort.

Just a quick note that we were forced to use the --ignore-constraints and --ignore-item-errors and --skip-invalid-items at the IHE Connectathon in Berlin last year since there were some SR documents that would not convert in dsr2html.

[Jörg Riesmeier]

... since there were some SR documents that would not convert in dsr2html.

I guess that these documents were also not standard compliant -- I know that from my own experiences during the last 8 year or so with DICOM SR

Anyway, I'll add a note to our to-do-list and think about it when time permits ...