Orthanc as a Hospital PACS?

[Emsy Chan]

Hi,

My boss just asked me to prepare a proposal to upgrade multiple hospitals who are still using printed film to a become fully "filmless" (for pure image viewing - no RIS integration)

The first issue before we go any further: Is there a licensing / moral issue if I decide to use Orthanc for this? I'm aware of GPLv3 and as far as I have read, I think it's OK for the implementation I'm thinking of. If there are issues, please please please let me know, either through this forum or through pm!

My current idea is as follows:

- A routing server running Orthanc that receives images from the modalities and routes them to:

1. A main PACS server
   
2. Multiple (about 100 - 200) client computers (based on DICOM data; i.e. if requesting doctor is so & so, it routes to their computer, etc)

- The main PACS server runs Orthanc

- The 200 client computers run Orthanc (that limits to about 300 studies)

- A web interface that queries Orthanc for the studies and launches a viewer (Weasis or anything else)

- The main PACS server also routes images through the internet to a central multi-center repository

The estimated load will probably be up to 5000 instances of CT, 2000 instances on MRI, 200 instances of CR/DR, 1000 instances of US per day.

The estimated use will probably be 60 concurrent users at any one time.

The estimated number of unique patients would be 400 per day.

I'm thinking that when each client computer runs its own Orthanc, it will reduce the load on the main PACS, although I'd be a little worried about Orthanc handling almost 10,000 instances a day.

Any comments on this? Thanks!

[maxpow...@gmail.com]

Been working on a similar thing here, Orthanc is not ready for this kind of thing, point blank.

Do not use it in a mission critical environment.

Here are some MAJOR reasons why.

Orthanc assumes that the patient id is unique to a single patient across all interactions. Imagine a situation where the patient id in dicom is being recycled or duplicated. For instance, 2 hospitals each use an internal id generator and there is a collision. In this case, the first patient assigned an id is assigned the record regardless of if they are in fact the correct patient. We actually have a pregnant man because of this.

Secondly, Orthanc uses SQLite for it's DB, this decision was a HUGE mistake. SQLite uses a single index file and no server front end. It cannot be accessed by multiple instances safely.

If you are somehow able to share the directory, e.g. NFS, Samba, or s3fs, that file will eventually become corrupt. SQLite is not designed for multiprocess concurrency.

Also it is a file sitting on the same filesystem as the rest of the dicom data.

If this file becomes corrupted or damaged you have now lost all information on all images and must re-import the entire image set. That might work for a single instance sitting in a small clinic. However we generate 50GB DAILY in images, terabytes of data being reimported is not realistic at all. Having Orthanc crawl the DICOM dir when it can't open it's SQLite index, would probably be a much better idea.

Finally, user access controls are a joke. I have no idea what use case the creator was imagining, but having each and every user in the same config file as the rest of the system is just bad design. A better solution would have been an LDAP connector for that stuff, or failing that a DB based solution.

Orthanc is nice, it has a slick ui and great licensing terms. I wanted this to work and we invested 400+ man hours in our setup (mostly importing extant data and trying to normalize it), only to find that there is no way to make this scale beyond a single instance.

It's odd because a couple of early design decisions from the original devs like SQLite instead of MySQL or PostGres (ODBC would have been best IMHO) and making all admin settings including user accounts something managed in config files is really what breaks this.

We are looking at the possibility of ripping out SQLite and using ODBC instead and LDAP for user auth.

However this looks like a pretty fundamental change and it may be better to simply start over.

Orthanc is probably suitable for a single instance pacs archive in a small clinic where the helpdesk/computer guy is technically proficient, but don't even dream of scaling this beyond that, sorry.

[maxpow...@gmail.com]

On Thursday, January 15, 2015 at 7:50:28 PM UTC-8, Emsy Chan wrote:

One more thought. Your use case seems much better suited to using Dicoogle on a box right next to the acquisition point. Probably be much easier to deploy anyways.

[Sébastien Jodogne]

Hello,

Thanks for sharing your ideas here. They are all valuable, but you miss the point about Orthanc.

Our initial goal was not to provide a full-featured RIS/PACS system, but to provide the most easy to setup, cross-platform, standard-compliant, and open-source DICOM store. Orthanc is designed for one-click install-and-enjoy. I am convinced it is the most accessible software of this kind. And this is made possible thanks to its SQLite back-end: SQLite brings zero-configuration to the DICOM world!

Besides its ease of setup, do not forget other major features that are unique to Orthanc: one-line auto-routing with Lua, REST API to automate imaging flows or to build rich Web applications, and plugins to build complex low-level applications dealing with DICOM.

We always claimed that Orthanc is a very valuable COMPLEMENT to any proprietary, closed-source RIS/PACS. 

Do not use it in a mission critical environment.

You CAN use Orthanc in clinical setups, for instance for auto-routing or to ensure proper QA of DICOM modalities.

 

Orthanc assumes that the patient id is unique to a single patient across all interactions.  Imagine a situation where the patient id in dicom is being recycled or duplicated.  For instance, 2 hospitals each use an internal id generator and there is a collision.  In this case, the first patient assigned an id is assigned the record regardless of if they are in fact the correct patient.  We actually have a pregnant man because of this.

The DICOM standard requires that any two studies are associated with different StudyInstanceUID. If 2 separate modalities create 2 studies with the same StudyInstanceUID, they do not fulfill the most basic DICOM requirements. Because of this, Orthanc will always assign different IDs to any pair of DICOM studies (except in there is a SHA-1 collision). The same holds at the series and instance levels. In your scenario, even if the 2 patients are merged, their studies will be separated.

You are only right about the patient level, because PatientID is not required to be globally unique. In this case, you have to use the "/studies" URI instead of the "/patients" URI in the REST API of Orthanc. It is almost trivial to create a version of Orthanc Explorer that would query "/studies" instead of "/patients"... certainly not a 400-hours job.

BTW, remember that "Orthanc Explorer" (the built-in Web interface of Orthanc) is an administrative, low-level interface that is fully implemented with a few hundreds lines of code. If your setup requires more advanced abilities, just implement another interface through the REST API. And share it with the Orthanc community: This is the most basic philosophy between any open-source project.

 

Secondly, Orthanc uses SQLite for it's DB, this decision was a HUGE mistake.  SQLite uses a single index file and no server front end.  It cannot be accessed by multiple instances safely.  

No, this is NOT a mistake, but a FEATURE to make Orthanc the most easy-to-setup DICOM server (see above).

If you need a PostgreSQL (for large-scale VNA), just wait for a couple of week, as I have written earlier today:

https://groups.google.com/d/msg/orthanc-users/XoFMV0XezJg/vfZKmHqA_tMJ

 

If you are somehow able to share the directory, e.g. NFS, Samba, or s3fs, that file will eventually become corrupt.  SQLite is not designed for multiprocess concurrency.

The experimental PostgreSQL back-end stores its files as large objects.

Also it is a file sitting on the same filesystem as the rest of the dicom data.

You can put the SQLite index in another filesystem that the DICOM data (cf. "StorageDirectory" and "IndexDirectory" options). In particular, the SQLite index can be put on a RAID device to prevent the loss of the index.

 

If this file becomes corrupted or damaged you have now lost all information on all images and must re-import the entire image set.  That might work for a single instance sitting in a small clinic.  However we generate 50GB DAILY in images, terabytes of data being reimported is not realistic at all.  Having Orthanc crawl the DICOM dir when it can't open it's SQLite index, would probably be a much better idea.

Wait and give a try to PostgreSQL once it is available.

 

Finally, user access controls are a joke.

Please be respectful. Many people have worked hard on Orthanc, it is very easy to destroy a 3-men-years software with a single mail such as yours. We have always been open to any external ideas. We always answer messages from the community, in the best delays. If user access is a problem to you, please be constructive and tell us so. We can help (see below).

 

I have no idea what use case the creator was imagining, but having each and every user in the same config file as the rest of the system is just bad design.  A better solution would have been an LDAP connector for that stuff, or failing that a DB based solution.

Do you know about Apache reverse proxying? Do you realize that the point of Orthanc is to provide a RESTful API that should not be directly published on the cloud? 

If HTTP basic authentication is insufficient for you, just branch the REST API of Orthanc behind Apache, and protect it with a proper ".htaccess".

So you need LDAP? Just implement it with a PHP/Django/nginx wrapper around Orthanc. Bottom line.

Orthanc is nice, it has a slick ui and great licensing terms.  I wanted this to work and we invested 400+ man hours in our setup (mostly importing extant data and trying to normalize it), only to find that there is no way to make this scale beyond a single instance.

Why didn't you get in touch with the Orthanc community earlier to ask assistance? 

It's odd because a couple of early design decisions from the original devs like SQLite instead of MySQL or PostGres (ODBC would have been best IMHO) and making all admin settings including user accounts something managed in config files is really what breaks this.  We are looking at the possibility of ripping out SQLite and using ODBC instead and LDAP for user auth.

To summarize:

• We work on PostgreSQL to replace SQLite.
• LDAP can be implemented at a higher level.

 

However this looks like a pretty fundamental change and it may be better to simply start over.

Just wait a couple of weeks for PostgreSQL and share with the open-source community your PHP/node/Django/nginx/whatever wrapper. Contribute to the project instead of recommending other people to trash it!

Sébastien-

[maxpow...@gmail.com]

Firstly allow me to apologize if the tone of my previous email came off as harsh or in any way condemning this project.

The OP was asking for specific suitability of Orthanc for a project that involves a lot of medical records distributed across multiple locations.

Let's be honest with ourselves here. Orthanc is great app. Probably the easiest to use and best built PACS in the open source world. It blows the doors of DCM4CHEE and most others we tried.

It is not however ready for mission critical usage in the environment described by the OP.

The project I'm wrapping now, integrates records from hundreds of locations in an effort to centralize medical records keeping.

We went through several test "pacs" before settling on Orthanc. The user interface and the rest interfaces were a major contributor to that decision, but also the fact that it was open source and you can build off from it.

What I called the mistake of using SQLite, is something you claim was a conscious design decision. Ok then that makes the mistake mine in assuming that we could scale this design out simply by changing a driver out and a few SQL calls.

However the fact remains as long as you continue to use SQLite as the backend, then scaling will be limited to a single machine, with a single point of failure and if whatever location that index file is sitting at goes away, becomes corrupt or whatever, you are now faced with the prospect of reimporting all of that data. If you have terabytes of data, that is not really realistic.

How you describe it, is not how I would have built it and that's OK. If I had wanted to build a PACS I would have done so, but this is not an itch I really have any desire to scratch. And like I said, honestly you have done an awesome job so far in addressing the particular use case you are targeting.

Nevertheless, your envisioned use case is markedly different from the actual use case both myself and the OP are/were attempting to put it to.

My comment about user account controls being a joke was probably a bit harsh, and was meant as a statement more of my own simple frustration, than a comment on the system.

Please don't take offense.

I would hope that everyone who has worked on open source projects has thick enough skin to walk away from a flame like that unscathed. I will excersize more tact in the future.

Nevertheless, my underlying but previously unstated opinion stands.
I believe, from real world experience that using the config file for anything other than telling app what port to bind to and where to look for things such as the DB to connect to, will always end up badly for everyone involved.

Orthanc is not bad, in fact it's great. I was unaware you were working on a PostGres port and I consider that to be an incredible reason to come back and re-evaluate Orthanc in a few months when that settles down. I still wouldn't recommend it for mission critical use though until it's had a chance to be vetted :)

If you want help with the port let me know. I've ported apps in the past from SQLite to ODBC (which is what I would recommend you do since some users may be unable to integrate with PostGres).

Again sincere apologies, but in specific reference to the OPs question, my experience from having actually trialled a similar project using Orthanc, is no it's not ready yet. With the caveat of check back soon!

> We work on PostgreSQL to replace SQLite.LDAP can be implemented at a higher level.

[Emsy Chan]

Hi guys! 

I thank you both for the points that you have made.

Sébastien, I apologize for causing confusion by raising the use of Orthanc as a main PACS despite it being written very clearly that Orthanc was never designed to do so. It's just that Orthanc has been working so well for me running ancillary systems in my hospital network, e.g. for dose monitoring, and as a back-end PACS for the web applications I've been working on - it was automatic for me to ask whether such a well-designed software could be scaled up to fulfill the needs of a hospital PACS.

This is a simple case of me reading the "Do not eat" package that comes with electronic equipment and asking, "Can this be eaten? It looks delicious."

maxpow... (sorry, I didn't get your full handle), I'm glad that you have shared your efforts with Orthanc trying to run a multi-centre PACS. You have probably saved me about a year's work - considering that at the moment, the number of team members I have is 1.

I'll admit right now that I do not have anything intelligent to say because although I am familiar with the basic concepts you are espousing, I do not have the basic technical expertise to completely appreciate the options that you mention. However, I feel that I am a fast learner, and I appreciate and will study whatever issues you have raised.

I'm a doctor, not a PACS administrator. However, in my current working environment, I'm as close to "the PACS guy" as they have. 

Am I right that the conclusion (at this point in time) would be that PostgreSQL should allow Orthanc to scale up to handle a moderately sized hospital? 

maxpow mentioned that Orthanc is superior to DCM4CHE. To be honest, DCM4CHE was my original fallback in case Orthanc (by intended design) cannot handle a mission-critical environment. In that case, I would most likely have to resort to spending millions of government money to set a proprietary PACS (which is the very very very last resort - something like ditching Enterprise to kill Khan...)

Again, thank you all for your time and expertise! :)

[maxpow...@gmail.com]

> This is a simple case of me reading the "Do not eat" package that comes with electronic equipment and asking, "Can this be eaten? It looks delicious."

Yeah I get that a lot too :) Orthanc has a positively sexy UI, it's very well thought out and everyone I've showed it to seems to be able to use it right off with no learning curve.

> maxpow... (sorry, I didn't get your full handle), I'm glad that you have shared your efforts with Orthanc trying to run a multi-centre PACS. You have probably saved me about a year's work - considering that at the moment, the number of team members I have is 1.

Glad I could help, the name is Max Powers, obviously just a nome de plume, so I can track conversations in different public forums easier and keep track when marketers, recruiters try to contact me :0

> I'll admit right now that I do not have anything intelligent to say because although I am familiar with the basic concepts you are espousing, I do not have the basic technical expertise to completely appreciate the options that you mention. However, I feel that I am a fast learner, and I appreciate and will study whatever issues you have raised.

That's understandable. The problem is with some underlying assumptions that the devs made about how it would be used. It is absolutely awesome for their considered use cases, but there are always tradeoffs in design.

Here the tradeoff was ease of deployment and ease of administration with the cost being scalability. They are however working on negating that impact by switching to an external DB.

There are 2 models for DBs. There is the client/server model which is what most software tends to use when you need to share data between instances. Then there is the embedded model.

The client/server model will always require you to deploy and manage a database server in addition to the software itself, whereas the embedded model puts the DB functionality directly into the application, thus nothing extra to deploy or manage.

When you go purely embedded (which is what SQLite is), you introduce a single point of failure into the system. If the DB index is corrupted then you are back to square one and need to re-import your data. Trying to share that index file between running instances is a sure fire way to corrupt it too:(

In our case this is terabytes of data and all that data needs to be normalized since different hospitals tended to duplicate patient ids. Which is where the 400+ man hours came from.

I can report that until the corruption of the index file it seemed to handle the load well though.

> I'm a doctor, not a PACS administrator. However, in my current working environment, I'm as close to "the PACS guy" as they have. 

This is not a criticism, but what you say tends to happen a lot in IT.
My advice is to be careful making decisions that could impact patient data without consulting with people who do this sort of thing for a living. I wouldn't try to plumb my house, I would hire a plumber to do it, too many things can go wrong. Same with Information Technology it's the plumbing for your organization and your organization will live or die by how it handles information. What usually happens in these cases is a very messy and expensive porting process later. There are ways t avoid that but they are situationally dependent.

> Am I right that the conclusion (at this point in time) would be that PostgreSQL should allow Orthanc to scale up to handle a moderately sized hospital? 

Yes Postgres will allow you to scale up by enabling the ability to share data between instances. The trade off is that Postgres requires a separate deployment & management process and as much as I love postgres you really do need a fulltime DBA to setup , secure & manage it (or at least a contracted one). This is doubly true in the USA where you have to worry about HIPAA compliance, since you need to have much tighter security than the default deployment. This is true for MySQL, Oracle and every other DB out there as well.

> maxpow mentioned that Orthanc is superior to DCM4CHE. To be honest, DCM4CHE was my original fallback in case Orthanc (by intended design) cannot handle a mission-critical environment. In that case, I would most likely have to resort to spending millions of government money to set a proprietary PACS (which is the very very very last resort - something like ditching Enterprise to kill Khan...)

DCM4CHEE (which is different from DCM4CHE by the way, one is a library, the other is a server), is good and reliable solution. However it has a steep learning curve and it's not fun to setup correctly. Furthermore, can't make it HIPAA compliant, so that was a deal killer for us. Also it's running on top of a positively ancient version of JBoss which besides being nearly impossible to find anymore, is really showing it's age.

I wouldn't go proprietary on anything because you run a real risk of vendor lockin, or as happened to one of my clients, vendor lock-out. They had a product that went 5 years without a new release and the new release when it came, completely broke backwards compatibility. Only way to read older data was pay for a per workstation license of a "bridging app" at a cost of several thousand dollars per workstation.

That was actually a problem we were trying to head off with this project.

[celerit...@gmail.com]

This is actually a good string of discussions -- it brings clarity to various issues and features to the surface. I am totally new to Orthanc, but I have seen and used many PACS before, including open source dcm4chee, dcmtk and ClearCanvas.

I have a few questions -- to anyone who is knowledgeable about Orthanc:

1). HIPAA compliance:
I noticed the previous message mentioned that dcm4chee isn't HIPAA compliance. dcm4chee met IHE security standard with login and audit trails. Any other things that are needed for HIPAA compliance? Could you elaborate on how you see it? Could you also elaborate on how Orthanc help you to be HIPAA compliant?

2). Database schema and Orthance architecture:
Is there a published database schema for Orthanc? It sounded that Orthanc supports an architecture that can have different database backends. (I also like it's plugin

3). Cloud support:
How does Orthanc work if I'd like to use it in a cloud environment?

4). Image viewers and reporting tools:
Do you have a list of medical image viewers and reporting tools that currently work well with Orthanc?

Look forward to hearing from anyone.

[maxpow...@gmail.com]

On Tuesday, January 20, 2015 at 11:08:50 PM UTC-8, Celerity Abbottt wrote:
> This is actually a good string of discussions -- it brings clarity to various issues and features to the surface. I am totally new to Orthanc, but I have seen and used many PACS before, including open source dcm4chee, dcmtk and ClearCanvas.

Glad I could be helpful, but always remember YMMV

> I have a few questions -- to anyone who is knowledgeable about Orthanc:
>
> 1). HIPAA compliance:
> I noticed the previous message mentioned that dcm4chee isn't HIPAA compliance. dcm4chee met IHE security standard with login and audit trails. Any other things that are needed for HIPAA compliance? Could you elaborate on how you see it? Could you also elaborate on how Orthanc help you to be HIPAA compliant?

We ruled DCM4CHEE out several months ago and I remember we cited that making it HIPAA compliant would be problematic and may not be possible. I honestly don't remember the specific reasons cited, but user access control sounds like the answer to my mind. However you say it has that, so honestly now I just can't defend that statement anymore. I still standby my previous statement of the new version being a horribly unstable mess right now and the "stable" version running on a version of JBoss that is literally so old even redhat doesn't provide a download for it.

> 2). Database schema and Orthance architecture:
> Is there a published database schema for Orthanc? It sounded that Orthanc supports an architecture that can have different database backends. (I also like it's plugin

I've not looked too closely myself at what it's using inside, but if I'm not mistaken you should be able to pull the index file into something like https://code.google.com/p/phpliteadmin/ and get a gander. I've never tried it, I was looking at the code and remembered my eyes glazing over :(

> 3). Cloud support:
> How does Orthanc work if I'd like to use it in a cloud environment?

That couldn't possibly be any more vague. It's not going to autoscale until they get the postgres thing working so you are limited to a single host instance no matter what you choose.

Because instance storage is ephemeral and at bit of a premium.
We ran it with OrthancStorage as a mounted EBS volume with great success but kept running out of room due to our dataset size. We also tried using s3fs to allow storage directly in s3 buckets (because instance storage is hard to come by and EBS volumes cost money), but that solution needed a lot of monitoring and babysitting.

You should also be advised that as a general rule, many cloud providers are not going to let you open up arbitrary ports and services either. For example OpenShift is http only.

So the real answer here is that your answer depends entirely on a HUGE number of factors not the least of which is that "cloud" is a horribly ill defined and vague term that can mean at least 1,000 different things. Be more specific about your plans and I'll be glad to let you know if I can forsee anything though.

> 4). Image viewers and reporting tools:
> Do you have a list of medical image viewers and reporting tools that currently work well with Orthanc?

Works well with everything we've thrown at it, the faster stuff speaks WADO I think. But we still have modalities pushing all studies to it directly even though some of the modalities are using software that was released circa 2001.

I also managed to write a custom app in Java/Swing that queried the studies via the rest API and produced a normalized record set. We used the record set for billing purposes, but it can also be imported into an RDBMS and using a quicky little web script, could provide access to the normalized data. That's how we dealt with our pregnant guy! :)

For online viewing we've used dwv-explorer. Offline viewing has been efilm or ginkocadx. Personally I'm liking ginkocadx, but I'm not a Dr and peoples lives don't depend on whether or not I like a tool.

It's a DICOM pacs, should work with about anything that speaks DICOM.

[Emsy Chan]

@max Thanks for the explanation. Saved me a lot of headache and gave me a jump-off point to do more research. And I totally agree about the plumbing part. Unfortunately though, I'm not confident that I can find a "plumber" that can run my project in my country.

Issue #1: Back-end Database

I'm not sure what database schema actually means, but I was using DB Browser for SQ Lite to dig through the index. file. I can recognize some structure in there (including the UUIDs for the patient/study/series/instance/file) but cannot make any intelligent opinions. I was actually looking to try to grab the patient name, ID, modality, study date and the associated UUIDs to build a searchable front-end GUI.

Issue #2: Front-end

At the moment, trying to develop a searchable front-end is a problem for me. Querying Orthanc through DICOM from another server is fast, but my attempts at using the REST with PHP take about 40 seconds to run through 2000+ patients (grabbing name, ID, modality, study date), which is too slow. Which led me to try to query the SQLite3 index file through PHP - although I fear that this may be a way definitely corrupt it (?). I'm hoping that once Postgres is available, I'll be able to write something in PHP to query Postgres. (Alternatively, one of the suggested upgrades which is still pending was to allow "searchable" queries through REST.) (Alternatively again, a searchable GUI plug-in would be immensely helpful as well. :)

Non-Issue #3: Viewers

As for DICOM viewers, Cornerstone works well with Orthanc. Also, somewhere in this forum, I managed to build a Weasis connector to Orthanc without WADO (although I fear that with the REST API available to everybody on the network, it may be a problem?). I wrote a webviewer (for learning purposes) which uses PHP as a bridge between Orthanc and the user, so REST is not available to remote users, but at the moment, it's extremely buggy and doesn't really do much. 

Humbly yours,

Emsy

p.s. Orthanc is amazing, though: My latest headache came when my angiography machine finally died, so we had to use a C-Arm fluoroscope which was not configured for PACS at all! (Being the 3rd-world [3rd-rate] country I'm in, the nephrologist who lent us the C-Arm did not see the need for PACS connectivity. WTF?!!!). I used Orthanc to DICOMize the BMP files the C-Arm was pumping out so that they could be exported into my hospital PACS.

[Sébastien Jodogne]

Dear all,

I have deliberately chosen not to dive into this discussion thread for several days, to prevent any interference with my own views as the original author of Orthanc.

First of all, Max, please apologize my "hot" reaction about your initial post. All the subsequent reactions were highly interesting for us to understand your expectations about the future of Orthanc.

A. Lessons Learned

Let me summarize the lessons I personally draw from this thread. Following Emsy's posts, I am even more convinced that SQLite is the right DBMS for out-of-the-box usage (e.g. for QA, for dose monitoring, for auto-routing, or as an ancillary PACS). In its current form, Orthanc is indeed very well suited for people with basic IT background: Doctors, technologists or medical physicists can easily play with the software, successfully enough to solve their fine-grained imaging problems. This is not surprising, since it is precisely the set of use cases that triggered the development of Orthanc.

As a natural consequence, the managers responsible of the IT architectures in the hospitals are then requested by the end users to put Orthanc into production. And, admittedly, SQLite is clearly not designed for that purpose because of its lack of scalability and reliability. Orthanc cannot currently be used to archive medical images, it must stay a complement to a PACS/VNA system. Max's posts allowed me to understand that the expectations are very high for a scalable vendor neutral archive (VNA) system, that is based upon open-source technologies to prevent lock-in/lock-out. According to both Emsy and Max, the frustration is high with Orthanc because it contains most of the features of a VNA, but it does not feature a simple "switch" in its configuration file to enable enterprise-ready tasks by choosing a different DB back-end.

In a nutshell, Orthanc requires bindings to other DBMS. As already announced, we are accordingly working on an experimental PostgreSQL back-end. This development will be as generic as possible, to allow bindings to other scalable database engines such as Oracle, MySQL or MongoDB. Please be patient, as this task is highly non-trivial. Emsy, to answer your original post, this will allow Orthanc to scale up to handle a moderately-sized, yet large-sized hospital.

The second lesson I draw is the high interest for an incarnation of Orthanc in the cloud. This is quite unexpected to me, and I still have to better understand your use cases to see how Orthanc can help you. Do not hesitate to write a mail (in...@orthanc-server.com) with your use cases: Perhaps they could ignite a sister project to Orthanc for the cloud.

B. Inquiries by Celerity

(1) HIPAA compliance. Sorry, I have no information on this topic, as I work in Europe. Any tip would be greatly appreciated (in...@orthanc-server.com).

(2.a) Database schema. It is readily available as a SQL file in the source distribution of Orthanc:

https://code.google.com/p/orthanc/source/browse/OrthancServer/PrepareDatabase.sql

Max talked about phpLiteAdmin (https://code.google.com/p/phpliteadmin/) if you want to explore the content of the SQLite index. Personally, I use sqlitebrowser during the development (http://sqlitebrowser.org/).

(2.b) Orthanc architecture. Sorry, this is ongoing work. We have internal documents, but they are draft and not ready for publishing.

(3) Cloud support. See above.

(4) Image viewers and reporting tools.

• As pointed out by Max, Orthanc provides a very generic support of DICOM, so that any DICOM-aware tool should be able to connect to Orthanc.
• Concretely, the following viewers are notably known to work in conjunction with Orthanc: OsiriX, 3DSlicer, Ginkgo CADx, Tudor for ImageJ, and medInria.
• Max also talked about DWV. Yves Martel has developed a plugin for Orthanc (https://github.com/ivmartel/DwvExplorer).
• Depending on your needs, you may also find an interest in our ImageJ plugin (http://orthanc-imagej.googlecode.com/).
• Finally, we are also working hard on a Web viewer based upon Cornerstone. An early preview is available (https://www.youtube.com/watch?v=r2XD35OOCco).
  

C. Inquiries by Emsy

(1) Back-end database. See above.

(2) Front-end. As written by Max, never open the SQLite index from a separate software (such as PHP) while Orthanc is running. You should instead use the REST API (even when PostgreSQL will be available). You could greatly boost your performance by creating an Orthanc plugin that would be responsible for caching and aggregating information about all your patients, so that it is available with a single REST call. 

Thanks to all of you for such a dynamic feedback!

HTH,

Sébastien-

[shufflet...@gmail.com]

This is really good information here. I am looking to setup a clinic as well and was really hoping to use Orthanc.

The office is much smaller than what you are dealing with. I am a bit concerned though regarding the SQL talk and reliability so I wanted to post this to see if I would be ok running Orthanc vanilla install.

The office has around 15 employees. It has one Siemens Acuson Sequoia device. I have a dedicated raid 5 server that would run Orthanc. They use the machine for about 5 patients a day. I was planning on running a nightly service to stop Orthanc, backup data directory and index files, and then restart Orthanc for backup purposes. I was going to use the standard remote web browser interface for them to login to the server. No more than 5 people at a time.

I am guessing this is more than adequate for my uses with this office? Or should I be making some changes from the standard install or adding plugins? I am very IT savvy, however this is my first dip into DICOM so I want to make sure I am not setting this up only to have a "gotcha" bit me in the a__ a couple months down the line. Thanks in advance for any advice.

[Toshko Andreev]

I've been using Orthanc for a couple of weeks now and it runs very well. In my setup I've installed the PostgreSQL plugin, WADO plugin, and WebViewer plugin. The only problem I had was with Orthanc loosing connection to Postgres but that got fixed by enabling keep alive in the postgres config file. Security is not the best as its only got basic auth but if your users VPN into your hospital and then use the builtin webpage (Orthanc Explorer) it should be good enough, I would not recommend opening up Orthanc to outside connections.

You can setup your Orthanc to use PostgreSQL only for the index and store the actual DICOM images to your RAID5 server (map it as a drive on the host machine). 

[Sébastien Jodogne]

As a complement to the previous answer about security, you might be interested in reading the following FAQ entry:

https://orthanc.chu.ulg.ac.be/book/faq/https.html