Experience Programming Radiotherapy Applications in

Common Lisp
1
Ira J. Kalet, Ph.D. , Jonathan M. Unger, M.S. , Jonathan P. Jacky, Ph.D. ,
2 1
Mark H. Phillips, Ph.D.
1
1 Radiation Oncology Dept., University of Washington, Seattle, WA 98195
2 RSA, Inc., 22 Terry Ave., Burlington, MA 01803

We report on our experience using Common Lisp [1] as the user can bring up simultaneously any number of these or other
programming language for a new radiation treatment planning component-specic panels during the Prism session.
(RTP) system, the Prism system [2]. The Prism system was
built to provide new features such as articial intelligence tools Design goals
and to take advantage of the most advanced computer graphic
display and networking technologies. We decided to use Lisp
because of: its high level of expressive power, the existence
of a direct interface to the X window system for network-based
graphic display, its standardization and its wide availability. Al-
In addition to the specic user requirements, we set out design
goals. They include:
 keeping the overall size of our programs small, so they
will take less time to build and maintain,
though Lisp is one of the oldest programming languages, in the  ease of nding and xing problems,
past its use had been limited to articial intelligence research.
It was not widely available, and Lisp compilers of the time were
not able to generate highly ecient binary code. Modern Lisp
systems have eliminated these obstacles, and added powerful
object oriented programming capabilities, along with standard-
ization, so that Common Lisp can be a powerful and practical
system implementation language for interactive graphic appli-
cations like radiation treatment planning.
THE PRISM SYSTEM
Prism takes a very generalized approach to display and user ma-
nipulation of the system, extending ideas we incorporated into
our previous work. The unique features of Prism are described
in another publication [2].
User interface requirements
The Prism system user interface is distributed among several
 ease of adding new features and extending existing ones,
 ability to add new kinds of objects,
 ability to add new kinds of control panels.
These items are examples of the need for software evolution,
a need that is dicult to satisfy, even using object-oriented de-
sign and object-oriented programming languages.
Architecture: objects and relationships
Our previous work [3] showed that RTP systems can be nat-
urally modeled as collections of interacting objects, radiation
beams, organs, etc. In Prism too, we chose an object-oriented
design. The patient, the treatment equipment, and all their
parts are represented as objects in the Common Lisp Object
System.
The patient case is the overall \container" object in the
Prism system. The other objects are parts or components of
the patient case. We have modeled some RTP object classes
task-specic windows we call panels, which act as a front end as subclasses. For example, there is a class, pstruct, that de-
for those components of the system which actually carry out
various functions related to radiotherapy planning.
The interface is designed to provide as little nesting of in-
teractions as possible, that is, we want almost all operations
to be available to the user at all times. On the other hand,
presenting a display with visible controls for every adjustable
parameter of every object would be impossible. So our com-
promise is to associate a type of control panel, or object editor,
with each type of object that the user can create or modify. A
control panel is a window on the screen that includes controls,
e.g., dials for angles, sliders for adjustable numbers, text input
boxes for typed text, etc. so that when the control panel for
a particular object is displayed, the user can at any time alter
nes a general three-dimensional anatomic object, and there
are subclasses for organs, tumors and targets. All have con-
toured volumes, a display color, etc., but each subclass has ad-
ditional attributes that represent special characteristics, e.g.,
organs may have a density, for use in the dose calculation.
We also make extensive use of the part-of relationship, in
which an attribute of an object may have as its value an in-
stance or collection of instances of another object class. For
example, a radiation beam is modeled as an object that in-
cludes a collimator subsystem as a component attribute. There
are dierent classes of collimators, but only one class, beam for
a radiation beam.
As an example of how we implement these objects, the fol-
any of those attributes of the object.
A patient panel that manages administrative information
about the current patient case is always present in a given
Prism session. Individual panels for plans, beams and other
component objects control their respective domains, and view
windows display graphical renditions of patient anatomy and
beam portals. A graphic editing panel provides for the delin-
lowing shows the code that denes the beam class.
(defclass beam (generic-prism-object)
((machine :type string
:documentation "The string naming the
machine used for this beam, eg. Clinac 2500-6MV")
(new-machine :type event :initform (make-event))
eation and modication of patient anatomy, tumors and targets. (gantry-angle :type single-float)
The plan panel includes controls for the specication, compu- (new-gantry-angle :type event
tation and display of dosimetric information for a plan. The :initform (make-event))
 (collimator :type collimator
:documentation "An object, one of the
various types of collimators.")
(collimator-angle :type single-float)
(new-coll-angle :type event
:initform (make-event))
(monitor-units :type single-float)
...etc... ))
The type declarations are not required but help the com-
piler produce faster, more ecient code. Documentation strings
up to a point. Objects modeled as abstract data types (classes)
can abstract and encapsulate attributes and operations on ob-
jects. But in a dynamic system, objects have actions that may
aect other objects. The internal code of object implementa-
tions will then refer to other objects, and the result is that the
objects are no longer independent and modular. Managing this
interdependence in writing a large program like an RTP system
is very dicult.
Sullivan and Notkin [4] argue that the generalization of ab-
stract data types (ADT) to include action interfaces, or ab-
stract behavioral types (ABT), provides improved correspon-
are parts of an object and can be accessed by a running pro- dence between specications and designs, improved abstraction
gram. They are data, not comments. We are considering us- and encapsulation, and behavioral composability of indepen-
ing this facility or something like it to incorporate context- dent types. This is particularly important in dynamic model-
dependent online help in the Prism system. The types string ing, where a software system must provide for the creation and
and single-float are the usual types you nd in most pro- destruction not only of objects but of relationships between
gramming languages, but an event is a type dened in the them. The use of ABT provides a way to model such actions
Prism system, to provide connections between objects. An ob- while retaining encapsulation.
ject announces an event, and other objects can respond. The The potential of this approach to software design was suf-
responses depend on what is registered with the event while the
program is running.
The collimator type is also a class, with subclasses for
dierent types of collimators. Here are some of the collimator
subclasses.
ciently appealing that we decided to use it in designing and
implementing the Prism system. We expected that behavioral
abstraction would result in a simpler, more modular design
than the use of object-oriented design and programming alone.
A separate report [5] describes how this approach worked out
in building the Prism system. In this report we address the
(defclass symmetric-jaw-coll (collimator) specic choice of Lisp as our implementation language and its
((x :type single-float) contribution to the success of Prism.
(y :type single-float)
(new-coll-x :type event
:initform (make-event)
:documentation
WHY LISP?
"Announced when x is updated.")
In choosing a programming language for Prism, we considered
(new-coll-y ...))
several characteristics to be important. The language we use
(:default-initargs :x 10.0 :y 10.0))
must support:
 object-oriented programming,
This class denition provides default values when a new
collimator is created, to insure that the attributes always have
valid values.
(defclass portal-coll (collimator contour)
()
(:default-initargs :z 0.0
:vertices '((-5 -5) (5 -5)
(5 5) (-5 5)))
(:documentation "A collimator that has a portal,
defined by a contour. The contour is
always at z = 0."))
The class portal-coll adds no new slots or attributes, but
combines the properties of the collimator and the contour
 the X window system, for graphic display and user inter-
action,
 a high level of abstraction,
 building large systems, i.e., programs that are large and
complex, and that can handle very large amounts of data
and numbers of objects,
 deployment in an application environment, i.e., routine
use in the clinic, not just an experimental lashup to be
used only by physicists.
Few languages meet all of these requirements. The obvious
choice of most designers these days is C++ but it does not pro-
vide as good an object-oriented programming environment as
classes, since a portal collimator has a portal dened by a con- Common Lisp, nor does it provide a very high level of abstrac-
tour. tion. We were not looking for \a better C". Before committing
to development in Common Lisp, we reviewed the limitations
(defclass electron-coll (portal-coll) we experienced with our earlier work, and did some prototyping
((cone-size :type single-float that helped determine the feasibility of using Lisp.
:documentation "An electron collimator
is a square cone with a Lisp in the light of previous work
metal cutout plate.") Our earlier work [3] used the Pascal programming language. It
...other slots...)) was dicult because there are no facilities in Pascal for dening
Adding a slot for specifying the cone in use allows for spe-
cialized methods, e.g., for the user to select the cone size from
exible (it was dicult to add new object
a menu, and for the dose computation to look up tables based
on cone size.
Object-oriented design provides a way to make a close cor-
respondence between the real world and the software system,
abstract objects, i.e., classes, and for dening generic functions
for those objects. Although we created a workaround for our
RTP system, it was in
classes), and hard to understand, because the implementation
had much code devoted to object management and function dis-
patch. This obscured the actual application, the radiotherapy
objects and their operations.
 We had some prior experience with Lisp, in writing an ex- programmer does not need to provide any code for formatted
pert system program for automating part of the radiation treat- or binary le reading. Prism takes advantage of this in storing
ment planning process [6]. That program did not have a graph- patient and plan data and retrieving it for reuse.
ical user interface and did not provide any of the complex data Prism objects contain many dierent types of data as values
management characteristic of RTP systems. Interlisp, the di- of their attributes. The data are all stored as ASCII text, us-
alect of Lisp that we rst used, was not a good candidate for an ing the Lisp write function. It formats the data automatically,
RTP system, as it did not have an ecient compiler (compiled without need for the programmer to do anything. The Prism
code ran slowly), it did not include support for the emerging function put-object executes the same code regardless of the
X window system, and although very large programs had been type or complexity of the object. It obtains the names of the
written using Interlisp, it was not well suited to writing pro- attributes of an object from its class denition, and writes all
grams for routine use by non-programmers. the attributes without concern for order or type.
The emergence of Common Lisp as a standard and widely When data are read back into a Prism session, the corre-
supported commercial product was a radical change. Common sponding function get-object executes the same code regard-
Lisp implementations became available that had very ecient
compilers, support for X windows (there is a de facto stan-
dard Common Lisp binding to the X window system, CLX,
and a public domain implementation is available), facilities
for application deployment, and an excellent standard object-
oriented programming system, the Common Lisp Object Sys-
tem (CLOS). Growing use of Lisp in serious applications has
less of what is read. The le contains data identifying the type
of the object and the get-object code calls the standard CLOS
function make-instance to make one. Then get-object reads
keywords naming the attributes, and then reads values whose
type is automatically known to Lisp by the format of the data.
This alone represents a huge saving in code, where in our
previous systems we had to write a lot of detailed code to han-
resulted in the formation of the Association of Lisp Users1 . dle the plan data le formats. It also makes it easy to add new
Lisp is used in the video game software industry, as well as in kinds of objects: the old les are not made obsolete, and no
software products such as AutoCAD and Interleaf, and as an new le reading and writing code needs to be written.
HTML server2 . An example of the use of multi-methods is the Prism draw
We wrote some prototype user interface code to experiment generic function. There are many places where an object needs
with the graphical performance of Common Lisp programs. to be drawn into a view. Neither the type of object nor the type
Satised with its performance, we discarded this code, and be-
gan in earnest to design and write the Prism system.
Characteristics of Lisp
In deciding to write the Prism software in Lisp, we expected
to take advantage of the ability to create layered designs, in
which the programmer constructs supplements to the language
as needed. In addition to meeting the criteria described above,
Lisp has features and characteristics that make it radically
dierent from all the more familiar programming languages.
These features are important in writing RTP software; they
of view is xed, and at the same place in the program, but at
dierent times during a Prism session, this function may need to
draw dierent objects into various types of views. The function
call is (draw object view) where object is some Prism ob-
ject, a beam perhaps, and view is a view on the screen, maybe
a transverse view. In general, in Prism, the types of the argu-
ments are not known at compile time, and may even vary as
the Prism session progresses.
Many object-oriented programming languages use method
dispatch on the type of a single parameter, i.e., a method is a
piece of code that implements a function for a particular class
are not just exotica that articial intelligence researchers play
with. In Prism the following features proved to be especially
useful:
 Run-time types: Lisp can determine the type of a piece
of data at run-time, and act accordingly. We take ad-
vantage of this to make the storage and retrieval of RTP
plan data very simple.
 Multi-methods: In the Common Lisp Object System,
methods for generic functions can be selected at run-time
based on the type of any number of arguments.
 Lexical closures: Lisp code can create new functions while
the program is running. This may be very unfamiliar to
most programmers, because it is impossible to do in most
programming languages, but it is very powerful. It is ex-
plained in Graham's book [1, pages 1{2].
Prism uses other unusual features of Lisp, too numerous to
go into here. We refer the interested reader to some excellent
books that explain Lisp programming in depth [1, 7].
Examples of advanced techniques
We include here some examples of Prism code that uses special
or advanced features of Lisp.
of object, and we say that the method \belongs" to that class.
This is analogous to the idea of \sending a message to an ob-
ject" in order to invoke a function. So there would be draw
methods for each of the dierent object classes. But what
about the dierent kinds of views? It is complicated. Per-
haps there will be a multiway branch inside the code for each
draw method. Then adding a new object means writing a big
method, and adding a new kind of view means modifying a lot
of dierent modules.
Instead, the Common Lisp Object System provides dispatch
on any number of parameters, so the draw function can have
methods organized according to the types of both parameters,
i.e., there is a method for each combination. Here is an excerpt
of a method for drawing an organ:
(defmethod draw ((org organ) (tv transverse-view))
(let ((prim (find org (foreground tv) ...))
...)
(dolist (con (contours org))
(let ((pts (pixel-contour (vertices con)
scale x0 y0)))
(push (nconc pts (list (first pts) (second pts)))
(points prim))))))
The Lisp function read can read text from a le and con- Drawing a dierent object, such as a beam, requires a dier-
struct the right type of object from the format of the le. The ent method for the draw function. The beam drawing method
1 refer to http://www.cs.rochester.edu/u/miller/ALU/home.html
2 in particular, for the White House Publications distribution system via the World Wide Web
uses a formula for projecting and transforming a portal contour
in arbitrary orientation, and also has to render the other items
in the beam depiction, the isocenter, the central axis, and a
wedge if present.
(defmethod draw ((b beam) (v view))
(let ((solid-clr (display-color b))
...
(wdg (wedge b)))
...beam portal drawing code...))
from Pascal or C, and the extra eort required to optimize the
performance of the system.
Overall, the choice of Common Lisp was a good one and
Prism is successful, having been in clinical use for over two
years. The system continues to evolve and is easy to maintain.
In the future we hope to explore the possibility of devel-
oping a more high level implementation, something along the
lines of the \Compiler TP" idea of Sterling [9], analogous to
the CLOS Meta-Object Protocol [10]. Imagine an RTP sys-
tem with all the standard features, and a high level dynamic
RTP macro programming language built in, for adding features
The nal example we provide from Prism illustrates that
in Lisp a program can write and execute programs as needed.
The idea is that a function may be needed but what function
is needed may vary. It is possible in most programming lan-
guages to pass functions as parameters to other functions, but
in Lisp, a program can make up functions depending on condi-
tions in the program, something impossible to do in most other
languages. The following code
(add-notify m (inserted os)
#'(lambda (md obj-set obj)
(dolist (v (elements (view-set md)))
(insert-element (funcall mediator-fn obj v)
(mediator-set md))
registers the function whose code begins with lambda so that it
will be called when a new object is added (for example, a beam
to a plan) and the new object therefore has to appear in all the
views. This lambda function is a dierent function depending
on the type of object and the type of view, when it is added,
i.e., the function that gets registered is created by this code, not
just selected. This is how Prism keeps all the objects and views
coordinated, even though objects and views are being added
and deleted all the time during a Prism session.
RESULTS AND DISCUSSION
The Prism system consists of about 45,000 lines of Lisp source
code, making it similar in size to our two previous RTP systems,
written in the Pascal programming language. It is an order of
magnitude smaller than many other RTP systems, including
commercial products. However, the capabilities of Prism far
exceed any previous system we built. We have described else-
where [2] some of the unique features of Prism, not found in
any other RTP system of which we know.
The object oriented programming support in Common Lisp
enabled us to add facilities for modeling multileaf collimators
without modifying any existing code, and being able to use any
existing components. That is our vision for the future of Prism.
ACKNOWLEDGEMENTS
This work was partially supported by NIH grant no. LM04174
from the National Library of Medicine.
References
1. Paul Graham. ANSI Common Lisp. Prentice-Hall, Engle-
wood Clis, New Jersey 07632, 1996.
2. Ira J. Kalet, Jonathan P. Jacky, Mary M. Austin-Seymour,
Sharon M. Hummel, Kevin J. Sullivan, and Jonathan M.
Unger. Prism: A new approach to radiotherapy planning
software. International Journal of Radiation Oncology, Bi-
ology and Physics, 36(2):451{461, 1996.
3. Jonathan Jacky and Ira Kalet. An object-oriented pro-
gramming discipline for standard Pascal. Communications
of the ACM, 30(9):772{776, September 1987.
4. Kevin Sullivan and David Notkin. Reconciling environ-
ment integration and software evolution. ACM Transac-
tions on Software Engineering and Methods, 1(3):229{268,
July 1992.
5. Kevin J. Sullivan, Ira J. Kalet, and David Notkin. Evalu-
ating the mediator method: Prism as a case study. IEEE
Transactions on Software Engineering, 22(8):563{579, Au-
gust 1996.
6. Ira J. Kalet and Witold Paluszynski. Knowledge-based
computer systems for radiotherapy planning. American
Journal of Clinical Oncology, 13(4):344{351, 1990.
7. Paul Graham. On Lisp: Advanced Techniques for Common
Lisp. Prentice-Hall, Englewood Clis, New Jersey 07632,
1994.
8. S. Sutlief, M. Phillips, I. Kalet, and P. Cho. Integration
and for stereotactic radiosurgery, after the initial system was
put into clinical use. We are also adding support for intensity
modulated radiotherapy using a computer controlled multileaf
collimator [8, this volume].
Other advantages of Lisp include: ease of incorporating ad-
vanced software engineering design ideas such as the \media-
and verication of intensity modulated radiation therapy
into a computer treatment planning program (Prism). In
Dennis Leavitt and George Starkschall, editors, Proceedings
of the Twelfth International Conference on Computers in
Radiotherapy(ICCR), Madison, WI, 1997. Medical Physics
Publishing.
tor method" [5], ease of debugging, and simplied interactive
graphics programming, particularly the CLX package for X pro- 9. Theodor D. Sterling. Natural language compilers and in-
gramming. CLX is much less cluttered with low level details terpreters in radiation treatment planning or nous parlons
than the C binding for Xlib, even though it provides the same anglais better than jede andere sprache. In Ulf Rosenow,
and even more functionality. We nd Lisp programming to be editor, Proceedings of the Sixth International Conference
enjoyable and satisfying because with it we can express eas- on the Use of Computers in Radiation Therapy, pages 8{
ily our ideas and specications without becoming embroiled in 24, Gottingen, 1977.
arcane details unrelated to our application. 10. Gregor Kiczales, Jim des Rivieres, and Daniel G. Bobrow.
Some of the obstacles we had to work with include learn- The Art of the Metaobject Protocol. The MIT Press, Cam-
ing a new programming language whose style is very dierent bridge, Massachusetts, 1991.