Difference between revisions of "CTSC:ARRA.061510"
From NAMIC Wiki
RandyGollub (talk | contribs) |
|||
(3 intermediate revisions by 2 users not shown) | |||
Line 31: | Line 31: | ||
*'''mi2b2 STAR-D site installation update:''' | *'''mi2b2 STAR-D site installation update:''' | ||
** Progress: able to retrieve image from DCM4chee amazon instance to middle layer using cmove and upload to i2b2 file repository - | ** Progress: able to retrieve image from DCM4chee amazon instance to middle layer using cmove and upload to i2b2 file repository - | ||
− | ** next phase: | + | ** next phase: developing user interface design and working logic into that new design. |
** Chris and Shawn talked with Mike Darcy at USC (BIRN) about what they're doing. They are using dcm4chee as a caching mechanism -- their problem is that there is no delete command for dcm4chee... (but this exists on the console, so Steve, Chris feel this functionality must be there somewhere?) | ** Chris and Shawn talked with Mike Darcy at USC (BIRN) about what they're doing. They are using dcm4chee as a caching mechanism -- their problem is that there is no delete command for dcm4chee... (but this exists on the console, so Steve, Chris feel this functionality must be there somewhere?) | ||
** Discuss another tool called "PixelMed" - another free dicom software package, but more limited than DCM4che. | ** Discuss another tool called "PixelMed" - another free dicom software package, but more limited than DCM4che. | ||
Line 40: | Line 40: | ||
*'''advisory board meeting preparation''' | *'''advisory board meeting preparation''' | ||
** Goals is to present where we are with each clinical site, including how close are we to being able to deliver images, and what are our plans for the next six months. | ** Goals is to present where we are with each clinical site, including how close are we to being able to deliver images, and what are our plans for the next six months. | ||
− | ** | + | ** We will let them know that we are only moving test images for the next six months during development. |
− | ** | + | ** The test images we will work with will include real patient images, all modalities, including moving files over to the XNAT development instance. |
** We will not be supporting an actual study at this point -- just in testing phase. | ** We will not be supporting an actual study at this point -- just in testing phase. | ||
** Collaborations with WashU: XNAT people are off preparing their example for how to receive images from mi2b2 STAR-D using webservices. | ** Collaborations with WashU: XNAT people are off preparing their example for how to receive images from mi2b2 STAR-D using webservices. | ||
*** Their example will tell us how to describe image data of interest using an xml wrapper | *** Their example will tell us how to describe image data of interest using an xml wrapper | ||
*** log in and be authenticated. | *** log in and be authenticated. | ||
− | *** upload it using webservices API (this should be pretty close. | + | *** upload it using webservices API (this should be pretty close). |
*** send our team the play-by-play 'how-to' documentation. | *** send our team the play-by-play 'how-to' documentation. | ||
** How will mi2b2 and XNAT coordinate authentication? | ** How will mi2b2 and XNAT coordinate authentication? | ||
*** STAR-D has images. May want to send them to Project A, Project B, or Project C on XNAT. | *** STAR-D has images. May want to send them to Project A, Project B, or Project C on XNAT. | ||
− | *** STAR-D has an administrative password for XNAT. It will use that admin password to | + | *** STAR-D has an administrative password for XNAT. It will use that admin password to communicate with XNAT. |
*** STAR-D will request a sessionID giving user name and password: XNAT will give access to any project with compatible permissions. | *** STAR-D will request a sessionID giving user name and password: XNAT will give access to any project with compatible permissions. | ||
** Keeping an Audit Trail: Should we generate an audit trail that lists | ** Keeping an Audit Trail: Should we generate an audit trail that lists | ||
Line 76: | Line 76: | ||
# select studies of interest from results | # select studies of interest from results | ||
− | To pick up next time: what are the minimal steps needed to streamline the use? How to format the data for maximum readability? How to minimize the clutter (e.g. don't show studies more than 5 years old, only query for one modality, etc) | + | Wendy and Cynthia will continue discussion after meeting to schematize the workflow fleshed out today. Plan is to refine the schematic to: |
+ | * identify ways to simplify workflow | ||
+ | * make sure workflow accommodates likely shortcuts | ||
+ | * solidify helpful concepts we want users to learn | ||
+ | * define appropriate navigation scheme to drive workflow | ||
+ | * make sure we use consistent language appropriate to user community | ||
+ | * develop design drawings from there. | ||
+ | |||
+ | To pick up next time: what are the minimal steps needed to streamline the use? How to format the data for maximum readability? How to minimize the clutter (e.g. don't show studies more than 5 years old, only query for one modality, etc) Go over workflow schematics. |
Latest revision as of 03:38, 17 June 2010
Home < CTSC:ARRA.061510Back to CTSC:ARRA supplement
Agenda
- mi2b2 installation update
- preparation for advisory board meeting.
- mi2b2 UI & UXP
Harvard Catalyst Medical Informatics group Meeting Minutes June 15, 2010
In attendance:
- Shawn Murphy
- Bill Wang
- Cynthia Lee
- Steve Pieper
- Yong Gao
- Chris Herrick
- Wendy Plesniak
- Darren Sack
- Charles McGow
- Valerie Humblet
- Jesse Wei
- Mark Anderson (by phone)
- Karl Helmer (by phone)
Meeting Minutes
- mi2b2 STAR-D site installation update:
- Progress: able to retrieve image from DCM4chee amazon instance to middle layer using cmove and upload to i2b2 file repository -
- next phase: developing user interface design and working logic into that new design.
- Chris and Shawn talked with Mike Darcy at USC (BIRN) about what they're doing. They are using dcm4chee as a caching mechanism -- their problem is that there is no delete command for dcm4chee... (but this exists on the console, so Steve, Chris feel this functionality must be there somewhere?)
- Discuss another tool called "PixelMed" - another free dicom software package, but more limited than DCM4che.
- Steve also describes a C++ dicom toolkit dcmtk.
- Generally mi2b2 STAR-D prototype software is progressing as expected.
- advisory board meeting preparation
- Goals is to present where we are with each clinical site, including how close are we to being able to deliver images, and what are our plans for the next six months.
- We will let them know that we are only moving test images for the next six months during development.
- The test images we will work with will include real patient images, all modalities, including moving files over to the XNAT development instance.
- We will not be supporting an actual study at this point -- just in testing phase.
- Collaborations with WashU: XNAT people are off preparing their example for how to receive images from mi2b2 STAR-D using webservices.
- Their example will tell us how to describe image data of interest using an xml wrapper
- log in and be authenticated.
- upload it using webservices API (this should be pretty close).
- send our team the play-by-play 'how-to' documentation.
- How will mi2b2 and XNAT coordinate authentication?
- STAR-D has images. May want to send them to Project A, Project B, or Project C on XNAT.
- STAR-D has an administrative password for XNAT. It will use that admin password to communicate with XNAT.
- STAR-D will request a sessionID giving user name and password: XNAT will give access to any project with compatible permissions.
- Keeping an Audit Trail: Should we generate an audit trail that lists
- who accessed,
- what data was retreived and
- and where it went?
- No UI issues yet for the advisory board.
- UI design and concepts
- Win Song developing UI software
- Cynthia will develop drawings
- Wendy will clarify concepts and workflow.
- Two possible entry points:
- already in i2b2 world. Here, you get a dataMart consisting only of patients you are permitted to see. Never constrained by study.
- user is "on his honor" can get any MRN that he pleases. Can be provided with a list of many, many patients. (user knows that this transaction will be audited).
- Note: at Partners, user group is educated, CITI certified, and understand the patient privacy issues. The software can't rely upon this however -- other sites may have different policies.
- Steps for executing a generic query:
- login and pick project
- enter MRN or list of MRNs (assume that any legitimate user of the tool will already know MRNs and has no need to lookup by patient name - can use i2b2 for that)
- MRN used by STAR-D to query PACS
- PACS returns demographic information (one per MRN)
- user sees patient name, date of birth, gender... for each MRN (info stays loaded in client as moving between tabs but goes away when client app exits)
- select studies of interest from results
Wendy and Cynthia will continue discussion after meeting to schematize the workflow fleshed out today. Plan is to refine the schematic to:
- identify ways to simplify workflow
- make sure workflow accommodates likely shortcuts
- solidify helpful concepts we want users to learn
- define appropriate navigation scheme to drive workflow
- make sure we use consistent language appropriate to user community
- develop design drawings from there.
To pick up next time: what are the minimal steps needed to streamline the use? How to format the data for maximum readability? How to minimize the clutter (e.g. don't show studies more than 5 years old, only query for one modality, etc) Go over workflow schematics.