AHM2013-PatientHierarchy
From NAMIC Wiki
Home < AHM2013-PatientHierarchy
Contents
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
- DICOM-independent patient concept (no database, no Uid, just the hierarchy)
- 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
- Incorporate type of relationship? (history + DICOM tag values to fill in the new data; replay "pipelnes")
- 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
