Well it sure isn't!
If that Presentation context isn't in my dgatesop.lst, is it a simple matter of adding a new line? I see the other items in this file have what look like a name, an ID value, and then an sop?
I just tried Googling that presentation context and found a big ole whopping ZERO results...
I can't seem to find a listing of SOP's or Presentation Contexts for specific C-Arm Models so I don't have a reference for what I should be adding to this list, if its even that simple.
Unfortunately our GE 9800 ESP's have stopped sending Images again.
These C-Arm workstations can query worklists from our server and can verify the DICOM store properly; however, when we try to send an image to the DICOM Store, the send process will fail after about 2-3 minutes of attempting to send, with a very non descript error.
Example of successful Worklist query:
2/9/2017 6:37:16 AM [QUIMBY] Calling Application Title : "9800ESP "
2/9/2017 6:37:16 AM [QUIMBY] Called Application Title : "DICOMSTORE "
2/9/2017 6:37:16 AM [QUIMBY] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 32000
2/9/2017 6:37:16 AM [QUIMBY] Presentation Context 0 "1.2.840.10008.5.1.4.31" 1
2/9/2017 6:37:16 AM [QUIMBY] (ModalityWorkListQuery) search level:
2/9/2017 6:37:16 AM [QUIMBY] C-Find (Modality Work List) located 23 records
2/9/2017 6:37:16 AM [QUIMBY] UPACS THREAD 897: ENDED AT: Thu Feb 09 06:37:16 2017
2/9/2017 6:37:16 AM [QUIMBY] UPACS THREAD 897: TOTAL RUNNING TIME: 1 SECONDS
Example of DICOM Store query:
2/9/2017 1:47:45 PM [QUIMBY] UPACS THREAD 50: STARTED AT: Thu Feb 09 13:47:45 2017
2/9/2017 1:47:45 PM [QUIMBY] A-ASSOCIATE-RQ Packet Dump
2/9/2017 1:47:45 PM [QUIMBY] Calling Application Title : "9800ESP "
2/9/2017 1:47:45 PM [QUIMBY] Called Application Title : "DICOMSTORE "
2/9/2017 1:47:45 PM [QUIMBY] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 32000
2/9/2017 1:47:45 PM [QUIMBY] Number of Proposed Presentation Contexts: 1
2/9/2017 1:47:45 PM [QUIMBY] Presentation Context 0 "1.2.840.10008.1.1" 1
2/9/2017 1:47:45 PM [QUIMBY] Server Command := 0030
2/9/2017 1:47:45 PM [QUIMBY] Message ID := 0002
2/9/2017 1:47:45 PM [QUIMBY] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"
2/9/2017 1:47:45 PM [QUIMBY] 0000,0100 2 US CommandField 48
2/9/2017 1:47:45 PM [QUIMBY] 0000,0110 2 US MessageID 2
2/9/2017 1:47:45 PM [QUIMBY] 0000,0800 2 US DataSetType 257
2/9/2017 1:47:45 PM [QUIMBY] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2"
2/9/2017 1:47:45 PM [QUIMBY] C-Echo
2/9/2017 1:47:45 PM [QUIMBY] UPACS THREAD 50: ENDED AT: Thu Feb 09 13:47:45 2017
2/9/2017 1:47:45 PM [QUIMBY] UPACS THREAD 50: TOTAL RUNNING TIME: 0 SECONDS
2/9/2017 1:47:59 PM [QUIMBY] Connected by address: 0100007f
2/9/2017 1:47:59 PM [QUIMBY] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'
2/9/2017 1:47:59 PM [QUIMBY] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"
2/9/2017 1:47:59 PM [QUIMBY] 0000,0100 2 US CommandField 48
2/9/2017 1:47:59 PM [QUIMBY] 0000,0110 2 US MessageID 7
2/9/2017 1:47:59 PM [QUIMBY] 0000,0800 2 US DataSetType 257
2/9/2017 1:47:59 PM [QUIMBY] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2"
2/9/2017 1:47:59 PM [QUIMBY] 9999,0400 6 LO ConquestConsoleComma "silent"
2/9/2017 1:48:00 PM [QUIMBY] ***No valid presentation contexts/transfer syntax found in 0 candidates
2/9/2017 1:48:00 PM [QUIMBY] ***In 0 presentation contexts
2/9/2017 1:48:00 PM [QUIMBY] ***#Possible transfer syntaxes: 10
2/9/2017 1:48:00 PM [QUIMBY] InterogateAAssociateRQ failed
2/9/2017 1:48:00 PM [QUIMBY] *** multiplex: connection terminated
2/9/2017 1:48:31 PM [QUIMBY] Connected by address: e882010a
2/9/2017 1:48:31 PM [QUIMBY] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'
2/9/2017 1:48:32 PM [QUIMBY]
So the DICOMSTORE server can tell the C-Arm is trying to send it an image but something is happening during the process where it stops responding or something.
Our current DicomConquest server is running on version 1.4.17d. So I tried downloading the newest version, 1.4.19 onto my laptop locally. I set it up with a default database and was able to successfully verify and send to it.
2/9/2017 1:58:52 PM [WS0582] UPACS THREAD 13: STARTED AT: Thu Feb 9 13:58:51 2017
2/9/2017 1:58:52 PM [WS0582] A-ASSOCIATE-RQ Packet Dump
2/9/2017 1:58:52 PM [WS0582] Calling Application Title : "9800ESP "
2/9/2017 1:58:52 PM [WS0582] Called Application Title : "1419LOCALDCMSTR "
2/9/2017 1:58:52 PM [WS0582] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 32000
2/9/2017 1:58:52 PM [WS0582] Number of Proposed Presentation Contexts: 1
2/9/2017 1:58:52 PM [WS0582] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.12.1" 1
2/9/2017 1:58:52 PM [WS0582] Server Command := 0001
2/9/2017 1:58:52 PM [WS0582] Message ID := 0006
2/9/2017 1:58:52 PM [WS0582] 0000,0002 28 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.1.12.1"
2/9/2017 1:58:52 PM [WS0582] 0000,0100 2 US CommandField 1
2/9/2017 1:58:52 PM [WS0582] 0000,0110 2 US MessageID 6
2/9/2017 1:58:52 PM [WS0582] 0000,0700 2 US Priority 0
2/9/2017 1:58:52 PM [WS0582] 0000,0800 2 US DataSetType 0
2/9/2017 1:58:52 PM [WS0582] 0000,1000 48 UI AffectedSOPInstanceU "1.2.840.113780.9800.8351652.20170209072525.1.40"
2/9/2017 1:58:52 PM [WS0582] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2"
2/9/2017 1:58:53 PM [WS0582] FreeStore Left 161767 on C:\
2/9/2017 1:58:53 PM [WS0582] Written file: C:\Users\Person\Downloads\dicomserver1419\Data\76918\1.2.840.113780.9800.8351652.20170209072525.20_0001_000001_14866739330000.dcm
2/9/2017 1:58:53 PM [WS0582] UPACS THREAD 13: ENDED AT: Thu Feb 9 13:58:53 2017
2/9/2017 1:58:53 PM [WS0582] UPACS THREAD 13: TOTAL RUNNING TIME: 2 SECONDS
Then I tried the same process but on another server at our remote Data center, and it failed.
I'll attach those results as a text file since they made this post pretty ungainly.
At this point what I've been able to determine is I can send images to a local dicom server from these C-Arms but not over our site to site vpn to the remotely hosted server, which is hosted on an ESXi based VM.
There aren't any other C-Arms to test with at this location, all they have are two 9800 ESPs. I was able to download and use a TestSCU program from the laptop locally and was able to send an image to our standard Dicom server without a problem.
My theory is that something with this C-Arm's ethernet adapter isn't communicating properly with the server, at some part of the networking layer. Unfortunately documentation for the network adapter for these devices is very difficult to find. I've run some packet captures while sending images and can see from following the TCP/UDP stream that our dicom store is responding.
Is there a local specialist I can contact to help investigate this? GE doesn't seem to be interested because "It's a dicom problem." which means we're out of luck for finding a commercial level support for this and I'm honestly not experienced enough with this software or equipment to go much deeper without assistance.
Okay, this is really weird. Today we had the surgery center try sending some images from the 2 C-Arms that haven't been working for the past few weeks while I had the Debug log on. As soon as they did, every single image sent over just fine. I'm not sure why this suddenly started working since nothing changed on either end since we tried last week. We walked through the configuration and everything was exactly the same on the C-Arms when the images were taken and sent over. I wish I knew what changed so I could post a solution for users in the future that may run into this, but I couldn't do that with any confidence. All I can say is that I enabled the Debug log and that the Conquest DICOM service, the networking equipment, and the C-Arms were restarted countless times and then it finally worked.
In any case, thank you for your quick response and I hope I don't run into this issue again.
Thanks for the fast response! I'll give that a shot and post my findings.
We have a few GE 9800 C-Arms that have been configured to send images to and pull worklists from our DICOM server. We have had issues in the past with these particular C-Arms, but recently, we have had an issue where they will no longer send images to the server. We have combed over the settings many times and nothing has changed from when they were successfully sending to now. The error log shows what appears to be a modality issue. However, the modality settings were not changed on the devices (still set to XA).
We keep seeing this type or error in the Problem Logs (modified the patient ID to XXXXXXX for this posting);
20160624 07:14:22 Inconsistent Modality in DICOMSeries: PatientID = 'XXXXXXX' SeriesInst = '1.2.840.113780.990001.9352096.20160624071524.20' AND SeriesPat = 'XXXXXXX', Old='OT', New='XA'
20160624 07:14:22 Inconsistent StudyModal in DICOMStudies: PatientID = 'XXXXXXX' StudyInsta = '559B90D3-7245-4A3A-9C86-26CA2010CC24', Old='OT', New='XA\OT'
We have checked network connections, replaced cables, restarted all related equipment and vpn tunnels. Communication does not appear to be the issue since the worklists can still be pulled from the same network that hosts the DICOM server. The other C-Arms in our network are all still working fine. We had our C-Arms service technician stop by and he said the C-arm configurations look fine, so it has to be something on the Conquest Dicom side.
Has anyone experienced a similar issue with these C-Arms (or any others)? Any help at this point would be appreciated since we have the surgery center staff breathing down our neck to get this working again.
