MC possibly corrupting DICOM message

[rbeckman-nextgen]

I believe I can show evidence of Mirth corrupting the DICOM files.

I downloaded a file from this website:

http://barre.nom.fr/medical/samples/

I attach my test channel (which reads the file and spits it out to the same directory). This has no transformer step, simple reads the file and deposits it.

I also attach two files.

One is the source file US-PAL-8-10x-echo.dcm Destination file: US-PAL-8-10x-echo.dcm.sent

You can see from the directory listing that the file sizes differ after passing through Mirth:

Image 1

I can open the original file:

Image 2

But cannot open it after passing through Mirth connect:

Image 3

Please can you investigate as a matter of urgency?

Imported Issue. Original Details: Jira Issue Key: MIRTH-3986 Reporter: jeffreyw Created: 2016-06-10T16:03:51.000-0700

[rbeckman-nextgen]

Test Channel for 3.4.1 used to test DICOM sender

Imported Comment. Original Details: Author: jeffreyw Created: 2016-06-10T16:05:58.000-0700

[rbeckman-nextgen]

From initial testing, it is certainly true that some modification is being done. When the DICOM message flows through the channel, the image tags are being extracted, and then later on re-attached to the header data.

While ideally no modification should be done if you're not actually transforming the message at all, it doesn't seem yet to me like this is "corruption" per se. For example, I used an open source DICOM viewer ([http://bettar.no-ip.org/lxiv/dmg.html]) to open the file after it has passed through the MC channel. It is able to open it and view the images just fine:

!screenshot-1.png!

Imported Comment. Original Details: Author: narupley Created: 2016-06-10T16:17:51.000-0700

[rbeckman-nextgen]

The DICOM viewer I was using was 'MicroDicom' which appears to be able to open the file before pushing through Mirth Connect, but not afterwards, so something has changed.

When I asked Sectra to investigate the problem with one of the production images they commented:

Hi Simon.

No, to clarify, Sectra PACS supports many transfer syntaxes (including Lossy JPEG) as per the attached DICOM conformance statement (section 3.2). The issue arises from a combination of Lossy JPEG and the pixel data in this particular image (no Basic Offset Table and Number of Frames discrepancy).

I am puzzled as to what is going on here and wonder if this helps you at all?

Imported Comment. Original Details: Author: seaston Created: 2016-06-10T16:30:22.000-0700

[rbeckman-nextgen]

This may be something dcm4che is doing... as I said, it certainly is true that the file is being modified to some degree. But the fact still remains that this well-known, widely used, open source project was able to open and view the output file just fine. I would suggest forwarding that info to your vendor to see why this product can view the file but their product cannot.

Additional research will be done on this side as well to see whether this is just a limitation / side effect of using dcm4che, or whether there are any changes we can make to ensure that when no transformation is done, the input/output files remain completely identical.

Imported Comment. Original Details: Author: narupley Created: 2016-06-10T17:19:36.000-0700

[rbeckman-nextgen]

Thanks for looking at this. In the production channel, there are transformations being done on the DICOM header, (only for patient ID / Accession numbers) which is the reason that we are putting the messages through Mirth Connect. Jeffrey has a copy of this channel attached to the heldesk log. Are you able to tell from the test channel if the changes are being made to the image data or the header? Sectra PACS says that there was nothing wrong with the header information, just the image. I'll try with the DICOM viewer you used (and any others you can suggest) and try and get hold of some of the production images next week that are going to Sectra via Mirth before and after, so that I can take my findings back to you / Sectra.

Imported Comment. Original Details: Author: seaston Created: 2016-06-10T23:10:38.000-0700

[rbeckman-nextgen]

It looks like there are a couple of issues. First, dcm4che definitely is causing some sort of modification. Even with an isolated test case using DicomInputStream and DicomOutputStream to read and immediately write out a file, the same modification happens.

The other problem is on the MC side, which we actually already have an issue for: MIRTH-3938. When a DICOM file has a pixel data element with multiple items, each of those items are extracted as its own attachment. However when those are reattached, the order isn't preserved. The end result is that the image parts are shuffled, and most importantly the initial 40 byte item (apparently containing table data for the rest) is no longer the first item.

The query to get attachments already happens to sort by the attachment ID, which is just a GUID. However if those attachment IDs were lined up correctly (perhaps by prepending "01", "02", etc.), then it should work. A custom attachment handler would do the trick until MIRTH-3938 is fixed.

Imported Comment. Original Details: Author: narupley Created: 2016-06-13T13:10:11.000-0700

[rbeckman-nextgen]

Attaching modified example channel.

Imported Comment. Original Details: Author: narupley Created: 2016-06-13T13:38:09.000-0700

[rbeckman-nextgen]

MIRTH-3938 will be concerned with making attachments reattach in the correct order. This issue will be concerned with the dcm4che issue where a simple input/output stream workflow doesn't result in identical files.

Imported Comment. Original Details: Author: narupley Created: 2016-06-13T13:39:56.000-0700

[rbeckman-nextgen]

Note that this does not seem to affect most DICOM files that have multiple images. Other DICOM files that have multiple slices in one pixel data item work just fine. It's only an issue when there are multiple pixel data items.

Imported Comment. Original Details: Author: narupley Created: 2016-06-13T13:43:22.000-0700

[rbeckman-nextgen]

Your findings seem to bear out what Sectra is telling is re. pixel data. Please note that related to this is issue: http://www.mirthcorp.com/community/issues/browse/MIRTH-3980 because at the moment we know that some messages are failing to be processed by the destination (Sectra PACS) but all the messages display as SENT in Mirth Connect. There does not appear to be any way to trap and process the response at the moment in a response transformer. It is not at all easy for us to identify which messages / images are failing.

Imported Comment. Original Details: Author: seaston Created: 2016-06-13T15:52:11.000-0700