Orthanc - is ready or meant to replace a real PACS?

Google Groups archive
1

Hi Everybody

Orthanc with its web GUI looks very interesting for us to give it a try for a basic failover PACS we are using.

We are currently running Conquest with about 10TB of DICOM data (roughly 44M images) and a MySQL databse set of just over 40GB.

From reading some of the documentation I know that Orthanc has the basic c-find and c-store implementation to receive and push studies and routing options,

However I missed references if Orthanc can:

- use MySQL as DB backend
- can have multiple DICOM storage devices/HDDs
- can handle Dicom data of 40M-100M images
- has basic function like - re-scan/re-index a specific dicom storage location
- assign special transfer syntaces to a dicom host - i.e. that one AET get files as JPEG lossless and another host as Jpek200 lossless

thx for any feedback

2

Hi Everybody

Orthanc with its web GUI looks very interesting for us to give it a try
for a basic failover PACS we are using.

We are currently running Conquest with about 10TB of DICOM data (roughly
44M images) and a MySQL databse set of just over 40GB.

From reading some of the documentation I know that Orthanc has the basic
c-find and c-store implementation to receive and push studies and routing
options,

However I missed references if Orthanc can:

- use MySQL as DB backend

No, the only supported open-source DB server supported is
currentlyPostgreSQL (PostgreSQL plugins — Orthanc Book documentation).
MySQL has been requested by a few people but I have not heard of any
initiative to build such a plugin right now. If anyone is willing to
contribute, please contact us.

- can have multiple DICOM storage devices/HDDs

No, Orthanc currently only supports one storage location. However, if you
need to store a large amount of data, you'd probably store it on a NAS/SAN
and therefore, the multiple storage devices can be seen as a single
location. Again, this could also be implemented in a new storage plugin.

- can handle Dicom data of 40M-100M images

As long as you use PostgreSQL as the DB index, you would basically have no
limit. We are aware of a few installs with around 10 TB of data. Orthanc
still works fine in this case but the Orthanc Explorer is not intended for
use with large number of patients (there's currently not pagination on that
page so it takes an incredible amount of time to load (again, contributions
are welcome))

- has basic function like - re-scan/re-index a specific dicom storage
location

For that, you should use an external script that will drive Orthanc through
its REST API. I.e:
https://bitbucket.org/sjodogne/orthanc/src/default/Resources/Samples/ImportDicomFiles/ImportDicomFiles.py

- assign special transfer syntaces to a dicom host - i.e. that one AET get
files as JPEG lossless and another host as Jpek200 lossless

Not out of the box but you can do it with some Lua scripting. First of
all, you've to remember that Orthanc is very lightweight and you may deploy
many of them on the same machine. You may sometime deploy an orthanc
instance to perform a single repetitive task like transcoding from one
transfer-syntax to the other.

Consider your big archive is A and your modality is C. You may deploy a
new Orthanc (B). Every time you need to send a study from A to C, you
actually send it to B. B will transcode it and forward it to C. This can
be done with a bit of Lua scripting (check this link for a lua script that
is transcoding to JP2K:
https://bitbucket.org/sjodogne/orthanc/src/default/Resources/Samples/Lua/AutomatedJpeg2kCompression.lua?at=default&fileviewer=file-view-default
)

3

Hi Everybody

Orthanc with its web GUI looks very interesting for us to give it a try for a basic failover PACS we are using.

We are currently running Conquest with about 10TB of DICOM data (roughly 44M images) and a MySQL databse set of just over 40GB.

From reading some of the documentation I know that Orthanc has the basic c-find and c-store implementation to receive and push studies and routing options,

However I missed references if Orthanc can:

- use MySQL as DB backend
- can have multiple DICOM storage devices/HDDs
- can handle Dicom data of 40M-100M images
- has basic function like - re-scan/re-index a specific dicom storage location
- assign special transfer syntaces to a dicom host - i.e. that one AET get files as JPEG lossless and another host as Jpek200 lossless

thx for any feedback

Here are my "2 cents"

Before using any terms, I believe it's relevant to define them.

What can you consider an archive and what can be considered a storage ?

In the DICOM archive world, you need

HL7 link to the RIS

in private practice HL7 ORM with the RIS is often enough (RIS to PACS)

This achievable with MIRTH + REST interface of Orthanc

in big enough hospital, HL7 ADT is necessary (to propagate patient merge for example and the status - HIS to Archive)

This achievable with MIRTH + REST interface of Orthanc

HL7 ORM from the PACS to the RIS and HIS is very often made to inform the PACS or the RIS that a study has been created. Also known as notification of presence of the images. That allows the RIS or the EMR to create an icon to allow the user to know the images are available, ready to be reviewed.

how to achieve it ? Maybe with REST interface of Orthanc and Mirth

HL7 ORU from the RIS or the EMR to the PACS so that the PACS can store the report in its Database and / or convert it into DICOM SR

Some opensource program might be able to do that

DICOM Store with modalities

This is one of the core feature of Orthanc

DICOM Storage commit

This is in the Orthanc roadmap

4

Hi

Thx for the answer.

So from the looks of it Orthanc seems to be lacking some basic functions we actually do need - and personally I think those are basic functions any PACS needs to find a wide acceptance outside the world of people who can actually code their own scripts etc.

Since I am not a coder I can't do my own Lua scripts for recompression and so on.

So as feedback I would like to post them as a list, maybe some will be implemented someday:

- define transfer syntaxes inc. compression for each AET for send/receive - preferably via GUI
- MySQL support - I know you are crowdfunding already
- GUI explorer that can handle large study lists and searches for editing / deleting studies
- manage storage location via GUI inc. compression settings
- easy import of folders via GUI/drag'n drop
- running as a service under windows

As for using an instance in the middle for recompression we had quite some issues with: query from Viewer A to PACS B and receiver over PACS C - I know that it is DICOM conferm to do this, but the real world showed us that it can cause a lot of trouble....

Even thoug orthanc isn'tan option at the moment I will donate for the MySQL as I think it has a great potential

5

Just a couple of comments that reflect our experience at RIH imaging research.

We have found that Orthanc's core services using Postgres expand comfortably to manage several TB of data at least (we have about 6TB of high resolution recons in an Orthanc research PACS).

As Alain says, Orthanc's web GUI is _NOT_ meant to handle this amount of data, so we need to work with the studies through the REST API and through other PACS nodes that can query the Orthanc store indirectly. We also use a parallelized "gang" of Orthanc instances working against the same Postgres backend to speed up response time under load. And as Alain mentions, this also allows us to have different DICOM receivers with different functions (compress, forward, etc.). We assume that physicians will not use the Orthanc GUI for any clinical review.

I agree that there are also a number of "missing" backend pieces as noted, such as support for multiple storage sites and HL7 feeds. We get around these issues by carefully managing a storage system to make space management transparent and present a single _big_ volume to Orthanc, and by indexing DICOM, DICOM SR, and HL7 metadata in yet another separate system for integration and analysis (Splunk).

Given that Orthanc is _free_ and nearly bulletproof in its core capabilities, we still look at the whole system as an extremely inexpensive alternative to purchasing a vendor VNA. It has been well worth the investment in time and resources to patch together the additional required functionality.

Derek-