CTSC:ARRA.020811 - Revision history

RandyGollub at 16:31, 8 February 2011

2011-02-08T16:31:17Z

RandyGollub at 15:55, 8 February 2011

2011-02-08T15:55:00Z

RandyGollub: Created page with 'Back to CTSC:ARRA supplement

== Harvard Catalyst Medical Informatics group Meeting Minutes February 08, 2011 == In attendance: * Bill Wang * Shawn Murphy * Vinc…'

2011-02-08T15:48:53Z

Created page with 'Back to CTSC:ARRA supplement <br> <br> == Harvard Catalyst Medical Informatics group Meeting Minutes February 08, 2011 == In attendance: * Bill Wang * Shawn Murphy * Vinc…'

New page

Back to [[CTSC:ARRA supplement]]
<br>

<br>
== Harvard Catalyst Medical Informatics group Meeting Minutes February 08, 2011 ==

In attendance:
* Bill Wang
* Shawn Murphy
* Vincent Roch
* Darren Sack
* Bill Tellier
* Randy Gollub
* Chris Herrick
* Yong Gao
* Jesse Wei (phone)
* Mark Anderson (phone)
* Alex Zeitsev

* Charles McGow
* Steve Pieper
* Paul Lamonica (phone)
* Kathy Andriole (phone)

=== mi2b2 software update ===

Working to resolve the incompatibility issue at MGH site (was problem on both initial laptop and new desktop servers) where C-move requests for data sets with more than 2000 images fail because the fetch fails after 2000 images. Tried DCMtk and it worked. Not sure why. This doesn't happen at CHB or BWH or BIDMC.

=== query process ===

At CHB, BWH and BIDMC there is a single gateway for query. At MGH, it is a multi-node PACS.

===Policies and Procedures for PACS access at each institution===

* Continued discussion about position the C-moves in a friendly way with the Radiology PACS. For each AE address it is "sufficient' to pull images between X time and X time on X day of the week at a rate of XX images/10 minutes per thread with a limit of X threads. Jesse suggests having some sort of dynamic parameter that will regulate the pulls by a factor that is responsive to the busy-ness of the PACS such as a ratio of 5x the pull return time before the next pull could be sent. Shawn points out that the limit to the number of threads in fact may accomplish this goal. This plan is simple and will be easier to test, build trust in and adjust as needed both increasing and decreasing parameters per site. Shawn expressed concern about complex algorithms as they are highly prone to fail.

@@ Line 1: / Line 1: @@
 Back to [[CTSC:ARRA supplement]]
 <br>
 <br>
 == Harvard Catalyst Medical Informatics group Meeting Minutes February 08, 2011 ==
@@ Line 20: / Line 18: @@
-* Charles McGow
+=== mi2b2 software update ===
-=== mi2b2 software update ===
+* Bill set up a second DMC4chee instance so can test software against multiple data storage sites (nodes) as will be the case for MGH for sure.
-Working to resolve the incompatibility issue at MGH site (was problem on both initial laptop and new desktop servers) where C-move requests for data sets with more than 2000 images fail because the fetch fails after 2000 images. Tried DCMtk and it worked.  Not sure why.  This doesn't happen at CHB or BWH or BIDMC.
+* Working out the algorithm for dealing with data sets that are archived.  Likely scenario is to have failed data requests move to a second (and then possibly to a third) workflow that is configured to deal with archived images (needs longer times and perhaps additional steps to change format to DICOM).
-At CHB, BWH and BIDMC there is a single gateway for query.  At MGH, it is a multi-node PACS.
+=== Continued discussion of Policies and Procedures for PACS access at each institution===
-===Policies and Procedures for PACS access at each institution===
+* Continued discussion about position the C-moves in a friendly way with the Radiology PACS.  The proposal that will be made to the Advisory Board next week is: for each site for each AE address, permission will be granted to mi2b2 to pull images between X time and X time on X day of the week at a rate of XX images/10 minutes per thread with a limit of X threads minimum time between data sets.  Can have as many of these unique time segments as needed to specify the level of granularity required per site. Failure triggers next step in workflow (e.g. problem solving to determine if shift to pull from archive (has longer timeout level) versus send error message that data set is not available and reason why will be returned).  Multiple threads - fast one, archive one, that has timeout configured properly.

@@ Line 36: / Line 36: @@
 ===Policies and Procedures for PACS access at each institution===
+Only email from Paul; Darren,Bill, Kathy and Jesse participated in discussion below
 * Continued discussion about position the C-moves in a friendly way with the Radiology PACS.  For each AE address it is "sufficient' to pull images between X time and X time on X day of the week at a rate of XX images/10 minutes per thread with a limit of X threads.  Jesse suggests having some sort of dynamic parameter that will regulate the pulls by a factor that is responsive to the busy-ness of the PACS such as a ratio of 5x the pull return time before the next pull could be sent.  Shawn points out that the limit to the number of threads in fact may accomplish this goal.  This plan is simple and will be easier to test, build trust in and adjust as needed both increasing and decreasing parameters per site.  Shawn expressed concern about complex algorithms as they are highly prone to fail.

CTSC:ARRA.020811 - Revision history

RandyGollub at 16:31, 8 February 2011

RandyGollub at 15:55, 8 February 2011

RandyGollub: Created page with 'Back to CTSC:ARRA supplement == Harvard Catalyst Medical Informatics group Meeting Minutes February 08, 2011 == In attendance: * Bill Wang * Shawn Murphy * Vinc…'

RandyGollub: Created page with 'Back to CTSC:ARRA supplement

== Harvard Catalyst Medical Informatics group Meeting Minutes February 08, 2011 == In attendance: * Bill Wang * Shawn Murphy * Vinc…'