search

rbeckman-nextgen / test-mc

test-migration
1 stars 0 forks source link

DICOM message state shows SENT even when the message fails in PACS #3897

Open rbeckman-nextgen opened 4 years ago

rbeckman-nextgen commented 4 years ago

When sending messages through to PACS, Mirth Connect reports a sent state in the message viewer even though the server log displays that the message errors when being received by the PACS application. Using the Request Storage Commitment option in the DICOM sender is not supported by PACS. Can an alternative can be made so that the Message Viewer will update the status of the messages based on the NACK that it receives from the destination application? Some error messages below:

ERROR Server: ERROR: Received RSP with Status A700H for /data/mirth/appdata/temp/temp3644737513451594016tmp, cuid=1.2.840.10008.5.1.4.1.1.3.1, tsuid=1.2.840.10008.1.2.4.50 ERROR Server: (0000,0002) UI #28 [1.2.840.10008.5.1.4.1.1.3.1] Affected SOP Class UID ERROR Server: (0000,0100) US #2 [32769] Command Field ERROR Server: (0000,0120) US #2 [1] Message ID Being Responded To ERROR Server: (0000,0800) US #2 [257] Command Data Set Type ERROR Server: (0000,0900) US #2 [42752] Status ERROR Server: (0000,0902) LO #38 [w_store failed, exit code -2147467259] Error Comment ERROR Server: (0000,1000) UI #54 [1.2.276.0.26.1.1.1.2.2016.194.55048.6561709.180224000] Affected SOP Instance UID

Further from Sectra, Mirth is possibly corrupting the images:

"Sectra PACS supports many transfer syntaxes (including Lossy JPEG) as per the 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)."

Imported Issue. Original Details: Reporter: jeffreyw Created: 2016-06-08T10:11:29.000-0700

rbeckman-nextgen commented 4 years ago

This is of some concern to us as we are currently unable to easily identify those images that fail to store correctly in the PACS system. I have noted that all of these messages have multiple DICOM attachments, and that the viewer in Mirth does not appear to be able to open the images. Sectra (whose PACS system we are sending to) say that there is nothing wrong with the information being sent in the PACS header, but that there is something wrong with the image data itself. I am wondering if Mirth could be incorrectly pushing the attachments back into the message and corrupting the image.

Here is the error I get in the administrator if I attempt to open the images:

java.lang.NullPointerException at com.mirth.connect.plugins.dicomviewer.DICOMViewer.viewAttachments(DICOMViewer.java:45) at com.mirth.connect.client.ui.browsers.message.MessageBrowser$19.doInBackground(MessageBrowser.java:1614) at com.mirth.connect.client.ui.browsers.message.MessageBrowser$19.doInBackground(MessageBrowser.java:1611) at javax.swing.SwingWorker$1.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at javax.swing.SwingWorker.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)

Imported Comment. Original Details: Author: seaston Created: 2016-06-08T10:20:11.000-0700