Difference between revisions of "CTSC:ARRA.040511"
From NAMIC Wiki
RandyGollub (talk | contribs) |
|||
Line 15: | Line 15: | ||
* Alex Zeitsev | * Alex Zeitsev | ||
* Bill Hanlon (phone) | * Bill Hanlon (phone) | ||
− | * | + | * Kathy Andriole (phone) |
* Mark Anderson (phone) | * Mark Anderson (phone) | ||
Line 22: | Line 22: | ||
*Continue working on multi PACS. Bill and Chris worked out interaction with UI, need to pass back and forward institutions | *Continue working on multi PACS. Bill and Chris worked out interaction with UI, need to pass back and forward institutions | ||
− | * Working on getting BWH up and running. | + | * Working on getting BWH up and running. Kathy said that it is fine to have the server in Needham. |
* Started options for encryption-decryption of images. Dave looked at what is supported through image J. DICOM images should work fine, offer format must be tested. | * Started options for encryption-decryption of images. Dave looked at what is supported through image J. DICOM images should work fine, offer format must be tested. | ||
* Baby brain project at MGH: Bill satisfied with testing, he identified a couple of issues to be fixed. | * Baby brain project at MGH: Bill satisfied with testing, he identified a couple of issues to be fixed. | ||
**Structured reports are still missing, they don't show up in the move. One thing to do is to check the format of those reports, maybe they are pdf, maybe they are text only in DICOM. | **Structured reports are still missing, they don't show up in the move. One thing to do is to check the format of those reports, maybe they are pdf, maybe they are text only in DICOM. | ||
− | **Time out issue: how we processed images now is c-move initiated, we wait for response and check if we got the right images. If the initiator does not get a response under 375 sec, the connection is dropped. It seems that PACS still send the images but it is not synchronized. The team is changing the | + | **Time out issue: how we processed images now is c-move initiated, we wait for response and check if we got the right images. If the initiator does not get a response under 375 sec, the connection is dropped. It seems that PACS still send the images but it is not synchronized. The team is changing the logic and will put together a monitoring progress to send a message that an initiation was created. |
===Planning for upcoming months=== | ===Planning for upcoming months=== | ||
Line 34: | Line 34: | ||
** User is distributed the mi2b2 workbench. Must be ready to run on PC and MAC. We are assuming the it is inside firewall, on approved clients. | ** User is distributed the mi2b2 workbench. Must be ready to run on PC and MAC. We are assuming the it is inside firewall, on approved clients. | ||
** mi2b2 server component that is running the mi2b2 cell | ** mi2b2 server component that is running the mi2b2 cell | ||
− | ** i2b2 server: project management server. This component will communicate directly with the user. Each time for every detailed request, it will be a new project created, that project will be enabled with a list of MRN known by the project manager. At Partners there is a | + | ** i2b2 server: project management server. This component will communicate directly with the user. Each time for every detailed request, it will be a new project created, that project will be enabled with a list of MRN known by the project manager. At Partners there is a defined request for data, it is defined by a specific set of patients. At CHB it also has to be project based, they will need a similar structure. |
− | ** Once they have the list of | + | ** Once they have the list of MRNs, they go to the mi2b2 server to request the images. Images will be sent to the mi2b2 cache then sent back to the user's image location (they can store it where they want: local drive, server). We could set up the workbench so it does the move of the images. Users need to move the data to the specific location because we don't want the cache to get jammed. They must specify a location that has enough disk space for the images. If there is too much traffic, cache management will be crucial. Images will be encrypted as long as they stay in the temporary space then be unencrypted when sent to the specified location. |
Latest revision as of 20:33, 11 April 2011
Home < CTSC:ARRA.040511Back to CTSC:ARRA supplement
Harvard Catalyst Medical Informatics group Meeting Minutes April 5, 2011
In attendance:
- Bill Wang
- Valerie Humblet
- Chris Herrick
- Shawn Murphy
- Steve Pieper
- Vincent Roch
- Darren Sack
- Charles McGow
- Alex Zeitsev
- Bill Hanlon (phone)
- Kathy Andriole (phone)
- Mark Anderson (phone)
mi2b2 software update
- Continue working on multi PACS. Bill and Chris worked out interaction with UI, need to pass back and forward institutions
- Working on getting BWH up and running. Kathy said that it is fine to have the server in Needham.
- Started options for encryption-decryption of images. Dave looked at what is supported through image J. DICOM images should work fine, offer format must be tested.
- Baby brain project at MGH: Bill satisfied with testing, he identified a couple of issues to be fixed.
- Structured reports are still missing, they don't show up in the move. One thing to do is to check the format of those reports, maybe they are pdf, maybe they are text only in DICOM.
- Time out issue: how we processed images now is c-move initiated, we wait for response and check if we got the right images. If the initiator does not get a response under 375 sec, the connection is dropped. It seems that PACS still send the images but it is not synchronized. The team is changing the logic and will put together a monitoring progress to send a message that an initiation was created.
Planning for upcoming months
- For June/July: we want to have self-service enabled: vision for grant: PI can get DICOM from clinical PACS through self-service. Want to have a group able to use it (examples: Ron and Steve for MS MRI and Todd Perlstein and Valerie for vascular US)
- Structure:
- User is distributed the mi2b2 workbench. Must be ready to run on PC and MAC. We are assuming the it is inside firewall, on approved clients.
- mi2b2 server component that is running the mi2b2 cell
- i2b2 server: project management server. This component will communicate directly with the user. Each time for every detailed request, it will be a new project created, that project will be enabled with a list of MRN known by the project manager. At Partners there is a defined request for data, it is defined by a specific set of patients. At CHB it also has to be project based, they will need a similar structure.
- Once they have the list of MRNs, they go to the mi2b2 server to request the images. Images will be sent to the mi2b2 cache then sent back to the user's image location (they can store it where they want: local drive, server). We could set up the workbench so it does the move of the images. Users need to move the data to the specific location because we don't want the cache to get jammed. They must specify a location that has enough disk space for the images. If there is too much traffic, cache management will be crucial. Images will be encrypted as long as they stay in the temporary space then be unencrypted when sent to the specified location.