Difference between revisions of "2017 Winter Project Week/dcmqi"

From NAMIC Wiki
Jump to: navigation, search
 
(6 intermediate revisions by 4 users not shown)
Line 14: Line 14:
 
* Andras Lasso, Queen's
 
* Andras Lasso, Queen's
 
* Csaba Pinter, Queen's
 
* Csaba Pinter, Queen's
 +
* Curt Lisle, KnowledgeVis, LLC
 +
* Teodora Szasz, University of Chicago
  
 
==Project Description==
 
==Project Description==
Line 24: Line 26:
 
<!-- Objective bullet points -->
 
<!-- Objective bullet points -->
 
* Introduce dcmqi to the community
 
* Introduce dcmqi to the community
* demonstrate Quantitative Reporting extension
 
 
* improve documentation
 
* improve documentation
 
* discuss next steps and specific open issues
 
* discuss next steps and specific open issues
Line 32: Line 33:
 
* discuss pros and cons of integration as an external project into Slicer, and agree on the plan
 
* discuss pros and cons of integration as an external project into Slicer, and agree on the plan
 
* discuss the process of integration of new segmentation contexts by the user
 
* discuss the process of integration of new segmentation contexts by the user
* Terminology Editor
 
 
* passing DICOM instances to the converters
 
* passing DICOM instances to the converters
* support of units/quantities in Slicer
+
* support of units/quantities in Slicer (also see [https://www.slicer.org/wiki/Documentation/Labs/Units labs page])
* communication of measurements tables and integrated support into Slicer Table node (CSV/JSON/other approaches - see https://github.com/QIICR/QuantitativeReporting/issues/105)
 
 
|
 
|
 
<!-- Progress and Next steps bullet points (fill out at the end of project week -->
 
<!-- Progress and Next steps bullet points (fill out at the end of project week -->
*
+
* Discussions with the groups interested in exploring the use of DICOM for quantitative imaging research
 +
* Identified an alternative (improved, hopefully) approach for communicating measurements to the SR converter using CSV: CSV table for the measurement quantities + CSV or JSON for describing the column names
 +
* Discussed harmonization of the existing Units support in Slicer, and support of quantities/units for scalar volumes (only, for now); agreed that for now it makes sense to communicate per-volume quantity/units as MRML node attributes
 
|}
 
|}
  
Line 45: Line 46:
 
* dcmqi Slicer extension: https://www.slicer.org/wiki/Documentation/Nightly/Extensions/DCMQI
 
* dcmqi Slicer extension: https://www.slicer.org/wiki/Documentation/Nightly/Extensions/DCMQI
 
* DICOM4QI at RSNA2016: https://fedorov.gitbooks.io/rsna2016-qirr-dicom4qi/content/
 
* DICOM4QI at RSNA2016: https://fedorov.gitbooks.io/rsna2016-qirr-dicom4qi/content/
 +
* https://peerj.com/articles/2057/

Latest revision as of 15:58, 13 January 2017

Home < 2017 Winter Project Week < dcmqi

Key Investigators

  • Andrey Fedorov, BWH
  • Christian Herz, BWH
  • Steve Pieper, Isomics
  • Jean-Christophe Fillion-Robin, Kitware
  • Andras Lasso, Queen's
  • Csaba Pinter, Queen's
  • Curt Lisle, KnowledgeVis, LLC
  • Teodora Szasz, University of Chicago

Project Description

Objective Approach and Plan Progress and Next Steps
  • Introduce dcmqi to the community
  • improve documentation
  • discuss next steps and specific open issues
  • Present, meet collaborators...
  • discuss pros and cons of integration as an external project into Slicer, and agree on the plan
  • discuss the process of integration of new segmentation contexts by the user
  • passing DICOM instances to the converters
  • support of units/quantities in Slicer (also see labs page)
  • Discussions with the groups interested in exploring the use of DICOM for quantitative imaging research
  • Identified an alternative (improved, hopefully) approach for communicating measurements to the SR converter using CSV: CSV table for the measurement quantities + CSV or JSON for describing the column names
  • Discussed harmonization of the existing Units support in Slicer, and support of quantities/units for scalar volumes (only, for now); agreed that for now it makes sense to communicate per-volume quantity/units as MRML node attributes

Background and References