CTSC:ARRA.060810 - Revision history

RandyGollub at 13:33, 16 June 2010

2010-06-16T13:33:20Z

RandyGollub at 13:32, 16 June 2010

2010-06-16T13:32:33Z

Valerie.humblet: /* Harvard Catalyst Medical Informatics group Meeting Minutes June 8, 2010 */

2010-06-08T19:10:29Z

Harvard Catalyst Medical Informatics group Meeting Minutes June 8, 2010

RandyGollub at 16:09, 8 June 2010

2010-06-08T16:09:18Z

RandyGollub at 15:34, 8 June 2010

2010-06-08T15:34:12Z

RandyGollub at 15:31, 8 June 2010

2010-06-08T15:31:29Z

RandyGollub: Created page with 'Back to CTSC:ARRA supplement
'''Agenda''' * mi2b2 installation update *
== Harvard Catalyst Medical Informatics group Meeting Minutes June 8, 2010 == In attenda…'

2010-06-08T15:20:09Z

Created page with 'Back to CTSC:ARRA supplement '''Agenda''' * mi2b2 installation update * == Harvard Catalyst Medical Informatics group Meeting Minutes June 8, 2010 == In attenda…'

New page

Back to [[CTSC:ARRA supplement]]
 

'''Agenda'''

* mi2b2 installation update
*
 
== 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.
 
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
Wikipedia entry for a description of the difference between C-get and C-move
Oleg S. Pianykh DICOM for Idiots (for Clinical Radiologists)
Dave Clunie's web site

 
*'''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.
**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.

@@ Line 35: / Line 35: @@
 <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 team 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 [[mi2b2 background material|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 data set 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 team 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 [[mi2b2 background material|site]]).  The target for the data to be transferred to is still being worked out, but it WON'T be an 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 data set 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>
 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.

@@ Line 35: / Line 35: @@
 <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 [[mi2b2 background material|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 data set 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 team 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 [[mi2b2 background material|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 data set 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>
 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.

@@ Line 34: / Line 34: @@
 <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 [[mi2b2 background material|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 [[mi2b2 background material|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 data set 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>
 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.
 <br>
 *'''mi2b2 User Interface Plug-In for Eclipse'''
-**Shawn shared the initial preliminary design for the user interface
+**Shawn shared the initial preliminary design for the user interface that he has begun to design.  Reviewed the multiple screens and actions that need to be actualized going forward.

@@ Line 25: / Line 25: @@
 * Jesse Wei
 * Kathy Andriole (by phone)
 <br>
@@ Line 39: / Line 34: @@
 <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 [[mi2b2 background material|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>
 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.
 <br>
-*'''mi2b2 User Interface Plug-In for Eclispe'''
+*'''mi2b2 User Interface Plug-In for Eclipse'''
 **Shawn shared the initial preliminary design for the user interface

@@ Line 5: / Line 5: @@
 * mi2b2 installation update
+* mi2b2 software development- planning DICOM retrieve
 <br>
 == Harvard Catalyst Medical Informatics group Meeting Minutes June 8, 2010 ==
@@ Line 37: / Line 38: @@
 **(BIDMC) In process, still saying it will happen in July.
 <br>
 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>
 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)
 <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