View source for Projects:QIN:3D Slicer Annotation Image Markup:Design and Implementation

AM = annotations+markup

=Implementation considerations=
* We will use existing annotation hierarchies to organize the AM. AM will be organized into findings that will be located in the hierarchy under a particular volume. Each volume can have separate findings. Each finding can be assigned to only one volume.
* We are focused on the support of markup in 2D slices; 3D view annotations are secondary.
* The functionality needed to support connection between the data and AM will be added to Slicer core. User-level interactions will be available in a separate module.
* Markup is defined relative to the active slice of the active volume. AIM/DICOM SR do not have a notion of 3D coordinate space (needs verification). Slicer annotations will be restricted to be in-slice for the use cases of this project.

==Markups to be supported==
These will be decided based on the existing requirements from the use cases provided by the QIN community, and based on the existing capabilities of the AIM-enabled tools (OsiriX and ClearCanvas TCGA workstation). The tentative list in the order of priorities (not finalized):
# Ruler (measurement)
# Marker (OsiriX/ClearCanvas: callout?; 3D Slicer: fiducial (can we consider arrow, fiducial + orientation, in the future?))
# Polyline
# Ellipsoid/rectangle
# Text annotation (fiducial?)
# Angle

=User-level Workflow=

=Implementation-level Workflow=

=GUI module design=

=Implementation task list=
Finalized:
# Add functionality to track the UID of the DICOM volume based on the current volume and IJK coordinates
# Add links between AM (hierarchy? finding?) and parent volume

To be discussed:
# IO support and details
# New/missing markup widgets
# Annotation template import and GUI

=Discussion points=
* From the QIN prospective, it seems to be more important to have a complete set of markups in-slice, without focusing on the support of 3d viever visualization. Is this OK with the Slicer development strategy?