Storage of measurements and qualitative evalutions on ROI objects

[hackermd]

Do we want to store ROI Measurements or Qualitative Evaluations on ROI objects?

[hackermd]

Related to #4

[swederik]

Yeah that seems like a good idea.

With Cornerstone we are storing some tool-specific information like e.g. length, area for each measurement inside the ROI. It would probably be useful to automatically compute them for each type of ROI, but I guess we would have to ask a pathologist which information would be valuable.

However, this would require the ability to define where and how these should be displayed as text. Do we want to handle this in the library or require an application to do this?

I think we should do this at the library and provide sensible defaults, but allow the display function to be configured for each type of annotation (or possibly each annotation itself). Lots of cases have come up where people want to have custom labels, e.g. showing the annotator name that made the measurement, showing the target # for the lesion for the clinical trial, switching the label to another language, but probably 95% of people are using the default "Area X mmˆ2".

[hackermd]

@swederik I agree that it could be useful to automatically compute measurements; however, here I was more generally referring to the ability to store measurements on the ROI object and how we may approach this.

According to TID 1411 Volumetric ROI Measurements and Qualitative Evaluations, each Measurement Group contains a reference to one volume. A ROI object is thus similar to a Measurement Group:

A grouping of related measurements and calculations that share a common context.

Therefore, I thought we could store the information for content items of TID 1411 Volumetric ROI Measurements and Qualitative Evaluations on the ROI objects, including the actual ROI Measurements as defined in TID 1419 ROI Measurements as well as other items, such as Unique Tracking Identifier or Activity Session.

Alternatively, we could let an application (e.g. OHIF) handle all of this and provide such functionality outside of the viewer library (e.g. in the dcmjs microscopy adapter.)

[pieper]

Yes, this makes sense. @swederik and I were digging through this a lot while working on converting the crowds-cure.org data into SR and it would have been great if all the data needed to create a Measurement Group were in the same place and all used the coded concepts for direct serialization.

[hackermd]

To me, it feels like these things should live in dcmjs rather than dicom-microscopy-viewer, because the same code could then be reused across projects/applications.

The viewer would then only handle the "bare" spatial coordinates (as it does at the moment). All other high-level information (e.g. measurements) would then be handled at the application-level (potentially using common tools provided via the dcmjs library).

What do you think?

[pieper]

Yes, abstracting measurements away from the specific imaging modalities sounds good. To the extent possible I'd want the in-memory data structure (application state) to mirror the SR encoding as closely as possible so that edits to that state, say from a widget/tool or from editing a parameter form, would be kept in sync and the state could be serialized back to a dicom encoding whenever needed.