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

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

• Assembla SlicerRt ticket #125 for Patient Hierarchy
• Assembla SlicerRt ticket #55 for DICOM-RT export