Monday, August 14, 2017

Better Image Review Workflows Part II: DICOM Spatial Registrations

I remember meeting with our colleagues at Varian's Imaging Lab a few years back, to discuss (among other things) better ways of using DICOM Spatial Registration Objects (SROs) to encode radiotherapy setup corrections.  They had been considering support for some advanced features, like 4D CBCT and dynamic DRR generation.  

It was clear that having a reliable DICOM RT Plan Instance UID and referenced Patient Setup module would be immensely useful in interpreting the setup corrections.   But where would this information be stored?  As private attributes in the CBCT slices?  Or in the SRO itself?  The treatment record contains this relationship for each treatment field, but there is no way of encoding a reference to a standalone setup image within the treatment record (or so I've been told)


Siemens has, for years now, used a DICOM Structured Report to encode offset values, in lieu of an SRO, at least for portal images.  I think skipping the SRO entirely was a mistake, but when I look at the state of RT SROs today, it seems in retrospect that a semantically meaningful Structured Report to pull together the other objects (SRO,  treatment record, CBCT slices) would be quite an advanced over current practice.  Looking at some of the defined IODs for structured reports:
  • Mammography CAD Structured Report
  • Chest CAD Structured Report
  • Acquisition Context Structured Report
it does not seem too far fetched to consider an SR encoding relationships among a CBCT or portal image and their context objects.

I've started (again) reading David Clunie's Structured Report book, in hopes of gaining more insight in what can (or should not) be encoded using SRs.  It seems like a quite powerful capability--I'm wondering why the RT domain has not made more use of it...

Better Image Review Workflows Part I: Zombie Apocalypse

I was reading a bit on the developing RayCare OIS, and wondered why an optimization algorithm company would have an interest in developing an enterprise oncology informatics system.

It doesn't take much to realize that oncology informatics is rife with opportunities for applying optimization expertise.  Analysis of the flood of data is only the most obvious benefit from expertise in machine learning and statistical inference.  But even the bread and butter of oncology informatics--managing daily workflows and data--could benefit from this expertise.

For the data generated by daily workflows to be meaningfully used, the workflows (and supporting infrastructure) must be efficient.  Such an infrastructure needs to support workflows involving various actors (both people and systems), as well as a consistent data model shared by the actors to represent the entities participating in the workflows.

The DICOM Information Model for radiotherapy provides a relatively consistent, if somewhat incomplete (yet), model of how data is produced and consumed during RT treatment.  Such a data model can be used to help streamline workflows, as a semantically consistent data stream can be used as the input to the fabled prefetcher (see Clunie's zombie apocalypse scenario), in order to ensure the right data is available at the right time.  And. if we know enough about the workflows (i.e. what processing needs to be done; what areas of interest are to be reviewed), then we can even prepare this before hand, so when the reviewer picks the next item from the worklist, it is all ready to go.

So if RayCare's OIS can make use of some optimization expertise to build a better autonomous prefetch algorithm (and the associated pre-processing and softcopy presentation state determination algorithms), this would probably be a pretty nifty trick.

But getting all the sources of data to fit in to the DICOM information model, or (even better) fixing the DICOM information model to make it more suited for purpose, seems to be the big hiccup here.  Maybe having RayCare also working on the problem, things will begin to advance.  That's what free markets do, and we all want free markets, right?

Friday, March 17, 2017

Better Image Review User Experience

In my previous post, I mentioned three aspects of image review that can be improved.  The first of these is improvements in the user experience during image review.

The increased use of image-guidance during the course of treatment represents a significant source of knowledge about the delivery, but also an additional burden on daily routines.  The subjective tedium of working through a list of images can be lightened by enhancing aspects of the review user experience.

Usability concerns that can be addressed include:
  • Color schemes that are better adjusted for visual analysis, for instance with darker colors
  • Animated transitions to facilitate visual parsing of state changes, such as pop-up toolbars and changes in image selection
  • Use of spatial layout to convey semantic relationships, as in thumbnail and carousel presentations of images in temporal succession
  • Progressive rendering and dynamic resizing of image elements, to minimize variations in the availability of network resources
Combining these techniques in a single workspace can produce a compelling user experience for image review.



A number of architectural patterns are used to support these techniques.  Examples of these patterns are contained in the PheonixRt.Mvvm prototype.

Onnx