Xnat and DICOMweb

[Jonas Scherer]

Hey everyone,

is there any news regarding DICOMweb support in near future?

regards,

Jonas

[Herrick, Rick]

Hi Jonas,

 

Right now we have a basic implementation that’s about 80-90% complete. The developer who’s working on that got pulled onto a critical-path development effort a couple months ago, so it hasn’t progressed much recently. He thinks there’s about 4 weeks of development effort to finish up, but when that 4 weeks will get done depends on when the other tasks he’s on clear up enough to give him the time to work on that!

 

-- 

Rick Herrick

Sr. Programmer/Analyst

Neuroinformatics Research Group

Washington University School of Medicine

Phone: +1 (314) 273-1645

--
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 https://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.

 

---

The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. 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.

[Jonas Scherer]

That sounds pretty good!
Thank you for the info

Best,
Jonas

[james...@gmail.com]

Just bumping this to see if there is any update on the timescale of this, and will it be core?

Kind regards,

James A. Petts

[Matt South]

I notice that Google's new healthcare API (https://cloud.google.com/healthcare/) supports dicomweb. 

M

[DavidMaffitt]

tldr; You can help by discussing your use cases!

I am curious about XNAT-user's use cases for DICOMWeb.  How do you typically munge incoming DICOM and what do you expect it to look like on the way out? I ask because "XNAT is not a PACS". There is not a one-to-one relationship between XNAT's data model and DICOM's data model. Nor should there be, but it introduces some conundrums that require careful thought to get an implementation that is coherent and useful between expectations in the two worlds.

For example, in XNAT, it is perfectly fine for PatientID in the DICOM to be different values for the same subject. In fact, it is common practice to set the value in this tag to the "session label" and XNAT will properly route it within XNAT's data model.  But, this leaves the DICOM broken from the point of view of a DICOM viewer. DICOMWeb allows one to search by PatientID (0010,0020). What does this mean in XNAT:  XNAT's subject ID?;  XNAT's subject label?; either XNAT's subjectID or subjectLabel?; the value in the (0010,0020) before XNAT munged it?; the value in (0010,0020) as currently stored in XNAT?  One can imagine use cases for each of these.

I would anticipate that a request made via DICOMWeb would not want "broken" DICOM to be returned. Thus, XNAT may need to munge the DICOM on the way out. But now the returned DICOM is not the DICOM stored in XNAT. What are the consequences of that?

In the long term, we want to move XNAT away from abusing DICOM.  In the short term, what do we do that is reasonable with the legacy data?  "Good-enough" answers to these questions are slowing down an implementation. (We are really good at debate).  You can help by providing your use cases so we are not just talking hypothetical situations.  Do you munge the DICOM on the way in for autorouting?  For other reasons?  What do you need the DICOM to look like when it is retrieved?

Thanks!  

Dave