Difference between revisions of "AHM2013-PatientHierarchy"

From NAMIC Wiki
Jump to: navigation, search
m
m
 
(4 intermediate revisions by 2 users not shown)
Line 23: Line 23:
 
<br />
 
<br />
  
 +
[[Image:DICOM_relationship_hierarchy.jpg|400px]]
 +
 +
Figure from Kahn CE, Langlotz CP, Channin DS, Rubin DL. Informatics in radiology: an information model of the DICOM standard. Radiographics : a review publication of the Radiological Society of North America, Inc. 2011;31(1):295–304.
 +
 +
<br />
 +
== Meeting minutes ==
 +
* Rename InstanceUid to Uid
 +
* Split PatientHierarchy concept?
 +
** DICOM-independent patient concept (no database, no Uid, just the hierarchy)<br />Experiment-based: less hospital-based, more research (CaseHierarchy?)
 +
**  DicomPatientHierarchy with DICOM-specific attributes
 +
**  tags instead of class types for the hierarchies
 +
*  Use cases
 +
** Original: visual grouping, preserving special attributes, automatic placing of derived/new data, finding corresponding data (color table for an isodose model set, transform for dose volume, etc.)
 +
** Transform the whole patient
 +
* CLI handling PH
 +
**  Extend XML syntax to specify roles
 +
**  Hidden parameter containing the related nodes (CLI doesn't know about the whole scene; similarly to ModelMaker)
 +
**  Add logic to put the output under the same hierarchy as the input? (like in the case of Transforms)
 +
* Derived data
 +
**  Incorporate type of relationship? (history + DICOM tag values to fill in the new data; replay "pipelnes")
 +
*** Use parameter nodes to store processing details (input, outpur, parameters)
 +
**  Possibility of specifying target hierarchy
 +
**  Allow creating new default hierarchy if the data wasn't loaded from DICOM
 +
*** Default hierarchy when starting Slicer?
 +
***  Or allowing no hierarchy just like in the case of Models
 +
**  Keep record of all the inputs? (reference volume, transform, ...) <- parameter nodes?
 +
**  Drag&drop new data under other hierarchy node<br />Maybe fixing ambiguous or wrongly loaded hierarchy branches (empty patient name/ID problem)
 +
**  Create new nodes (new patient, new study)
 +
**  If base data is not modified we use the Uid of that one for the derived object
 +
* Use the tree representation to display them in the slice viewers<br />'Right click -> show in all slice viewers' instead of 'link viewers -> change foreground'
 +
* Export
 +
**  User accesses this function from the PH tree (right click -> export ?)
 +
**  Register actions to nodes (like Edit properties, we would have Export)
 +
* Actions to take
 +
**  Make it general (tags instead of levels? multiple tags? replace all hierarchy types eventually?), extensible
 +
**  Add comments in the code of possible limitations and extend
 +
**  Move utility functions to a logic
 +
* Conclusion
 +
** Consensus: PatientHierarchy is useful and necessary
 +
** The implementation should be more general, flexible and extensible
 +
 +
<br />
 
== References ==
 
== References ==
 
* [https://www.assembla.com/spaces/slicerrt/tickets/125#/activity/ticket: Assembla SlicerRt ticket #125 for Patient Hierarchy]
 
* [https://www.assembla.com/spaces/slicerrt/tickets/125#/activity/ticket: Assembla SlicerRt ticket #125 for Patient Hierarchy]
 
* [https://www.assembla.com/spaces/slicerrt/tickets/55#/activity/ticket: Assembla SlicerRt ticket #55 for DICOM-RT export]
 
* [https://www.assembla.com/spaces/slicerrt/tickets/55#/activity/ticket: Assembla SlicerRt ticket #55 for DICOM-RT export]

Latest revision as of 16:04, 9 January 2013

Home < AHM2013-PatientHierarchy

Attendees

  • Alex Yarmarkovich
  • Andrey Fedorov
  • Csaba Pinter
  • Greg Sharp
  • Jean-Christophe Fillion-Robin
  • Julien Finet
  • Jim Miller
  • Kevin Wang
  • Nicole Aucoin
  • Steve Pieper


Agenda

  • Presenting the already implemented parts of Patient Hierarchy - Csaba
    • Showing what has been done and why
    • Further ideas
  • Getting feedback about the implementation
    • Possible mistakes, bottlenecks
    • Future-proofing
    • Identifying limitations that persist and need to be handled
  • Discuss DICOM export mechanism - Kevin
  • Creating action plan


DICOM relationship hierarchy.jpg

Figure from Kahn CE, Langlotz CP, Channin DS, Rubin DL. Informatics in radiology: an information model of the DICOM standard. Radiographics : a review publication of the Radiological Society of North America, Inc. 2011;31(1):295–304.


Meeting minutes

  • Rename InstanceUid to Uid
  • Split PatientHierarchy concept?
    • DICOM-independent patient concept (no database, no Uid, just the hierarchy)
      Experiment-based: less hospital-based, more research (CaseHierarchy?)
    • DicomPatientHierarchy with DICOM-specific attributes
    • tags instead of class types for the hierarchies
  • Use cases
    • Original: visual grouping, preserving special attributes, automatic placing of derived/new data, finding corresponding data (color table for an isodose model set, transform for dose volume, etc.)
    • Transform the whole patient
  • CLI handling PH
    • Extend XML syntax to specify roles
    • Hidden parameter containing the related nodes (CLI doesn't know about the whole scene; similarly to ModelMaker)
    • Add logic to put the output under the same hierarchy as the input? (like in the case of Transforms)
  • Derived data
    • Incorporate type of relationship? (history + DICOM tag values to fill in the new data; replay "pipelnes")
      • Use parameter nodes to store processing details (input, outpur, parameters)
    • Possibility of specifying target hierarchy
    • Allow creating new default hierarchy if the data wasn't loaded from DICOM
      • Default hierarchy when starting Slicer?
      • Or allowing no hierarchy just like in the case of Models
    • Keep record of all the inputs? (reference volume, transform, ...) <- parameter nodes?
    • Drag&drop new data under other hierarchy node
      Maybe fixing ambiguous or wrongly loaded hierarchy branches (empty patient name/ID problem)
    • Create new nodes (new patient, new study)
    • If base data is not modified we use the Uid of that one for the derived object
  • Use the tree representation to display them in the slice viewers
    'Right click -> show in all slice viewers' instead of 'link viewers -> change foreground'
  • Export
    • User accesses this function from the PH tree (right click -> export ?)
    • Register actions to nodes (like Edit properties, we would have Export)
  • Actions to take
    • Make it general (tags instead of levels? multiple tags? replace all hierarchy types eventually?), extensible
    • Add comments in the code of possible limitations and extend
    • Move utility functions to a logic
  • Conclusion
    • Consensus: PatientHierarchy is useful and necessary
    • The implementation should be more general, flexible and extensible


References