Orthanc - is ready or meant to replace a real PACS?
1,741 views
Skip to first unread message
stoe...@googlemail.com
Jun 30, 2017, 3:31:00 PM6/30/17
to Orthanc Users
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
Alain Mazy
Jul 3, 2017, 4:30:57 PM7/3/17
to stoe...@googlemail.com, Orthanc Users
On Fri, Jun 30, 2017 at 9:31 PM, stoeve007 via Orthanc Users <orthan...@googlegroups.com> wrote:
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 (http://book.orthanc-server.com/plugins/postgresql.html). 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)
thx for any feedback
Alain Mazy / CTO
a...@osimis.io / +32 494 31 67 27
| OSIMIS S.A.
|
johan.z...@gmail.com
Jul 3, 2017, 6:53:17 PM7/3/17
to Orthanc Users, stoe...@googlemail.com
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
> for multiple site implementation IOCM is necessary in order to be considered a real player (Image Object Change Management)
> Multiple storage location : Orthanc does not have this feature yet but it's easy to expand the size of SMB share. It would be nice to have multiple location to store data to. The probleme beeing, when to store a study on share 1 and when to store on share 2 and when to start storing on share 3 considering they have all different size... That's an issue we cam across at Agfa for the Entry Level solution
stoe...@googlemail.com
Jul 15, 2017, 3:57:20 AM7/15/17
to Orthanc Users, stoe...@googlemail.com
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
derek...@brown.edu
Jul 16, 2017, 11:28:22 AM7/16/17
to Orthanc Users, stoe...@googlemail.com
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-
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-
Reply all
Reply to author
Forward
0 new messages