An Intracardiac Navigation Interface for
Electrophysiology Modelling Tools
by
Ojonimi A. Ocholi
Submitted to the Department of Electrical Engineering and Computer Science
in Partial Fulfillment of the Requirements for the Degrees of
Bachelor of Science in Electrical [Computer] Science and Engineering
and Master of Engineering in Electrical Engineering and Computer Science
at the Massachusetts Institute of Technology
May 24, 2006
Copyright 2006 Ojonimi A. Ocholi. All rights reserved.
The author hereby grants to M.I.T permission to reproduce and
distribute publicly paper and electronic copies of this thesis
and to grant others the right to do so.
Author
Department of
Electrical Engineering and Computer Science
May 20, 2006
Certified by
Pr
Research
--
Accepted by
William J. Long
ntist, MIT CSAIL
Thesis ,upervisor
K
Arthur C. Smith
Graduate Theses
on
Committee
Department
Chairman,
MASSACHUSElTS INSTmJTE
OF TECHNOLOGY
AUG 14 2006
LIBRARIES
BARKER
An Intracardiac Navigation Interface for
Electrophysiology Modelling Tools
by
Ojonimi A. Ocholi
Submitted to the
Department of Electrical Engineering and Computer Science
May 24, 2006
In Partial Fulfillment of the Requirements for the Degree of
Bachelor of Science in Computer [Electrical] Science and Engineering
and Master of Engineering in Electrical Engineering and Computer Science
ABSTRACT
This thesis describes an interface that has been developed to assist in medical procedures.
Several commercial systems are currently available each with their own strength and
weaknesses and the goal of this interface is to leverage each of them.
It is based upon a number of toolkits such as the Visualization Toolkit (VTK) and the
GUI development tool QT. To facilitate the rapid deployment of highly modular
applications, an Application Programming Interface (API) was created and modeled after
the Model-View-Controller paradigm. The interface was then built using this API into an
executable application and it provides various features such as accurate catheter
navigation and the registration of data from different sources. In addition, the interface
was used to investigate the accuracy of one commercial system (LocaLisa) with regards
to another (CARTO).
Thesis Supervisor: William J. Long
Title: Principal Research Scientist, MIT CSAIL
2
Acknowledgements
Many thanks to my advisor, Bill Long for being willing to oversee the research
I've done since junior year. If I have accomplished anything it is because of the
confidence you showed in me. I also want to thank my off-campus supervisor, Dr. Vivek
Reddy for giving me the opportunity to research at MGH. Your patience and guidance
are deeply appreciated.
Special thanks go to Zach Malchano and Ragu Vijaykumar for being the smartest
and coolest research group mates ever. I would not be writing this now if not for you
guys.
Finally, I thank my parents for their love and constant support over the last five
years and I thank my saviour Jesus Christ for giving me a reason to live. To all the people
I missed out from this list you know who you are and I am greatly indebted to you. Thank
you.
3
Contents
1 Introduction
9
1.1 Summary of Thesis Contents.....................................................
12
2 Background
13
2.1 The CARTO system..................................................................
14
2.2 The LocaLisa system................................................................
17
20
3 Myo Application Programming Interface
3.1 T oolkits...........................................................................
....
20
3.1.1 The Visualization Toolkit................................................
21
3.1.2 The Insight Segmentation and Registration Toolkit................
22
3.1.3 QT - A GUI development tool..........................................
22
3.2 Design and Development of the API.............................................
23
3.2.1 MyoControllers for the Model and View............................
28
3.2.2 Modular Communication................................................
29
3.2.3 Threading..................................................................
33
3.2.4 Visualization............................................................
35
4
38
4 The Myo Interface
4.1 The Catheter Module............................................................
43
4.2 The CARTO Module............................................................
48
4.3 The LocaLisa Module...........................................................
52
4.4 The Registration Module.......................................................
57
5 An investigation of the accuracy in LocaLisa
63
5 .1 R esu lts..............................................................................
65
5.2 C om ments.........................................................................
74
76
6 Conclusion
6.1 Summ ary..........................................................................
76
6.2 E xtensions.........................................................................
78
5
List of Figures
2-1 Catheter tip components, location determination through use of magnets and
rendering of different orientations. Courtesy[7]...........................................
15
2-2 Image of rendered points acquired with CARTO software. Mapping legend is on the
top right. C ourtesy[7]..........................................................................
15
2-3 Illustration of LocaLisa principle in one plane. Measured impedance changes as the
catheter moves from one electrode to the other. Courtesy[9]............................
18
2-4 Typical LocaLisa setup. Electrodes in three orthogonal planes and reference patch
connected to LocaLisa Machine. Machine connected to PC for data rendering.
C ourtesy [9 ]......................................................................................
18
3-1 Sample Application built with the QT framework. Courtesy [13]..................
23
3-2 Structure of the Interface. Several layers are needed to make development less
co mplex ...........................................................................................
25
3-3 Myo API top level hierarchy.............................................................
25
3-4 Myo API implementation of the Model-View-Controller paradigm................
27
3-5 Structure of Data within the Myo hierarchy...........................................
28
3-6 GUI items within the Myo hierarchy....................................................
29
3-7 Intra-modular communication. All classes are MyoControllers. A signal from the
ListView is reflected to the data in the backend...........................................
31
3-8 Inter-modular communication. An event from one module is processed by one which
listens for those events...........................................................................
33
3-9 Threading within the Myo Framework...................................................
34
6
3-10 The VTK pipeline. Source data is ultimately rendered as
vtkA ctors.........................................................................................
35
3-11 MyoWindow showing a VTK object..................................................
36
4-1 The M yo Interface..........................................................................
38
4-2 MyoPopupMenu selection options for Surface Models...............................
39
4-3 Myo Interface in 'float' mode...........................................................
40
4-4 Myo Interface in 'integrate' mode........................................................
41
4-5 MyoWindow showing clipping action. Toolbar buttons are above window and
modeless options dialog floating on left....................................................
42
4-6 Typical catheter representations - CARTO 8mm on the left. Lasso Catheter with ten
electrodes on the right. 6 electrodes are extrapolated.......................................
44
4-7 MyoPopupMenu selection for a Lasso Catheter......................................
46
4-8 TTSM in action. Option is selected from MyoPopupMenu on left. Target surface
model is selected from dialog on the right...................................................
47
4-9 TTSM in action. MyoWindow shows measurement in mm at bottom and also
projection of tip to surface of model.........................................................
48
4-10 MyoPopupMenu options for interaction with the CartoXP Server.................
51
4-11 MyoPopupMenu options for interaction with the LocaLisa Server................
55
4-12 LocaLisa Diagnostics Dialog in action..................................................
56
4-13 Registration with the Myo interface (1st of 3 figures). A. The Point maps and the
surface models are in different co-ordinate spaces. B. MyoPopupMenu with option for
creating new registration........................................................................
7
59
4-14 Registration with the Myo interface (2 "dof 3 figures). C. The Point maps and the
surface models are selected in the registration dialog. D. Registration thread runs in the
background after registration process is started.............................................
60
4-15 Registration with the Myo interface (3'd of 3 figures). E. The Point maps and the
surface models are now registered............................................................
61
4-16 MyoPopupMenu options for Registrations and Feedback of registration
statistics........................................................................................................................
62
5-1 Schematic of set-up for investigating LocaLisa accuracy.............................
63
5-2 3-D spatial representations of CARTO and LocaLisa Data. Day I above; Day 2
belo w ..............................................................................................
65
5-3 Graphs of LL v CARTO data along the X axis. Day 1 above; Day 2 below.......
66
5-4 Graphs of LL v CARTO data along the Y axis. Day I above; Day 2 below.......
67
5-5 Graphs of LL v CARTO data along the Z axis. Day 1 above; Day 2 below.........
68
5-6 3-D spatial representations of CARTO and LocaLisa Data. Day 3 above; Day 4
below ............................................................................................
.. 70
5-7 Graphs of LL v CARTO data along the X axis. Day 3 above; Day 4 below......... 71
5-8 Graphs of LL v CARTO data along the Y axis. Day 3 above; Day 4 below......... 72
5-9 Graphs of LL v CARTO data along the Z axis. Day 3 above; Day 4 below....... 73
8
Chapter 1
Introduction
According to statistics from the American Heart Association, treating patients
with Heart Diseases and other conditions (such as coronary heart disease, congestive
heart failure, and cardiac arrhythmias) will directly and indirectly cost the US healthcare
system about $258.5 billion in 2006. [1] In addition, 335,000 people die of coronary heart
disease without being hospitalized or admitted to an emergency room each year and most
of these deaths are caused by sudden cardiac arrest (SCA). Sudden cardiac death (SCD)
happens at about 930 times a day in the US and the risk in adults is estimated to be about
I per 1,000 adults 35 years of age and older per year. [2]
SCA occurs when the heart abruptly and unexpectedly and stops functioning.
Prior to this victims may or may not have had diagnosed heart disease. More often than
not the underlying cause is arrhythmic - a result of either ventricular tachycardia (VT),
ventricular fibrillation (VF), or a combination of both. The heart stops beating suddenly
because the ventricles cannot pump blood properly to meet the demands of the body.
Although it is less likely, SCA can also be a result of the heart beating extremely slowly.
SCA leads to SCD in 94-95% of cases. [3]
Cardiac arrhythmia is a condition where any chamber of the heart beats with an
irregular rhythm because electrical impulses in the heart cells fire more quickly
(tachycardia), slower than they ought to (bradycardia) or in a chaotic manner
(fibrillation). Apart from being an underlying cause in SCA i.e. from VT and VF, there
9
are many other types of arrhythmias and they are typically described by the part of the
heart which they affect and the nature in which they act. There are many clinical
manifestations of arrhythmias and these include shortness of breath on exertion,
lightheadedness, fatigue and weakness, or loss of consciousness. Overall, these
arrhythmias affect more than 5 million people in the US and result in more than 1.2
million hospitalizations and 400,000 deaths each year. [4]
Traditionally, there have been several approaches used to address the various
arrhythmias. They range from the use of anti-arrhythmic pharmaceuticals, to the
implantation of medical devices known as pacemakers that electrically stimulate the heart
directly, to more surgical approaches such as radio-frequency ablation where a burst of
energy is delivered to destroy a small area of heart tissue that causes the abnormal
electrical signals. The underlying goal of these approaches is ultimately to improve the
quality and length of life of patients and lower the healthcare costs by reducing the
number of hospitalizations and the amount spent on medical drugs and other medical
costs.
Before many of these approaches can be executed, the attending physician needs
to know several details that are specific to the anatomy of the patient, usually obtained
through intracardiac procedures. This typically involves a minimally-invasive process
known as catheterization where the physician uses a tube (catheter) to guide several
electrodes to relevant areas of the heart. Using these electrodes, it is possible to measure
several cardiac signals at different sites such as the electrocardiogram and thus create a
map of the arrhythmia based upon the electrical data acquired and previous knowledge
10
and memory of their anatomical location. [5] This map ultimately serves as a guide for
the physician in numerous types of procedures.
Furthermore, advanced systems have been developed that can superimpose the
information upon 3-D models of the relevant heart chamber in several forms such as
voltage, propagation or isopotential maps providing more insight. Examples of these
advanced systems include 'CARTO' by Biosense Webster, Inc. which is based upon
magnetic fields, 'LocaLisa' by Medtronic which is based upon impedance changes,
'Realtime Position Management' by Cardiac Pathways which is based upon ultrasound
and 'Ensite Array' by Endocardial Solutions Inc which is based upon triangulation of low
frequency signals. [6] Each of them has its own strengths and weaknesses which makes it
particularly suitable for some procedures and less suitable for others. For instance, the
LocaLisa system is designed so that it can be used with catheters from various
manufacturers making it more flexible than other systems while the CARTO system
allows for catheter localization and navigation to within 1mm which is more accurate
than other systems.
Overall, the general benefits of these systems include providing an increasingly
accurate anatomical model of the heart, accurately guiding radio-frequency ablation (i.e.
the process of electrically isolating regions of the heart that cause tachycardias) and
reducing fluoroscopy (i.e. the need for exposure to ionizing radiation in order to provide
guiding X-ray images during a procedure). This thesis describes a customizable interface
that has been developed to manage several of these systems (CARTO and LocaLisa) and
leverage their various strengths. Furthermore, this thesis provides an investigation of the
accuracy of the LocaLisa system.
11
1.1 Summary of Thesis Contents
Chapter 2 provides some background for the subsequent chapters. It describes the
underlying principles behind the CARTO system and the LocaLisa system.
Chapter 3 describes the API that has been developed to facilitate creation of the
interface.
Chapter 4 describes interface that has been designed to manage each of the systems in a
modular fashion. It also highlights the features of the interface that allow it to leverage
the strengths of the other systems.
Chapter 5 describes the approach to investigating the accuracy of the LocaLisa system
by comparing it with another system. This chapter also concludes with a discussion of the
results.
Chapter 6 discusses any lessons learned in the implementation of the Interface and
possible avenues of further research.
12
Chapter 2
Background
Current practice has shown that a number of arrhythmias such as atrioventricular
nodal re-entry tachycardia (AVNRT - an AV nodal slow conduction pathway) and
accessory pathways (anomalous connections between the atria and ventricles, located
along the mitral or tricuspid valve) can be treated with conventional catheter ablation and
fluoroscopy with a high success rate - about 90%. [7] This is largely because these
arrhythmias are largely stable with predictable locations or characteristics on their
resulting electrocardiograms and so determining where to provide therapy is relatively
straight forward. The same cannot be said for more complex arrhythmias such as atrial
fibrillation (AF) and many other forms of ventricular and atrial tachycardia. For each of
them it is relatively difficult to associate observed intracardiac electrograms with
particular sites and account for anatomical variations over each cardiac cycle, thus
determining regions to ablate becomes a very elusive process.
It is for this reason that several systems have been developed and this chapter
describes two such systems, CARTO and LocaLisa. The underlying principle of each will
be explained followed by a brief discussion of its clinical contribution and finally any
perceived shortcomings. It is overcoming these shortcomings and leveraging these
strengths that have strongly motivated the implementation of the navigation interface
described in this thesis.
13
2.1 The CARTO System
The CARTO system is based on electromagnetic principles and was designed by
Biosense Webster (Diamond Bar, California, USA). [8] It continuously records catheter
location and uses that to connect heart anatomy to electrophysiologic properties for each
site. The system consists of an external emitter of magnetic fields and a catheter with a
magnetic field sensor, several electrodes and a thermocouple at its tip. Furthermore, a
positional reference device such as another catheter is used and all elements are
connected to a processing unit.
The emitter is designed as a pad and is placed beneath the operating table and
consists of three coils. They each generate ultra-low power magnetic fields that map the
space around and within the patient's thorax with spatial characteristics. The magnetic
field from each coil decays in strength as a function of distance from the coil and the
sensor in the catheter tip uses the variation in magnetic field strength to determine
location and orientation i.e. (x,y,z and roll, pitch, yaw). Other electrical information
acquired from the system includes the local electrogram, and its voltage (unipolar and/or
bipolar). The reference device is used in conjunction with the catheter to determine
position more accurately by compensating for respiration and any other body movement
during the procedure. In addition, it helps to determine the local activation time (LAT) by
comparing the time between the cardiac signal acquired in the reference device and the
cardiac signal from the catheter. The system continuously monitors the quality of
catheter-tissue contact and LAT stability to ensure the validity and reproducibility of each
measurement. The information acquired is processed by an external unit and sent to a
14
__
OW
99
A
0
§ 'WA
- __ -
- -
_
I-
- -"I ---
,,
computer for rendering. The electrical information is color-coded and as new positions
are collected sequentially by the physician, the new information is superimposed upon
the previous data to ultimately give a three dimensional model of the chamber. Thus
maps based on the different type of information (voltage, LAT) can be generated to aid in
localization of tissue abnormalities.
Ti
P*Lef
p
elecurod a
we
k~cafl.~fl Ring
ler
9W
9W
elecfode
I
Figure 2-1 Catheter tip components, location determination through use of magnets and rendering
of different orientations. Courtesy[7]
Figure 2-2 Image of rendered points acquired with CARTO software. Mapping legend is on the top
right. Courtesy[7]
15
From a clinical perspective the CARTO system has been shown to be effective in
the treatment of several complex arrhythmias. For AF, the main approaches to treat the
arrhythmia involve ablation of the actual trigger sites, usually from the pulmonary veins,
or creation of linear lesions in the heart to block electrical conduction pathways. Because
anatomical sites can be recorded using CARTO with their corresponding voltage
information, the system can be used to return to these locations in the pulmonary veins
that may be the source of these arrhythmias and perform ablations. [7] On the other hand
creating linear lesions proves to be more difficult and time consuming regarding mapping
of the entire length while pacing from a second site.
For VT, by mapping the chamber during sinus rhythm or pacing instead of
mapping the arrhythmia itself, areas of scar (those with lower voltage) from the product
of previous heart conditions can be determined and used to predict areas likely to exhibit
macro-reentrant behaviour. Guiding ablation based on this information can eliminate VT
without the need to map the arrhythmia itself. [7]
Overall the strength of the CARTO system lies in its ability to create accurate
maps with a very high resolution (<1mm) with localized information that can be used to
treat various complex arrhythmias. In addition, it greatly reduces the need for
fluoroscopy. Its shortcomings include the need to use dedicated magnetic catheters.
Furthermore, sequential data recording can prove to be a time consuming process and for
some types of arrhythmias such as hemodynamically unstable VT, the system is not as
effective because the acquired data is incoherent temporally.
16
2.2 The LocaLisa System
The LocaLisa system is based upon the principle of detecting applied electrical
fields through sensing electrodes and was designed by Medtronic (Minneapolis, MN). [9]
Three low current fields, each with a unique frequency close to 30kHz, are applied along
three orthogonal planes through pairs of skin electrodes on the patient. A catheter with
sensing electrodes is placed intravenously within the volume encompassed by the planes.
In addition a reference patch may be placed on the skin of the patient or another catheter
may be intravenously placed with the first one to act as a reference. The purpose of either
is to determine position more accurately by compensating for respiration and other body
movement during the procedure. The skin electrodes and catheter are all connected to a
central processing unit which provides the applied current and processes the sensed
electric field in three dimensions. The position information from the processing unit is
then sent to a computer for rendering. The total signal mixture from every electrode on
the catheter is digitally separated with the use of filters to measure the amplitude of each
of the 3 frequency components. The electric field strength for each plane is the difference
in amplitude of the neighbouring skin electrodes divided by the known distance between
the electrodes. By diving the measured amplitude from the catheter electrode by its
corresponding electrical field strength the electrode position along that plane can be
determined and thus the position of the electrode in three dimensions can be realized. In
addition, positions that are streamed to the processing unit in real time can be averaged to
reduce cyclic variations.
17
30kHz 1mA
SkiShin
10
Log
L)TV
150
Long
\
Inv
10
V
3110 -'#V
IrnV
151 MYQ
Figure 2-3 Illustration of LocaLisa principle in one plane. Measured impedance changes as the
catheter moves from one electrode to the other. Courtesy[9]
00 00 ~
z
om
0o
o Ref
n
Figure 2-4 Typical LocaLisa setup. Electrodes in three orthogonal planes and reference patch
connected to LocaLisa Machine. Machine connected to PC for data rendering. Courtesy[9]
18
From a clinical perspective, the LocaLisa system has also shown to be effective in
treating several complex arrhythmias. In treating incisional-related AT, the system
effectively marked areas of scar, reproducibly identified past ablation sites and future
location targets and allowed for the realization and evaluation of ablation legions. [10]
Accessory AV pathways have also been successfully treated with ablation
techniques using this system. [9] Because several electrode positions can be measured at
the same time arrhythmias where a point by point acquisition would be ineffective can be
more accurately determined.
Overall the strength of the LocaLisa system lies in its ability to use almost any
type of catheter with the system to acquire simultaneous locations of cardiac signals with
respect to a reference electrode or patch. In addition, ablation sites can be tagged with
respect to fixed electrodes and the information can be used in subsequent procedures. The
need for fluoroscopy is greatly reduced as well. Finally, proper filtering ensures that RF
current during ablations does not interfere with determination of catheter position. Its
shortcomings include its lower resolution when compared to CARTO and its inability to
provide maps with voltage information or local activation times at different sites.
19
Chapter 3
Myo Application Programming Interface
The design and implementation of software to be used in medical procedures is a
very complex and challenging task. Part of the challenge is as a result of the current
plethora of existing commercial packages available to physicians and the features they
provide. Unless a system is able to provide superior functionality or the ability to
leverage the features of existing packages, attempting to create a new system is
inefficient. The interface described in this thesis attempts to address the latter option. In
addition, it must meet the following criteria if it is to prove useful to physicians: (1) It
must employ the most up to date algorithms in medical visualization; (2) It must be stable
enough to run at its full potential throughout a surgical procedure, some of which can last
up to 10 hours; (3) It must be aesthetically pleasing granted the potential frequency of
use.
3.1 Toolkits
In order to deal with the challenges of medical visualization and cross-platform
development several software frameworks have been created to compile sophisticated
algorithms into modular libraries. The ones used in this project are the Visualization
Toolkit (VTK), the National Library of Medicine Insight Segmentation and Registration
20
Toolkit (ITK), and the GUI development tool, QT. All written in C++, these libraries
provide software engineers with the ability to process and visualize medical data with a
variety of algorithms and present that data within rapidly developed applications that can
be executed on several platforms.
3.1.1 The Visualization Toolkit (VTK)
The VTK package is an open-source framework that is primarily used in the
visualization of 2D and 3D graphics. [II] It is essentially a collection of C++ classes that
provide and interface to the OpenGL environment and thus the functionality to process
and render images. The design and implementation of the library was strongly influenced
by object-oriented principles. A number of choices were made to improve its accessibility
and usefulness: (1) Several interface layers were designed to allow it to be used on a
variety of operating systems i.e. PCs, Macs and most Linux machines. These include
Java, Python, and Tcl/Tk layers. This choice allows software programmers to quickly
design powerful applications in languages they are comfortable with. (2) A wide variety
of visualization algorithms were supported including vector, scalar, tensor, volumetric
and texture methods. Advanced modeling techniques such as mesh smoothing,
contouring and triangulation (Delaunay) were also supported and algorithms were created
to allow for the mixing of 2D and 3D information together. Support in the form of
mailing lists and texts books is also available to reduce the time it takes to become
familiar with the library.
21
3.1.2 The Insight Segmentation and Registration Toolkit (ITK)
The ITK package is an open-source framework primarily used in performing
registration and segmentation. [12] Registration is the process of developing
correspondences between data typically from different sources i.e. determining spatial
transforms that map positions between images. Segmentation is the process of isolating
data in a digitally sampled image. For instance, some connected arteries and veins from a
digitally acquired CT scan of the heart can be removed to give a better perspective of the
chamber of interest. Similar to VTK, the ITK is a library of code written in C++ which
was designed to be platform independent (i.e. able to run on PCs, Macs or Linux
machines). Java, Python, and Tcl/Tk interface layers were designed to make this possible.
On its own, the ITK is unable to visualize its outputs. Thus, it was designed to work
seamlessly with VTK and display its outputs through it.
3.1.3 QT - A GUI development tool
The QT framework is an application development framework developed by
Trolltech that provides a substantial library of C++ classes and other tools for crossplatform development and internationalization of software.[13] Many of these classes are
widgets (menu items, buttons, etc) and objects that can be sub-classed or instantiated to
rapidly develop graphical user interfaces which are platform independent - similar to the
Java programming language. To further assist in the process of rapid development
Trolltech provides QT Designer, an optional graphical user interface for design and
22
.-- I
W_ -
. '..
WHEN"
,
development within the QT framework and QT Assistant, a collection of very extensive
documentation. It also provides support for back-end interactions with servers including
XML parsing and networking functionality.
Birds of the Western Palearctic by Famil...
e
STpna
--
M
'PilbF
f
dI
Birds of the Western Paleartic by Famil
v~irds of the Western Patearctic by Family
*Ostriches
b.Divers
VGrebes
Pied-billed Grebe
......
Vas
as
w
fte~a
iliie
Lttle Grebe
Lapwing Vanellus vanellus
Field
29-l
characters
dg4 ,n
rq%
deII ad iW7
82-47 c.
MP-
~
I
Wh
A
IMC4V'i
5N
-4Wd
C
d
i
Great Grebe
Great Crested Grebe
Red-necked Grebe
Slavonian Grebe
Black-necked Grebe
bAlbatrosses
wFulmars. petrels, shearwaters
ioStorm-petrels
mTropicbirds
bBoobies. gannets
b.Cormorants. shags
P'Darters
P-Pelicans
beFrigatebirds
4
W faList
down...
eggs
nest
Filte
chick
chick... non-
copul.
Hunc
Anta...
Cat-.
Invita
Copu
eggs
West...
annu...
song
Figure 3-1 Sample Application built with the QT framework. Courtesy [13]
3.2 Design and Development of the API
Leveraging the power of each framework proved to be a challenging task because
of their fundamental differences in design. For instance, the VTK framework forces
constructors and destructors to be private and wraps them within its own public methods.
This allows it to prevent direct memory management of objects. On the other hand, in
23
order to use container classes such as linked lists and hash maps in QT, all objects that
are created are required to have public constructors and destructors. In addition, the ITK
framework is based upon a "C++ Template" style also known as 'generic programming'
and although this provides for a very high amount of abstraction, the result is a
framework that is much more difficult to use. As a result the interface that was designed
had to take these and several other differences into account before the frameworks could
be used together.
All development was done on Windows XP Machines using Visual C++ 6.0 with
the QT, VTK and ITK libraries installed and with modified desktop environment
variables. Cygwin, a Linux-like environment for Windows and the Concurrent Versions
System (CVS) were used to get and store the interface code at a remote location through
secure shell connections (SSH). Using the tool NMake at a DOS prompt, with settings
customized for the project, the Visual C++ workspace was constantly being rebuilt to
incorporate any new changes during development and ensure the interface was still
stable.
In order to bridge the gap between the VTK and QT framework abstractions, a
vtkQtObjectFactory class was created. Its function was to convert all vtkObjects into QT
GUI objects upon initialization. As a result, the interface could be developed without a
concern for direct integration and display of VTK and ITK objects. Below is a diagram
showing the structure that the overall interface is based upon:
24
Myo Interface
(Application)
Myo API
VTK/QT
integration
VTK/ITK
integration
ITK
QT
VTK
Figure 3-2 Structure of the Interface. Several layers are needed to make development less complex.
Before the any application implementing the interface can be developed, an
application programming interface (API) is required to allow the program to use the
VTK, ITK and QT libraries easily. An additional specification is that the API must be
able to support development of applications that are highly modular. This API should
also provide classes that can be sub-classed for intra-modular and inter-modular
interactions. The figure below illustrates the hierarchy of the API that has been created:
Myo
Myo Object
MyoController
MyoWindow
Figure 3-3 Myo API top
25
MyoEventpvha
level hierarchy
First, all the coded classes of the API were prefixed with the word "Myo" to
prevent namespace clashes with other software libraries. Within the code, there are
miscellaneous identifiers that are used which must be globally declared. A Myo class
exists at the top of the hierarchy to serve as a place holder for them.
Next, there are some properties that must be common to every class that is
developed in this interface. They include having a unique string hashcode for object
differentiation, the ability to compare itself with other objects and the ability to 'print'
itself i.e. convert its internal properties into a string representation. The last property was
particularly useful for debugging while creating the interface. A MyoObject class is
derived from the Myo class to meet these specifications.
The architecture of rest of the API must meet some other requirements if highly
functional and modular applications that exhibit robust inter-modular communication can
be developed. They include the ability to implement common visualization standards, the
ability to manage GUI widgets, and the ability to implement data processing algorithms.
Several architectures exist that make this possible and one such paradigm is called the
Model-View-Controller (MVC) architecture.[14] In order to make software more
powerful the data (the Model) and how it is viewed (the View) are decoupled, and a
Controller serves to mediate between the two. To keep them synchronized, changes to
either the Model or the View are reflected through the Controller. The design of the API
is based upon this paradigm and illustrated conceptually in the following diagram:
26
K 2
API
Model
(MyoDataController)
Alters
Controller
Updates
Configures
(MyoProcessor)
View
(MyoGUIController)
Observed by
Uses
I
User
Figure 3-4 Myo API implementation of the Model-View-Controller paradigm.
In this design the developer must first create a MyoProcessor to allow the module
being constructed to be able to interact with other modules and to manage the flow of
information within a module. More information about interactions between modules can
be found in section 3.2.2. The MyoProcessor also acts as the main Controller of the MVC
architecture. Each MyoProcessor can then define specific instances of
MyoDataControllers and MyoGUIControllers. MyoDataControllers are responsible for
managing data that is made by a module and MyoGUIControllers are responsible for
creating GUI widgets that support user interaction with that module.
27
3.2.1 MyoControllers for the Model and View
MyoDataControllers serve to manage the data that must be stored and
manipulated within a module. Because the nature of the data is hierarchical, two classes
were developed to encapsulate this tree-like relationship - a MyoRootNode for data that
has no parent data and a MyoDataNode for data that has parent data.
[
000
r
MyoRootNode
MyoDataNode
MyoDataController
73
MyoDataNode
MyoRoot Node
,,,
MyoDataN ode
MyoDataNode
MyoDataNode
MyoDataNode
MyoDataNode
e
Figure 3-5 Structure of Data within the Myo hierarchy
MyoDataNodes hold pointers to instances of a data type. MyoRootNodes are used
to distinguish specific types of data and can hold any amount of MyoDataNodes. Each
module, through its MyoDataController can have as many MyoRootNodes as necessary
to handle the different data types it manipulates.
28
MyoGUIControllers on the other hand serve to manage the GUI widgets that
allow for user interaction. Many of them are part of the QT framework but required extra
functionality and this was accomplished through sub-classing together with additional
modifications. Examples of the widgets created include a MyoDialog that provides for
the ability to make choices through pop-up dialogs, a MyoPopupMenu that provides
selectable options when the right mouse button is clicked and a MyoListView that is a
visual representation of the tree-like data structures. More details about these can be
found in Chapter 4.
MyoGUIController
Myo-QT Widgets
MyoDialog
{
MyoListView
MyoPopupMenu
Figure 3-6 GUI items within the Myo hierarchy
3.2.2 Modular Communication
Before the API and subsequent applications can function properly there are a
number of requirements that must be met. Communication occurs in two different
manners: Intra-modular communication (within a module) and inter-modular
communication (between modules).
29
To facilitate communication between all classes in this architecture a
MyoController class was created. It serves to automatically setup communication
pathways between the various sub-classes. For example, upon creating
MyoDataControllers within a MyoProcessor, the MyoController constructor stores a
pointer to the MyoProcessor as the parent of the MyoDataController and the
MyoProcessor also stores a pointer to the MyoDataController as its child. This behaviour
is reflected throughout the API.
In order to actually communicate between MyoControllers, a sub-classable
MyoSignal class was created. It encapsulates commands to be performed within the
module. Of note are the two methods that are used in processing these signals:
1)
void send(MyoSignal*, Receipient) - This method is used to send a signal throughout
the module. The second argument represents the intended target of the message and
could be one of three options - 'Children', 'Parent' or 'All'. With reference to the
MyoController hierarchy, 'Children' implies that the message is sent down the chain,
'Parent' implies that the message is sent up the chain, and 'All' indicates both
directions.
2) void receive(MyoSignal*, Sender) - This method is used to receive signals that are
sent within the module. The second argument informs the MyoController of the
message sender and could be one of two options - 'ParentController' which implies
that the message was received from a node above or 'ChildController' which implies
that the message was received from a node below.
30
In addition, the MyoContoller class handles memory management by deleting
MyoSignals once they have been processed by every Controller in that module.
MyoSignal path
traversed
MyoObject
Subclassed by
Parent Of
- ------
-
-
.-..-.-.
M yoController
--
MyoProcessor
MyoListView
---
............
MyoDataController
MyoGUIController
MyoDialog
--
--
MyoRootNode
MyoRootNode
MyoActionManager
V
MyoDataNode
Figure 3-7 Intra-modular communication. All classes are MyoContollers. A signal from the
ListView is reflected to the data in the backend.
With regards to inter-modular communication things are a bit more complicated.
Before the modules can communicate with each other, the following elements were
necessary:
1) MyoEvent: This is very analogous to the MyoSignal in function. It represents data or a
set of instructions that must be transmitted between modules. A post( ) method is
provided to be able to send events from any point within the application.
31
2) MyoListener: This is an interface that must be implemented by a MyoProcessor.
When coupled with a respective MyoEvent it allows modules to selectively receive
information. For instance, if a window wishes to receive events from a Catheter module
then its MyoProcessor must implement the Catheter Listener before it can receive any
Catheter Events. This applies to every other type of module within the application.
3) MyoEventHandler: Before events can be processed by the different modules a
MyoEventHandler class was created to handle the receipt and distribution of events. This
class is instantiated only once and is able to receive MyoEvents that are sent from any
point within the application. In addition, MyoProcessors are also required to register with
the MyoEventHandler upon their creation. A received MyoEvent is processed by iterating
through a list of all the MyoProcessors that implement the appropriate MyoListener and
delegating the MyoEvent to each of them. This functionality is abstracted away to make
the design of module specific features easier for the programmer.
Once again certain methods are provided for each MyoController to be able to
process received MyoEvents:
1) void notify(MyoEvent* ) - This method is used to propagate events within a module.
Because all events must be received by MyoProcessors first, it is only possible for events
to be propagated down the chain to child MyoControllers.
2) void receive(MyoEvent* ) - This method is used to receive propagated events within a
module . Because of the notify( ) method above it is safe to assume that events can only
be received from parents.
32
MyoObject
Subclassed by
--
Parent Of
- -
--
-
(
MyoEvent path
traversed
-
-
-1--
MyoController
MyoEventHandler
..........
],
.
MyoProcessor
(MyoListener)
MyoProcessor
MyoRootNode
MyoRootNode
\V
0
MyoRootNode
MyoRootNode
*
MyoDataNode
N
r
0
S
S
MyoDataNode
Figure 3-8 Inter-modular communication. An event from one module is processed by one which
listens for those events.
3.2.3 Threading
A very important property of any large and complex application is the ability to
perform several tasks at the same time. Unthreaded programs can only run tasks serially
and typically end up blocking user access during the process. In order to implement
multi-threaded functionality a MyoThread class was created. When sub-classed this
allows for modules to perform tasks in parallel without blocking user access within the
33
main application thread. The MyoThread class provides a run( ) method that can be
called from any point in the application but within a different thread environment.
MyoObject
Subclassed by
P trent Of
MyoQTEventHandler
.........>
MyoProcessor
Distributed as MyoEvent
or MyoSignal
V
MyoDataController
VV
MyoRootNode
MyoQTEvent
MyoRootNode
sent
V
MyoThread
I
Thread Environment
MyoDataNode
MyoDataNode
Main Application Environment
Figure 3-9 Threading within the Myo Framework
A challenge posed by this configuration is the ability to make use of the
information from MyoThreads within the main execution thread. To allow for this
communication in the current architecture two classes were created:
1) MyoQTEvent: This event is used to encapsulate MyoSignals or MyoEvents that are
created within a MyoThread. They can only be processed once they are received by the
34
main execution Thread. They also have a post() method to allow them to be sent from
anywhere in the MyoThread.
2) MyoQTEventHandler: This class is similar in functionality to the MyoEventHandler
class. The only difference is that it is exclusively used to process MyoQTEvents for use
within the main application thread. MyoQTEvents that are received from MyoThreads
are converted to either MyoSignals or MyoEvents for propagation.
3.2.4 Visualization
Before the data could be viewed in an application in 3D a MyoWindow and
MyoVTKPipeline class were provided to provide integration with the VTK pipeline. [11]
Below is the basic structure of the VTK pipeline:
Cascade of Filters
Source Data
Filter I
Filter 2
Data processing Level
--
Filter 3
Ma
er
Rendering Level
F
Actr
Figure 3- 10 The VTK pipeline. Source data is ultimately rendered as vtkActors.
35
Source data is passed through as many filters as necessary before being mapped to
a 3D form called a vtkActor. These actors are then rendered in an OpenGL 3D space and
they allow for user interaction - rotation, translation and zooming the perspective.
Analogous classes for the earlier stages in the chain were created in the API to provide
for extra functionality while also integrating with the VTK. They include MyoSource and
the MyoFilter classes. The MyoVTKPipeline class was responsible for mapping the
filtered data into vtkActors and the MyoWindow class was responsible for managing
their presence in multiple windows.
Figure 3-11 MyoWindow showing a VTK object
36
MyolmageSource, MyolmageFilter, MyolmagePipeline, and MyolmageWindow classes
were also created to visualize data processed using the ITK package. Work is currently
on-going to provide full functionality for segmentation tasks.
Another important element was the creation of a MyoApplication class to allow
for proper instantiation of standalone programs. This class contains a single execute()
method that automates the process of building modules and any event handlers for
communication. It is this MyoApplication that contains the main thread that MyoThreads
provide information for.
37
Chapter 4
The Myo Interface
Based upon the designed API described in the previous chapter an application
been built that is currently in use by the Massachusetts General Hospital Cardiac
Arrhythmia Service. Below is a snapshot during a typical medical procedure:
Re Toots
\ldov
ep
P dyt
esse
amw u'e ma
A
LL AL LAO
AP Ph
RAO
LPO NPO
WP
F
Nar
sdy 2_essel
esse
-udy
Surfac.
Mo,*s
aca
'O.zr'A=AP
PA
LI
LA
M
O " WO SP IF
N.
erts
3eraI
TC
P
Pe o ete
Pavent 'rformabon
Regstraco
1 ?7:rfm
tatitvs
:
1.2
2
-
m
"I. x ...
f
Thess.
MyC4....
'C
5.
O
Figure 4-1 The Myo Interface
There are several features of the interface that improve its usability. First, it
leverages QTs ability to create multi-document interfaces (MDIs) and so the same data
38
can be viewed from different angles. Each window is an instance of the MyoWindow
class which can provide several different views from the same data. Next, a feedback text
pane is provided at the bottom left of the application to inform the user of choices that
were made or any actions currently in progress. Right above that, a TreeView is provided
that holds a major part of the interface's functionality. It is based upon the MyoListView
class. Most of the root nodes correspond to modules in the back end of the application e.g
the 'Catheters' node represents the catheter module, the 'Registrations' node represents
the registration module and so on. Because the TreeView is right-clickable most of the
actions that can be performed on each module are made available through pop-up menus.
These popup menus were derived from a MyoPopupMenu class in the API and
customized for different modules.
..study_2_Vessel 4
Surface Models
.. 3
lodules
- olor M
Design 1
Map Do
Model F
Registra
er
-ere
ings
-- ients
Show'
Hide
-
Set Color
Set Qpacty-
Solid
Pickable
Point
Dragable
Spaw.n Pipeline
Remove
--..
TC P.
Figure 4-2 MyoPopupMenu selection options for Surface Models
The illustration above shows that the surface model data type (acquired from MRI
images) provides options to view the data in wireframe, solid, or point representations
39
from the right click menu. Depending on the point in the procedure one representation
could prove to be more useful than another.
9e
'NincloviTools
Help
{A
AP~~~~s
a
Figurhe-
3
yo.
Ce
'
PA
7*N
NF4bft
md
Figure 4-3 Myo Interface in 'float' mode
Another important feature is the presence of toolbars and menubars in the main
window and within the MyoWindows. These are QT GUI Widgets that are created within
different modules and sent to the main GUI window for placement. Most notable on the
main Window are the buttons representing 'float' and 'integrate' modes. Virtually all
MDI applications exist in the 'integrate' mode where child windows are always
constrained by the dimensions of the main window. Sometimes this can be a problem for
a physician who desires several views without sacrificing the size of each window. As the
name suggests the 'float' mode button releases each window from the main application
with the use of the reparent() method provided by QT. These windows can then be
40
resized as desired and translated to any position on the desktop. The 'integrate' mode
undoes the change by making the main window the parent of all the floating windows
once again.
File
Tools Vndow Help
Patbent Knonndon
study_
A
eSels
ssudy_3_Voses1-studyj2 iess2
-
-
study_
AP
U
Nw
. LA"MLPOWXoWxiw2i
WL
?
_esset
study_3_essev
a
Surface Models
-aorta
i
-
p
ocules
.aAP
PA
LL
NL
LAO
RAO
LPO
RPO
S
M
L.:"ign ne
ap Down
Mcdel Rotatfic
Registratmons
termtve Oosest Port
ar
Settings
-
ena
Port
Patient lrformahOn
Target
et4
5347
1412
n sta'stcS
-...
1
m-
00w. 'Y.o....M
Figure 4-4 Myo Interface in 'integrate' mode
Within each MyoWindow are several buttons that allow the user to directly
manipulate the current data view. Many of those buttons allow the user to view the image
from opposite directions along the three cardinal axes and even along oblique planes. For
example the 'AP' button translates to VTK arguments that cause the window to be
viewed looking into the z-axis perpendicular to the x-y plane - an anterior to posterior
view. An 'options' button opens a tabbed modeless dialog of several options for further
manipulation of the view. For instance, an important feature is the ability to see the
internal view of a vessel with the use of clipping planes. When selected the option
41
translates to some level of temporary filtering of the data source (using the
vtkClipPolyData filter) in the VTK pipeline.
~tert nfonraton
O
;_.
Gid
Axes
Enable
A
!
Sagittal ipping
SceneOptone
F
AP PA
LL
RL LAQRAG LPO RPO SP
11
Namei Igstaticn
OtherOptons
o
f- Enable .,oaI Ciping
F EalCamna OqV
r-t-t-
fw Enable Oiblque dippng
Figure 4-5 MyoWindow showing clipping action. Toolbar buttons are above window and modeless
options dialog floating on left.
Next, in order to record a procedure a red button is also provided with a text-field
to identify the recording. The recording effectively amounts to successive snapshots or
frames of the current view during the procedure with the provided name appended to the
current computer timestamp and then saved in a typical image format such as jpeg. This
allows a physician to post-operatively review different aspects of the procedure.
In the sections that follow, several modules crucial to the proper functioning of
this interface will be highlighted. The specifications for each module will be listed as
well as a description of how those specifications were addressed.
42
4.1 The Catheter Module
The catheter module is responsible for the visualization and the interaction of the
catheter with the data currently visible. During a typical procedure it provides the
physician visual feedback of the catheter location which is very important for techniques
such as tissue ablation. In this interface, the specifications for the catheter module
include:
" The ability to convert position and orientation information into a 3-D
representation of the catheter tip.
*
The ability to extrapolate any missing electrodes with proper dimensions between
those that are adjacent.
" The ability to render multiple catheters concurrently and have them respond
selectively to events from different servers.
" The ability to accurately be transformed to a new co-ordinate space after any
registration steps.
*
The ability to change visual properties - electrode and body representations
(Cylindrical/Spherical), and visibility.
" The ability to selectively determine active electrodes during run-time while using
the LocaLisa system.
* The ability to provide real time measurements of the catheter tip to the surface of
a vessel (TTSM - tip to surface measurement). This last requirement is
particularly helpful for determining when the catheter is in contact with the tissue
prior to ablation.
43
To address the first requirement a custom vtkDataSetToCatheter filter was created. Its
main function is to take in a set of data points representing electrode and body locations
and construct three dimensional catheter representations such as the ones below:
Figure 4-6 Typical catheter representations - CARTO 8mm on the left. Lasso Catheter with ten
electrodes on the right - 6 electrodes are extrapolated.
A key method in this class is buildCylinders( ) which creates a vtkCylinder at the position
of interest. It then uses the information from the dot and cross products of the vector
representing the cylinder's initial position and the vector of the supplied orientation to
determine the angle and axis to rotate the cylinder along. Finally it uses the vtkTransform
and vtkTransformPolyDataFilter classes to perform the actual transformation before
rendering occurs. Another key method is buildSpline( ) which uses the
vtkKochanekSpline class to parametrically extrapolate positions in between the provided
locations and then uses a vtkTubeFilter to create a volume through all the points. There is
also a buildSpheres( ) method that is responsible for building vtkSpheres around given
locations. Together these and several other methods ensure that location data can be
converted into a three dimensional representation.
44
To extrapolate electrode positions that are missing from the data provided by the
algorithm is inherently dependent on the type of catheter to be used. For the CARTO
catheters the tip end is approximated as a rigid body while the LocaLisa catheters are
approximated as more flexible. Because the physical distances between electrodes is
already known a method called extrapolatePositions() in the MyoMath class provided in
the API is used to take in several arguments (tip position, a direction vector and the
distance between electrode centers) and return the position of a second electrode relative
to the first. For the flexible catheters the vtkKochanekSpline class is used to
parametrically extrapolate the locations of missing electrodes in between two or more
given electrodes. In figure 4-6 above electrodes 2,3,5,6,8 and 9 of the Lasso catheter
represent extrapolated positions.
In order to selectively respond to events from different servers, the classes that
represent the different catheters had their receive(MyoEvent* ) methods modified. For
instance in the class representing an 8mm Catheter the receive method checks to make
sure that any MyoEvents can be successfully cast into a CartoOrientationEvent before
applying position and orientation updates. Similarly in the class representing a Lasso
Catheter the receive method checks that MyoEvents can be successfully cast into a
LLElectrodePositionEvent before applying position updates. Multiple catheters can be
rendered at the same time because they are each treated as separate MyoDataNodes upon
creation and they can be modified from the main tree View.
To be accurately represented after registration steps, a CatheterPipeline class was
provided which subclasses the MyoVTKPipeline class in the API. It implements a
requiredpostProcess() method which couples the output of a preceding transformation
45
fer
filter to its internal vtkDataSetToCatheter filter. The output of its internal filter is then
returned for rendering upon request.
Changing visual properties is a feature also included in the design of the
vtkDataSetToCatheter filter. Methods such as SetElectrodeRepresentationToSphere()
and SetBodyRepresentationToOff() are used to fully encode different visual
representations. Visibility can be turned on and off, and representation can be toggled
between rigid modes comprising of just cylinders or flexible modes comprising of
spherical electrodes and a spline tube connecting them.
The ability to selectively determine which electrodes are active was implemented
as a selectable option in the MyoPopupMenu associated with the MyoDataNode
representation of each Catheter in the main tree view. Upon selection MyoSignals are
sent to the Catheter representation in the back-end to alter which electrodes are processed
in the receive(MyoEvent* ) method.
Tools
,-,atheters
--Cathetermm
4PatientSnow
Patient Information
Hide
Add T ts Measurement
atarting Registrat onCatheer
source f: 1C1
Y =
Body
Set Radius
Target C:11
Registration
Statistics: 1.2'
1.2rn
>
Catheter 71p
Set Color
Registraton Min Max Error
.22 - 5.S2*
Localisa: Select 1-4
Localisa: Select 5-8
Cylinder Reoresentaton
Log
Remove
Hide
Sphere Representation
Figure 4-7 MyoPopupMenu selection for a Lasso Catheter
46
Finally, an important feature is the ability to determine the tip to surface
measurements (TTSM) between the catheter and surface of a chamber in question. A
TTSM module was created within the Catheter Module and it contains a TTSM class that
can be instantiated upon request from the MyoPopupMenu. During an update, the output
of the CatheterPipeline is used to obtain the current catheter position after any prior
transformations. This is supplied to the internal TTSM class. The vtkPointLocator class
and a pointer to a previously designated Surface Model are then used in the TTSM class
to calculate the smallest distance from the tip to the model. This is then used to update a
vtkSphere representing the projection of the tip upon the surface. It is also used to update
distance labels in the MyoWindow which take the form of 2D vtkActors at the bottom
left-hand corner.
A00, To
Tools
Surface "odels
El aorta Pipeline
Show
Patent Infomiation
Select Models to estimate
TTSM from.
Catheter Body
Catheter Eectrode
e47y
Models which are grayed out
cannot be chosen.
1
Catheter Tip
Localisa: Select 1-4
Localisa: Select 5-3
Log
Remove
Name !at
Figure 4-8 TTSM in action. Option is selected from MyoPopupMenu on left. Target surface model
is selected from dialog on the right.
47
W1.
Patient Information
tstucyesse u
stucy_
+
Surface
A
AP
PA
LL
RL LAO RAO LPO RPO
5UP1F
X
Name
Vessel 3
Models
f-aorta
4t LA-P' s
-odues
Coior Mapping
Design Line
Down
Vodel Rotation
Map
Registrations
terstive uosest Pont
inSetgs
>ents
TCP. IP
Servers
ntiveX
Calto XP
Senal Port
- TCP. IP
Too[s
Catheters
- Cathetermm
Patient Informatiorn
Figure 4-9 TTSM in action. MyoWindow shows measurement in mm at bottom and also projection
of tip to surface of model.
4.2 The CARTO Module
The CARTO module is an illustration of how the interface that has been created
interacts with an external system. Several specifications must be addressed if the
interface is to function properly and they are:
9
The ability to provide information about catheter position and orientation for the
whole interface.
*
The ability to hold features that are specific to CARTO catheters.
* The ability to load and save CARTO data in a distinct format. This data includes
bipolar/unipolar voltages, Local activation times and any other custom tags (e.g.
'ablation', 'scar').
48
A number of specifications pertain to direct interactions with the external CARTO server
and they include:
" The ability to receive data over a TCP/IP Ethernet connection.
" The ability to interact with the external server via ActiveX protocols, originally
designed by Microsoft.
" The ability to process a constantly updating data stream without causing the
interface to deadlock.
" The ability to create/remove instances of the connection to the external server
during run-time
" The ability to rapidly process incoming data or suspend its flow.
" The ability to use multiple CARTO maps during a procedure and alternate
between which of them is active.
When information is acquired from the CARTO server, this module is responsible for
distributing that information to the rest of the interface. This is done using the
CartoOrientationEvent class which is a subclassed MyoEvent. This module is also
responsible for holding classes that contain catheter specific information. For example the
8mm catheter class has the unique dimensions of the catheter tip that are used during
catheter construction. It also contains the modifications to the receive(MyoEvent*)
method that allow it to filter all but the CartoOrientationEvents.
In order to successfully save CARTO data, a save( ) method was provided in the
CartoMap class. This save( ) method uses the vtkPolyDataWriter class to store the data
structures in a custom file format that ends in '.cpm'. Each file contains the bipolar and
49
unipolar voltages for each acquired position, the local activation times and any associated
tags (e.g. 'ablation', 'scar'). To load CARTO data, this requires a CartoParseController, a
subclassed version of the MyoParseController class found in the API. Its function is to
take CARTO files and load them into active maps that can be modified as
MyoDataNodes in the main tree view.
To receive information from the CARTO server an extra local area network card was
installed on the machine running the interface. This had an ethernet port that was
connected to a network hub. The CARTO server was also connected to this hub to
complete the physical connection between the machines.
On the software level, the interface needed to implement ActiveX protocols to
communicate with the CARTO server. QT provides a class called QAxWidget that
implements many of the ActiveX protocols. Modeled after the architecture already
described, an ActiveXServer class was created in the interface and it was subclassed to
give a CartoXPServer class that contained several more modifications. The setControl()
method of the QAxWidget class was used with a string argument of letters and numbers
to register the interface with the external system.
Because the incoming data off the server was a continuous stream, a MyoSemaphore
class was created to prevent system blocking during data processing. Only 150 successive
data points could be processed at any moment. The lock( ) and release( ) methods of the
MyoSemaphore class helped to prevent different methods of the CartoXPServer class
from using the incoming data stream at the same time. This also made it possible to
perform rapid acquisition of data without deadlocks.
50
Using the right-click functionality already described, the user is able to create and
remove an instance of the CartoXPServer in the main tree view through a
MyoPopupMenu. They are also able to toggle the rapid acquisition of data and can also
suspend data acquisition temporarily. Each selection is translated via MyoSignals to a
backend method in the CartoXPServer class that reflects the request through ActiveX
calls.
Settings
settings
-TCP.
IP
Servers
Servers
ctiveX
Sen
Senal Port
-TP. IP
- Tools
Patient Infomtnation
Successfuly saved file:
Procedures
athetersAdd
Catheter-m
4
Add Catheter8mm
Patient Hformation
Add CatheterIrrigated
Add CatheterMinor
Successfully saved file:
study_2 _Vessel 1
Successfuly saved file:
study_2 _essel 1
CARTO XP Serr Using
stuay Vessel
Start Rapid Acquisition
Stop Rapid Acquisition
Suspend Information
Disconnect
Lo7g
Figure 4-10 MyoPopupMenu options for interaction with the CartoXP Server
Finally, the ability to create CartoMaps to store acquired information is provided as a
choice in the MyoPopupMenu of the CartoXPServer node. Because the menu items can
also be toggled it is possible to select which map should be active. The effect is translated
to the backend through MyoSignals to determine which CartoMap the data should be sent
to. The maps are visible as nodes in the main tree view and can be renamed.
51
4.3 The LocaLisa Module
The LocaLisa module is also an illustration of how the interface that has been
created interacts with an external system. Several specifications must be addressed if the
interface is to function properly and they include:
*
The ability to provide information about multiple (14) catheter electrode positions
for the whole interface.
*
The ability to hold features that are specific to LocaLisa catheters.
" The ability to load and save LocaLisa data in a distinct format. This data includes
position information and corresponding electrodes.
A number of specifications also pertain to direct interactions with the external LocaLisa
machine and they include:
*
The ability to send and receive data over a Serial RS232 connection.
" The ability to interact with the external machine via sending and receiving data in
bytes.
" The ability to process a constantly updating data stream without causing the
interface to deadlock.
" The ability to set-up/remove instances of the connection to the external machine
during run-time.
" The ability to rapidly start the flow of incoming data and to save data using a foot
pedal.
52
" The ability to use multiple LocaLisa maps during a procedure and alternate
between which of them is active.
" The ability to provide real-time diagnostics of incoming data and alter some
server parameters such as number of electrodes in use.
When information is acquired from the LocaLisa server, this module distributes it to
the rest of the interface via the LLElectrodePositionEvent class which is a subclassed
MyoEvent. The module is also responsible for holding classes that contain catheter
specific information. For instance, the Lasso catheter class has the dimensions of the
catheter head (the inter-electrode distances) that are used during catheter construction. It
also contains the modifications to the receive(MyoEvent* ) method that allow it to filter
all but the LLElectrodePositionEvents and to determine which of the 14 electrodes to
process.
To successfully save LocaLisa data, a save( ) method was provided in the
LocaLisaMap class. The save( ) method uses the vtkPolyDataWriter class to store the
data structures in a custom file format ending in '.lpm'. Each file contains the timestamp,
the location information and corresponding electrodes. By subclassing the
MyoParseController class, a LocaLisaParseController class was created for loading
LocaLisa data. It loads LocaLisa files into active maps that can be modified as
MyoDataNodes in the main tree view.
An RS232 serial connection cable was directly connected from the LocaLisa
machine to the 'COM 1' port of the system running the interface. Further configuration
was done in software. Based upon the architecture hierarchy already described, a
53
SerialPortServer class was created in the interface and it was subclassed to give a
LocaLisaServer class that contained several more modifications. Coupled with this server
was a LocaLisaThread class that also subclassed the MyoThread class and was modified
to handle interactions with the LocaLisa machine without blocking user access. The
LocaLisaThread class contained an internal QextSerialPort class provided by QT that
made it possible to write and read from the port. During the running of the thread the
communicate( ) method in the LocaLisaThread uses putch( ) and getch( ) methods of the
QextSerialPort class to write and read characters from the port. Because these values are
in a primitive form a MyoValueCommunicator class was also created to perform the
translation of these signals to bytes. The class uses mutexes on all its methods to ensure
that it is thread-safe.
The first time the LocaLisaServer is instantiated a transmitDSPcode( ) method is
called and it transmits digital signal processing code that allows the LocaLisaServer to
understand subsequent messages from the interface. The communicator can then process
arguments within an array of up to four words. There were five types of arguments used
which are: 'S' - status of the LocaLisa server, 'M'
-
current mode of operation (Program,
Hold, Running), 'I' - determine if input is being adjusted for variations in amplifier gain
and/or foot pedal is being pressed, 'D' - request electrode impedance data, and 'R' - set
up system ROM. When the system is ready and has successfully accepted a request to
send position data the byteToFloat() method is used in the LocaLisaThread class to
translate the bytes into impedance floating point values. These values can then be used to
calibrate the system through mathematical processing and translation into co-ordinate
positions.
54
Once again the right-click functionality already described can be used to create and
remove an instance of the LocaLisaServer in the main tree view through a
MyoPopupMenu. The temporary start and suspension of data acquisition can also be
performed. Each choice is translated via MyoSignals to a backend method in the
LocaLisaServer class that reflects the request to the LocaLisaThread class.
Settings
TCPA P
Ciens
4.Settings
L Client
- Clients
P. IP
.erers
3I~VT1S
ertivex
A.tiveX
Senal Port
.TC
Tools
Add LocaLisaMap
.0atheter-
Catheters
-
-
--
Request Data
dShow,.
Diagnostics
-
Reconnect
Set Isotropic Scale
Disconnect
Sv eo
-
_Load
rnfommttin
tM I U A
Add F!ower
lap
Patient
v
Add Localisa
Tools
study_3 /,esself
CARTO XP Serier: Usi
Locausa: Atempting C0
_ocausa: Reset DSP
LhccaLsa Server: Using:
points
Add Carto
calibration points
--
zero data
A dd Lasso
Add Lasso4
Add Cecapolar
Add Flower
Request Data
Advanced
>
Reconnect
Disconnect
Zeros
Figure 4-11 MyoPopupMenu options for interaction with the LocaLisa Server
Creating LocaLisaMaps to store acquired information is provided as a choice in the
MyoPopupMenu of the LocaLisaServer. Because the menu items can be toggled,
selecting which map should be active is possible. The effect is translated to the backend
through MyoSignals to determine which LocaLisaMap the data should be sent to. The
maps are visible as nodes in the main tree view and can be renamed. In addition, altering
which set of electrodes are to be used is also an option that can be selected from the
55
MyoPopupMenu for each LocaLisa Catheter in the main tree view. The change is
effected in the receive( MyoEvent* ) method of the Catheter class.
Finally, a LocaLisa diagnostics dialog (LLDiagnostics) was created to make it
possible to monitor the information coming in off the server. The dialog subclasses the
MyoDialog class in the API and has tabbed panes each providing the streaming
impedance information, the impedance at the six terminals of the orthogonal directions,
The calculated distances between electrodes and a moving average filter. This was also
particularly helpful for section 5.
? 1.J
'M LocaLisa Diagnostics
mpedance Patches
EIeIoelsitons
Electrode Distances
Position #1
X:
Yr:
Z
Position #2
X
Y:
Z
Position #3
X
Y:
Z
Position #4
X,
Y:
Z
Position #5
X
Y:
Z
Position #6
X-
Y:
Z
Position #7
X:
Y:
Z:
Position #8
X:
Y:
2:
Position #9
X:
-
Z
m
Position #10Q
X:
Y:
Z
Position #11
X
:
Z
Position #12
X:
Y: i
Z:
Position #13
X- m
Position #14
X:
Z:
Y:
Y: i
Z:
Close
Figure 4-12 Local-isa Diagnostics Dialog in action.
56
4.4 The Registration Module
The registration module is responsible for using registration algorithms to deduce
transformations between different datasets and applying those transformations within the
interface. The specifications that must be met are:
" The ability to perform the Iterative Closest Point (ICP) algorithm.
" The ability to selectively choose which maps to register with which surface
models.
" The ability to perform registrations without blocking user access.
* The ability to undo transformations.
* The ability to select which elements in the interface that the transformations
should be applied to.
" The ability to provide registration statistics.
The iterative closest point algorithm is used to correlate distinct point clouds. In this
case the point clouds are data sets of the same vessel acquired from different sources. As
the name suggests the transformation between the two data sets is iteratively deduced by:
1) Associating points by their nearest neighbour criteria 2) Using a mean square cost
function to estimate parameters 3) Using those parameters to apply the transformation to
the points 4) Repeating the process for as long as desired. The output is a highly refined
transformation. A class in the VTK called vtkNIterativeClosestPointTransform was used
to perform this function for given data sets. Statistics for the process were also made
available.
57
In order to provide these datasets the registration module relied heavily on the patient
module which contained the data unique to each patient. The main types of data used
were the surface models acquired from MRIs prior to the medical procedure and
PointMaps (e.g. CartoMaps) acquired during the procedure. By registering the PointMaps
to the SurfaceModels then the correct transformation can be used to put the catheter and
other elements in the correct co-ordinate space during the procedure. A special
MyoDialog called MyoSTAOptions was designed to allow for the selection of maps in a
tree of checkable elements and models in a different checkable tree prior to registration.
Another tabbed pane in the dialog allowed for the selection of elements that the
registration should be applied to in a tree view. In order to function properly this
communication was heavily dependent on the sending and receiving of MyoEvents
between the two modules - Events to the Registration Module with a list of source maps
and surface model targets and events to the Patient Module to confirm which elements
were already registered. With this setup, successive registrations could be performed
without using the same dataset more than once in the chain of transformations.
58
-- -
PPROMMUMW
A.
Tooks Wio
FPe
g
-
,-
me
Name
ai
- -
-
=-
Hell
gMEtS a
Patmeno
A
M PRA
P~at
Data
-
-- -
-1?4
U
W LAORAC LPO U
SOP
0JO
-
Pont Maps
study_3_Vesje 1
-
study_3Veaseal
2
study3veassa 3
+*t
.y3Ve.il
4
Suface Models
*aota
Mdules
Color Mapping
Dwk,
Map Dow
Model Rouon
Region
GenX
Iteave Cosedb Pool
ses
TCP/iP
serve"
cvex
Seel Pot
TCP/IP
Pafta bfoubon
Log
-
Registrations
GenX
Start New Registration
.. ttigjs
Clents
TCP/IP
Servers
Figure 4-13 Registration with the Myo interface (1" of 3 figures). A. The Point maps and the
surface models are in different co-ordinate spaces. B. MyoPopupMenu with option for creating
new registration
59
- "E"44-
NOON a-
I
C.
Source/Target
Apply To
Sources
Point Maps
- study3_essel
2 study_3Vessel
study_3_Vessel
study_3_Vessel
Targets
Surface Models
aorta PIpeline
LA-PW Pipeline
DPipeline
1 PipelIne
2 Pipeline
3 Pipeline
study.3_Vessel 4 Pipeline
Surface Models
-
Name
aorta
Pipeline
LA-PV Pipeline
reg
OK
Fi. Tolsa
Cance
hlW Hl
1OWU 00
PatiPtoen
[)I"
01
Spacebo
A
AP
PA
U.I
A
G AL
-
O W
VM
NOW:
Pont Mums
Sadi,-3vessel 0
ud*y3_vessei 1
+-u_*3_Vessel 2
udy_3,Vessef 3
4
*2dy3Vessel
LAP%
RSuda
des
Model %etabon
Geg
TCPIP
SenalPont
IStatk&g Repizabon
Scuce O- 106
Twgi 0- 125594
j in. ~3W
3Th..
-1]
3:560M
1 *My..
Figure 4-14 Registration with the Myo interface (2nd of 3 figures). C. The Point maps and the
surface models are selected in the registration dialog. D. Registration thread runs in the background
after registration process is started.
60
F*e
To*l
HeO
WVndW
M@
E.
S
A
Da
AP
PA LL
RL
LAO
PAO LPO RPO
S
000
Nurne
mages
Port Maps
-
tudy.3yVessel 0
4 study_ 3Vessel 1
sudy 3Vessel 2
study_3_Vessel 3
study_3 Vessel 4
Sbac Models
LA-PVs
Wdula
Color
De
MappNg
um
MapDow
Model
Rststlsn
Regotrabos
Cliets
TCPAP
-ActiveX
-s&rWa
Pa
t
Pon
r!
nmabn
gd0: 125584
Regstaln Stabstss 189nmmt.+
1A427mm
Regisen MnMa
[0.008 -5.84]
Regssrtin
Eo
(m):
Anmhed
Figure 4-15 Registration with the Myo interface (3 rd of 3 figures). E. The Point maps and the
surface models are now registered
In the registration module an ICPRegThread class was created to perform the
registration algorithm without blocking user access in the main thread. This thread was
given the input sources and targets and returned the transformation after the algorithm
was applied. It is this transformation that is used in the VTK pipeline.
Because each registration was represented as a MyoDataNode in the main tree view it
could be removed by using the option in the right-click MyoPopupMenu. The effect was
a MyoSignal to the backend to remove the MyoDataNode and undo the transformation it
represents. Because registrations can be chained together, all registrations that succeeded
one removed higher up in the chain are also removed.
61
Fie Tools VWndow Plp
E.
On C3
Pabut WOMHOW
A
-Data
-
1
MP PA
UL
W LMO RM LPO WO SW Iwo
Is*
NhFl
3Veso0
stdudy3Vse
adpvLeaWo 2
d
studyJVess6 3
study3Vessel 4
LA-PW
COlbr Mappn
ft DoRege lratians
1GwiX
TCP IP
-Sew'
Saw Pont
Taget
Oi-125594
ReFegoran
Stafctml8mm
Registration
r (_)_
1.487 rm,
ja_
Figure 4-15 Registration with the Myo interface (3rd of 3 figures). E. The Point maps and the
surface models are now registered
In the registration module an ICPRegThread class was created to perform the
registration algorithm without blocking user access in the main thread. This thread was
given the input sources and targets and returned the transformation after the algorithm
was applied. It is this transformation that is used in the VTK pipeline.
Because each registration was represented as a MyoDataNode in the main tree view it
could be removed by using the option in the right-click MyoPopupMenu. The effect was
a MyoSignal to the backend to remove the MyoDataNode and undo the transformation it
represents. Because registrations can be chained together, all registrations that succeeded
one removed higher up in the chain are also removed.
61
Chapter 5
An investigation of the accuracy in LocaLisa.
The interface that has been created may also be used to evaluate the accuracy
between systems. Previous research has stated that localization accuracy with LocaLisa
was better than 2mm with an additional scaling error of 8% to 14%. [9] Unfortunately,
the methods and processes of determining this accuracy were not explicitly described.
This chapter aims to propose one such method in an investigation of those claims.
The schematic set-up below was used to make measurements:
Phantom
C
eter
-----
CARTO
System
PIU
Carto Magnet
Localisa
System
RS 232
TCP/IP
Myo Interface
System
Figure 5-1 Schematic of set-up for investigating LocaLisa accuracy.
63
First the catheter, the reference catheter and the magnet were placed in and around
a phantom water tank and connected to the external unit to process signals before sending
them to the main CARTO machine. Six patches and an extra reference patch were also
put around the phantom and connected to the terminals of the LocaLisa machine. Using
extra ports from the unit, the electrodes of the catheter were also connected to the input of
the LocaLisa machine. The machines were both connected in parallel to the machine
running the interface and the remainder of the analysis was done on the software level.
The CARTO system was used as the reference system because multiple
procedures done in house have routinely showed an accuracy of about 0.8mm and this
has also been externally corroborated.[ 15]
Using the interface, instances of both servers were created as MyoDataNodes in
the main tree view and a generic PointMap was used to collect data from both systems.
Because the LocaLisa module was coded to detect the use of the foot pedal, the pedal was
used to make the process of data collection from both systems into the same map easier.
Data was collected along the different orthogonal directions and saved into different
maps. These maps were then processed using Matlab scripts and plots were made to
provide more insight into correlations between the different systems. The data from the
CARTO system was positions in space while the data from the LocaLisa Machine was
impedances at those locations. Given the nature of the space being mapped it was
expected that there would be a linear relation between the CARTO positions and the
LocaLisa impedances.
64
5.1 Results
In order to improve the reliability and repeatability of the results the data was
acquired multiple times on different days. Figure 5-2 shows 3-D plots of the data
acquired along the three orthogonal axes on two of those days. The CARTO plot has a
unit of mm while the LocaLisa plot is in microVolts.
Carto spatial plot
ILL spatial plot
x
0.5-
120'--
-
40
++i
100
80
60(
-2
40
20
y (mm)
0
40
20X(mm)
--
-2.5
x 10
-
p3 x 10
-2.5
x Impedance(WV)
-
y Impedance (uV)
LL spatal plot
x 10
Carto spatial plot
~
x
1~-1
120,-5o
E
E
100-
++
0
-xeu
5~
60
-
-,~--
80
-
-
60
40
y(mm)
20
20
--
0
20
x (mm)
xx 10
y Impedance (uV)
-
-05
-
-1
J
-1417
x 10
x Impedance(uV)
Figure 5-2 3-D spatial representations of CARTO and LocaLisa Data. Day I above; Day 2 below
65
MW
-
-
-2mmmn-
-
-,-
-
-
Figures 5-3, 5-4, 5-5 show the correlation along each of the orthogonal axes.
X
-1J.4
LL vs Carto - X axis
5
F
-1-6
-41
I
*
-2
*
*
,
*
*
-Z-Z
*
*
*
*
-2,4 [
E
*
*
*
4
*
$
*
*
-3
I
-32 L
-5C
I)-
-40
-20
I
I
I
I
-30
30
20
10
0
-10
x position (mm)
LL vs Carto - X axis
x 104
*
-4
-6
*
*
*
*
-8
C3
E
-10
-
*
*
*
*
*
*
*
*
*
*
*
*
*
$
-12-14
-
-16'
-4 0
-30
-20
0
-10
x position (mm)
10
20
30
Figure 5-3 Graphs of LL v CARTO data along the X axis. Day 1 above; Day 2 below.
66
-
=m
-A
LL vs Cato -Y axis
x 105
-1 5F
$
*
-21
*
A
*
*
0
0
-2.51
I
*
*
*
0
9
*
*
a.
E
~
*
*
-31
.
*
*
*
-3.5 L
p.
-41
-40
1.5
I
I
10
20
I
I
I
I
0
50
40
30
y position (mm)
I
I
I
60
70
80
*
$
__
90
LLvs Cato -Y axis
x105
11**
0-5 I
*
0
*
*
*
*
*
CL
*
*
*
*
*
E
*
*
*
*
*
*
*
*
*
I
*
±
*
-0.51-
-1
~1
-20
r,
-I
- I
0
- -
I
20
- -
I
I
40
y position (mm)
60
80
-
100
Figure 5-4 Graphs of LL v CARTO data along the Y axis. Day 1 above; Day 2 below.
67
OEM=
0
X
LIL vs Cafto - Z axis
5
I
I
I
I
I
I
I
*
-5
*
*
$
*
*
-1
:
$
I
*
*
E -1.5 F-
$
*
I
*
-2 F-
*
*
*
*
4C
1.5
I
I
I
I
50
60
70
80
I
I
I
100
90
z position (mm)
110
120
130
*
*
$
$
140
LL vs Caito - Z axis
105
I
I
0.5
I
*
*
*
5
*
R.
0
*
E
*
*
-0.51*
*
-1
-1.51
40
50
I
I
I
60
70
I
100
90
80
z position (mm)
110
120
130
140
Figure 5-5 Graphs of LL v CARTO data along the Z axis. Day I above; Day 2 below.
68
In each of the figures, only the plot along the axis of interest is shown. The 3-D
plots (CARTO) show that the data is fairly linear along each axis. First impressions show
that the Localisa system is not as accurate at a 5mm resolution (this was approximately
the distance between the CARTO points acquired). Although the LocaLisa versus
CARTO plots were roughly linear there was significant overlap of LocaLisa points that
corresponded to each CARTO location leading to ambiguity at that resolution. This
seems to suggest that the resolution of data from LocaLisa is lower than previously
suggested.
Using the same set-up similar data was acquired on separated days but this time a
moving average (MA) filter was applied - from the last tab of the LLDiagnostics dialog.
Previous literature has shown that this technique is used to deal with respiratory
compensation during in vivo procedures.[16] Here, it is expected that this filter may help
to improve the resolution of LocaLisa that was demonstrated above. The plots of the
acquired data are below. Once again, Figure 5-6 shows 3-D plots of the data acquired
along the three orthogonal axes on two of those days. The CARTO plot has a unit of mm
while the LocaLisa plot is in microVolts. Figures 5-7, 5-8, and 5-9 show the correlation
along each of the orthogonal axes.
69
LL spatial plot
5
Carlo spatial plot
44
100
-44
-20
O)
-2
x0
4
y'
p
dance (W) -26
-3
xlo
-- 2.2_.4
x ipedance(WV)
LL spatial plot
x 10
5
Carto spatial plot
1601
140
tv
-
*
-2s
aV
CL
fU
T4
80,
i
I0.
-
50
0
y mm;
- *
1-20
20
-3
40 6
x (mm)
-6
*
-2x 105
-2.5
2
4 -2
-3
y 5peance
tuv)
D
3
v
a
x
elw
below
Figure 5-6 3-D spatial representations of CARTO and LocaLisa Data. Day 3 above; Day 4
70
10
x 105
-1~6
LL vs Carto - X axis
*
*
.
*
*
-21-
*
*
I
-2-2CL
*
E
I
26
2.0 -
*
0
-31
-a 0
f ;0
40
20
0
-20
-40
x position (mm)
LL vs Carto - X axis
x 10
A.
2
I
I
0
-2
CL
E
-4
I
-6
I
I
-81-
-101
-60
-40
I
I
II
-20
20
0
x position (mm)
I
I
40
60
80
Figure 5-7 Graphs of LL v CARTO data along the X axis. Day 3 above; Day 4 below.
71
-1
l0
X
LLvs Carto - Y axis
I
I
I
*
-1.5
*
**
*
-2
5F
4
*
t
*
**
40
.1 ~
-2-5:
*
*
*
*
-3
3 -20
I
I
I
I
I
0
20
40
60
80
120
100
y position (mm)
-1.5
LL vsCarto - Y axis
x 15
I
I
I
S
*
-21F
*
S
CL
-2.5
F
*
S
E
*
-3
S
S
*
-3.5'
)
0
I
I
20
40
I
60
80
100
120
y position (mm)
Figure 5-8 Graphs of LL v CARTO data along the Y axis. Day 3 above; Day 4 below.
72
LL vs Catto - Z axis
X 10 5
II1
-05=
g+
*
-1
-1-5 [
CL
tI
E
-2 =
-2;5 [
-3'
21)
I
I
40
60
I
I
I
120
140
z position (mm)
-0.5
LL vs Carto - Z axis
x 10
I
I
I
*
14.
S
*
-1.5 =
S
-2 CL
S
E
S
-2.5
-3
-3.5 '
4(0
I
I
I
I
I
60
80
100
120
140
160
180
z position (mm)
Figure 5-9 Graphs of LL v CARTO data along the Z axis. Day 3 above; Day 4 below.
73
The graphs above appear to show a much better correlation at that resolution. The
set of graphs acquired on day three were from the use of an MA filter of 10 points while
the graphs acquired on day four were from the use of an MA filter of 20 points. The
overlap was much less (and virtually non-existent for day four) and the relationship was
highly linear. The 3-D plots for LocaLisa also showed linear data along each axis rather
than a cloud of points as shown earlier. The implication is that resolution increases with
the use of MA filtering which is expected. On the other hand a by-product of MA
filtering was slower response time to the motion of the catheter but this effect was not too
disruptive to the eye.
5.2 Comments
Certain sources of error could have affected the above findings. First it is unclear
if the presence of the magnet with the CARTO system contributed to the noise of the
LocaLisa system - possibly through any electromagnetic interactions. In addition,
variations in the homogeneity of the phantom solution could also be a factor affecting the
results over multiple days. At this point only in vitro experiments could be performed and
it is possible that in vivo experiments could be more accurate because of the homogenous
nature of blood. Accounting for any noise errors in the LocaLisa machine itself was not a
straight forward process. Although the patent of the system describes an internal noise
compensation process using filters, the data acquired still appeared to be fairly noisy.
Finally, because of time constraints not as much data was acquired as would have been
preferred. Again at this point it is unclear whether collecting data over several months as
74
opposed to several days would have made a significant difference although intuition
would seem to suggest so. With that said there was definitely improvement with the used
of the MA filter although that came at a cost of catheter responsiveness to motion.
75
Chapter 6
Conclusion
6.1 Summary
The goal of this thesis is set out in the introduction: to create an interface that
leverages the strengths of various electrophysiology modeling tools currently used in the
medical field. Several of these strengths include increased accuracy during procedures,
and the ability to associate electrical information such as bipolar or unipolar Voltages,
and Local Activation Times to specific locations within the heart vessels. As a starting
point, various toolkits such as the VTK, ITK and QT were chosen because they each
provided necessary functionality for the interface - a GUI for real-time user interaction,
the visualization of data to be processed, and so on. An API was developed to make
integration with these toolkits an easier process. Classes were created to abstract away
complex function calls into simpler ones and to make the creation of highly modular
applications possible. A messaging system was also designed to facilitate seamless
communication between the different modules. New modules can be added without the
need to restructure the whole design.
An interface was then designed to build upon the API and create a fairly straightforward way to perform several important functions such as registration between data sets
and catheter navigation during a procedure. Many of these functions were accessible
76
through familiar avenues such as toolbars, dialogs or popup menus and these improved
the usability of the interface.
Over the course of development there were a few lessons learnt and challenges
that were encountered. First it paid off that a considerable amount of time was spent in
the design of the framework before coding. And earlier prototype of the interface was
created which lacked the modularity described in this thesis. As a result, integrating new
systems into the interface was difficult. The further time spent on the design of later
iterations for the interface led to the choices to abstract out common functionality into the
API and to model the API after the MVC design pattern. With hindsight it is regrettable
that an equal amount of effort was not put into the creation of help and documentation for
the interface. This would have greatly contributed to the learnability of the interface by
future developers. With regards to the look and feel of the interface, each system had a
customized feel of its own but we chose to use that of the native Microsoft machine. The
benefit of this was also less time spent learning to use the interface since many users are
familiar with the Microsoft look and feel. Finally, whether it was the time spent
debugging, or the time spent getting the development workspace to compile with custom
settings, or the time spent deducing and translating the protocols of each system, this
project also reinforced Murphy's Law. Things almost always took longer than anticipated
to tackle. It helped that this was factored into the planning of the project timeline.
77
6.2 Extensions
There are several next steps that can be taken in this research. First is the
remainder of the LocaLisa Calibration process. The experiments in the preceding chapter
demonstrated a shift in the range of impedances measured on different days. A scheme is
needed to ensure that calibration into position co-ordinates (mm) can be performed in real
time. Next, is the integration with other commercial systems. Work is currently ongoing
at MGH to integrate the interface with medical systems from Philips (Andover, MA), and
Hansen Medical (Mountain View, CA). In addition full integration with the ITK and
segmentation functionality is also still in progress. Compiling the ITK within the
designed interface has proven to be a more complicated task than the VTK or QT. From a
usability perspective, there are a number of other functions that resident physicians who
use the interface request for and this is inherently an iterative process. For example, the
surface models acquired from MRI systems could not be directly manipulated within the
MyoWindows. The perspective view could be changed but sometimes it is more
convenient to rotate, scale or translate the model itself and not the view. This
functionality was developed as a new module and integrated into the designed
framework.
Because of the groundwork already in place it is expected that the interface can
develop into a powerful tool since new functionality can be integrated into the existing
setup without causing complications.
78
Bibliography
[1] American Heart Association: Heart Disease and Stroke Statistics-2006 Update.
Dallas, TX: American Heart Association, 2005.
[2] American Heart Association: Sudden CardiacDeath!
CardiopulmonaryResuscitation (CPR) Statistics - http://vww.americanheart.org/.
Date Visited: 4/14/2006.
[3] Pell JP. Presentation,managementand outcome of out-of-hospital
cardiopulmonaryarrest: comparison by underlying etiology. Heart. 2003;89:839-842.
[4] Medtech Insight: Reports http://www.medtechinsight.com/ReportA230.html.
Date Visited: 4/14/2006.
[5] Vias Markides, D. Wyn Davies, New Mapping Technologies:An Overview with a
ClinicalPerspective, Journal of Interventional Cardiac Electrophysiology, Volume
13, Issue 0, Aug 2005, Pages 43 - 51.
[6] Packer, Douglas L. (2005) Three-DimensionalMapping in Interventional
Electrophysiology: Techniques and Technology. Journal of Cardiovascular
Electrophysiology Volume 16 (Issue 10), 1110-1116.
79
[7] Friedman P. A. Novel mapping techniques for cardiacelectrophysiology. Heart
2002; 87: 575-82.
[8] Vias Markides, D. Wyn Davies, New Mapping Technologies: An Overview with a
Clinical Perspective, Journal of Interventional Cardiac Electrophysiology, Volume
13, Issue 0, Aug 2005, Pages 43 - 51.
[9] Fred H. M. Wittkampf, Eric F. D. Wever, Richard Derksen, Arthur A. M. Wilde,
Hemanth Ramanna, Richard N. W. Hauer, and Etienne 0. Robles de Medina
LocaLisa : New Technique for Real-Time 3-DimensionalLocalization of Regular
IntracardiacElectrodes Circulation, Mar 1999; 99: 1312 - 1317.
[10] Lustgarten D. L. Advances in diagnostics:novel mapping systems and
techniques Coronary Artery Disease 14 (1): 29-40 Feb 2003.
[11] Schroeder, W.J.; Avila, L.S.; Hoffman, W., "Visualizing with VTK: a tutorial,"
Computer Graphics and Applications, IEEE , vol.20, no.5pp.20-27, Sep/Oct 2000.
[12] T. Yoo, M. J. Ackerman, W. E. Lorensen, W. Schroeder, V. Chalana, S.
Aylward, D. Metaxes, and R. Whitaker, "Engineeringand algorithm design for an
image processing api: A technical report on itk - the insight toolkit," in In Proc. of
Medicine Meets Virtual Reality, J. Westwood, ed., pp. 586-592, IOS Press
Amsterdam, 2002.
80
[13] Trolltech: Qt, http://www.trolltech.com . Date Visited: 4/26/2006.
[ 14] Gamma, E. et al. Design Patterns:Elements of Resuable Object-Oriented
Softvare: Addison Wesley. Indianapolis, IN. 1995.
[15] Shpun S, Gepstein L, Hayam G, Ben-Haim SA. Guidance of radiofrequency
endocardialablation with real-time three-dimensionalmagnetic navigation system.
Circulation. 1997;96:2016-2021
[16] Wittkampf FH, Wever EF, Derksen R, Ramanna H, Hauer RN, Robles de
Medina EO: Accuracy of the LocaLisa system in catheterablationprocedures. J
Electrocardiol 1999;32: 7-12.
81