Using GDCM as a SCU for XNAT's C-STORE

[Antonio Rueda]

I'm using GDCM (Win 7) as a SCU, I want to use its C-FIND, and C-STORE operations. I want to write a DICOM client in C++ that uses XNAT as its PACS. 

I enabled the DICOM Receiver option in XNAT's administration module (this is a local dummy installation). 

An echo request written as:

gdcmscu --echo -H http://127.0.0.1:8080/xnat --aetitle XNAT -p 8104

outputs nothing. Not even a cmd error message. Why?

Acually, all of these parameters produce the same behavior:

     --patientroot       C-FIND Patient Root Model.

     --studyroot         C-FIND Study Root Model.

     --patient           C-FIND Query on Patient Info (cannot be used with --studyroot).

     --study             C-FIND Query on Study Info.

     --series            C-FIND Query on Series Info.

     --image             C-FIND Query on Image Info.

     --key   %d,%d[=%s]  0123,4567=VALUE for specifying search criteria (wildcard allowed)

                         With --key, leave blank (ie, --key 10,20="" or --key 10,20) to retrieve values 

Am I missing something in the gdcmscu specification?

[Archie, Kevin]

Hi, Antonio,

I 'll start with a conceptual point: XNAT really isn't a PACS. We have some interoperability with DICOM, but DICOM isn't in any sense a native format. XNAT has a C-STORE SCP, but pretty much the first thing it does when it receives the files is translate the DICOM metadata to XNAT before stowing away the DICOM objects as blobs. There's no other intrinsic DICOM functionality -- there is an external application, XNAT Gateway, that builds a C-FIND SCP wrapper around an XNAT, but it's a little fussy because of all the DICOM-to-XNAT-and-back-again conversions that happen along the way.

WADO is one of the many DICOM things we don't support, so you can't do HTTP-based DICOM against an XNAT. The closest match: we do support MIRC/RSNA FileSender-style HTTP C-STORE-ish operations. I would say that we're unlikely to support WADO any time in the future, mostly because the protocol hasn't been widely enough adopted to create important use cases for us. Of course we'd be happy to offer advice to anyone in the community who wanted to implement WADO for XNAT.

 - Kevin

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To post to this group, send email to xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.

---

The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

[Antonio Rueda]

Hi Kevin,

So, I'd have to use XNATGateway to query XNAT from GDCM or DCMTK? 

I noticed this project uses a DCMTK + XNATGateway combination. http://nrg.wustl.edu/software/jaat/

--
You received this message because you are subscribed to a topic in the Google Groups "xnat_discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/xnat_discussion/7yAYzp-dYag/unsubscribe.
To unsubscribe from this group and all its topics, send an email to xnat_discussi...@googlegroups.com.

[Archie, Kevin]

Using XNAT Gateway would probably be the quickest way to get going if you're building DICOM SCUs. I think that Gateway also does not speak WADO, so you'll need to do your C-FIND/C-MOVE as DIMSE.

  - Kevin

[Antonio Rueda]

Hmm.. I'm thinking about the feasibility of my current project: setting up an instance of XNAT in Amazon EC2 to use as a PACS server. 

Would I be able to query it via XNATGateway using DCMTK or GDCM as the SCU? Or would I need to use XNATRestCliient or curl? 

[Archie, Kevin]

I think it would depend on the details of what you want your application to look like. If you're looking for a pure DICOM workflow -- if, for example, the various instance UIDs are really the natural way for you to refer to data objects --  then you might want to use a PACS like dcm4chee instead of XNAT. If you want non-DICOM data as first-class objects in your system, or if the natural object identifiers for your workflow are human-readable subject and session labels rather than UIDs, then XNAT may be a better fit.

If it does make sense for you to use XNAT, and you're going to be writing your own client programs, it will be much easier and more robust to use the XNAT REST API than DIMSE and XNAT Gateway. (The one possible exception is pushing DICOM objects into XNAT, which is often most easily done via C-STORE, unless the SCU and SCP are in different locations, in which case C-STORE like all the DIMSE services is a complete disaster. CTP and the MIRC-style XNAT HTTP receiver work pretty well for that case.)

In short: if you tell us a little more about how you see the whole system working, we can probably offer more concrete advice.

 - Kevin

[Antonio Rueda]

If it does make sense for you to use XNAT, and you're going to be writing your own client programs, it will be much easier and more robust to use the XNAT REST API than DIMSE and XNAT Gateway. (The one possible exception is pushing DICOM objects into XNAT, which is often most easily done via C-STORE, unless the SCU and SCP are in different locations, in which case C-STORE like all the DIMSE services is a complete disaster. CTP and the MIRC-style XNAT HTTP receiver work pretty well for that case.)

Well, yeah, I'd be using XNAT (or another PACS) to push *solely* DICOM objects (DICOMDIR of image files, Secondary Captures and Structured Reports / Encapsulated pdfs) in a setting where the SCU and the SCP are in different locations (XNAT would be in Amazon EC2), the SCU would be a custom client application written in C++ and C#. 

Would the XNAT REST API be suitable for this task?

[Herrick, Rick]

Hey Antonio,

 

Kevin and I were just discussing your question this morning. One thing I think Kevin and I are both pretty certain about is that you do NOT want to use DICOM composite operations to manage transfers between a server up on EC2 and some endpoint somewhere. For long-haul transfers, DICOM is just terrible, with no validation of transfer integrity, little error messaging, etc.

 

WADO *may* do what you want if you can find a decent implementation, but dcm4chee is pretty old stuff and isn’t even written using dcm4che2. I’m not familiar with GDCM other than knowing that it exists. I am familiar with DCMTK, but only as a set of command-line tools. Others in the discussion group may have a better idea than I do of PACS with WADO implementations that are available out there.

 

It does sound like XNAT would do a lot of the things that you want, with a couple caveats:

 

·         Like Kevin said, XNAT runs a DICOM SCP receiver that handles C-STORE operations. The problem with it is the same as above: it’s great when you’re transferring data a short way, e.g. we run multiple receivers on our CNDA installation that takes in data from scanners downstairs where research subjects come in for scans. But without something in the middle to manage the traffic across the internet, you are guaranteed a certain amount of data loss trying to do C-STORE operations there.

·         XNAT does not currently support C-FIND and C-MOVE operations to transfer data to or from other PACS (I’m actually working on this right now for an operational deployment of XNAT called TIP; these functions will be available as a module sometime in the near future and standard in XNAT in the 1.7 release).

 

The XNAT REST API should actually fulfill a lot of your requirements though. Basically deploy an XNAT onto an EC2 server, start it up, then start pushing data via the XNAT upload applet (which itself uses the REST API) or via a script utilizing curl or the XNAT data client (the XNAT REST client works but is deprecated). You can also use C++ to make the REST calls, either with standard networking libraries or some pre-packaged REST client library. You can do just about anything in XNAT with the REST API, including importing, retrieving, and querying your data.

 

I’d recommend having a look at the XNAT developer documentation for a start:

 

https://wiki.xnat.org/display/XNAT16/Home

 

Let me know if you have any particular questions.

 

Rick Herrick

Sr. Programmer/Analyst

Neuroinformatics Research Group

Washington University School of Medicine

(314) 827-4250

[Antonio Rueda]

Hey Rick, thanks to you and Kevin for your thoughtful response, you've saved me a lot of time. 

I'm not actually *tied* to C++ in the client app (which is actually just a bunch of download/upload functionality to be called from a C# visualization app)  a  and I've been looking into using pyxnat to consume your REST API functionality.I think I'll go that way.  

[Antonio Rueda]

* with something like this: http://stackoverflow.com/questions/11779143/run-a-python-script-from-c-sharp