Orthanc on cloud!

[Mario Ceresa]

Dear Orthanc Group,

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?

Thanks and regards,

Mario


[1] http://simbiosys.upf.edu/
[2] http://aws.amazon.com/s3/

[Chris Hafey]

Why not use Amazon EBS?

http://aws.amazon.com/ebs/

[Erik Anderson]

On Thu, Aug 28, 2014 at 3:40 PM, Chris Hafey <cha...@gmail.com> wrote:
> Why not use Amazon EBS?
>
> http://aws.amazon.com/ebs/

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...

-Erik

[Mario Ceresa]

Thanks Chris, Erik for your mail: I'll try with EBS then!

Best,

Mario

[Sébastien Jodogne]

Dear all,

Thanks for this interesting discussion!

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:

https://trello.com/c/rN4lJUkH

With this modification, it will become possible to write user-contributed plugins to handle the file storage back-end (e.g. for Amazon S3).

Stay tuned,

Sébastien-

[Sébastien Jodogne]

It is now possible to replace the Orthanc default back-end for file storage, by a custom plugin. Here is a sample of this feature:

https://code.google.com/p/orthanc/source/browse/Plugins/Samples/StorageArea/Plugin.cpp

You could therefore develop a plugin to use Amazon S3 instead of the filesystem. Let me know if anyone has success in this task ;)

HTH,

Sébastien-

[agrot...@gmail.com]

Sébastien-

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?

I see this post on supporting Postgres (is that instead of SQLite?): https://twitter.com/OrthancServer/status/553648007020027904.

If I wanted to write my own index provider, potentially using REST calls rather than a local DB, is that possible?

-Alex

[Sébastien Jodogne]

Dear Alex,

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.

Regards,

Sébastien-

[celerit...@gmail.com]

Hi

1). Do you know anyone has developed a plugin for Amazon S3? Any other plugins for other clouds?

2). Is there a place to find Orthanc plugins?

Thanks,
Celerity

[Sébastien Jodogne]

Hello,

(1) I am not aware of any such initiatives so far, but the code of Orthanc is ready for that since release 0.8.3.

(2) The developers of Orthanc plugins are kindly invited to put a link in the "OrthancContributed" repository:

https://github.com/jodogne/OrthancContributed

Sébastien-

[Luke Huang]

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.)

[agrot...@gmail.com]

Sébastien-

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?

[A Ashton]

There are several concerns for cloud :

1 - the SQL Lite index to be replaced by Postgres to manage large volumes

2 - the adoption of Could FS such as a GS.

3 - the recent  HTTP Proxy Plugin 

[Sébastien Jodogne]

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.

[Sébastien Jodogne]

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.

[Celerity Abbottt]

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.)

Thank you.

[Sébastien Jodogne]

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.)

• By default, the TCP port for HTTP, including the REST API, is 8042 (cf. https://code.google.com/p/orthanc/wiki/OrthancConfiguration).
• By default, the TCP port for DICOM is 4242.
• Orthanc embeds Mongoose as its HTTP server (https://github.com/cesanta/mongoose).
• SSL configuration is explained in our FAQ (http://goo.gl/p9SB2d).

 

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.  [...] 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:

1. Create your own Web application above the REST API of Orthanc.
2. 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?  

Our roadmap is contained in 2 Trello boards:

• Our internal roadmap can be found at: https://trello.com/b/cjA9X1wM/orthanc-roadmap
• Orthanc users can suggest features at: https://trello.com/b/gcn33tDM/orthanc-requests (I must grant write access, as explained on the README card)

Regards,

Sébastien-

[jer...@gmail.com]

Hi!

I notice there is an AWS SDK for C++ since September 2015. That could make it easier to write an AWS database plugin for Orthanc.

The SDK includes Client-Side Data Encryption.

The code is open source and available on GitHub: https://github.com/aws/aws-sdk-cpp

Is anyone interested in giving it a try?

Jérôme Pinguet
https://freemedsoft.com

[Bill Clifford]

Hello Sébastien,

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).

Thanks for your help,

Bill

On Tuesday, September 9, 2014 at 7:50:52 AM UTC-7, Sébastien Jodogne wrote:

[Sébastien Jodogne]

Dear Bill,

Here is the new link to this sample plugin:

https://bitbucket.org/sjodogne/orthanc/src/default/Plugins/Samples/StorageArea/

Sharing a plugin for GCS would indeed be a great contribution!

HTH,

Sébastien-