I wonder if you’d evaluate Orthanc Sever’s Restful APIs against these standards, and if they are in conformance, then you can add it to Orthanc Server’s DICOM Conformance Statement. With DICOM conformance, Orthanc will have one more advantage over others.
By the way, there was a Hackathon at last year’s SIIM conference (SIIM 2014 Hackathon) where the ‘first’ uses of these standards were demonstrated. This year, SIIM will also holds SIIM Hackathon, and it also has a Open Source Plug Fest (http://siim.org/?15exh_ed_program). These events perhaps can greatly benefit Orthanc in the medical imaging community (in the U.S. at least).
In short, could you let us know if Orthanc Server is QIDO-RS, WADO-RS and STOR-RS conformed?
Out-of-the-box, Orthanc features a custom, ad-hoc REST API. This stems from the fact that the development of Orthanc began in 2011, at a time when QIDO-RS, WADO-RS and STOW-RS were not fully specified. Furthermore, one of our basic goals is to provide the most straightforward, easy-to-use implementation of an open DICOM server, so that the default REST API was itself designed as the most straightforward as possible.
That being said, it is clear that Orthanc is an ideal candidate to host a reference implementation of the standard DICOM RESTful services, as it provides all the required primitives in an open, standalone, cross-platform, lightweight framework. Accordingly, a task is recorded in our development roadmap since the end of 2012 (https://trello.com/c/JhrXqv3Z). This reference implementation could effectively be implemented as a set of plugins to Orthanc. Incidentally, a CodeProject article explains how to implement a basic WADO server as a plugin to Orthanc (http://goo.gl/Z3Pg7F): This article could be used as a starting point.
The only reason why QIDO-RS/WADO-RS/STOW-RS plugins have not been implemented by ourselves yet is that Orthanc does not benefit from any funding in Belgium. We thus currently have to focus our development team on the core features. Such development could certainly be achieved in the context of the “Open Source Plug Fest”, which is indeed an event in which Orthanc would be a nice fit! However, I cannot attend such an event by myself, because of the absence of traveling funds. Fortunately, thanks to the plugin SDK, I think that any interested developer familiar with C/C++ could succeed in implementing the DICOM RESTful services as Orthanc plugins. I would happily provide any required support.
Another option than the “Open Source Plug Fest” would be to start a crowdfunding campaign to raise funds to implement open-source DICOM RESTful services, so that I could hire an additional developer in my team. However, I need to know beforehand whether private companies or individuals would be interested to fund such a development. Could you tell me whether crowdfunding would make sense in this context?
Thanks again for your interest,
Sébastien-
PS: The DICOM conformance statement of Orthanc 0.8.5 is available (http://goo.gl/MMcAEY).
(1) Yes, the plugin SDK of Orthanc contains the required primitives to expand the default REST API of Orthanc with a custom REST API. In other words, the embedded Web server of Orthanc can host QIDO-RS, STOW-RS and WADO-RS without modifying the core of Orthanc.
(2) Hard to say without digging by myself in the technical details of the DICOM RESTful services, and without having a database of sample queries with full covering of the spec. There are a couple of examples (cf. F.2.1.1 in Part 18), but they are very sparse. As a rough guess, I would assume between 100 and 200 hours of work for each of the 3 parts (QIDO-RS, STOW-RS and WADO-RS).
I think Orthanc already has the same kind of functions as QIDO-RS, STOW-RS and WADO-RS, and the APIs kind of look similar. You are right - the trick is to have someone who is really familiar with QIDO-RS, STOW-RS and WADO-RS in particular to find the gaps between the standards and the Orthanc implementation. If you / Orthanc can first find out the gaps, it’d be easier to plan further.
I love to contribute to this topic, have great interest on DICOM/Orthance and would love to put my personal efforts to implement these 3 services. My C++ skills are rusted now more into .net and Javascript. If you can provide me directions, I would certainly would like to work on identifying the gaps and them implement a plugin that can work like a plugin.
I love to contribute to this topic, have great interest on DICOM/Orthance and would love to put my personal efforts to implement these 3 services. My C++ skills are rusted now more into .net and Javascript. If you can provide me directions, I would certainly would like to work on identifying the gaps and them implement a plugin that can work like a plugin.
As far as reading/writing XML is concerned, I would recommend you to use this C++ library that is already used by the core of Orthanc: http://pugixml.org/
Finally, the members of the DICOM WG-27 (working group 27) are responsible for the standardization of STOW-RQ/QIDO-RS/WADO-RS and may give you technical explanations if needed.
That’s great that you are very interested in this project. We can work together. My problem is the time – or lack thereof. I used to do a lot of C++ programming before, including using and working on dcmtk, but haven’t done C++ programming for a long while. Luckily, I am still in the medical imaging field, and have a good grasp on DICOM standards. Once you get a hang of implementing Orthanc plugins, Let’s connect, and let’s work on this together.
Realistically, how soon can you see if you can start implementing the Orthanc plugins? Once you can do that, we (you, Sébastien, me, and maybe even others) can figure out how long it will take to get these 3 DICOM standards RS APIs implemented. Could you let us know your timeframe?
Really look forward to getting this task off the ground!
Did a basic understanding on DicomWeb 2.0 Standards (QIDO-RS, WADO-RS and STOR-RS). Found that WebApi exposed by Orthance can be remapped to fix some basic requirements. These are my recommendations.
Lets role out in Phases, Basic and comprehensive support for DicomWeb compatibility. In the Basic we shall provide Upload of DICOM images (STOR-RS) in any format and Query/Retrieve (QIDO-RS, WADO-RS) them in the same format all via HTTP. In the Comprehensive mode we will try to support the rest of the parameters exposed by DICOM Standard.
The Basic could map the current RestApi exposed by Orthance and build an additional WebApi Service that would interact with Orthance RestApi.
Your plan sounded good. For implementing the basic Dicom Web support (QIDO-RS, WADO-RS and STOR-RS), do you have an estimate for how soon it will be implemented?
Great that you have looked into the latest DICOM standard. In your previous post, you proposed to divide the implementation into two phases: basic and comprehensive. A couple of questions:
1). How many man-hours for the basic implementation of the QIDO-RS, WADO-RS and STOR-RS?
What are entailed in the basic implementation?
It’d be helpful to break down the costs for each of 3 parts
2). Can your team show a working, sample Orthanc plugin that can be used as the base for the implementation?
As Sébastien mentioned earlier, there are a plugin sample and other materials. It should be very easy to get going by doing a sample plugin.
What are the software development skills does your team have? Are they experts in Microsoft stack?
We can use Google hangout to talk if you prefer. I am U.S. West, and should be available during normal hours. Look forward to hearing back from you.
In this context, I will shortly work on Orthanc plugins for QIDO-RS, STOW-RS, and WADO-RS. My idea is to provide a basic support of these 3 protocols as an illustration for my talk. I target a “pre-alpha” release for mid-March. You could then experiment with these plugins to provide me continuous feedback.
I will start this work on around February 25th, after the open-source Web viewer based upon Orthanc is released.
Adding just even basic support to QIDO-RS, WADO-RS and STOR-RS would attract substantial interests to Orthanc. One of the biggest attractions of dcm4chee was its claim of support of IHE. DicomWeb fits very well with what Orthanc is intended to do – it’d be very beneficial for Orthanc to claim it is in Dicom Web compliant.
Once you have a basic implementation, I will for sure use it – I know quite a few will use it, too. I’d also suggest you to take a closer look at the upcoming SIIM conference in Washington DC in April, as I sent the links previously. I think with the SIIM attendenc, Orthanc would get popular in the U.S.
Regarding the upcoming SIIM conference, I would of course like to attend it as it looks very great for Orthanc! But unfortunately, I do not have access to any funding for such a trip… well, to be fair, I do not even have funding for a trip outside Belgium. This is clearly a silly thing, but open-source is not supported at all in Wallonia.
Well, crowdfunding is unfortunately not easily applicable in my case for legal reasons.
I indeed develop Orthanc as an employee in a hospital, which implies that I legally cannot collect money deriving from my daily job for my personal convenience (which would result in a conflict of interest). Reciprocally, my hospital is not ready to launch a crowdfunding campaign in its own name as open-source development is not its core business. As a consequence, crowdfunding is sadly not an option for Orthanc.
I haven’t been around much lately, due to other projects. Hope you are in good progress with the DICOMWeb implementation. Any specific release date? Also, would the new Orthanc web viewer have an option to choose to use the DICOMWeb protocola?
