Difference between revisions of "CTSC:ARRA.060810"

From NAMIC Wiki
Jump to: navigation, search
(Created page with 'Back to CTSC:ARRA supplement <br> '''Agenda''' * mi2b2 installation update * <br> == Harvard Catalyst Medical Informatics group Meeting Minutes June 8, 2010 == In attenda…')
 
Line 5: Line 5:
  
 
* mi2b2 installation update
 
* mi2b2 installation update
−
*  
+
* mi2b2 software development- planning DICOM retrieve
 +
* mi2b2 User Interface Plug-In for Eclipse
 
<br>
 
<br>
 
== Harvard Catalyst Medical Informatics group Meeting Minutes June 8, 2010 ==
 
== Harvard Catalyst Medical Informatics group Meeting Minutes June 8, 2010 ==
Line 37: Line 38:
 
**(BIDMC) In process, still saying it will happen in July.  
 
**(BIDMC) In process, still saying it will happen in July.  
 
<br>
 
<br>
 +
*'''mi2b2 software development- planning DICOM retrieve:'''
 
Chris reports that in the current instance of the project software the C-find command is working.  We can query and get results from PACs.  Now the development time is working on finding the correct protocol to get the images from the PACs and move them onto the STAR-D platform.  They have learned that the C-move command is preferred over C-get (background reading and references are provided for your edification at this site).  The target for the data to be transferred to is still being worked out, but it WON'T be and XNAT instance.  The transfer to from with PACs will be a zipped or tarball data "chunk" that will need a place to land before beginning the transfer to XNAT if that is going to happen.  Chris, Steve and Shawn are expecting some complications on this front because DICOM standards don't robustly support this as an automated task (e.g. a retrieve request may not gather a complete dataset because there is no "end tag" or "close tag").  Kathy provided some context for this situation.  For every study there is a Date, Time, patient with unique medical record number, and unique ID accession number for study, then series with number of images.  The technologist is supposed to set a status flag to "complete" to signal that the acquisition is finished (other status flag are "ordered", "in process", "complete", then on to the reading task, where the flags are "preliminary" and "final". But many scenerios result in irregularities such as a patient needing to get out of the scanner to go to the bathroom and then resumes study.  There is also the issue that all vendors have their own idiosyncracies.  This project includes PACS software/hardware from multiple vendors (GE, Fuji, AGFA, etc plus the open source solution DCM4CHEE) so that our solutions will be robust for a large portion of the market.  
 
Chris reports that in the current instance of the project software the C-find command is working.  We can query and get results from PACs.  Now the development time is working on finding the correct protocol to get the images from the PACs and move them onto the STAR-D platform.  They have learned that the C-move command is preferred over C-get (background reading and references are provided for your edification at this site).  The target for the data to be transferred to is still being worked out, but it WON'T be and XNAT instance.  The transfer to from with PACs will be a zipped or tarball data "chunk" that will need a place to land before beginning the transfer to XNAT if that is going to happen.  Chris, Steve and Shawn are expecting some complications on this front because DICOM standards don't robustly support this as an automated task (e.g. a retrieve request may not gather a complete dataset because there is no "end tag" or "close tag").  Kathy provided some context for this situation.  For every study there is a Date, Time, patient with unique medical record number, and unique ID accession number for study, then series with number of images.  The technologist is supposed to set a status flag to "complete" to signal that the acquisition is finished (other status flag are "ordered", "in process", "complete", then on to the reading task, where the flags are "preliminary" and "final". But many scenerios result in irregularities such as a patient needing to get out of the scanner to go to the bathroom and then resumes study.  There is also the issue that all vendors have their own idiosyncracies.  This project includes PACS software/hardware from multiple vendors (GE, Fuji, AGFA, etc plus the open source solution DCM4CHEE) so that our solutions will be robust for a large portion of the market.  
 
<br>
 
<br>
 
Shawn notes that to work on this, it would be helpful to have representative sample set of data from each site.  We will elaborate on this in upcoming meetings.
 
Shawn notes that to work on this, it would be helpful to have representative sample set of data from each site.  We will elaborate on this in upcoming meetings.
−
background material
+
 
−
Wikipedia entry for a description of the difference between C-get and C-move
+
*background material
−
Oleg S. Pianykh DICOM for Idiots (for Clinical Radiologists)
+
#Wikipedia entry for a description of the difference between C-get and C-move
−
Dave Clunie's web site
+
#Oleg S. Pianykh DICOM for Idiots (for Clinical Radiologists)
 +
#Dave Clunie's web site
  
 
<br>
 
<br>
−
*'''mi2b2 User Interface Plug In for Eclispe'''  
+
*'''mi2b2 User Interface Plug-In for Eclispe'''  
−
**Need to get 'plumbing' (software and hardware programming for image query, retrieve and transfer) in place and then auditing before making it available to our first users.  Estimated date for being ready for the first protypical study IRB approved to use this infrastructure is March 2011 (exactly on target with our grant proposal).  If the IRB were approved by this fall, this team could use these images to finish working out the bugs of the system.
+
**Shawn shared the initial preliminary design for the user interface
−
**Potential future issues noted at MGH is that the server is set up to access their system through a single entry gateway.  If anything were to happen to shut that gateway down, access would not be available until the gateway is back open.  In the i2b2 world that is normal and to be expected.  In the clinical world it wouldn't be tolerated.  Mi2b2 is in the i2b2 world and as such will not need to perform at clinical specifications.
 

Revision as of 15:31, 8 June 2010

Home < CTSC:ARRA.060810

Back to CTSC:ARRA supplement

Agenda

  • mi2b2 installation update
  • mi2b2 software development- planning DICOM retrieve
  • mi2b2 User Interface Plug-In for Eclipse


Harvard Catalyst Medical Informatics group Meeting Minutes June 8, 2010

In attendance:

  • Shawn Murphy
  • Bill Wang
  • Cynthia Lee (newest mi2b2 programmer/designer who will be working on UI for our project)
  • Steve Pieper
  • Yong Gao
  • Randy Gollub
  • Chris Herrick
  • Wendy Plesniack
  • Darren Sack
  • Mark Anderson
  • Charles McGow
  • Valerie Humblet
  • Jesse Wei
  • Kathy Andriole (by phone)
  • Paul Lamonica
  • Bill Tellier
  • Alex Zeitsev


Meeting Minutes


  • mi2b2 STAR-D installation site update:
    • (BWH) Chris spoke with Mike Clyne who is going out of town but passed him along to Ed and Jamie on his team who will fill in. Kathy reports that they have the passcodes and are working on it right now.
    • (BIDMC) In process, still saying it will happen in July.


  • mi2b2 software development- planning DICOM retrieve:

Chris reports that in the current instance of the project software the C-find command is working. We can query and get results from PACs. Now the development time is working on finding the correct protocol to get the images from the PACs and move them onto the STAR-D platform. They have learned that the C-move command is preferred over C-get (background reading and references are provided for your edification at this site). The target for the data to be transferred to is still being worked out, but it WON'T be and XNAT instance. The transfer to from with PACs will be a zipped or tarball data "chunk" that will need a place to land before beginning the transfer to XNAT if that is going to happen. Chris, Steve and Shawn are expecting some complications on this front because DICOM standards don't robustly support this as an automated task (e.g. a retrieve request may not gather a complete dataset because there is no "end tag" or "close tag"). Kathy provided some context for this situation. For every study there is a Date, Time, patient with unique medical record number, and unique ID accession number for study, then series with number of images. The technologist is supposed to set a status flag to "complete" to signal that the acquisition is finished (other status flag are "ordered", "in process", "complete", then on to the reading task, where the flags are "preliminary" and "final". But many scenerios result in irregularities such as a patient needing to get out of the scanner to go to the bathroom and then resumes study. There is also the issue that all vendors have their own idiosyncracies. This project includes PACS software/hardware from multiple vendors (GE, Fuji, AGFA, etc plus the open source solution DCM4CHEE) so that our solutions will be robust for a large portion of the market.
Shawn notes that to work on this, it would be helpful to have representative sample set of data from each site. We will elaborate on this in upcoming meetings.

  • background material
  1. Wikipedia entry for a description of the difference between C-get and C-move
  2. Oleg S. Pianykh DICOM for Idiots (for Clinical Radiologists)
  3. Dave Clunie's web site


  • mi2b2 User Interface Plug-In for Eclispe
    • Shawn shared the initial preliminary design for the user interface
Retrieved from "https://www.na-mic.org/w/index.php?title=CTSC:ARRA.060810&oldid=53445"