Custom Variables at SCAN Level

[David Gutman]

So I am in the process of cleaning up a very heterogeneous data set...
and am remapping the scan_ID's to a more standardized naming
convention.... for example I have PRE/POST Gadolinium T1's which have
probably 8 different names throughout my data set... and have gone
through and identified the pre/post scans.

I wanted to basically add a <TAG> for each individual scan that lists
a "normalized scan name"... for the scans of interest. Originally I
was putting this into the NOTES field that is already exposed... but
this seems kind of dirty, and I may want to have multiple tags for
scans based on my data cleanup.... I also have cases where there are
multiple series that have identical names, but have different data...
for example I have multiple seequences named <DTI> but the first one
is an FA map, the second is a DWI map, etc... and I want to
programmaticaly retrieve them. Ideally I could just manually retag
them as FA,DWI,B0,etc in a separate column (or just put it into the
notes if that's the easiest thing to to).

I tried adding a custom variable, but only saw the ability to add it
at the MR Sesssion, ct Session or Subject level.... I looked around
briefly in the archive but my search terms may not be optimal......
it sounds like manualQC or something in that arena might be somewhat
related (or exactly related?)

--
David A Gutman, M.D. Ph.D.
Center for Comprehensive Informatics
Emory University School of Medicine

[Olsen, Tim]

I think this is the goal of the scan TYPE field. For many users, the TYPE is basically a duplicate of the SERIES_DESCRIPTION (which is also stored in the scan). This is not the goal. The goal for the scan TYPE column is to be the 'normalized' name of this scan. That is the place where this would be most useful. The scan TYPE is already used throughout the site (particularly in the pipeline stuff). Its going to become even more widely used in the next few months. For example, in some future development work that will be getting started soon, you'll be able to specify what kinds of conditions (eyes open, eyes closed) can be used for specific scan types, and what kinds of additional resources you can use (or require) for specific scan types (behavioral files, other expected file types).

The goal is that you should be able to look at a scan and see what expected file types are missing. Potentially, you could look at a list of sessions and see which ones are missing expected files. In order to support this, we need a normalized scan type. Our best shot at this currently is the scan TYPE.

Scan TYPE is currently populated when you archive image data. It tries to predict the proper scan TYPE for a series based on historical precedence. It looks at the history of other series you have stored in your project and tries to replicate your previous choices. It does this by looking at the combination of SERIES_DESCRIPTION and frames (num of frames). This is usually enough to distinguish scans. However, we plan on making this logic more robust and extensible.

The current scan type mapping system works decently if the first time you archive a session you modify the scan TYPE to match your expectations. The default behavior on new scans is to duplicate the SERIES_DESCRIPTION, unless you modify it in the archive page. If you consistently use the same SERIES_DESCRIPTION/frames combination to match the same TYPE, then this works well. Once the same SERIES_DESCRIPTION/frames combination has been stored multiple times with different types, it fails miserably.

Keeping scan type consistent has been an ongoing problem in our production instances. I think one of the major problems is that users don't pay attention to the TYPE until they want to process their data (by which point the TYPE may have inconsistent values). In order to remedy this, we have plans (soon) to create a scan TYPE cleanup page which will allow you to format the scan TYPEs for a project in one fell swoop (including the cleanup of existing scans). This could currently be done with a moderately intelligent SQL statement on the xnat_imageScanData table. We also have further range dreams to build an XML description of scan type mapping logic (though this seems only slightly less intimidating as curing cancer), that would be used to assign scan TYPE based on something other than historical precedence.

All of that said, if there is a way to use the existing TYPE field to capture this that would be ideal. Though if you need multiple TYPEs for one scan there would be a problem.

Tim

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To post to this group, send email to xnat_di...@googlegroups.com.
To unsubscribe from this group, send email to xnat_discussi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/xnat_discussion?hl=en.

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.

[David Gutman]

AAH-- VERY very helpful Tim..as always.

I noticed the scan TYPE was essentially related to
SERIES_DESCRIPTION... but I was afraid altering the type would somehow
"change" the underlying SERIES_DESCRIPTION.... now that I can see the
original SERIES_DESCRIPTION remains.... I am much less scared about
changing that.

I saw in some of the documentation on the wiki scan types like "t1"
were supported by the REST interface, so of course it makes sense to
edit that..... I just didn't want to screw up any provenance
information, as if I subsequently learn what I labeled as DTI_FA is
really a B0... I was fearful I couldn't "undo" this sort of stuff
easily... but I see the original data is preserved....

On a related issue... if I for example access my XNAT server using a
DICOM client (like efilm/clearcanvas/osirix/whatever)... what is
actually "seen".... is it the original SERIES_DESCRIPTION or the
perhaps more informative TYPE field?

[Olsen, Tim]

I would guess that it is the series_description. Though I'm not sure. Misha, any thoughts?

[misha]

>if I for example access my XNAT server using a
>DICOM client (like efilm/clearcanvas/osirix/whatever)... what is
>actually "seen".... is it the original SERIES_DESCRIPTION or the
>perhaps more informative TYPE field?

If you're using XNAT Gateway, all fields you see in a PACS interface
originate from DICOM, so you see the original SERIES_DESCRIPTION.
I'm also guessing that XNAT scan type value is derived from
series_description (and perhaps few other DICOM tags).

[David Gutman]

That was my guess--- an interesting discussion point though in the
future.... I could imagine a scenario where we would want clinicians
to access the XNAT "PACS" to pull images, but to make their lives
easier it returns a set of pre-standardized tags.... that would of
course require a dynamic swapping of the DICOM SERIES_ID without
whatever "TYPE" is associated with that field... but still might be a
neat future in XNAT 2.0....

Thanks!