This thrust was newly organized in year 6 to consolidate the many infrastructure activities that were previously performed, as well as adding new ones. Its role in our overall strategy is to promote maximum sharing of research results by working closely with projects within thrusts and providing architectural guidance and shared infrastructure for research and implementation efforts.

The decision to formalize these activities as a thrust provides more cohesion and strengthens their contribution to the entire range of the Centers research strategy. The Center has now developed a sufficient critical mass of professional engineering staff to manage and execute the development of common interfaces, standards, software libraries, and subsystems. Administratively, this thrust provides a home for the Centers cadre of professional engineering staff and for students who are new to the ERC and have not yet become associated with a specific research project

The objective of this task is to support the other two thrusts while creating hardware and software artifacts of enduring value. Our strategy is to focus our infrastructure development on four key areas:

Distributed System Architecture: Our goal is to define system architectures and standardized interfaces that enable the integration of medical components into sophisticated CIS applications.

Visualization and Application Control Software: We selected the 3D Slicer software package that was originally developed at MIT as a Tool Command Language (TCL)-based interaction shell for medical visualization tasks. It is supported and distributed on an open source basis by the Surgical Planning Lab at Brigham and Womens Hospital. We are developing other application control systems for cases that do not require the visualization capabilities of 3D Slicer.

Medical Robot Controller: We developed the Medical Robot Controller (MRC) software to provide a common programming interface to multiple types of surgical robots and are using it to control several robots within the ERC. Our strategy is to evolve this software into a robust, flexible and extensible open source software system for use throughout the research community. We are also developing various controller platforms using off-the-shelf and custom hardware.

Computer Integrated Surgery Software Library: This library consists of modules that provide common services (e.g., messaging, data logging, exceptions and error handling), 2D and 3D data types (e.g., vectors, matrices, transformations), tracking system interfaces (optical, electromagnetic), geometric meshes, numerical methods, registration techniques (e.g., iterative closest point) and some image processing functions. Our strategy is to continue to build this library by incorporating software from the research thrusts. The incorporation process includes peer review, development of automated test methods and (possibly) modification to conform to architectural and/or programming guidelines.

We seek to avoid duplicating components that are readily available elsewhere. For example, the National Library of Medicines Insight Toolkit (ITK) provides a comprehensive set of image processing functions. Our goal is to write software that uses these toolkits or is compatible with them.

The most notable accomplishments in the past year were the maturation of the Computer Integrated Surgery software libraries, now called the cisst libraries, as well as the proliferation of the Medical Robot Controller hardware and software to several projects, as described below.

The Distributed System Architecture received increased focus two years ago with the formation of a System Architecture & Middleware group that meets every two to three weeks. This group is composed of faculty, staff and students from Johns Hopkins University (JHU) and Morgan State University (MSU). In the past year, the JHU investigators created an initial requirements document for Distributed Medical Devices and the MSU investigators created a testbed to evaluate different middleware standards against these requirements. The MSU investigators focused on CORBA (Common Object Request Broker Architecture) and SOAP (Simple Object Access Protocol), which are client/server protocols with wide industry support. The JHU investigators focused on publish/subscribe protocols, such as DDS (Data Distributed Services) and Spread (originally developed by Prof. Yair Amir of the JHU Computer Science Department). These protocols are less popular than CORBA and SOAP but are targeted at systems that require real-time data exchange. Currently, one of Professor Amirs graduate students is evaluating the suitability of Spread for medical devices by creating an implementation based on our system requirements.

We are using 3D Slicer (www.slicer.org) for much of the Visualization and Application Control Software. It integrates several facets of image-guided medicine into a single environment: automatic registration (aligning data sets); semi-automatic segmentation (extracting structures such as vessels and tumors from the data); generation of 3D surface models (for viewing the segmented structures); 3D visualization; and quantitative analysis (measuring distances, angles, surface areas, and volumes) of various medical scans. The visualization framework is based on the Visualization Toolkit (VTK), while the user interface and scripting capabilities are implemented with TCL. We are also developing alternative systems for applications that do not require 3D Slicer. At the most recent site visit, we demonstrated a 3D stereoscopic visualization system that integrates surgical microscope images and robot control. We also implemented an Interactive Robot Environment (IRE), which includes a Python interface to our underlying C++ software and is targeted at rapid prototyping and interactive development.

In the past year, we developed the real-time foundations necessary for our new Medical Robot Controller (MRC-II) software. We selected the Real Time Application Interface (RTAI) for Linux as our real-time operating system, but created an operating system abstraction layer (library) for portability to other systems. We defined a device dependent interface class for hardware interfaces. Our real time support library provides a task class, which includes a real-time thread, an instance of a device dependent interface, an input mailbox and a state data table. This class also inherits from the device dependent interface class, which allows tasks and devices to be used interchangeably. This satisfies the requirement that our software transparently support both intelligent hardware, such as motion control boards, and non-intelligent hardware, such as simple I/O boards. We used the new MRC-II software for the snake robot for laryngeal surgery (JHU and Columbia University), the daVinci-based testbed for haptic research (JHU) and an RCM robot (BWH). We are currently porting Micron (CMU) from an intelligent data acquisition board, with a proprietary software environment, to a standard PC with RTAI/Linux and our real-time foundation software.

On the hardware side, we support both off-the-shelf and custom controller electronics, with an emphasis on low cost, high performance and high reliability. In the past year, we added the Ethernet-based Galil motion controller (DMC-21X3) to our list of supported hardware and used it for two projects. We also designed and built Rev 2 of our Low Power Motor Controller (LoPoMoCo), which is a 6-layer printed circuit board (PCB) that provides all I/O and power amplification necessary to control four small DC motors. This custom hardware was originally designed to satisfy specific requirements for the snake robot for laryngeal surgery, but we are now using it for the daVinci-based testbed and the RCM robot mentioned above. The Rev 2 hardware supports higher power motors and contains additional I/O, such as zero index and limit switch inputs.

We have an extensive Computer Integrated Surgery Software Library, written in C++, which has been developed over many years. In the past year, we made significant progress towards completion of a major revision of the CIS library, which we now call the cisst libraries. At the time of this report, the cisstCommon, cisstVector and cisstNumerical libraries have reached maturity and are being used for many new projects within the ERC. These libraries provide common tools such as logging, error and exception handling, serialization, class and object registries and Python embedding (cisstCommon), vectors and matrices (fixed size and dynamic), quaternions and transformations in 2D/3D (cisstVector), and an interface to the CLAPACK numerical methods as well as numerical tools such as polynomials (cisstNumerical). The cisstOSAbstraction, cisstDeviceInterface and cisstRealTimelibraries, described in the Medical Robot Controller section, are in active development and are being used for projects that require real-time performance.

We developed the cisst libraries by following the software development procedure that we defined in the previous year. This procedure includes documentation, programming standards, test suites and an audit trail. Although a formal development process is generally not necessary for a specific research project, it is appropriate when the goal is to create core modules or platforms that support diverse research projects. Furthermore, the formal development process and associated documentation should facilitate Institutional Review Board (IRB) approval for clinical trials.

Achieving our vision of a broad family of related surgical CAD/CAM and surgical assistant systems necessarily requires a strong and open systems infrastructure of versatile components and subsystems. Engineering research results must be embodied in robust, modular and reusable software and hardware components and subsystems. Further, standard interfaces are essential for collaboration, both within the ERC and between the ERC and other researchers and industrial companies.

Task 1 of each thrust is explicitly devoted to systems and clinical test beds. However, these are not independent activities; they all rest upon common architectures and shared components. It is explicitly expected that technology and subsystems developed in one thrust will be used in other thrusts. Ensuring that this happens requires a common control point for architecture definition, software library maintenance, shared laboratory infrastructure, and other elements.