Is Orthanc Server QIDO-RS, WADO-RS and STOR-RS conformed?

[Celerity Abbottt]

I have a question about whether Orthanc Server is in conformance with DICOM web standards.  These standards are:

QIDO-RS: http://medical.nema.org/dicom/2013/output/chtml/part18/sect_6.7.html

WADO-RS: http://medical.nema.org/dicom/2013/output/chtml/part18/sect_6.5.html

STOR-RS: http://medical.nema.org/dicom/2013/output/chtml/part18/sect_6.6.html

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?

[Sébastien Jodogne]

Hello,

Thanks for your interest!

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

[Celerity Abbottt]

To implement QIDO-RS/WADO-RS/STOW-RS plugins in Orthanc Server:

1). Could it be built from the existing custom RESTful 'module'?

2). What would be your estimates of the effort for implementing QIDO-RS/WADO-RS/STOW-RS plugins?  

[Sébastien Jodogne]

Hello,

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

Sébastien-

[Celerity Abbottt]

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. 

[Ravindran Padmanabhan]

Hello Jodogne and Abbottt,

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. 

Please let me know your interest levels. 

with regards

Rady

[Ravindran Padmanabhan]

Hello Jodogne and Abbottt,

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. 

Please let me know your interest levels. 

with regards

Rady

On Thursday, January 22, 2015 at 4:01:08 AM UTC+5:30, Celerity Abbottt wrote:

[Sébastien Jodogne]

Dear Rady,

Thanks for your motivation!

As a starting point, I would suggest you to read the following CodeProject article that explains how to create an Orthanc plugin:

http://www.codeproject.com/Articles/797118/Implementing-a-WADO-Server-using-Orthanc

Please note that plugins have to be written either in C or in C++.

You can find other examples of plugins at the following locations:

https://code.google.com/p/orthanc/source/browse/#hg%2FPlugins%2FSamples

https://github.com/jodogne/OrthancContributed/tree/master/Plugins

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.

Let me know if you need further information.

Regards,

Sébastien-

[Celerity Abbottt]

Hi Rady:

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!

[Celerity Abbottt]

Hi Rady:

Did you get a chance to look into this issue?  Anything that you might need help with?

Best,

[Ravindran Padmanabhan]

Hello Jodogne and Abbottt,

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. 

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

2. The Basic could map the current RestApi exposed by Orthance and build an additional WebApi Service that would interact with Orthance RestApi.

Need your inputs..

with regards

Rady

Rady (Ravindran Padmanabhan)

CTO of Innowave Healthcare

Mob    : +919790974930

e-mail : ra...@innowave.in

Skype : radyworks

[Celerity Abbottt]

Hi Rady:

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?

Best,

[Celerity Abbottt]

Hi Rady:

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.

On Wed, Feb 11, 2015 at 10:10 PM, Ravindran Padmanabhan <ra...@innowave.in> wrote:

Hello Abbottt,

Just read about the recent release of DICOM 2015 standards, in that I understand the WADO Restful final text is made available the other two services are still in WIP. So we are on safe wicket. 

Since this is a social contribution, I have limited time to my involvement. This month the weekends are completely tieup with out door activities like Hill Run and Trekking. 

On commercial aspect I had checked with the team (that is the reason for the delay), the indication I have received from the team, it is min around two man month of efforts and charge 20 USD per man hour. This is their initial estimate. Based on the final scope and requirements this could change. 

We need more clarity as well on your requirement, you please let me know if there is a possibility of a skype call with you. 

With regards. 

Rady

[Sébastien Jodogne]

Dear Celerity,

Dear Luke,

I am pleased to inform you that I will give a talk at Hacking Health Camp about DICOM Web Services on March 20th:

http://hackinghealth.camp/health-data-day.html

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.

Sébastien-

[Celerity Abbottt]

Hi Sébastien:

That sounded great! 

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.

Look forward to the first release!

[Sébastien Jodogne]

Fine, thank for your feedback and support!

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.

[Celerity Abbottt]

Hi Sébastien:

About funding for trips promoting Orthanc: What about crowd sourcing?   What can Orthanc offer to attract, say, $3,000usd, from the crowd? 

(I for sure will "invest".)

[Sébastien Jodogne]

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.

[Celerity Abbottt]

I see.  Well, "Build, they will come."  Keep building.

[Celerity Abbottt]

Hi Sébastien:

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?

Best regards.

 

On Friday, February 13, 2015 at 1:41:21 AM UTC-8, Sébastien Jodogne wrote:

Dear Celerity,

[Sébastien Jodogne]

Hi,

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?

The implementation work has started. I will first focus on the most common features of DICOMWeb, then extend it in subsequent releases to cover more of the full spec.

An initial public release is scheduled around April.

 

Also, would the new Orthanc web viewer have an option to choose to use the DICOMWeb protocola?

This is not planned, as the Orthanc Web viewer is built upon the Orthanc plugin framework (in other words, the viewer takes advantage of primitives that are provided by the core of Orthanc). However, another plugin could be developed to download images from DICOMWeb servers into Orthanc, so that the Web viewer plugin could be used.

Sébastien-

[Celerity Abbottt]

On Mon, Mar 9, 2015 at 5:27 AM, Sébastien Jodogne <s.jo...@gmail.com> wrote:

The implementation work has started. I will first focus on the most common features of DICOMWeb, then extend it in subsequent releases to cover more of the full spec.

An initial public release is scheduled around April.

 

Sounds good.  Look forward to it.

 

[Sébastien Jodogne]

Hi,

As promised, I have just released an open-source, reference implementation of QIDO-RS, WADO-RS and STOW-RS.

The source code of the plugin is now available for download under the GNU Affero General Public License (AGPL) license at the following location:

https://bitbucket.org/sjodogne/orthanc-dicomweb/

This work is still in progress, and does not fully cover the spec yet (cf. the "Status.txt" file of the source distribution). There are also probably misinterpretations of the standard that will have to be subsequently fixed.

Please also note that, as I attend LibrePlanet 2015 as a speaker, I will not be able to fix/improve this plugin before 10 days... but you can already enjoy it ;)

Sébastien-

[Celerity Abbottt]

Sounds great, Sebastien.  Will give it try shortly.

[Celerity Abbottt]

Hi Sébastien:

I saw there are some py samples for stow and wado in the repository.  Would you also have some samples for qido as well?  (Would be great if the samples are in JS. :)

Thanks.

[Sébastien Jodogne]

Hi,

Just added a sample JavaScript/jQuery application that makes a QIDO-RS request "SearchForSeries":

https://bitbucket.org/sjodogne/orthanc-dicomweb/src/8e7bc8bf874de1f286eaa951c8c9b1b8a8bda23f/Samples/JavaScript/?at=default

Providing WADO-RS and STOW-RS will require to encode and decode "multipart/related" messages. According to many posts on StackOverflow, this does not seem to be part of the jQuery core. Maybe the following plugin might help:

https://github.com/getify/mpAjax

I cannot help further for the moment, but please have a look and share your achievements!

Sébastien-

PS: The code of the plugin has been improved with encoding support (all the JSON/XML responses are now properly encoded using UTF-8).

[Sébastien Jodogne]

Finally, I had success quicker than expected with STOW-RS and JavaScript. I share the sample here:

https://bitbucket.org/sjodogne/orthanc-dicomweb/src/3ec1e035c84f7b13897c50da73653ebcf5d33f1a/Samples/JavaScript/stow-rs.js?at=default

Sébastien-

[Celerity Abbottt]

Great, awesome!

[Chris Hafey]

Hi Sebastian,

I just checked the source and it doesn't look like the WADO-RS RS-RetrieveMetadata endpoint is supported yet (/metadata).  This endpoint is really powerful for viewer based applications and it would be great to see it added (especially if it supported the application/json content type). Any chance of this happening in the short term? 

Chris

[Sébastien Jodogne]

Hi Chris,

Clearly, RS-RetrieveMetadata is a must.

It is not implemented yet, simply by lack of time, but it is on the top of my roadmap.

I should be able to work on it within about 3 weeks.

Sébastien-

[Chris Hafey]

Great!  I stared a github repo to track the status of various dicomWeb implementations, feel free to submit pull requests with updated info about orthanc (or others):

https://github.com/chafey/dicomWeb

[Sébastien Jodogne]

Fine! This is a really useful initiative :)

Just a remark about our licensing scheme: The Orthanc DICOMweb plugin is licensed under AGPL.

Sébastien-

[Celerity Abbottt]

Hi Chris, Sebastian,

Great idea to track DicomWeb.  Not clear what the state of art is.

I heard dcm4chee now has support to DicomWeb protocols, though I haven't got any time to look -- too much traveling and other stuff in the last few weeks.  Hope get back to this soon.

Cheers.

[Chris Hafey]

Hi Sébastien,

Just checking in to see where RS-RetrieveMetadata is at.  I do plan to highlight Orthanc at my SIIM Learning Lab and it would be great to show it working with WADO-RS RetrieveMetadata!

Chris

On Friday, April 10, 2015 at 9:10:55 AM UTC-5, Sébastien Jodogne wrote:

[Sébastien Jodogne]

Hi Chris,

The aforementioned 3 weeks have just passed, so I will start working on this feature as promised during this week ;)

Sébastien-

[Chris Hafey]

Awesome!  Feel free to use my DICOMToFHIRImagingStudy program which uses WADO-RS RetrieveMetadata to help test it out:

Code:

https://github.com/chafey/DICOMToFHIRImagingStudy

Live App:

http://chafey.github.io/DICOMToFHIRImagingStudy/

It isn't a complete test but it is better than nothing.

Chris

[Celerity Abbottt]

Chris:

From your excellent SIIM enabling enterprise imaging presentation last week, you mentioned that one of the keys is for an imaging application / app to create, save, retrieve and display DICOM presentation states of an image or a series of images.  How are these covered by DicomWeb specifically?  I'd guess it would be super useful if Orthanc-Server's DicomWeb implementation be able to support them.

 

[Chris Hafey]

DICOM PR, KO and SR each have their own SOP Class and are stored as individual SOP Instances in the same study as the images they refer to.  So you can CSTORE, CFIND and CMOVE them using DIMSE and you can also QIDO-RS, WADO-RS and STOW-RS them too.  I am pretty sure Orthanc already supports these SOP Classes so it should just work.  The viewer will have to parse the PR and apply it to the image though - this is something I hope to do before SIIM (or perhaps at SIIM if I can't find the time).  Note that ClearCanvas supports creation of PR and KO so you can download that and play with it if you like.  I used CC to create some PR and KO instances for one of the studies in the SIIM dataset, it works great.

Chris

[Sébastien Jodogne]

Hi Chris,

I have just pushed initial support of WADO-RS RetrieveMetadata inside the Orthanc DICOMweb plugin.

The good news is that your DICOMToFHIRImagingStudy software can connect to Orthanc without any problem, and that the corresponding FHIR data is correctly generated! All of this looks very promising :)

Sébastien-

[Chris Hafey]

Hi Sébastien,

Just tried this out and noticed the following:

1) The value for Pixel data 7FE00010 is being returned as a string.  The string doesn't look like valid base64 so I think it might be a bug.  I believe you are supposed to return the pixel data as a bulk data item.  Note that DCM4CHEE omits it completely so I might be wrong here.

2) The VR for pixel data 7FE00010 is listed as "OB or OW" which is not a valid value - needs to be either OB or OW. 

3) Several of the elements returned have a vr of "??" which is also not valid. I think you need to use "UN" for unknown or perhaps add a config flag to omit them if unknown.  I also believe you do a binary inline for UN values (or perhaps bulk item if it is too large)

My ultimate goal is to not use WADO-URI and I can do this once you implement WADO-RS RetrieveFrames.  Any idea on when that might be done?

Chris

[Chris Hafey]

Also, I noticed that several elements are incorrectly being returned as bulk data items in WADO-RS and QIDO-RS responses.  Specifically Rows, Columns, Bits Allocated, High Bit and Retrieve URL.

Chris

[Sébastien Jodogne]

Hi Chris,

I have pushed several changelists that should fix all the problems you have reported.

I would love to hear your feedback about these fixes: Do they solve your problems?

Regarding the WADO-RS "RetrieveFrames", this is certainly on my roadmap for June. However, my priority is now to implement C-Move SCU and to subsequently release Orthanc 0.9.0.

Sébastien-

[Sébastien Jodogne]

Hi Chris,

My ultimate goal is to not use WADO-URI and I can do this once you implement WADO-RS RetrieveFrames.  Any idea on when that might be done?

WADO-RS RetrieveFrames is implemented in the version 0.2 of the DICOMweb plugin that has just been published:

http://www.orthanc-server.com/browse.php?path=/plugin-dicom-web

HTH,

Sébastien-

[Chris Hafey]

Awesome!!  I'll see if I can test it out in the coming weeks (I already added initial support for it to the OHIF Viewer and cornerstone but haven't had a server implementation to test with yet!)

[Sébastien Jodogne]

Great! Let me know if you face issues... because on my side, I've no viewer to test against, this is kind of chicken-and-egg problem :)

[delink]

Hi,

For some few days now i have struggled with the store of dicom files in orthanc using the dicom-web.

i have tried the example provided here https://bitbucket.org/sjodogne/orthanc-dicomweb/src/3ec1e035c84f7b13897c50da73653ebcf5d33f1a/Samples/JavaScript/stow-rs.js?at=default&fileviewer=file-view-default, it works fine. But when i implement the same on an angular app i get 

{

   "HttpError" : "Bad Request",

   "HttpStatus" : 400,

   "Message" : "Bad file format",

   "Method" : "POST",

   "OrthancError" : "Bad file format",

   "OrthancStatus" : 15,

   "Uri" : "/dicom-web/studies"

}

The same file uploads fine using the jQuery sample.

Seems like the encoding of the file after the Unit8Array is not right, how do i convert to the right format?

[Sébastien Jodogne]

Hello,

I'm not an angular developer, so I can't provide any support.

Furthermore, you should share source code for other people to be able to help you.

Regards,

Sébastien-

PS: Make sure to use the just-released 0.5 version of the DICOMweb plugin.

[delink]

Below is a sample code in anguar, which returns a Bad file Format

private apiUrl = environment.pacs_servers[0].apiUrl;

BOUNDARY = 'MESSAGEBOUNDARY';

storeStudies(image): Promise<any> { // the passed parameter is in bufferArray

  return new Promise((resolve, reject) => {

    // construct Multipart

    let body = this.constructMultipart(image, 'application/dicom');

    

    var convertedBody = this.convertUint8ArrayToBinaryString(body)

    const headers = {

     'Accept': 'application/json',

     'Content-Type': 'multipart/related; type=application/dicom; boundary=' + this.BOUNDARY

    };

    // post to the api

    this.http.post(this.apiUrl + 'studies', convertedBody, { headers: headers, responseType: 'json' }).subscribe((res) => {

      console.log('saved', res);

      let count = res['00081199'].Value.length;

      console.log('Upload was a success! ' + count + ' instance was uploaded.');

      resolve(res)

    }), (err: HttpErrorResponse) => {

      console.log('error with http post', err)

      reject(err)

    };

  });

}

convertUint8ArrayToBinaryString(u8Array) {

  var i, len = u8Array.length, b_str = "";

  for (i=0; i<len; i++) {

    b_str += String.fromCharCode(u8Array[i]);

  }

  return b_str;

}

stringToArrayBuffer(str) {

  // http://updates.html5rocks.com/2012/06/How-to-convert-ArrayBuffer-to-and-from-String

  let bufView = new Uint8Array(str.length);

  for (let i = 0, strLen = str.length; i < strLen; i++) {

    bufView[i] = str.charCodeAt(i);

  }

  return bufView;

}

constructMultipart(body, contentType) {

  let headerStr = '--' + this.BOUNDARY + '\r\nContent-Type: ' + contentType + '\r\n\r\n';

  let trailerStr = '\r\n--' + this.BOUNDARY + '--\r\n';

  let header = this.stringToArrayBuffer(headerStr);

  let trailer = this.stringToArrayBuffer(trailerStr);

  // Concatenate the header, the body and the trailer

  // http://stackoverflow.com/a/14071518/881731

  let b = new Uint8Array(header.byteLength + body.byteLength + trailer.byteLength);

  b.set(header);

  b.set(new Uint8Array(body), header.byteLength);

  b.set(trailer, header.byteLength + body.byteLength);

  // console.log(b);

  // returns a Unit8Array

  return b;

}

[delink]

Figured out the problem

The function i used before to convert to convert to bufferArray didn't return the right format, here is a code that works for me to convert from Unit8Array to BufferArray:

// convert unit8Array back to buffer

const convertedBody = body.buffer;

[Manasa Manchale]

Hi,

I am trying to make stow-rs request to store an instance in orthnac. but i want to send json metadata not dicom file as it is. I could not find any solid example of  framing json metadata with jpeg body. Please help me with some example of sending stow-rs with json metadata.

Thanks

Manasa 

[Sébastien Jodogne]

As can be read in the "Status.txt" file, the DICOMweb plugin currently does not support STOW-RS with JSON metadata:

https://bitbucket.org/sjodogne/orthanc-dicomweb/src/default/Status.txt