Difference between revisions of "CTSC:ARRA.061510"

From NAMIC Wiki
Jump to: navigation, search
 
(17 intermediate revisions by 3 users not shown)
Line 6: Line 6:
 
* mi2b2 installation update
 
* mi2b2 installation update
 
* preparation for advisory board meeting.
 
* preparation for advisory board meeting.
 +
* mi2b2 UI & UXP
  
 
<br>
 
<br>
−
== Harvard Catalyst Medical Informatics group Meeting Minutes June 8, 2010 ==
+
== Harvard Catalyst Medical Informatics group Meeting Minutes June 15, 2010 ==
  
 
In attendance:
 
In attendance:
Line 23: Line 24:
 
* Jesse Wei
 
* Jesse Wei
 
* Mark Anderson (by phone)
 
* Mark Anderson (by phone)
−
* Carl (by phone)
+
* Karl Helmer (by phone)
 
<br>
 
<br>
  
Line 29: Line 30:
 
<br>
 
<br>
 
*'''mi2b2 STAR-D site installation update:'''     
 
*'''mi2b2 STAR-D site installation update:'''     
−
** Progress: able to retrieve image to middle layer using cmove, upload to file repository -
+
** Progress: able to retrieve image from DCM4chee amazon instance to middle layer using cmove and upload to i2b2 file repository -
−
** next phase: taking user interface design and working logic into that new design.
+
** next phase: developing user interface design and working logic into that new design.
−
** talked with Mike Darcy at USC about what they're doing. They are using dcm4chee as a caching mechanism -- 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"
+
** Discuss another tool called "PixelMed" - another free dicom software package, but more limited than DCM4che.
−
** Steve also describes dcmtk.
+
** Steve also describes a C++ dicom toolkit [http://dicom.offis.de dcmtk].
 +
** Generally mi2b2 STAR-D prototype software is progressing as expected.
  
 
<br>
 
<br>
 
*'''advisory board meeting preparation'''  
 
*'''advisory board meeting preparation'''  
−
** want to present where we are with each site
+
** 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.
−
** how close are we to being able to deliver
+
** We will let them know that we are only moving test images for the next six months during development.
−
** what are our plans for the next six months.
+
** The test images we will work with will include real patient images, all modalities, including moving files over to the XNAT development instance.
−
** Shawn wants to be able to say we are only moving test images for the next six months during testing.
 
−
** These are real patients, all modalities, move things over to XNAT.
 
 
** 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.
−
** 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.
−
*** take image data
+
*** Their example will tell us how to describe image data of interest using an xml wrapper
−
*** assemble it with xml wrapper
+
*** 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?
 +
*** 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.
 +
 +
 +
<br>
 +
*'''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.

Latest revision as of 03:38, 17 June 2010

Home < CTSC:ARRA.061510

Back 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:
  1. login and pick project
  2. 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)
    1. MRN used by STAR-D to query PACS
    2. PACS returns demographic information (one per MRN)
  3. 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)
  4. 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.

Retrieved from "https://www.na-mic.org/w/index.php?title=CTSC:ARRA.061510&oldid=54314"