Difference between revisions of "AHM2013-PatientHierarchy"

From NAMIC Wiki
Jump to: navigation, search
(Added meeting minutes)
m
 
Line 60: Line 60:
 
**  Add comments in the code of possible limitations and extend
 
**  Add comments in the code of possible limitations and extend
 
**  Move utility functions to a logic
 
**  Move utility functions to a logic
 +
* Conclusion
 +
** Consensus: PatientHierarchy is useful and necessary
 +
** The implementation should be more general, flexible and extensible
  
 
<br />
 
<br />

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