Design/requirements for the initial version of the new Reporting module

[fedorov]

There should be different modes of operation for annotation vs viewing (from existing SR data).

Annotation mode:

• Save intermediate results as the user does annotation for fault-tolerance (not DICOM representation in the user-visible database interface)
• When user explicitly confirms completion or exists the module, export SEG and SR - when user finalizes
• (note for the future) maintain predecessor reference (DICOM thing) - for SR only, perhaps can be used to differentiate SEGs as well
• If predecessor concept is used, only the final version of the report is exposed to the user in the interface
• Import DICOM image series
• On entering the module - prompt the user what datasets in the scene can be annotated (only those that were imported from DICOM)
• Use Segmentations Editor for annotation
• Only volumetric/pixel labeling annotations
• Provide interface for selecting terminology of the structure being annotated (Csaba is working on this)
• Calculate measurements when interaction is done - just the basic measurements (as in Label Statics)
• use Table node for storing the measurement results, displaying the table and organizing the measurements in the SubjectHierarchy module
• SR complete/partial - verified/unverified - initially, set it to complete+verified when user is done
• when user clicks on the structure in the list, re-center the view
• take the best features as makes sense from the mpReview module (center on click, solid vs outline shortcuts, window/level)

[fedorov]

let's do prototype in this one? http://pencil.evolus.vn/Features.html

[fedorov]

initial iteration, done in Pencil

Source file and screenshot are also available https://github.com/fedorov/Reporting/tree/v2-design/Doc/design

@che85 can you join the QIICR hangout tomorrow to have some brainstorming about this? If you have any suggestions/iterations before that, they are definitely welcomed, but I prefer to have an early prototype and early discussion then waiting for another 2 weeks.

[che85]

Looks good to me. Anyway it was better, that you created the first draft because you had a more concrete idea of all this than me. I will be joining the QIICR call.

[fedorov]

I agree - that's what I thought too!

[fedorov]

Notes from the discussion at the QIICR hangout Sept 16, 2016:

• @pieper about MRML node - may make sense to use a ScriptedModule MRML node with the JSON content; can constraint node selector by an attribute.
• Consider using Table node for content of the measurement report?
• Add capability to plot the measurements in the table and configure the layout to include the plot

[pieper]

Here's a module for handling a bunch of measurements using a json attribute
of a mrml node:

https://github.com/DCBIA-OrthoLab/AnglePlanes-Extension/tree/master/AnglePlanes

On Thu, Sep 15, 2016 at 10:34 AM, Andrey Fedorov notifications@github.com
wrote:

Notes from the discussion at the QIICR hangout Sept 16, 2016:

• @pieper https://github.com/pieper about MRML node - may make sense
  to use a ScriptedModule MRML node with the JSON content; can constraint
  node selector by an attribute.
• Consider using Table node for content of the measurement report?
• Add capability to plot the measurements in the table and configure
  the layout to include the plot

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#74 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAHsfVrIQ_b-Mhvgl4X-Tkq9H2oCmJ34ks5qqVeBgaJpZM4J71wD
.

[fedorov]

Questions from @che85

1. What would the measurement report selector display in the first place? A new vtkMRMLScriptedModuleNode?After saving a report

It should give an option to create new (that is defined by a flag on node selector widget). After saving, it will remain the same. After finalizing, everything should probably become locked/read only, and switch to a view mode.

1. Where do I get those measurements from? JSON file? If so, where would it be selected?

While creating the new report, they will come from some statistics tool. We have LabelStatistics module, and it will need to be augmented to allow execution from a scripted module (not sure it can be done right now) and to communicate quantity/units etc codes. It may take some thinking how to design the architecture to allow measurement plugins, but in the beginning it may make sense to keep measurement calculator fixed.

1. What exactly is TrackingID? Maybe the name of the segment?

Tracking ID is a human-readable identifier of the measurement group. It does not need to be unique. We should have a way to initialize it automatically, but allow user to modify it if needed (as an advanced option).

Now that you asked, I remembered that we worked to add Tracking ID and UID to the segmentation object itself, and the corresponding CP-1496 has become standard. We need to add this to dcmqi, I created an issue QIICR/dcmqi#87.

1. Quantity 1 would be what? Where do we get the information from? Measurements report? What would it be in the first place? Or really just those values from label statistics?

For the measurements loaded from DICOM, Quantity 1 will be Code Meaning from the report, as in https://github.com/QIICR/dcmqi/blob/master/doc/sr-tid1500-ct-liver-example.json#L48 (another action item on dcmqi side is converter from SR to JSON metafile QIICR/dcmqi#88). For the newly created reports, as I mentioned above, the measurement calculator will need to supply this for the new report.

1. The user interface for viewing, would it be the same with disabled components? I could imagine having two modes (Annotation, Reading or something similar) where the basic components would be the same like segmentations, measurements, but we would have different selectors. What do you think?

I think to make it prettier, we can remove certain components from the layout that are irrelevant, such as editing tools. I am also wondering how customizable is the Segmentations list widget. We should look in more detail when you get there. For the initial iteration, it is ok to keep the UI the same for viewing.

Going forward, let's keep questions like this on github, so we can have a chance to go back and revisit our thinking (and also make it available for review for the other collaborators and prospective users).

[che85]

@fedorov Which effects should I hide from the segmentation editor?

Right now I reorganized it like that:

[che85]

@fedorov when using predecessor concept, how would you detect the final(most recent) version of the report? Basically you can only depend on those being stored in the SlicerDICOMDatabase and you would have to iterate through all SRs for the patient of the current SR and climb up the chain of references....

[che85]

@fedorov Another thing is: How would you want to save the intermediate results?

[che85]

Any further thoughts on this issue, otherwise let's close it?

[fedorov]

@che85

when using predecessor concept, how would you detect the final(most recent) version of the report? Basically you can only depend on those being stored in the SlicerDICOMDatabase and you would have to iterate through all SRs for the patient of the current SR and climb up the chain of references....

Yes, I agree, I don't know of a better way.

How would you want to save the intermediate results?

I have to admit I don't recall what exactly I was thinking at the time I put this in the initial issue. I think maintaining non-DICOM representation in some temporary space is too cumbersome, so let's not do it.