Nuclear Med data

[Simon Doran]

Dear All,

One of my next tasks is to introduce some Nuclear Medicine data to
XNAT.

The thing I notice immediately is that the nmSessionData and nmScan
complexTypes are just empty shells around imageSessionData and
imageScanData respectively. Has anyone out used these for their own
nuclear med data or modified these?

Tim, what would be the best thing to do? It seems silly to create a
custom datatype for something which presumably in the fulness of time
will be built in. Is it more sensible to modify the xnat.xsd document
to add to nmScanData the NM equivalent of the parameters section of
mrScanData?

I have written a fairly general uploader for arbitrary datatypes. It
should be straightforward to populate the nmScan and nmSession
elements from the Interfile parameter files with which I am being
supplied, and then to upload both the parameter and the pixel data
files to the repository via REST. What I don't yet know how to do is
how to create NM Session pages on the web interface, corresponding to
the MR Session pages that I see routinely, with thumbnails, file
counts, etc. How much of this will occur automatically, based on the
fact that nmSession inherits from imageSession? Am I on the right
track in thinking that I will need to modify
xnat_imageScanData_details.vm for my particular case?

Presumably, I need to launch a pipeline from my upload application
in order to create the thumbnails, etc?

Is there any documentation on this particular topic?

Thanks in advance,

Simon

[Simon Doran]

Dear All,

  Not a lot of activity on my part over the last (three!) years since I wrote this original post, so when I wrote "one of my next tasks" that was a bit optimistic! However, I have now recruited somebody whose main role is to add new datatypes to XNAT corresponding to the data we generate.

  As an easy first use case, we are looking at importing the interfile format, used in nuclear medicine scanners (primarily SPECT), but this query applies to any data format for nuclear medicine data.

  Shall we take the plunge and code our new details into xnat.xsd, given that the datatypes to be changed are  xnat:nmScanData and xnat:nmSessionData? It doesn't make sense to create a new data type in a local schema for nuclear med data, since you have the shell there already. Then, if what we produce looks good, the definition could be merged into the XNAT release at a later stage.

  Would this be of interest to the community or do you have other plans in this area. We don't want to duplicate effort.

  Best wishes,

Simon 

[Archie, Kevin]

Simon,

Yes, absolutely, please do. Most of the DICOM types are stubs and we'd be very happy to get them filled out. I can help by adding to the metadata translation (aka the session builder) if you can send me a description of how to map the DICOM metadata into your new fields, or of course you're welcome to make those changes yourself and I can offer advice on how to get started with that.

Thanks,

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.

[Verónica García-Pérez]

Hi all!

My name is Verónica and I have started to work at the ICR two months ago within the Radiotherapy and Imaging Division. 

One of my duties is trying to devise a schema that captures the essentials of NM pre-clinical metadata. Simon is my line manager :)

For this purpose, we’ve been looking over DICOM Nuclear Medicine Image IOD specification, together with the metadata found in non-DICOM examples of nuclear medicine data (e.g., Interfile) that we have access to locally. The first issue that we would like to discuss is that we found some relevant parameters that maybe could help to cover a wider description of some of the existing elements of the current XNAT Schema.  Some of them could be merely useful in order to put the element at hand in context, and some others could be relevant for subsequent procedures on visualization or imaging applications. Actually, mrScanData, for instance, contains some elements that could “rise" to imageScanData since they are common attributes for different kind of images.

On one hand, I appreciate that schema changes to a part of XNAT as important as imageSessionData and imageScanData are not something to be undertaken lightly. But on the other hand, it is also not clear to us why, in XNAT, basic image properties such as matrix sizes, FOVs, etc. are described in the parameter sections of the individual modalities, rather than in imageScanData. Thus, I would be grateful for some comments on the parameters below and why you chose to locate them where you did. Given that we want to have access to a number of these parameters for our nuclear medicine images, could people give me some advice on how best to include them?

Our potential inclusions could be: 

* imageSessionData:

Laterality - Laterality of paired body part examined

Description - Free-text description of the Session (ctSessionData has this but mrSessionData appears not to)

Body part - Body part examined

Orientation - Anatomical orientation and relative orientation of the patient to both the gantry and the gravity

* imageScanData:

Pixel Spacing - Physical distance in the patient between the center of each pixel

Slice separation - Separation between slices

Number of slices - Number of slices

Voxel resolution - Physical measures of each voxel (in mm) = fov / matrix

Field of view (fov) - Physical space, x and y, captured in the image (in mm)

Rows and Columns (matrix) - Number of rows and columns of the image

Samples per pixel - Number of separate planes in the image

Photometric interpretation - Monochrome, color, etc…

Transformation matrix - Transformation from image space to anatomical space

Image position and orientation - To describe the position and orientation of the image slices relative to the patient-based coordinate system 

Finally, there are some other fields in the DICOM headers that are not represented in XNAT that look as if they could be either useful search terms, or would be useful to store in order to save downloading the DICOM files in and scanning the complete header. 

What do you think? 

Kind regards,

Vero.

Verónica García | Software Engineer

Division of Radiotherapy and Imaging

Royal Marsden Hospital

15 Cotswold Road, Sutton, SM2 5NG, United Kingdom

[Archie, Kevin]

Verónica,

I'll start with a quick and general response, including a few questions, with a more detailed response to come later:

I'm generally in favor of adding the fields you're describing. Mostly, the ones that we don't capture are ones that just haven't come up for us: we've been to this point primarily focused on neuroimaging (though this is changing) so some fields (e.g., Laterality) haven't been applicable before now and some modalities (anything but MR, PET, CT) have gotten short shrift. Also, much of the XNAT schema precedes our support for DICOM, so in some places we wedged DICOM attributes into existing XNAT fields. Some things you're looking for may already be in there with a non-obvious name.

Changing the schema other than simple addition (e.g., moving a field from mrScanData to imageScanData) is complicated for architectural reasons; it's not that it can't be done, but we usually avoid it unless it's so clearly the right thing to do that it's worth the maintenance and support headaches. I haven't yet decided which side of the line I think your changes are on, and I won't be the only person with an opinion. XNAT 2.0 is likely to have better support for schema changes, but that doesn't help you today.

It would help if you could provide the DICOM tags (or SQ paths) for the fields you're interested in capturing, since in many cases DICOM has multiple similarly-named fields. Also, knowing the scanner manufacturer(s) would be useful, as different vendors read the standard differently. Sample data would be really useful if you have deidentified files (preferably of a pseudonymized variety rather than field-stripped) handy.

Thanks,

Kevin

[Simon Doran]

Dear All

  Thanks to Kevin for his useful and encouraging reply. Verónica is going to post her schema file so you can see what she has done. We decided to go for a substantial implementation of the information model from DICOM on the basis that someone, somewhere might one day want to search on any of the various tags. This may be over the top and I would appreciate any advice that you might have on the impacts that this might have on the performance of XNAT.

  In principle, I think that the schema file "works". On my development box, we replaced xnat.xsd in $XNAT_HOME/projects/xnat/src/schemas/xnat and deleted the schemas/xnat/display directory for good measure. I then ran bin/setup.sh and this completed "successfully".

  However, there seem to be two oddities:

  First, this during the run of bin/setup.sh:

    [java] org.nrg.xft.exception.FieldNotFoundException: Field not found: 'xnat:pVisitData/terminal'

    [java] at org.nrg.xft.schema.Wrappers.GenericWrapper.GenericWrapperElement.TranslateXMLPathToTables(GenericWrapperElement.java:2646)

    [java] at org.nrg.xft.search.QueryOrganizer.buildJoin(QueryOrganizer.java:243)

    [java] at org.nrg.xdat.search.QueryOrganizer.buildJoin(QueryOrganizer.java:440)

    [java] at org.nrg.xdat.search.QueryOrganizer.buildQuery(QueryOrganizer.java:1162)

    [java] at org.nrg.xdat.search.QueryOrganizer.buildQuery(QueryOrganizer.java:1128)

    [java] at org.nrg.xdat.search.DisplaySearch.getSQLQuery(DisplaySearch.java:512)

    [java] at org.nrg.xdat.display.DisplayManager.GetCreateViewsSQL(DisplayManager.java:632)

    [java] at org.nrg.xdat.XDAT.GenerateUpdateSQL(XDAT.java:295)

    [java] at GenerateAllUpdateFiles.process(GenerateAllUpdateFiles.java:127)

    [java] at org.nrg.xft.commandPrompt.CommandPromptTool._process(CommandPromptTool.java:205)

    [java] at org.nrg.xft.commandPrompt.CommandPromptTool.run(CommandPromptTool.java:163)

    [java] at org.nrg.xft.commandPrompt.CommandPromptTool.<init>(CommandPromptTool.java:77)

    [java] at GenerateAllUpdateFiles.<init>(GenerateAllUpdateFiles.java:27)

    [java] at GenerateAllUpdateFiles.main(GenerateAllUpdateFiles.java:31)

    [copy] Copying 1 file to /Users/xnat/XNAT/code/xnat_1.6.3/deployments/XNAT_104012cmrdt/sql

Having looked at a copy of the original xnat.xsd file on which Verónica based her new schema, there did not seem to be an xnat:pVisitData/terminal element.

Second, since the restart, I am getting the a dialog box popping up on the home page saying "ERROR 500: Failed to load experiment list." and in xdat.log, I see this:

2014-06-27 12:10:14,364 [http-bio-8080-exec-2] ERROR org.nrg.xft.db.DBAction -

org.postgresql.util.PSQLException: ERROR: relation "xdat_meta_element_meta_data" does not exist

  Where: PL/pgSQL function "update_ls_xdat_meta_element" line 6 at FOR over SELECT rows

        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2102)

        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1835)

        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)

Any ideas on either of these?

Best wishes,

Simon

[Verónica García-Pérez]

Hi everybody,

Please, find attached in this post a possible approach to our schema. 

As mentioned above, it aims at extending the Nuclear Medicine elements. Changes has been made only within nmSessionData and nmScanData complex type

Following your valuable comments Kevin, on one hand, I have included on each element an annotation which contains: (1) The definition of the term, and (2) The related DICOM tag. And on the other hand, parameters that I think they could upgrade to imageScanData have been remarked with a xml comment.

For example, you can find on nmScanData:

<xs:element name="matrix" minOccurs="0">
    <xs:annotation> 
        <xs:documentation>
            <!-- Candidate to imageScanData -->
            DICOM: Rows (0028,0010), Columns (0028,0011)  
            Number of rows and columns in the image
        </xs:documentation>
</xs:annotation>

...

The proposal of tagging some elements as candidates to upgrade is based on two ideas:
(1) mrScanData, for instance, already contains some general information about image and pixel (such as voxelRes or matrix) that other complex types like nmScanData probably need to include.
(2) If I am not wrong, I think that there exists an equivalence between some XNAT and DICOM concepts like Image - Scan. Parameters ticket as "candidates" appear within the General Image and General Pixel DICOM modules, which are present in all the Image IODs (
Computed Radiography, Computed Tomography,  Magnetic Resonance, Nuclear Medicine, Ultrasound, etc.) 

As Simon has introduced, this version gathers numerous attributes of the DICOM NM Image so we would appreciate son much all the comments you have about the structure and convenience of them.

KR,
Vero

[Archie, Kevin]

Verónica and Simon,

Thanks for the details. This looks really promising and I think we (the XNAT team) should review it in detail, partly to see if we have any changes to propose, and partly just for educational value. I'll have to discuss with Rick and/or Dan (Rick: brown bag topic for next Wednesday?) and even if it's just me, it'll be at least next week before I can really give this the time it deserves. We'll also need to look into modifying the metadata translation--which shouldn't be a big deal, since presumably these are mostly copying the DICOM attribute into the corresponding XNAT field.

Thanks for all the work. I'm excited about getting this into core XNAT.

  - Kevin

p.s. Simon, I'm leaving your missing relations questions unanswered because I don't have a quick answer, hoping that someone closer to core XNAT will pipe up. If I have to dig into it myself, that would be next week.

---

From: xnat_di...@googlegroups.com [xnat_di...@googlegroups.com] on behalf of Verónica García-Pérez [icr.ve...@gmail.com]
Sent: Friday, June 27, 2014 7:34 AM
To: xnat_di...@googlegroups.com
Subject: Re: [XNAT Discussion] Re: Nuclear Med data

[Verónica García-Pérez]

Hi Kevin,

Thank you very much, we are also enthusiastic about the prospect of doing a good job so we will be very happy if we can improve the schema with any proposal you have!

Kind regards.