I’ve seen impressive development in orthanc in the last months: congratulations especially to Sébastien!
I was interested in using it in the cloud (amazon aws, openstack etc…) so I could set up quick collaborations between physicians and our group here at university [1].
However, I’m unsure on which is the best way to configure the storage and the index in this case. With cloud providers you usually have buckets, not a proper filesystem [2]. This means that permanently storing dicoms on an compute instance is at best unreliable (image can disappear at any moment), tricky and expensive (you have to mantain the instance running or snapshot an evergrowing disk).
Do you think it is possible/advisable for Orthanc to operate storing on the filesystem only the index and not the images?
Yep, that's definitely the way to go. Mario, I think you may have been
thinking of the EC2 ephemeral volumes, which you surely do not want to
use for any data that can't be easily re-created.
That said, and S3-based file storage backend for Orthanc certainly
would be interesting...
That said, and S3-based file storage backend for Orthanc certainly would be interesting…
The modifications to support other file storage back-ends in Orthanc should be very limited. I have just added a task to abstract the “FileStorage” class, around which this back-end revolves:
I am dealing with a similar issues: being able to run Orthanc in the cloud. This plugin is great for being able to swap out the data store to use some sort of bucket system.
How feasible is to similarly use a plugin to swap out the index / DB?
Neither the plugin framework, nor the REST API enables to “outsource” the Orthanc index from SQLite to another database back-end.
We are indeed working on an “enterprise-ready” version of Orthanc that would take advantage of PostgreSQL instead of SQLite to store/index large amount of DICOM images (with scalability, replication, load-balancing, backup)… This would bring Orthanc even closer to a full-featured Vendor Neutral Archive (VNA) for medical imaging.
This development is still experimental. Expect more news on that topic in the next few weeks.
It’d be very interesting to have Orthanc Server run on those ‘Managed Servers’ in Google/Microsoft/Amazon clouds. We may try that.
Would port assignment be a problem? Would it be OK to just use port 443 or 8000? Any other potential issues that you may perceive?
(Better audits for image access and upload perhaps would be a requirement for a clinical operating production environment. So is end user access control. But those are not really a big big issue for tests and prototypes. Thought just share these concerns a bit here.)
Would port assignment be a problem? Would it be OK to just use port 443 or 8000? Any other potential issues that you may perceive?
Technically, as far as the SQLite back-end as well as storing DICOM instances directly on the filesystem is OK, then Orthanc can be deployed in any virtual machine framework that supports Windows or Linux. This should for instance apply to Microsoft Azure, Amazon EC2, or Google Cloud Platform.
Port number should not be an issue (the HTTP interface of Orthanc can be set to listen on port 80). The only problem I can imagine is that the cloud framework could block the DICOM protocol with their firewalls. In such a case, the REST API of Orthanc could be used as a fallback.
Obviously, do not use Orthanc directly as a cloud front-end to store sensitive or patient data. As you pointed out, its lightweight architecture is not focused on audit, security and user management: Such features must be implemented at a higher level.
Once the work for Postgres is merged, how swappable is the index backend?
ie would it be hard to use a set of REST calls rather than a traditional relational DB as index?
Once the PostgreSQL implementation is merged, it will be possible to derive from an abstract C++ class (i.e. a pure interface) to define new back-ends. It will certainly be possible to define a back-end that takes advantage of a REST system (or, similarly, of a NoSQL engine).
However, please note that the database schema of Orthanc is subject to changes with every release of Orthanc. The C++ interface for the index back-ends will thus evolve. This is notably why we do not plan to release a plugin SDK to replace the back-end in a generic way.
Sounds very good. I think I will try it on both Azure and Google.
I have two requests:
1). Ports:
Could you elaborate on the port assignments? Is 8084 the default port for everything? What are other ports that are used? (e.g. for DICOM communications.) What web server is Orthanc using? (and how to configure SSL for the web server.)
2). Basic Security:
I would also like to make is for Orthanc to implement User Access Control (roles, user, group) and to implement Audit Control (track access to patient, study). As it stores DICOM images, Orthanc Server should act as a Security Node. IHE Security and Privacy would be good model.
(Is there a Roadmap / backlog for Orthanc features? I think you should put high priority on User Access Control and Audit Control, as once they are implemented, Orthanc will find more users who will be comfortable to use it in more ‘enterprise’ and clinical environments.)
Sounds very good. I think I will try it on both Azure and Google.
I would be glad to hear about your experience on this topic
I have two requests:
1). Ports:
Could you elaborate on the port assignments? Is 8084 the default port for everything? What are other ports that are used? (e.g. for DICOM communications.) What web server is Orthanc using? (and how to configure SSL for the web server.)
I would also like to make is for Orthanc to implement User Access Control (roles, user, group) and to implement Audit Control (track access to patient, study). As it stores DICOM images, Orthanc Server should act as a Security Node. IHE Security and Privacy would be good model. […] I think you should put high priority on User Access Control and Audit Control, as once they are implemented, Orthanc will find more users who will be comfortable to use it in more ‘enterprise’ and clinical environments.
You currently have 2 options to implement security or to monitor access:
Create your own Web application above the REST API of Orthanc.
Implement a “security plugin” to Orthanc. The trick is to override the entire default REST API of Orthanc by a single REST callback that would implement access control&monitoring, and that would forward the call to the default REST API of Orthanc if access is granted.
As explained in the other active thread (“Orthanc as a Hospital PACS?”), our initial goal was not to support enterprise environments. But, furthermore, Orthanc was not initially thought of as a front-end component: It is currently designed to work as a back-end DICOM server, with only administrative access.
Once Orthanc supports PostgreSQL, I think we should start a separate “front-end” project (similar to a PACS system) that would provide end users with an interface to the “back-end” project (the Orthanc VNA). User management (e.g. with LDAP) should be a responsibility of the front-end interface, letting Orthanc focus on the DICOM jobs. I think that this would make perfect sense according to the recent “deconstructed PACS” philosophy (cf. http://goo.gl/kJwL82).
Is there a Roadmap / backlog for Orthanc features?
Your post of 9/9/2014 references a sample backend file storage plugin, but that link no longer works, orthanc having moved from Google Code. Is that sample plugin available elsewhere? I have looked on github without success.
I’m interested in maintaining dicom files on Google Cloud Storage (GCS).
