IGSTK supports development of image-guided surgery applications that are classical examples of safety-critical applications. As a mechanism for preventing patient’s harm, the architecture is based on the concept of safety-by-design. In particular, the IGSTK team followed a component-based architecture7
and used state machine8
software design methodologies. Every IGSTK component has a well-defined set of features that are governed by state machines. The state machine ensures that the component is always in a valid state and all state transitions are valid and meaningful. Figure shows the state machine implementation for the tracker component (the IGSTK components will be described later in this section).
State machine for IGSTK tracker component showing the four states in black and the transitions in blue.
In a component-based architecture, the main capabilities are broken down into functional components with well-defined interfaces for inter-component communication. This type of architecture has several benefits when developing a reliable and robust toolkit. Breaking down the complex functionalities into smaller pieces makes implementation manageable and makes it possible to enforce higher standards of quality control. It is much easier to thoroughly test small components with well-defined interfaces than to test medium or large size components with myriads of features and convoluted interfaces. Consequently, complexity and implementation details are encapsulated in the component level and hidden from the application developer or user. This encapsulation allows IGSTK to better manage the inherent complexity of an image-guided surgery system. Furthermore, testing is easier at the component level compared to traditional procedural software thereby increasing the quality of the software. Application developers can also use some of the components independently in their application without the need to integrate the full toolkit. This should increase the adoption of the software and subsequently benefit the user community. Lastly, a component-based architecture is suitable for structured toolkit extension. This will encourage users to extend the toolkit by adding new components and by contributing them back to the community.
A state machine is defined by a set of states, a set of inputs, and a set of directed transitions from state to state. Each IGSTK component is subjected to state machine control. Incorporation of state machines has enhanced the reliability of the toolkit for the following reasons. State machines can ensure that the components have deterministic behavior at all times and are always in a known and error-free state. Formal validation9
of the software can be undertaken because inputs, states, and transitions are well defined and are finite. This framework is suitable for automated testing. Interaction between the user and other applications can be explicitly defined using state machines reducing the possibility of design and implementation flows in application development. In summary, state machines ensure safety and reliability, cleaner design, application programming interface (API) simplicity, consistent integration pattern, and allow quality control. State machines can also prevent the misuse of components and help manage complexity, traceability, and testing.
IGSTK components are implemented using the C++ programming language. The component implementations are mostly based on ITK and VTK classes subjected to a strict state machine control. IGSTK components however do not expose ITK or VTK classes in their public interface. This exposure is avoided to increase the level of safety of the components. Interactions with the ITK and VTK classes are done only inside the IGSTK components and only under the supervision of the state machine.
The IGSTK architecture is shown in Figure . The main components in IGSTK are presented in the following list, and a short description of each component is given:
- View (Display)
- Spatial objects (geometric representation)
- Spatial object representation (visual representation)
IGSTK component architecture.
Viewers display the graphical representations of the renderings of surgical scenes. Surgeons perform their task by visualizing the information provided in the viewers. Furthermore, the view components serve as a link between the graphical user interface library and the rest of the IGSTK toolkit.
Spatial Objects (Geometrical Representation)
Spatial objects define a common structure for geometrical objects in IGSTK. The spatial objects hold the shapes and physical locations of objects in the surgical environment. IGSTK spatial objects encapsulate ITK spatial objects in a restrictive API. Spatial objects provided by IGSTK include objects such as axes, boxes, cones, cylinders, images, ellipsoids, meshes, tubes, and vascular networks.
Spatial Object Representation (Visual Representation)
Spatial object representations characterize the graphical representations of the spatial object. The graphical representations dictate how an object should be displayed on the screen. This will include specifying color, opacity, and other rendering properties.
The tracker component handles the communication between tracking tools and tracking devices to get position, orientation, and other relevant information from surgical instruments present in the scene. The tracking component encapsulates the tracking tool, tracking device, and all static and dynamic information associated with tracking.
Readers bring data into the scene generation and representation process. The most important readers in IGSTK are the Digital Imaging and Communications in Medicine (DICOM) image reader classes. These classes are used to read preoperative and intraoperative scans for surgical planning and guidance. Validity check logic is implemented in these classes to avoid incorrect file reads and 3D volume generation. Additional readers are available also for loading mesh and calibration data.
In addition to the above main components, IGSTK has a collection of infrastructure and service classes. The infrastructure classes include state machines, events, pulse generators, and real-time clock generator classes. Service classes include loggers, registration, and calibration classes. Loggers are useful for post-analysis of surgical procedures and recovery from a failure. Integrating loggers into applications streamlines and expedites the application development process and also provides a suitable framework for verification and validation.
Another service class in IGSTK is the registration class. This class computes the spatial transformation between the patient and the coordinate systems of the multiple image data sets that may be present in the scene, including preoperative and intraoperative images. Finally, a calibration class is available to measure the most important point of a surgical instrument relative to the position of the tracked element on the tool attached to the instrument.
Putting It All Together
To demonstrate how the components can be integrated to develop an application, we will discuss an example image-guided needle biopsy application developed using IGSTK.
Needle biopsy is a medical procedure intended >to take a sample of tissue from a lump or tumor or other abnormal growth in the body with the purpose of performing a pathological analysis. An interventional radiologist will insert a needle into the tumor and take a tissue sample. This is a common procedure for cancer diagnosis. It is critical to ensure that the needle reaches the target that has been identified from the images.
In this application, the patient is positioned on the CT table, a CT image is acquired, and the location of the pathological tissue is identified on the images. A landmark-based registration technique is then used for registering the image coordinate system to the patient coordinate system. During the biopsy procedure, a computer graphics-generated representation of the surgical scene is presented in the display and is updated with the current position and orientation of the needle as they are continuously reported by a tracker. The workflow of this application is outlined below.
- Record patient demographic information
- Acquire and transfer CT image to the image-guided system
- Identify landmark points in the image using the mouse. A minimum of three noncollinear landmark points are required.
- Initialize the tracking device
- Identify the corresponding landmarks in the physical body using the tracker pointing device
- Perform registration to compute the transformation from patient to preoperative image
- Identify entry point and target position for needle path planning
- Start tracking.
When tracking is started, an updated position of the needle is displayed and overlaid on the CT image. The radiologist can then manipulate the needle, watching the virtual image, until the needle reaches the target. A confirming CT image can then be acquired.
For this example application, a Polaris Vicra optical tracker (Northern Digital, Ontario, Canada) was used. Testing was performed using an abdominal phantom (CIRS Model 57, Norfolk, VA). The application set up is shown in Figure . Figure shows the user interface, which consists of a control panel and four standardized views: axial, sagittal, coronal, and a 3D view. The four view windows show CT images of the abdominal phantom with the overlay of the biopsy needle path. The green cylinder represents the needle as tracked by the Polaris Vicra Tracker. The four views automatically re-slice and update the images to show the needle tip position as it moves in the patient’s anatomy.
Needle biopsy application system setup.
Graphical user interface for the needle biopsy application.