Difference between revisions of "CTSC:ARRA.070610"

From NAMIC Wiki
Jump to: navigation, search
(Created page with 'Back to CTSC:ARRA supplement <br> '''Agenda''' * Update * uxp and UI design: workflow analysis <br> == Harvard Catalyst Medical Informatics group Meeting Minutes July 6, …')
 
 
(3 intermediate revisions by the same user not shown)
Line 29: Line 29:
  
 
== Meeting Minutes ==
 
== Meeting Minutes ==
 +
 +
===Update===
 +
 +
* Chris and Bill continue to do the testing of the phase 2 software. Each PACS will need to register 2 ports for the software. The query/retrieve (C-FIND) is running on 1 port (real-time query) and the image retrieve (C-MOVE) is using another port (this is a step that takes longer, images are not sent instantly to the user, it needs a listener). The phase 2 software should be ready to deploy next week at the different sites.
 +
* STAR-D will be centrally located, it is important to make sure that several users will be able to use it at the same time.
 +
* Once we start using multiple PACS we will have to see how many ports will be needed.
 +
 +
=== Workflow analysis===
 +
 +
* Recap from last week presentation: there are 3 steps (site selection and finding patients; finding studies and destination selection; transfer and view )performed in series but an user will be able to log in and jump to any step depending on what he saved during his last session (what is savable? The scoutlist, the patient list, the study set, the individual images).
 +
* Scout list vs patient list: a scout list is a list of MRN that the user will type to see if they are in the system. He will get back a list of MRN found (the patient list, confirmed present at the site searched) vs not found.
 +
* Is there a need for a scout study list? Yes, some people will already have a list of accession numbers that they want to refine into a study set. Investigators must be able to jump into step 2 (finding studies and destination selection), some of them might have used another mechanism than step 1 to get the accession numbers.
 +
* What is filtrable? Many people ask to retrieve images by date and MRN. Another filtering concept to consider is the modality.
 +
* What is persistent? We want to keep a clean break between data coming from i2b2 and data coming from other sources. If needed (for example when searching by modality), we might have to insert some of the i2b2 ontology tools for both sources.
 +
* Darren mentioned that some PACS (such as cardio) might not generate a specific ID like the radiology PACS. There will thus be an option to append data from the different PACS at the same institution. Ex: PI searches MGH cardiology PACS, get a patient list. He will then reload the same MRN into MGH oncology PACS and append the results.

Latest revision as of 19:25, 7 July 2010

Home < CTSC:ARRA.070610

Back to CTSC:ARRA supplement

Agenda

  • Update
  • uxp and UI design: workflow analysis


Harvard Catalyst Medical Informatics group Meeting Minutes July 6, 2010

In attendance:

  • Valerie Humblet
  • Bill Wang
  • Wendy Plesniak
  • Chris Herrick
  • Darren Sack
  • Shawn Murphy
  • Cynthia Lee
  • Charles Mc Govern
  • Mark Anderson
  • Alex Zeitsev
  • Yong Gao
  • Bill Tellier (phone)
  • Paul Lamonica (phone)
  • Katie Andriole (phone)


Meeting Minutes

Update

  • Chris and Bill continue to do the testing of the phase 2 software. Each PACS will need to register 2 ports for the software. The query/retrieve (C-FIND) is running on 1 port (real-time query) and the image retrieve (C-MOVE) is using another port (this is a step that takes longer, images are not sent instantly to the user, it needs a listener). The phase 2 software should be ready to deploy next week at the different sites.
  • STAR-D will be centrally located, it is important to make sure that several users will be able to use it at the same time.
  • Once we start using multiple PACS we will have to see how many ports will be needed.

Workflow analysis

  • Recap from last week presentation: there are 3 steps (site selection and finding patients; finding studies and destination selection; transfer and view )performed in series but an user will be able to log in and jump to any step depending on what he saved during his last session (what is savable? The scoutlist, the patient list, the study set, the individual images).
  • Scout list vs patient list: a scout list is a list of MRN that the user will type to see if they are in the system. He will get back a list of MRN found (the patient list, confirmed present at the site searched) vs not found.
  • Is there a need for a scout study list? Yes, some people will already have a list of accession numbers that they want to refine into a study set. Investigators must be able to jump into step 2 (finding studies and destination selection), some of them might have used another mechanism than step 1 to get the accession numbers.
  • What is filtrable? Many people ask to retrieve images by date and MRN. Another filtering concept to consider is the modality.
  • What is persistent? We want to keep a clean break between data coming from i2b2 and data coming from other sources. If needed (for example when searching by modality), we might have to insert some of the i2b2 ontology tools for both sources.
  • Darren mentioned that some PACS (such as cardio) might not generate a specific ID like the radiology PACS. There will thus be an option to append data from the different PACS at the same institution. Ex: PI searches MGH cardiology PACS, get a patient list. He will then reload the same MRN into MGH oncology PACS and append the results.