IGT:Image Transfer
Back to NCIGT:Main_Page
Data Acquisition in the SPL
Please note the main changes to the image transfer policy and procedure, followed by a more detailed explanation.
* Images are no longer automatically transferred from the MR scanners
* Image transfer by users to hosts jake and elwood were unreliable and have been replaced by host jerome.
* Support for genesis format is being phased out by GE in favor of DICOM
* In order to maintain HIPAA compliance, the username of the person sending images to the SPL in DICOM
format is now automatically recorded.
This page is intended to help people who are working at the Surgical Planning Lab (SPL) to acquire data generated at Brigham and Women's Hospital. For many years, the majority of the data processed in the SPL was acquired in genesis format. This (genesis) is a proprietary General Electric (GE) format that will not be supported in the future. For several years we have been migrating toward the DICOM standard and continue to do so. The bay2, bay3, and bayms MR scanners have been upgraded and no longer support genesis format at all. Many of the other MR scanners will soon be upgraded and will only allow image transfers in DICOM format after being upgraded. It is best to acquire your data in DICOM format whenever possible. DICOM is the medical imaging standard format for most modalities of data. In some cases however, it may be necessary or more convenient to acquire data in genesis format. The following data acquisition methods are available.
* Pushing images from scanners to SPL(DICOM)
* Restoring CT and MR images from PACS from 09/1998-present (DICOM)
o Finding DICOM data in /spl/tmp/incoming after it has been transferred)
* Image transfer to SPL using xferx from host jerome(genesis)
* Pseudo real-time image transfer to SPL with the mrxfer program from host jerome (genesis)
* Restoring MR images from tape from 1991 to January 2004. (genesis)
Pushing images from scanners to SPL (DICOM) This is a good way for researchers to get their data to the SPL after a scan has been done. Most of the scanners have been configured to allow images to be sent to the SPL. As noted above, user name of the sender of the images is recorded to maintain HIPAA compliance. At the scanner select either LISA or SPL as the DICOM destination and transfer the images. Data will be sent to the directory /spl/tmp/incoming. If there is a lot of data in /spl/tmp/incoming it may take a while to locate your particular case. One method is to find timestamps on files in /spl/tmp/incoming that match the time that the images were transferred from the scanners or see Finding DICOM data in /spl/tmp after it has been transferred) If non-clinical scans are not transferred to the SPL or stored on MOD, there is a good chance the data will be deleted unless a prominent note is left for the techs and they are reminded not to delete the data. Clinical cases are archived and can be restored via the following method.
Restoring images from PACS from 09/1998-present (DICOM) This is the best way to get all CT and MR images from September 1998 to present that are not on the scanners. Data can be sent to SPL directly to /spl/tmp/incoming from any of the IMPAX systems in the reading rooms. Send email to Mark Anderson mark@bwh.harvard.edu or Marianna Jakab marianna@bwh.harvard.edu to get cases transferred via this method. If you plan to use this method frequently, you may want to get your own BICS account with transfer privileges by calling the help desk at x2-5927
Finding DICOM data in /spl/tmp/incoming after it has been transferred
The easiest way to find your DICOM data is to point your browser to /spl/tmp/incoming/ and look for a file with a name beginning with
DICOM_files_as_of
The file name will contain a time stamp and look similar to the filename below.
DICOM_files_as_of:12_30_04_at_14:10:28.html
This file is updated every hour on the hour with a list of the current contents of /spl/tmp/incoming/ and the time that the file was updated is part of the file name. The above file shows the contents of /spl/tmp/incoming as of Dec 30 2004 at 2:10 in the afteroon. After clicking on the DICOM html you will see information similar to the following which should help you to locate your data. One way to use the page similar to the one below is to do the following:
* open a command window and change to the Root Directory in the window (e.g cd /spl/tmp/incoming) * load the DICOM_files_as_of:**********.html page into your browser * use the edit->Find in This Page tab of the browser and type in the Patient ID or Patient Name. If you get the Alert message "The text you entered was not found." Then either you have entered the incorrect information or you will need to wait until the page is updated on the next hour. * If your Patient Name or Patient ID is found in DICOM html then cut and paste from the DICOM html page the path above the Patient Name or Patient ID pointing to where your data is located and change to that directory(e.g. cd MR0000.MOD/LMRC3T.STA/20050623.DAY/1.2.840.113619.2.136.1762888421.2231.1119526620.0.UID/) * from this directory, copy your data to a safe place as it will be deleted 1 week after it is last accessed
Below is an example of how the directories might be organized in /spl/tmp/incoming:
./MR0000.MOD/BWOW1.STA ./MR0000.MOD/BWOW1.STA/20040609.DAY ./MR0000.MOD/BWOW1.STA/20040609.DAY/1.2.840.113619.2.5.1762874864.1706.1086778760.584.UID ./MR0000.MOD/BWOW1.STA/20040609.DAY/1.2.840.113619.2.5.1762874864.1706.1086778760.584.UID/000001.SER ./MR0000.MOD/BWOW1.STA/20040609.DAY/1.2.840.113619.2.5.1762874864.1706.1086778760.584.UID/000002.SER ./MR0000.MOD/BWOW1.STA/20040609.DAY/1.2.840.113619.2.5.1762874864.1706.1086778760.584.UID/000003.SER ./MR0000.MOD/BWOW1.STA/20040609.DAY/1.2.840.113619.2.5.1762874864.1706.1086778760.584.UID/000005.SER ./MR0000.MOD/BWOW1.STA/20040609.DAY/1.2.840.113619.2.5.1762874864.1706.1086778760.584.UID/000006.SER ./CT0000.MOD ./CT0000.MOD/BWCTPIKE.STA ./CT0000.MOD/BWCTPIKE.STA/20040610.DAY ./CT0000.MOD/BWCTPIKE.STA/20040610.DAY/1.3.12.2.1107.5.1.4.28154.4.0.4973204933331248.UID ./CT0000.MOD/BWCTPIKE.STA/20040610.DAY/1.3.12.2.1107.5.1.4.28154.4.0.4973204933331248.UID/000002.SER
The following describes the hierarchy of the directories (we will use the CT0000.MOD directory above as an example)
* CT0000.MOD this is the modality usually either CT or MR for most SPL data * BWCTPIKE.STA this is the StationName where the image was transferred from. * 20040610.DAY The date of the scan. This scan was done on June 10, 2004. * 1.3.12.2.1107.5.1.4.28154.4.0.4973204933331248.UID This annoyingly long string is called the StudyInstanceUID and it uniquely identifies this study. This string does not provide much useful information to most users. The beginning part of the string (1.3.12.2.1107.5.1.4) is the Implementation Class UID and identifies the images in this directory as coming from a Siemens scanner.
Image transfer to SPL using xferxfrom host jerome (genesis) NOTE: xferx is an ancient program and fails frequently so it might be better to use Pseudo real-time image transfer to SPL with the mrxfer program Below is a list of MR scanners in the hospital:
* bay1 - clinical scanner * bay2 - **NO xferx SUPPORT** * bay3 - **NO xferx SUPPORT** * bay3t - LMRC 3 Tesla scanner * bay4 - bay4 scanner * bayms - **NO xferx SUPPORT** * mrt - open magnet for surgical cases * pike - clinical scanner * bwhmrpike2.partners.org - clinical scanner - new pike magnet
The procedure for using xferx to transfer your images is as follows:
1. login to host jerome, the server for the image database manager (idbm) that the xferx program communicates with to store images transferred from the scanners.
NOTE: Formerly jake, elwood and lisa were the idbm servers, but these are no longer supported. Now jerome is the image transfer server
2. set the display to be your local machine:
setenv DISPLAY your_desktop:0
3. on your local machine, allow remote display from host jerome:
xhost + jerome
4. on jerome, run the program:
xferx (if this does not work, type /opt/local/crd/xferx)
5. make sure the idbm server is running properly by toggling the Listing widget to Local and touching the List Hpat button. Now to the right of the directory? text entry you will see the location where the images will be transferred to. Currently, from jerome, this location is /export/home/images/new. Since this software is somewhat unstable, these locations are subject to change. Please note also that /export/home/images/new are local file systems. This means that the data will need to be copied from /export/home/images/new to a global location such as /spl/tmp after the data is transferred. If /export/home/images/new does not appear to the right of the directory? text entry, try the using host jerome. If this fails, send email to Mark Anderson mark@bwh.harvard.edu
6. when you are sure the database manager is running, toggle the Listing to Remote and select your Remote host from the list
7. scroll through the list of patients and select the patient of interest.
8. if you want the entire exam, touch the Get From Remote button. If you want just a single series or image, use the List Ser and List Ima buttons to choose the series/image of choice. If all goes well, xferx will transfer the images to the local directory /export/home/images/new/GINX/GENESIS/.... where the .... depends on the remote host
images from bay1, bay4, pike and mrt go to /export/home/images/new/GINX/GENESIS/BWS
images from bay3t go to /export/home/images/new/GINX/GENESIS/LMR
images from pike scanners go to /export/home/images/new/GINX/GENESIS/PIK
images from remote sites that have been transferred to our scanners will go to /export/home/images/new/GINX/GENESIS/xxx where xxx is the Suite ID of the scanner on which the data was originally generated.
Pseudo real-time image transfer to SPL with the mrxfer program from host jerome (genesis) A command line program called mrxfer can be used to transfer your images. This program takes a series of arguments but all you really need to know is the name of the Remote host (e.g. bay1) and the exam number. It will run continuously, comparing the images in the exam number on the remote host to those locally for the same exam. As long as there are images for the remote exam that have not been transferred, mrxfer will transfer the images. This command is particularly useful in 2 cases: when images need to be acquired as soon as they are generated on the remote scanner, and to get parts of exams that xferx failed to acquire properly. Use the following procedure to transfer images with the mrxfer program:
* login to host jerome - if you dont know the exam number run xferx and list the remote exams for your Remote host to find it.
* run the command - the example below will get study 276 from the bay3t scanner, using the local host (jerome) and the default database and wait 1 second after the final image is transferred before trying to find new images for exam 276. The wait time can be changed to any number by changing the 1 prior to 276 to a different wait time. The argument labelled /txt was intended to describe a local suite id (e.g. BWS) but is actually ignored by the program. /anytext will work.
Trying to run a multiple transfer session at a same time might cause program crash.
/opt/local/crd/mrxfer bay3t /txt local default 1 276
After running the command you will see something similar to:
argv[0] = [/opt/local/crd/mrxfer] argv[1] = [bay3t] argv[2] = [/txt] argv[3] = [local] argv[4] = [default] argv[5] = [1] argv[6] = [276]
/opt/local/crd/mrxfer started Tue Dec 31 14:44:26 2002 studys 00282 and 00276 differ study 00276 exists on remote!! match is the 1 study exam pat 007 study 00276 doesnt exist locally getting txt 007 00276 001 001 getting txt 007 00276 001 002 getting txt 007 00276 001 003 getting txt 007 00276 001 004 getting txt 007 00276 001 009 getting txt 007 00276 004 001 getting txt 007 00276 004 002 getting txt 007 00276 004 003 . . . after the transfer is complete, or if there are currently no images to transfer, you will see:
check done, going to sleep for 1 seconds at Tue Dec 31 14:58:03 2002
At this point you can either kill the program with Control-C or if the image acquisition is ongoing you can leave the program running continuously and the images will be transferred as soon as they are registered in the remote scanner's database.
As mentioned above, images from bay1, bay4, pike and mrt go to /export/home/images/new/GINX/GENESIS/BWS images from bay3t go to /export/home/images/new/GINX/GENESIS/LMR images from remote sites that have been transferred to our scanners will go to /export/home/images/new/GINX/GENESIS/xxx where xxx is the Suite ID of the scanner on which the data was originally generated.
Database manager issues DO NOT DELETE IMAGE FILES FROM THE DATABASE! As previously noted, the xferx program is ancient and problematic. A frequent problem that occurs is that xferx will Segmentation fault and terminate during image transfer. What people often try to do is to delete the images that have been transferred and re-transfer them. When a second attempt to transfer the images is attempted, xferx will still think the images exist. This is because the image database manager (idbm) process running on jake was not notified via a database call that the images were removed. When the idbm process starts, it searches the directory hierarchy of /export/home/images/new and creates a memory-resident data structure describing the image hierarchy. As images are added/deleted via database calls from xferx and mrxfer, this data structure changes.
For this reason the following is recommended for image transfer:
* use the mrxfer program instead of xferx * if you run into troubles, use the backup idbm server on host jerome and look for your images in /export/home/images/new/... * if these procedures fail, send email to Mark Anderson mark@bwh.harvard.edu
Restoring MR images from tape from 1991 to January 2004 (genesis)
A copy of most the MR scans done from 1991 until January 2004 at BWH exists on tape backup in the SPL. If there is no other way to retrieve your data we can search thru our tape backups as a last resort and attempt to retrieve MR data from our tapes in genesis format. For tape restore, send email to: mark@bwh.harvard.edu
