Difference between revisions of "CTSC:ARRA.020811"
From NAMIC Wiki
RandyGollub (talk | contribs) |
RandyGollub (talk | contribs) |
||
| Line 1: | Line 1: | ||
Back to [[CTSC:ARRA supplement]] | Back to [[CTSC:ARRA supplement]] | ||
<br> | <br> | ||
| − | |||
| − | |||
<br> | <br> | ||
== Harvard Catalyst Medical Informatics group Meeting Minutes February 08, 2011 == | == Harvard Catalyst Medical Informatics group Meeting Minutes February 08, 2011 == | ||
| Line 20: | Line 18: | ||
| − | + | === 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. Group discussed possible sources of the problem and potential solutions. | ||
| − | + | * 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 | + | * 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). |
| + | * Dave's UI is coming along with additional filtering capabilities and image processing abilities. | ||
| − | |||
| − | + | === Continued discussion of 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. | |
| − | |||
| − | * Continued discussion about position the C-moves in a friendly way with the Radiology PACS. | ||
Latest revision as of 16:31, 8 February 2011
Home < CTSC:ARRA.020811Back to CTSC:ARRA supplement
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
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. Group discussed possible sources of the problem and potential solutions.
- 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 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).
- Dave's UI is coming along with additional filtering capabilities and image processing abilities.
Continued discussion of 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.
