support for "Enhanced Dicom Standard"

[dmd]

We are working with Chris Rorden @neurolabusc and Siemens to figure out some issues with transmission of XA30 diffusion images now that mosaicing is deprecated.

Siemens asked us: "Does your dicom router accept the Enhanced Dicom Standard"?

Do you know the answer to this? The issue we're having is XA30 is sending tens of thousands of images instead of a single mosaiced one, and Siemens thinks maybe the router is having an issue accepting the new format.

[neurolabusc]

@dmd your Siemens scanner is a SCU (user = client) that will send data to a SCP (provider = server).

I think that mercure uses orthanc that uses dcm4che.

If I were you, I would try to remove all of these from the equation, to see if any of them are the bottleneck. To do this, I would install dcmtk, shut down mercure, and launch the dcmtk SCP. Assuming you are using the default DicomPort (4242) and Application Entity Title (ORTHANC) and that you have write permission to a folder named ~/neuro you would launch your dcmtk with this command.

storescp -od ~/neuro -aet ORTHANC 4242

You can then test the transfer speed of data from your scanner. If the transfer speed is vastly improved, the issue is with mercure, otherwise it is with your Siemens XA30 upgrade (I assume the nextwork, SCP hardware, etc. have not changed since VE11C).

You can also remove the Scanner from the equation, by using the dcmtk storescu to send a dataset. You can do this locally from the computer running storescp/mercure with:

storescu 127.0.0.1 4242 *.dcm

Or just set the IP address if you are sending the data from a different computer location within your firewall (to see the impact of your network).

While I can not vouch for the speed, nor have I tested Mercure, Orthanc 1.12.0 does accept enhanced DICOMs. I do note that dcm4che can exhibit strange behavior, but perhaps this has been fixed or avoided. I have been hugely impressed by the reliability, evolution, license and performance of dcmtk. It is lean, low level code that simply downloads the files. When I tried Orthanc, transfers created a lot of folders as well as a SQL database. I do wonder if some of these extra features could be impacting your performance.

[tblock79]

No, this is not quite correct. mercure does not use Orthanc. Orthanc can be installed together with mercure to have a "playground PACS" for testing things (i.e., to have a development environment when developing own modules), but mercure itself does not depend on Orthanc. mercure internally uses dcmtk for the DICOM communication.

Not sure what "Enhanced DICOM Standard" exactly means. Can they provide more information on that? My understanding is that DCMTK supports pretty much all DICOM standards.

[neurolabusc]

@tblock79 thanks for your quick response.

Siemens MR scanners running V* software (VA..VE) have produced classic DICOMs where a separate file is created for each 2D slice of an image (or for EPI scans, Siemens created a mosaic format where all slices from a 3D volume were stored as a single slice). Siemens is now upgrading users to XA software, which saves data as enhanced multi-frame DICOM, where an entire 3D volume (Siemens) or 4D series (Canon, Philips) are saved as a single file.

Here is an example of enhanced XA30 images and the XA30 images saved in classic interoperability mode. In contrast, here are VE11 mosaics. Finally, here are enhanced datasets from other manufacturers.

The issue that @dmd is facing is that his scanner got upgraded from VE11 to XA30, and now experiences data transfers that are orders of magnitude slower. In theory, VE11 classic mosaics and XA30 enhanced images should have similar file size (since both store an entire 3D volume in a single file).

This issue is a serious one for the rest of the community who is deferring XA30 upgrades: we do not see the software benefits and VE11 is based on Windows 10 which is EOL which is a security risk for clinical centers like mine.

@dmd If mercure supports dcmtk by default, I would set up an orthanc SCP to see if that is the bottleneck. Likewise, run the dcmtk stropescp in isolation from mercure.

[guruevi]

Here is the standard for multi-frame DICOM: https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.16.html

Mercure uses DCMTK to receive and then merely moves the files around after extracting the DICOM tags, if anything, multi frame DICOM should speed up processing as there are less loops and IO to do, although if you’re strained on memory resources (say you have it running in a 512MB container), opening up large DICOM files can cause issues.

I would indeed isolate the problem, check from a different server with sufficient resources, not sure what your setup is like, but it could be a networking issue, if you still have an old Siemens provided Cisco firewall/VPN router in front of your scanner or anything else that may not be able to handle TCP delayed ACK, we’ve had issues with that in the past for large data transfers which you wouldn’t have noticed with smaller packets. You’re going from a dressed down Windows XP or 7-like (it’s really a modified Server 2013/2016) platform in the V-series to a modern Windows 10 in the XA.

[dmd]

So the issue isn't "slowness" per se - it's that for some reason multiframe isn't working at all, and instead for these diffusion images we are seeing tens of thousands of individual dicom files arriving at our final destinations (Orthanc and XNAT servers).

The Siemens person, if I understand their email to us correctly, seems to think this is because the router is refusing to receive multiframe, and so the scanner is sending it without that functionality:

I see that micdicomrouter configuration is set to interoperability mode now. Can it accept the Enhanced Dicom Standard?

[guruevi]

Different problem then, you're asking about the DICOM conformance of storescp.

And according to the DCMTK documentation, the current version accepts EnhancedMRImageStorage 1.2.840.10008.5.1.4.1.1.4.1 by default. The question is thus whether Siemens conforms to the DICOM standard or if what they call "Enhanced" is really "Proprietary", so what does Siemens mean when they say "Enhanced", does DCMTK has to "accept" something specific and you have to program/add/modify the syntax or syntax order (see here: https://github.com/dcmtk/DCMTK/blob/master/dcmnet/etc/storescp.cfg)

Also find this note: Please note that the order of transfer syntaxes within a section might be significant. For example, an implementation of a DICOM Storage SCP, such as storescp or dcmrecv, will use this order to determine which transfer syntax to prefer when multiple transfer syntaxes are offered by the SCU and are acceptable for the SCP. The transfer syntax selection policy is to prefer the first transfer syntax that is acceptable, i.e. the one with the lowest number.

Regardless, Mercure runs storescp like this: storescp --fork --promiscuous $transfer_syntax_option -od "$incoming" +uf -xcr "$binary $incoming/#f #a #c$bookkeeper$bookkeeper_api_key" $port

Can you force Siemens' software to only accept a specific way to send instead for your DICOM AE (it should be possible) and then it will either error out or agree to use the correct syntax.

If you need to modify the storescp command to accept Siemens' stuff, please share, we're looking to migrate to XA soon.

[tblock79]

Also, try what happens if you set the following value in the mercure configuration (e.g., via the web UI): "accept_compressed_images": true,

It could be that Siemens uses a proprietary multiframe implementation for EPI images that is handled as separate Transfer Syntax. By default, mercure asks senders to transfer images in uncompressed format and, assuming that multiframe is indeed handled as different Transfer Syntax, the Siemens software would therefore divide images into separate files prior to the transfer. If you set above value in the configuration file, mercure will accept any format. This, however, requires that all of your mercure processing modules (if you use any modules at all) can handle the multiframe format, and it requires that your final DICOM receiver node (e.g. your PACS) can also accept those images (because mercure would not know how to separate the multiframe images into separate files -- if demanded by PACS).

[dmd]

I tried setting "accept_compressed_images": true but it had no effect.

Here is the series in question: https://www.dropbox.com/s/sl2dg5bjys7ycdy/3ef7b1dd-10736f86-cd400782-f0b65f6f-1fdad655.zip?dl=0

(No PHI - it's a phantom)

If I send directly to our Orthanc instance, it arrives as 100 instances. If I send it through the router, it arrives as 9200 instances.

FYI I am not using any modules.

[bbfrederick]

@neurolabusc - it's even worse than you said! XA30 is an upgrade to Windows 10. VE11 is Windows 7.

[bbfrederick]

So we did the side by side comparison tonight (the source of the data @dmd posted). The difference in speed is pretty dramatic. Sending to the Orthanc receiver took under a minute and transferred 528 total instances. Sending to the router transferred over 10000 instances and took more than 20 minutes.

[dmd]

(That's 528 including all the other series - the above zip file is only the biggest example series.)

[tblock79]

Thanks for providing those images!

Unfortunately, I cannot reproduce this effect here -- if I send those images from the command-line to mercure, the number of images doesn't change. Thus, it probably would be necessary to test this by directly sending the DICOMs from the Siemens workstation/scanner (because the workstation is doing the separation into different files), which I can't easily test here.

As mentioned, mercure is just building on top of the DCMTK package for all DICOM communication (it just uses the "storescp" tool for receiving DICOMs). If you install mercure on Ubuntu 20.04, the DCMTK version is 3.6.4, which is relatively old (from 2018). Various extensions to the DICOM standard have been added to newer DCMTK versions (3.6.6 or 3.6.7). Hence, it might be worth trying to upgrade the DCMTK version on your server to a recent version.

I am not aware that newer prebuilt packages are available for Ubuntu 20.04. You could either upgrade to Ubuntu 22.04 (which is now supported by mercure), or you could build the DCMTK package from source code (as described here: https://github.com/DCMTK/dcmtk/blob/master/INSTALL).

Note that the Docker-based installation still uses Ubuntu 20.04 for the service containers. Thus, even if upgrading the host OS to 22.04, you would still get the old DCMTK 3.6.4 inside the Docker containers. Therefore, I would try this with a systemd-type installation.

[dmd]

Possibly what I did here was insufficient in some way, but as far as I can tell, switching to 3.6.7 did not help.

What I did:

• downloaded dcmtk 3.6.7 static binaries
• copied storescp, storescp.cfg, and dicom.dic out of that tarfile
• did a bind mount of those into /usr/bin/storescp, /etc/dcmtk/storescp.cfg, and /etc/dcmtk/dicom.dic respectively from the docker-compose.yml
• added DCMDICTPATH: /etc/dcmtk/dicom.dic to the x-env: &env environment stanza

We then tried sending our test data again. In the logs, I start seeing:

bookkeeper_1  | 2023-04-20T14:32:41.377676980Z INFO:     172.23.0.6:34906 - "POST /register-dicom HTTP/1.1" 200 OK
receiver_1    | 2023-04-20T14:32:41.422547056Z E: DcmDataDictionary: /etc/dcmtk/dicom.dic: bad VR field (line 3109): OV
receiver_1    | 2023-04-20T14:32:41.422563234Z E: DcmDataDictionary: /etc/dcmtk/dicom.dic: bad VR field (line 3110): SV
receiver_1    | 2023-04-20T14:32:41.422568967Z E: DcmDataDictionary: /etc/dcmtk/dicom.dic: bad VR field (line 3111): UV
receiver_1    | 2023-04-20T14:32:41.425607231Z E: DcmDataDictionary: /etc/dcmtk/dicom.dic: bad VR field (line 4549): OV
receiver_1    | 2023-04-20T14:32:41.425652211Z E: DcmDataDictionary: /etc/dcmtk/dicom.dic: bad VR field (line 4550): OV

but more to the point, it's still sending the images broken up into separate files, not as multiframe.

[dmd]

I just verified that if we send to Orthanc or to XNAT directly, the multiframe send succeeds. So it's only storescp having the problem.

[neurolabusc]

@dmd I also can not replicate your beahvior. Can you share your storescp.cfg and make sure you allow EnhancedMRImageStorage?

[dmd]

Before making any changes, it's just the one that is there by default in mercure's docker setup. Afterwards it's the one shipped with dcmtk.

In both cases, I see:

PresentationContext14  = EnhancedMRImageStorage\AnyTransferSyntax

[guruevi]

Run storescp in debug mode (-d info or -d debug) and see what it yields during the negotiation phase, this is likely a definitional issue with Siemens suggesting a Presentation Context that is higher up the priority list for storescp or Siemens suggesting a Presentation Context with an invalid (proprietary) SOP.

Alternatively, force it by only accepting the EnhancedMRImageStorage context (comment out everything else in storescp.cfg)

[neurolabusc]

@guruevi is this the line where mercure launches storescp? If so, I do not think mercure uses the storescp.cfg. I think to use the configuration file you need to explicitly invoke both the file (e.g. storescp.cfg) and the profile (e.g. default).

storescp -od ~/neuro/enh --config-file ~/src/dcmtk/etc/dcmtk/storescp.cfg default 4242

But your suggestion of forcing this might be a fix. I think you would need to both edit the file and make sure it is invoked.

[dmd]

Here are logs from when I enabled debug and sent it.

(There's one irrelevant dicom association in there, from 'weathertop', just an echo, but everything else in there is the test data in question.)

assoc.txt

I'm concerned that commenting out everything but EnhancedMRImageStorage might affect receiving data from our other scanner, which is still on VE11C?

[guruevi]

So reading over the logs, there is nothing there that I can think of that would affect it, basically, DCMTK just sends back everything the scanner has said it will send, the scanner then selects the "wrong" TransferSyntax. I think the fact the scanner has it in Enhanced MR format is a red herring. From the VE11C, Siemens sends MRImageStorage with a higher priority, but it has EnhancedMR as well further down, storescp just parrots it back at the sender in the same order.

It would be interesting to see how/what XNAT/OrthanC negotiates.

Here is the Siemens DICOM conformance statement: https://cdn0.scrvt.com/39b415fb07de4d9656c7b516d8e2d907/9a7005df382f8fd9/e44161b95b3d/Conformance_DC_VA30A.pdf - Which states you can configure on a per-node basis which transfer syntaxes to use and in which preference order. Can you go in the scanner console and verify that this DICOM node has the correct syntax preference order (perhaps inherited from a previous Siemens version configuration).

[tblock79]

Yes, wondering the same, whether this might be just a setting that can be configured in the Siemens XA30 software (i.e., if it should keep the files in multi-frame format or if it should divide into individual files). Would be great if you could check that with your Siemens onsite engineer. Will try to find some information on it too.

[dmd]

Yep, we just found it a few minutes ago!

The DICOM node was indeed configured incorrectly. The problem was it took several hours to find the configuration, because it is very carefully hidden. Go to the gear menu, open the Administration portal. From there, select Remote DICOM nodes, then select the node you want to edit. On the right, select the blobby pencil that means edit the node. Then when the node is open, if you look at the blue bidirectional arrow between the scanner and the destination node labelled Storage, you will notice (on the 700th time you go to that page) a nearly invisible blue screwdriver or eyedropper or something at the end of the line. Click THAT, and you get to the transfer configuration page.

From there it’s a simple matter to scroll down to the bottom to the “Multiframe Conversion” section, and uncheck every box. You may also want to uncheck “Convert GSPS for MR Images” in the section above (don’t know what that means) and “Encapsulate Non-Supported Objects” in the section above that.

I don’t know what those options do, but they were checked in the node that wasn’t working, and weren’t checked in the one that was, so I turned them off too.

Daniel / Blaise

“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”

[neurolabusc]

@dmd nice to hear you solved this. I suggest you post this on snug-discuss (perhaps with a screenshot).

[dmd]

So in very short conclusion - there was no issue with mercure or dcmtk; they were doing exactly what they were supposed to. The issue was that the console's configuration for sending to the destinations that succeeded was different than its configuration for sending to mercure.

[bbfrederick]

@neurolabusc - already done, although I will probably put in a more extensive one with pictures.

[bbfrederick]

So, pictures to get you to that screen:

To edit the node, in the Administration portal:

This is the tricky one - the little icon to get you to the DICOM configuration screen:

Then once you're there, here's what you can adjust:

[tblock79]

Glad to hear that it's working now, and thanks for posting those screenshots.