Good morning,
I have been working through an issue with an instance of Orthanc at one of our locations. This is the only known instance within our entire company that I am aware.
Our third party is sending studies, but they are not able to be seen in the web interface at http://localhost:8042/app/explorer.html. During testing here are some items I have noticed.
a. Wiresark connectivity from their server to our workstation over port 4242.
b. Files and Folders in the C:\Orthanc folder was updated
c. The study was not able to be pulled up in the Orthanc web interface.
3. I looked at all the json files in c:\Program Files\Orthanc Server\Configuration but didn’t see anything to my knowledge that needed to be changed.
4. Restarted the Orthanc service but didn’t update either.
5. There are no instances of SQLite from what I can see.
They are currently running version 1.5.0.8 but I’m not sure how long ago this was installed. Apparently, this has been going on for the last several months. In the explorer page if I search for Today, Yesterday, Last 7 Days, and Last 3 months nothing displays. Only when I select Last year that studies actually appear.
Unfortunately, no one that I’ve asked in our IT department has any idea. I’m a network engineer and this incident was originally sent to me to troubleshoot a VPN connection which was actually working. Any suggestions or tips would be greatly appreciated because I’m lost.
Thanks!
Hello
First thing I would do would be to grab a test DICOM file and try to upload it manually from the web interface to check if Orthanc storage and DB are in good shape.
You should then see the corresponding study appear and you should be able to download it back as a zip from the explorer (both tests should be performed to rule out any db or storage issue)
If this works fine , then it is very likely that there is a network or DICOM issue. You should first make sure that network access to this Orthanc is possible.
There are multiple ways to send issues to Orthanc : either through the DICOM protocol or through the REST interface. The TCP/IP ports are different.
- The REST API can be reached on the
HttpPort in the JSON config (default 8042)
- DICOM communication is also specified in the configuration file (
DicomPort entry). Default is 4242.
If the other party sending studies is a non-Orthanc system, it is very likely that studies are pushed with DICOM, so you need to check the firewall.
For the other system to reliably send studies with DICOM, there’s more to it than simply making sure the DICOM port is opened on the firewall : both systems need to cross reference each other. On the Orthanc side, you need to make sure that the other system is mentioned with the correct AET (a Dicom concept aka AE title), IP and port in the DicomModalities field of the JSON config. If its IP, port or AET has changed, this could explain why transfer fails. Doing the same on the other system is also required, through whatever means the vendor supplies for this purpose.
It is likely that the existing configuration already has one or several entries for DICOM modalities. Otherwise, have a look at the default configuration file that contains examples on how to specify DICOM modalities (~line 400)
If everything has been checked (network + DICOM configuration) and transfer still does not work, you might want to carefully read the logs of both Orthanc and the other modality that is attempting to send studies.
The Orthanc Book is an invaluable reference, and I would advise you to read the configuration sections.
HTH
Thank you for the tips!
I was able to manually upload one file from the C:\Orthanc folder that was sent from our hospital on 7/10. I was also able to download a zip too. Regarding the protocols, when they sent their study I had a capture going and saw that port 4242 on our workstation was allowed and open. Possibly why the C:\Orthanc folder was updated at the time time. I’ll have them test 8042 when they attempt another study, but I can verify that port is open from our side.
About a week ago I did have to update the DicomModalities portion of the orthanc.json field as it was pointing to their old server address. (Hence fixing the VPN as they changed their server address).
I’ll review the book and see if there are any outliers I am missing. Thanks again!
You’re welcome. So Orthanc in itself is working. That’s good.
Maybe check that Orthanc itself is correctly referenced (by its AET) on the other modality side? This goes beyond my basic DICOM skills, but I seem to recall that it is possible that the modality contacts Orthanc and then drops the connexion because the AE Title that Orthanc reports is not the one that the modality expects.
You might want to browse the DICOM-related entries in the configuration file too : some control the level of permissivity in some DICOM network interactions.
And, as a final note, restarting Orthanc with this flag:
./Orthanc --trace-dicom
(or even ./Orthanc --verbose-http --trace-dicom)
HTH. Keep us informed on your progress!