Find SCP and other features


First, congratulations the great work.
I really like how you think the Ortahnc PACS.
I’m testing on Ubuntu and I want briefly collaborate.
I’m crazy for using OsiriX with Orthanc.
Is expected to implement Find SCP?

Other important features:

  1. auto-deleting a study (by date, file size, storage …)
  2. integrated HL7 server
  3. compliant auditing
  4. auto-routing (forward)


Hi Vinicius,

Thank you much for your positive feedback! Find and Move SCP will be the highlights of Orthanc 0.6.0, that will hopefully be released around June 2013. This should enable the use of OsiriX with Orthanc (assuming that OsiriX is able to receive files through the DICOM protocol). We are also planning to develop a FUSE filesystem on the top of the Orthanc REST API: This FUSE module would be bring Orthanc to any software that can read DICOM but that does not embed a DICOM server (such as Matlab).

Your points (1) and (4) are already supported through the REST API of Orthanc. An external script can indeed monitor the arrival of new images inside Orthanc and react accordingly (e.g. to delete files or to forward them to another location). Example of such a Python script can be found on our ISBI 2013 poster:

For the point (2), because Orthanc is designed as an auxiliary DICOM store and not as a full-pledge PACS, we have decided to make Orthanc revolve only around DICOM and not around other protocols such as HL7. However, this could be the topic of off-side open-source projects. We would of course be happy to discuss the integration of Orthanc inside such projects.

For the point (3), could you give more details about the application you have in mind? I am not comfortable enough with medical processes to understand what you exactly mean about “compliant auditing”.

Finally, please note that if you wish to contribute to Orthanc, a list of open problems for which we are seeking help is available on the Orthanc homepage:


Hi Sébastien,

Thank you for replying!

Sorry for the delay. I’m in the middle of many projects.

About the point 3, is something like the Audit Record Repository (ARR) of dcm4chee.

This is necessary for HIPAA and IHE, audit log of all transactions within the archive.


Hi Vinicius,

Sorry, I had forgotten to answer this question.

About the point 3, is something like the Audit Record Repository (ARR) of dcm4chee.

This is necessary for HIPAA and IHE, audit log of all transactions within the archive.

Such a feature is not present in our mid-term roadmap. Do not expect it to become available before the Orthanc 1.0.0 milestone. Indeed, our plan is first to strengthen the DICOM support and the REST API (which will be the target for Orthanc 1.0.0), before extending Orthanc to other protocols.

Please however note that such a feature could be the topic of a separate project, that would query Orthanc through its REST API. The transactions are indeed already recorded inside the “/changes” and “/exports” logs.


Hi Vinicius,

As you have seen on Facebook, we have just released Orthanc 0.7.0. This major release introduces the support of DICOM Query/Retrieve [1]. This means that Orthanc can now act as a C-Find SCP and C-Move SCP.

So, it is now possible to connect DICOM viewers such as 3D Slicer, Ginkgo CADx or OsiriX to Orthanc, using the DICOM protocol.



Very good Sébastien!
I follow their development updates.
I am grateful for the beautiful code.


Thanks for yet another great feature Sebastien!

I tried accessing the files stored in Orthanc with different viewers,
the study lookup (find), went alright. The problem is with moving the
files, I'm getting the following error:

... OrthancInitialization.cpp:541] Connecting to remote DICOM
modality: AET=HP0001, address=hp, port=104
W: DIMSE Warning: (ORTHANC, HP0001): sendMessage: unable to convert
dataset from 'JPEG Lossless, Non-hierarchical, 1st Order Prediction'
transfer syntax to 'Little Endian Implicit'
... MoveScp.cpp:128] IMoveRequestHandler Failed: DicomUserConnection:
DIMSE Failed to send message

I've tried to change the transfer mode in OsiriX (there are various
modes, including the JPEG Lossless), but it did not help. Also tried
Ginkgo CADx and ClearCanvas Workstation. All of them failed with the
same error.

Best regards,



Thanks for your feedback!

To be fair, because my test images directly come from the medical imaging devices of my hospital (that produce raw, uncompressed DICOM images), I have not been actively working on the support of JPEG/JPEG2K images by Orthanc so far. This is on my roadmap for Orthanc 0.8.0:

Would it be possible for you to send me the problematic images (even anonymized)? This could help the development.


Thank you for addressing this issue.

In case anyone runs into the same problem before Orthanc 0.8.0 is
ready, it is fairly easy to convert files to the supported raw format.
There is a command line utility - gdcmconv [1], which can convert
between different dicom formats. It is part of the Grassroots DICOM
project. If you are running Ubuntu, it is included in the
libgdcm-tools package.

The command for this particular conversion is:
gdcmconv -w input_file output_file

Where the input_file was a JPEG image in my case.



Dear Peter,

Many thanks for the images you sent me, I have been able to greatly enhance the support of JPEG files thanks to them.

Orthanc is now able to act as a C-Store SCP and a C-Store SCU that (hopefully) correctly handles the JPEG/JPEG2k/… transfer syntaxes. In other words, your JPEG images can be stored into Orthanc and can be retrieved from Orthanc by clients such as Ginkgo CADx and Slicer. While it is true that Orthanc is still not able to decode such images by itself, it can be used to transfer them between DICOM modalities.

The changes have been submitted to the mainline of Orthanc. I would like to have your feedback before creating an official release to see whether my fixes indeed solve your problem. Would it be possible for you to quickly test this mainline code? I would like to release the code on Friday November 8th, as other important fixes are also included. You can find pre-built Windows binaries at the following location:


PS: For 3D Slicer to accept the upload of your files, a patch must be applied to the Slicer distribution. I have included this patch along with this message (“slicer.patch”). This contrasts with Ginkgo that works out of the box.

slicer.patch (585 Bytes)

FYI, I have just released Orthanc 0.7.2 which should correctly handle JPEG/JPEG2k transfer syntaxes:

I’m seeing this same error with the latest version, when sending a study from Orthanc to another system. I can send the same study from Orthanc to Osirix OK, but this other system errors out with:

W: DIMSE Warning: (ORTHANC,TF_Server): sendMessage: unable to convert dataset from ‘JPEG Lossless, Non-hierarchical, 1st Order Prediction’ transfer syntax to ‘Little Endian Implicit’

E0411 14:16:34.290205 27113 MongooseServer.cpp:711] MongooseServer Exception [DicomUserConnection: DIMSE Failed to send message]

Is this a problem with Orthanc, or the receiving system?


Hello Joe,

If you are able to send the study from Orthanc to OsiriX, but not to your other system, this most probably reflects a problem in the configuration of the receiving system. The warning given by Orthanc seems to indicate that the receiver is not able to deal with the JPEG* transfer syntaxes.

What is your receiving system? If this is “storescp” from the DCMTK package, you should add the “+xs” (–prefer-lossless) command line option when launching “storescp”.


I know this thread is a bit old, but if it’s still live, I’m getting a similar problem on V 1.5.4 …

E0324 OrthancException.h:85] Error in the network protocol: DicomUserConnection to AET “myTestAET”: DIMSE Failed to send message (0006:031d TCP I/O Error (An existing connection was forcibly closed by the remote host.) occurred in routine: writeDataPDU)

E0324 StoreScuOperation.cpp:77] Lua: Unable to send instance c6bf74ef-c8979b32-76aefbdc-f6f92868-061b76c2 to modality “myTestAET”: Error in the network protocol

The first image always gets sent however … and sometimes, they all get through. I poured through all I could, but can not find where I can require the store to use a specific transfer such as JPEGLossless:Non-hierarchical-1stOrderPrediction …

The remote AET is always available and open and is not closing connections … is it DicomAssociationCloseDelay … or some other setting I can’t find?


Your error log is by no way related to the five-years-old original problem.

Please read the FAQ: