CTSC:ARRA.020111 - Revision history

RandyGollub at 15:51, 8 February 2011

2011-02-08T15:51:23Z

RandyGollub at 03:34, 2 February 2011

2011-02-02T03:34:41Z

RandyGollub: Undo revision 64080 by RandyGollub (Talk)

2011-02-02T03:34:06Z

Undo revision 64080 by RandyGollub (Talk)

RandyGollub at 03:23, 2 February 2011

2011-02-02T03:23:36Z

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

2011-02-01T16:49:16Z

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

New page

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

'''Agenda'''
*
*

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

In attendance:
* Bill Wang
* Shawn Murphy
* Vincent Roch
* Steve Pieper
* Darren Sack
* Bill Tellier
* Randy Gollub
* Alex Zeitsev
* Chris Herrick
* Charles McGow
* Paul Lamonica (phone)
* Kathy Andriole (phone)
* Jesse Wei (phone)
* Yong Gao (phone)

=== mi2b2 software update ===

Further discussion users would site can have one or multiple Departmental PACSs (e.g. Radiology, Cardiology) and each Departmental PACS can have one or multiple nodes.

=== 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.

← Older revision		Revision as of 03:34, 2 February 2011
Line 2:		Line 2:
	<br>		<br>

−	~~'''Agenda'''~~
−	*
−	*

	<br>		<br>

@@ Line 24: / Line 24: @@
 === mi2b2 software update ===
-Further discussion users would  site can have one or multiple Departmental PACSs (e.g. Radiology, Cardiology) and each Departmental PACS can have one or multiple nodes.
+*We discussed how to manage the response that each AE will provide for a patient query if several AE's can be specified.  TO be most compatible with the current patient lookup UI, the current table will select (randomly?) a single response to fill in for each MRN, and perhaps at some later time a full list can be made to appear when one clicks on that patient.
-=== query process ===
+*The AE's would be specified by site and department.  One can filter queries to specify a single department in the "filter" part of the UI.
 ===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.