Orthanc and ClearCanvas

Hi all,

Due to a harware failure of our PACS server (ClearCanvas), I have decided to change to Orthanc, but I’m hitting a wall trying to connect the ClearCanvas clients to the Orthanc server.

I imported all FS of CCserver into Orthanc without problems, but I’m unable to do a simple query from the CCclient :frowning:

I defined a DICOM modality like this:

“clients” : [“”, “”, 104]

I don’t want to be defining the clients one by one … because they are too much, apart that they have dynamic ips.

With that … every time I query the server from a CCclient I get a timeout error

With the same config, If I use a DICOMed Review Radio client v4.1 (we use it for MR studies), I could query the server without any problem and retreive the studies, no matter if they are MR, CR or Eco

Do I have to change something on the config to let CCclients query and retreive?

I have also tryed to use the 4th param and put it at “ClearCanvas”, as the sample config suggested … but with no luck.

Best regards


Such a configuration is doomed to fail: For a query/retrieve request (aka. C-Move) to succeed, the PACS must know the AET and the IP address of the target DICOM modality. As a consequence, there is no way to write a single line to configure several DICOM clients. You have to create one single entry for each of your clients.

Please note that this is not a problem that is specific to Orthanc: This is a limitation of the DICOM standard that is present in all the DICOM servers supporting the C-Move mechanism. I suspect that your previous setup worked because your DICOM server and client used the C-Get mechanism instead of the C-Move. Unfortunately, the C-Get mechanism is now tagged as obsolete in the DICOM standard, therefore we do not plan to support it in Orthanc.

Your problem with dynamic IPs is clearly the reason why Orthanc proposes a bridge from the DICOM protocol to the REST API. By resorting to the HTTP protocol, Orthanc proposes an easier configuration and allows dynamic IPs. In your case, I would recommend you to ask the CCclient and/or the DICOMed Review Radio client to introduce support for the REST API of Orthanc in their software. Orthanc comes with a C++ API on the top of the REST API (aka. “OrthancClient”) that allows such an interface to be implemented.


Hi Raul,

So, you are trying to query Orthanc with both Clear Canvas Client and DICOMed Review.
DICOMed succeeds and CC fails with a timeout.

  1. Can CC do a C-Echo on Orthanc?
  2. Can you post the CC client logs, and the Orthanc server logs?


Also keep in mind that if you are no longer using Clear Canvas PACS, then you won’t be able to use
Clear Canvas streaming to view images: you will need to retrieve them first.

Also, if you want to replace CC Pacs, have you considered DCM4CHEE ?

So, it sounds like Orthanc is not handling the modality search tag when doing a C-FIND.
It sounds like a bug to me.


Me too … spend some hours doing test during the weekend and found things that need to be fixed … will be doing the fixes during the next days and submit a patch.


Please could fill a bug report:

This will greatly help us to track the problems inside Orthanc.

Please could you also attach sample DICOM files (possibly anonymized) to reproduce the problem?

Have you tried with Orthanc 0.7.5 that was released last week?

Thanks for you contribution!

For the sake of correctness: David Clunie has just written me that C-GET is not tagged as obsolete or deprecated in the DICOM standard. Sorry for this mistake.


I’ve tried to comment to this David Clunie’s post:


But he didn’t approve my comment yet.

I think that an opinion that C-GET is obsolete is correct (despite C-GET is useful thing). I think that this quote of the DICOM Standard proves it:
“In the case where an Application Entity wishes to request that it receives one or more images for storage, it may use either a C-GET operation or a C-MOVE to itself. It is expected that in most environments the C-MOVE is a simpler solution despite the fact that two Associations are required. The use of the C-GET service may not be widely implemented. It may be implemented in special cases where a system does not support multiple Associations. It was left in this version of the Standard for backward compatibility with previous versions of the Standard.”

You can see it here (see the 2nd Note):


Dear Valentin,

Thanks for this interesting feedback!