Kris T. Huang, MD, PhD, CTO
Legacy systems, technical debt, and the advantage of starting (mostly) from scratch
In the midst of COVID-19, at Pymedix we’re busy working on 3D medical imaging software for the future of medicine, and we’re gearing up to test our Autofuse pilot product under real-world conditions. Our roots are in radiation oncology, but our perspective is the future of cancer imaging, and medical imaging. We have the strange and wonderful task of thinking inside the box, from the outside of the box. And, being a startup, we started (mostly) from scratch.
It sounds daunting to build clinical software from the ground up, but it’s actually a rare opportunity to step back, survey the landscape, map out technical and clinical lessons from the past (legacy), and thoughtfully craft the solution the future calls for. Not just change for the sake of change.
Yesterday’s technology… today!
Image credit: Wikipedia
The most visible example of this is the user interface. The plethora of dials and knobs of yesterday’s mainframes has generally been replaced with… a plethora of virtual dials, knobs, buttons, and menus on our screens. Images of certain radiation treatment planning-related systems come to mind. This is the natural result of the complexity of what we do with clinical imaging. A very superficial list of functions for radiation oncology might include:
- Contouring therapeutic target structures
- Contouring normal organ structures to be avoided/spared
- Algebraically manipulate structures to create new ones
- Combine information from multiple scans, to help perform #1 and #2
- Propagate contours from #1 and 2 to multiple scans
- Assess motion
- Assess potential error of #4 (and #5)
- Accumulate/propagate dose from prior treatments
And, of course, we want to do all of these somewhat disparate things as accurately, quickly, and automatically as possible. Over time a product, through evolutionary development, might tack on features incrementally, with a result akin to the following diagram:
An example of design gone wrong, from The Design of Everyday Things, by Don Norman
In the short list above, 7 of the 8 functions require an awareness of the image contents, and the last 5 additionally require direct spatial correspondence, or image registration. If you consider #1 and 2 (segmentation) to be a subset of the registration problem, we arrive at an interesting train of thought, with proof left as an exercise for the reader:
Image segmentation is concerned with the borders of certain image contents.
Corollary 1. Image segmentation requires awareness of the image contents.
Image registration is concerned with the general spatial correspondence of image contents.
Image registration requires general awareness of the image contents.
Image segmentation is a subset of the image registration problem.
A good portion of radiation therapy planning is actually an exercise in image registration.
Truly solid image registration, therefore, is requisite to automating the planning process up to the point of actual plan generation. It changes the paradigm from thinking about scans as separate entities to considering each scan as another aspect or time point of a single patient entity. Imagine that – focusing on the patient, rather than fiddling with data!
The automation enabled by image registration is also requisite to simplifying the user interface. The dependency runs deep, and it affects many subsequent design decisions. Here we run into a concept related to legacy systems – technical debt.
Here again, starting from a clean slate allows us to design Autofuse with an awareness of existing solutions without the constraints they impose. This is not to be confused with reinventing the wheel, related to Not-Invented-Here (NIH) syndrome. Take for example our Boolean contour builder – imagine a simple yet powerful visual tool that allows building nested Boolean expressions and margins of unlimited complexity… without the expressions!
It’s just the beginning.