An Automated Web-Based Searchable Archive
For Implantable Cardioverter Defibrillator Data
by
Shin-Ning Duh
S.B., Management Science
S.B., Electrical Engineering & Computer Science
Massachusetts Institute of Technology (2002)
Submitted to the Department of Electrical Engineering and Computer Science
in Partial Fulfillment of the Requirements for the Degree of
Master of Engineering in Electrical Engineering and Computer Science
at the
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
August 29, 2003
@ 2003 Shin-Ning Duh. 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
August 29, 2003
Certified by
,,,Professor Roger G. Mark
Thesis Supervisor
Accepted by
Professor Arthur C. Smith
Chairman, Department Committee on Graduate Theses
MASSACHUSETTS INS-T
OF TECHNOLOGY
E
JUL 2 0 2004
LIBRARIES
BARKER
An Automated Web-Based Searchable Archive
for Implantable Cardioverter Defibrillator Data
by
Shin-Ning Duh
Submitted to the
Department of Electrical Engineering and Computer Science
August 29, 2003
In Partial Fulfillment of the Requirements for the Degree of
Master of Engineering In Electrical Engineering and Computer Science
ABSTRACT
This paper details the research, design, and implementation of a computer system built to archive
electrograms and related patient data from implantable cardioverter defibrillators (ICDs) produced by
Medtronic in particular.
The archive will provide a central and stable repository for researchers looking for data originally
stored in the ICDs. The Web interface to the system provides an easy means of searching for patients or
episodes of interest. The database will also provide the functionality for appending comments onto a
particular episode.
Furthermore, the system allows the physicians to directly upload data from the ICDs into the
database. Automatic detection and expansion functions will also allow data from new models and
current models that have been modified to be inserted properly into the database.
Thesis Supervisor: Roger G. Mark
Title: Professor, Department of Electrical Engineering and Computer Science
2
Table of Contents
Introduction ................................................................................................................................................................6
1.1
Background .............................................................................................................................................. 6
1.1.1
Cardiac Arrhythm ias .......................................................................................................................... 6
1.1.2
Electrocardiogram s ............................................................................................................................. 7
1.1.3
Ventricular Arrhythm ias ................................................................................................................... 9
1.1.3
Sudden Cardiac Death ..................................................................................................................... 10
1.1.4
Autom ated External Defibrillators ................................................................................................. 11
1.1.5
Im plantable Cardioverter Defibrillators ........................................................................................12
1.2
M otivation .............................................................................................................................................. 17
1.3
Related W ork ......................................................................................................................................... 18
1.4
The paper ................................................................................................................................................ 18
The Current Archive System .................................................................................................................................
2.1
System overview ....................................................................................................................................
2.1.1
Client system .....................................................................................................................................
2.2.1
Shared Archive ..................................................................................................................................
2.3
Technology choices ...............................................................................................................................
2.3.1
Inform ation storage ..........................................................................................................................
2.3.2
W eb server .........................................................................................................................................
2.3.3
Softw are .............................................................................................................................................
2.4
Incorporation of existing and future m anufacturers ........................................................................
19
19
20
24
26
26
27
27
28
G oals and Design ....................................................................................................................................................
3.1
Goals ........................................................................................................................................................
3.2
M edtronic D ata structure .....................................................................................................................
3.2.1
De-identified text file ........................................................................................................................
3.2.2
Intra-section structure ......................................................................................................................
3.2.3
Overview file .....................................................................................................................................
3.2.4
EGM files ...........................................................................................................................................
3.3
Interface design ......................................................................................................................................
3.3.1
Present site structure for Guidant data ..........................................................................................
3.3.2
M odifications for Medtronic data ...................................................................................................
3.4
Database design .....................................................................................................................................
3.4.1
H andling of new models and fields ...............................................................................................
3.4.2
Table relations ...................................................................................................................................
29
29
30
30
32
34
34
35
35
41
49
49
50
Im plem entation .......................................................................................................................................................
4.1
Middlew are generation ........................................................................................................................
4.1.1
Algorithm ..........................................................................................................................................
4.1.2
Notable specifics ...............................................................................................................................
4.2
Table generation ....................................................................................................................................
4.2.1
Algorithm ..........................................................................................................................................
4.2.2
Issues and sacrifices ..........................................................................................................................
4.3
Data insertion .........................................................................................................................................
53
53
54
55
56
56
57
58
3
4.3.1
Insertion detail ..................................................................................................................................58
4.3.2
Database m odification routine ........................................................................................................59
4.3.3
Generation of non-section tables .................................................................................................... 60
4.4
Data retrieval and display ....................................................................................................................60
4.4.1
Guidant integration ..........................................................................................................................60
4.4.2
Special considerations ...................................................................................................................... 61
Conclusion ................................................................................................................................................................62
5.1
Future w ork ............................................................................................................................................64
5.1.1
Tem plate sections ............................................................................................................................. 64
5.1.2
Text file dow nload ............................................................................................................................ 64
5.1.3
Sorting function ................................................................................................................................ 65
5.1.4
Statistical analysis tools ................................................................................................................... 65
5.2
Lesson learned ....................................................................................................................................... 65
Appendix ...................................................................................................................................................................66
1.
Sample De-Identified File Content .......................................................................................................... 66
2.
User Guide ..................................................................................................................................................81
4
List of Figures
Figure 1. Exam ple of a cardiac signal. .....................................................................................................................
Figure 2. Intervals betw een cardiac signals. .....................................................................................................
Figure 3. ICD and the heart.....................................................................................................................................13
Figure 4. Components inside the ICD . ..................................................................................................................
Figure 5. System overview diagram . .....................................................................................................................
Figure 6. Client site ICD disk index/archive system .....................................................................................
Figure 7. The shared ICD data archiving system .............................................................................................
Figure 8. Current search page screen shot. .....................................................................................................
Figure 9. Patient result page screen shot.........................................................................................................
Figure 10. Episode search result screen shot. ...................................................................................................
Figure 11. Patient page screen shot........................................................................................................................39
Figure 12. ICD page screen shot.............................................................................................................................40
Figure 13. Episode page screen shot......................................................................................................................40
Figure 14. EGM page screen shot...........................................................................................................................41
Figure 15. Bank page screen shot. ..........................................................................................................................
Figure 16. M edtronic and Guidant integrated search page ...........................................................................
Figure 17. M edtronic ICD page screen shot....................................................................................................
Figure 18. Tachycardia Log Entry page screen shot. ......................................................................................
Figure 19. Full detail and com ment page screen shot. ....................................................................................
Figure 20. Beat interval plot page screen shot .................................................................................................
Figure 21. N on-log ext section page screen shot. ............................................................................................
Figure 22. Log-based text section page screen shot ........................................................................................
Figure 23. Relationships in the database .........................................................................................................
Figure 24. Insertion process of data. ......................................................................................................................
Figure 25. Insertion details......................................................................................................................................59
5
8
9
15
19
21
25
37
38
39
41
42
43
44
46
47
48
49
51
53
Chapter 1
Introduction
This paper details the research, design, and implementation of a web-enabled and searchable
computer system built to archive electrograms and related patient data from implantable cardioverter
defibrillators (ICDs). This system will handle how the data sent from the hospitals should be handled and
how users will be able to search the ICD data they need. In particular, I will go into depth in describing
the implementation for models manufactured by Medtronic, one of the major manufacturers of ICDs.
1.1 Background
Implantable cardioverter defibrillators are common devices employed to constantly monitor the heart
rhythm of patients at high risk of sudden cardiac death from ventricular tachyarrhythmias. The most lifethreatening arrhythmia is ventricular fibrillation (VF), where the patients can die within minutes if
immediate treatment is unavailable. The less serious ventricular tachycardia (VT) can also turn into VF,
thus posing additional threat. ICDs have been shown to possess higher life-saving potential than medical
therapy for patients with VF. Not only do they apply shocks to the patients' hearts when necessary, they
also store electrogram (EGM) documentation of episodes of VF and VT attacks.
1.1.1
Cardiac Arrhythmias
Arrhythmias are disorders of the heart rhythms. They can describe hearts that beat outside of the
normal range of 60 to 100 beats per minute, or hearts that beat irregularly. Some of them are of minimal
6
consequence, while some of them are fatal. The seriousness of arrhythmias also depends on a person's
age, activity, and physical fitness.
Bradycardiais the term for a heart that beats less than 60 beats per minute. Many athletes actually have
it because their hearts have become very efficient in circulating blood. Thus bradycardia can happen to
perfectly healthy individuals. However, bradycardia can also cause insufficient cardiac output. With so
few contractions, the body may not get enough blood. Symptoms of fatigue, dizziness, lightheadedness,
fainting or near-fainting spells will then arise. When needed, bradycardia can be easily corrected by
pacemaker implantation.
Tachycardia is the term for a heart that beats more than 100 beats per minute. It is also called
tachyarrhythmia.While it is less harmful at the lower range, it is much more serious above the optimized
cardiac output rate of 180 beats per minute. The heart is no longer able to adequately fill its chambers
with blood before each contraction. The body becomes deprived of blood despite the heart pumping
madly. Symptoms may include palpitations, rapid heart action, dizziness, lightheadedness, fainting or
near fainting. Ventricular fibrillation may also arise, making the heart unable to beat at all and sending
the patient into cardiac arrest, and treatment may involve cardioversion, medication, and implantation of
ICDs.
Arrhythmias can also be classified according to the origin of the heartbeat abnormality. Ventricular
arrhythmiascome from the lower chambers of the heart called the ventricles, while supraventricular
arrhythmiascome from tissues above the ventricles. Supraventricular arrhythmias can describe any
arrhythmias coming from the sinus node, the atrium, or even the atrioventricular node that connects to
both the ventricles and the atria. As an example, ventriculartachycardiadescribes unusually fast beating of
the heart originating from the ventricles.
1.1.2
Electrocardiograms
An electrocardiogrammeasures the electrical activity of the heartbeat from the surface of the patient's
body. It is often abbreviated to ECG or EKG, and sometimes called a cardiogram.When the electrical
impulses move through the heart, they can be picked up by electrodes on the patient's arms and legs, and
7
across his chest. These electrodes are connected to wires that send the signals to the ECG machine, where
the electrical activity of the heart will be printed on moving strip of paper for examination by the
physicians. By examining the ECG, a physician can determine the presence of any arrhythmias.
There are two major kinds of information provided by the ECG. By measuring the time intervals on
the ECG, the physician can determine the speed and regularity of the heartbeats. Next, by measuring the
morphologies of the impulses, the physician can determine where in the heart the problem may have
risen. The ECG machine automatically records signals from a number of different combinations of the
electrodes, with each one being a lead by itself. For example, a lead records the signals between the
patient's two arms, another one records the signals between the patient's left arm and right leg, and yet
another one records the signals across the patient's chest. With all these leads of varied combination, the
physician can practically get a three-dimensional picture of the electrical activity within the patient's
body.
1:
E4.
Figure 1. Example of a cardiac signal'.
Example of an electrical signal produced by one single heartbeat is shown in Figure 1. The first little
hump marked by P is the P-Wave produced by the atria. The big spike that follows is the QRS Complex
produced by the ventricles. Following the QRS Complex, another hump marked by T is the T-Wave,
which represents the repolarization of the ventricles in preparation for the next signal. The interval in
between the beginnings of the P-Wave and the QRS Complex is called the PR interval during which the
impulse is traveling through the atria, the atrial-ventricular (AV) node, and the ventricular conduction
1Cardiac Arrhythmia InfoCenter. http:/ /home.earthlink.net/-avdoc/infocntr/htrhythm/hrecg.htm,
2003.
8
system. The distance between the QRS Complex of one signal to the next is called the RR interval. These
intervals are shown in Figure 2.
- - - ---.
F~j
Figure 2. Intervals between cardiac signals.
1.1.3
Ventricular Arrhythmias
It has been estimated that 350,000 sudden cardiac deaths occur in the United States each year, and
most of them are due to ventricular tachycardia and ventricular fibrillation [1]. The most common causes
that trigger these ventricular arrhythmias are heart attacks and heart muscle diseases.
1.1.3.1 Ventricular Tachycardia
Ventricular Tachycardia (VT) is one of the most frequently observed arrhythmias in the United States.
It is the unusually rapid beating of the heart that originates from the ventricles at a rate of greater than
100 beats per minute, but oftentimes VT may reach 200-350bpm. When VT reaches a rate of 300bpm or
more, it can be called Fast Ventricular Tachycardia (FVT). Other characteristics of VT include wide QRS
complexes of greater than 120ms, presence of AV dissociation, and fusion beats. Its greatest risk comes
from its tendency to spontaneously degenerate into fatal Ventricular Fibrillation (VF) [2].
There are two types of VT, non-sustained and sustained. Non-sustained VT stops on its own within a
few seconds of its onset. Although it may cause palpitations, lightheadedness, and fainting, it is generally
not life threatening. For sustainedVT, the continuous rapid heartbeats dramatically reduce cardiac output
and blood pressure. Eventually collapse and death may ensue, so medical intervention is necessary to
stop sustained VT. If the patient is still awake, medications can be given intravenously. However, if the
9
patient goes into cardiac arrest with loss of consciousness and no detection of pulse or blood pressure,
electrical cardioversion has to be given via the use of defibrillators.
1.1.3.2 Ventricular Fibrillation
Ventricularfibrillation(VF) is a condition in which the heart's electrical activity becomes disordered
and chaotic [3]. It is often preceded by VT. For VT, the individual myocardial muscle fibers contract in a
rapid, unsynchronized manner. The heart would look like a trembling piece of organ with no ability to
pump any blood. VF can cause immediate collapse of the patient's cardiovascular system, and it is the
primary cause of sudden cardiac death. The patient has to be treated with electrical cardioversion right
away to have any chance of survival. However, even if the patient is successfully resuscitated, he is still at
very high risk of recurrence [4].
Characteristics of VF include an irregular heart rate usually exceeding 300 bpm, an initial amplitude
exceeding 0.2mV, and a waveform that completely flattens within 15 minutes. VF is associated with
coronary artery disease and can be caused by blockages in the coronary arteries. ICDs are the best
treatment for patients of VF.
1.1.3
Sudden Cardiac Death
Sudden Cardiac Death (SCD) is the consequence of a cardiac arrest caused by VF or VT.
Approximately 250,000 out-of-hospital cardiac arrests occur annually in the United States, making SCD
the leading cause of death in the country [5]. However, only 2 to 5 percent of these cardiac arrest victims
are successfully resuscitated. In treating these patients, time is the key. It has been shown that for every
minute that elapses before defibrillation, 7 to 10 percent of patients who might be saved are lost [6], and
the American Heart Association advises a 4-minute critical time frame. It has been documented that
individuals who have had near sudden death experiences, severe heart diseases, and congestive heart
failure are more susceptible to SCD.
10
Several alternatives exist in the prevention of out-of-hospital SCD. Traditionally, VF patients have
been given antiarrhythmic medications to keep their heart conditions in check. These medications include
amiodarone, sotalol, and other drugs as needed, such as beta-blockers, aspirin, and ACE-inhibitors.
However, automated external defibrillators (AEDs) and implantable cardioverter defibrillators have been
shown to be more effective in recent years.
1.1.4
Automated External Defibrillators
Automated External Defibrillators(AEDs) are defibrillators able to automatically detect the presence of
VT and VF and perform cardioversion to cardiac arrest victims. When a cardiac arrest case is suspected,
an AED operator can place electrodes on the patient's chest. The AED will detect the patient's condition,
confirm the presence of an arrest, and make a decision for cardioversion. The AED will also instruct the
operator to carry out necessary steps for defibrillating the patient.
There are about 50,000 AEDs in use today [7], and effort has been spent to disseminate AEDs aboard
airplanes and in communities. For these publicly accessible AEDs, liability is not an issue at all since
legislation has been passed in almost all states. For the remaining few states without their own legislation,
the proposed federal Cardiac Arrest Survival Act would protect businesses that provide AEDs from
liability.
American Airlines tested a program in 1997 where automated external defibrillators were placed on
all flights and all 24,000 of its flight attendants were trained to use them in a two-year period [8]. During
this time, defibrillators were used 200 times, which included 191 times on the aircraft and 9 times at the
terminal gate. The AEDs were able to identify cases of VF at 100% specificity and sensitivity, and 13 out
of 13 VF victims that underwent the defibrillation were successfully defibrillated. The rate of survival till
discharge from the hospital was 40% compared to originally rare survival of VF victims aboard due to
delay in getting defibrillation.
Equipping police with the devices and training officers to use them can also save lives since the time
to defibrillation is greatly reduced. In the casino study [9], AEDs were stored such that the farthest device
was no more than 3 minutes away from anywhere with the casinos. Security officers were also trained to
11
first apply AEDs to patients of suspicious cardiac arrest, followed by manual cardiopulmonary
resuscitation. With a mean 4.4 minutes from collapse to the delivery of the first defibrillation shock, the
survival rate of 90 witnessed cases is 74% compared to 49% of patients who waited till the arrival of
paramedics at a mean of 9.8 minutes.
Even when the defibrillator operators have not used the device in the past, use of AEDs within five
minutes of cardiac arrest proved to be invaluable in resuscitating victims. In a two-year study where
AEDs were installed through out terminals at three Chicago airports, 11 out of 18 VF cardiac arrest
victims were successfully revived, with 6 of the rescuers having no training for AEDs in the past, and
only 3 of them having medical degrees. Out of the remaining 7 unfortunate cases, 4 were due to use of
defibrillation later than 5 minutes, and only 3 were patients who stayed in fibrillation even after the
application of defibrillation within 5 minutes of cardiac arrest [101.
However, since the time to defibrillation is so crucial, the locations at which AEDs are placed have to
be carefully strategized. Operation Heartbeat from the American Heart Association aims to start a chain
of survival that will eventually raise the 5% survival rate for SCD victims to more than 20%. To achieve
this goal, immediate access to an AED is very important in the four-step process of early access, early
CPR, early defibrillation and early advanced care. However, for patients with constant and high known
risk of cardiac arrest or recurrent VF, an implantable cardioverter defibrillator (ICD) would prove more
effective than an AED.
1.1.5
Implantable Cardioverter Defibrillators
Implantable cardioverter defibrillators (ICDs) are defibrillators that can be implanted into patients'
chests to automatically detect episodes of arrhythmias and deliver therapeutic cardioversion if necessary
(Figure 3). They have been in use since 1985 and have saved the lives of many people who would have
been sent home only to experience another VF induced cardiac arrest.
12
Figure 3. ICD and the heart.
An ICD is about the size of a beeper, and performs functions that include those of a pacemaker. For
example, sustained VT can now be stopped by the ICD with the use of anti-tachycardiapacing, a rapid and
painless stimulation of the ventricles that avoids the need for an uncomfortable shock. The ICD system
utilizes one or more pervenous electrodes for rate sensing and defibrillation. The electrode is placed in
the apex of the right ventricle. The ICD and electrode combination follows the parameters programmed
into the ICD by the programmer.
The concept of an ICD to treat SCD is due to Michel Mirowski in 1966 [11]. When an arrhythmia is
detected, the device will deliver the programmed cardioversion, energy of less than 5 Joules for VT, or
defibrillation therapy, energy up to the maximum of the device for VF [12]. The device usually has
independently programmable tachyarrhythmia detection procedures for each case, but the detection of
FVT can be programmed via either VT or VF detection. The detection is based on heart rate and the
length of time that rate remains above the programmed rate. Different therapies can be independently
programmed for each arrhythmia type.
ICDs have been shown to be highly effective for saving lives of patients with high cardiac death
probability. A European study where the researchers followed 102 patients, there was a 91% survival rate
with 58% receiving therapies from their devices [13]. The Multicenter Unsustained Tachycardia Trial
(MUSTT) and Multicenter Automatic Defibrillator Implantation Trial (MADIT) have confirmed that
defibrillator implantation can reduce mortality by as much as 50% in coronary artery disease patients
with ejection fraction of less than 0.40, spontaneous nonsustained ventricular tachycardia, and inducible
13
sustained ventricular tachycardia on electrophysiologic studies [14]. In the MADIT II Study where the
researchers enrolled 1232 patients over four years and assigned them to conventional medical therapy
and ICD implantation in a 2:3 ratio showed that the mortality rate for the ICD group was 5.6% lower than
that of the other group. There was also a 31% reduction of hazard ratio for the risk of death from any
cause in the ICD group [151. The AVID (Antiarrhythmics vs. Implantable Defibrillators), CASH (Cardiac
Arrest Study Hamburg), and CIDS (Canadian Implantable Defibrillator Study) have also shown results
that support the superiority of ICDs in treating patients over antiarrhythmics. ICDs are thus considered
highly effective devices to prevent SCD in patients of ventricular arrhythmias.
ICDs also serve the function of providing information about patients' conditions or deaths. A
collaborative study by several universities has found that for patients with ICDs, non-cardiac related
deaths were sometimes wrongly associated with SCD [16]. The reason for death for 109 patients was
classified into three categories: sudden cardiac, nonsudden cardiac, and noncardiac. Later, the
categorization was assessed via autopsy and interrogation of ICDs. Out of the 17 patients categorized as
sudden cardiac cases, only 7 had their ICDs discharge near the time of death, suggesting that deaths
classified as sudden cardiac can in fact be non-cardiac. The examination process can be greatly facilitated
if ICD data have been supplied throughout the patients' history with their ICDs as data contained in the
ICDs proved to be an invaluable source of information.
ICD Implantation
Recent advances in ICD technology have made it relatively safe to implant in a minor operation that
takes one to two hours. The implantation procedure is performed under local anesthetic by an
electrophysiologist,a cardiologist specialized in the treatment of arrhythmias. An incision is made below
the patient's collarbone and a pocket is created for the device's pulse generator, composed of the battery
and other electronics, under the skin. Electrodes are then guided into the heart through the veins with the
use of x-ray technology. After a testing by the physician artificially simulating an arrhythmia and the ICD
correctly identifying and performing necessary treatment, the incision is closed and the operation is
completed.
14
ICD Components
The various components within an ICD are shown in Figure 4. The functions of these components are
also described below.
7b
Figure 4. Components inside the IC
1.
ho
2
Beeper: Warning beeps are sounded when the battery runs low. Other problems that the
physician should check out may also be indicated by beeps.
2.
Battery: Batteries made of lithium silver vanadium oxide last six years or more.
3.
CPU: The processor chip analyzes electrical signals from the heart and determines whether any
shocks are necessary. The chip runs at less than 100 kilohertz for energy efficiency considerations.
4.
Antenna: Communication between the ICD and the programmer is made through low-frequency
radio waves sent from the unit's antenna.
A shock to the system. New York Times on the Web, http://www.medtronic.com/icd/nyt/article.html,
2001.
2
15
5.
Connectors: A lead with three connections provides sensing capabilities and a pathway for highenergy shocks to one of the heart's lower chambers. A second lead with only one connection
provides sensing and pacing to an upper chamber.
6.
Casing: The ICD is encased in titanium. Scar tissues grow around it, locking it in place. The
device is sealed shut to prevent leakage, so when the battery dies, the entire device must be
replaced.
7.
Memory: The pattern of heart activity before, during and after disturbances is recorded. Since
these signals are recorded from the patient's heart chambers, they are electrograms (EGM) rather
than ECGs.
8.
Leads: Flexible wires convey sensing information to the ICD and carry electric shocks to the
heart. A patient may receive one or two leads depending on the nature of the heart problem.
They are covered with silicone insulation.
9.
Capacitors: Similar to the ones used in camera flashes, capacitors can take up to 10 seconds to
draw enough energy from the battery for a large jolt. Charge times for smaller shocks are much
shorter.
10. Transformer: For serious heart disturbances requiring a shock, a transformer converts lowvoltage battery power into a higher voltage.
The Programmer
Apart from the ICD device itself is the monitoring device used by the physicians. After implant, the
physician can check or adjust the ICD settings by using an external computerized device called a
programmer/recorder/monitor (PRM). The PRM device communicates with the ICD in patient's body
via radio waves from a doughnut-shaped receiver held over the implant site. It works much like using a
garage door opening or clicking a remote control to change channels on a television. The doctor or nurse
uses the PRM to program and test the ICD after implant. When the patient goes in for a checkup, the
PRM is used to read the information stored in the pulse generator's memory since the patient's last visit.
16
The programmer is also able to print paper copies of the data contained in the device at the time of
download. This is how EGMs are traditionally made available for the physician to examine. If a floppy
disk is supplied and inserted into the programmer, the programmer will also save the result of its
interrogation into the diskette.
1.2
Motivation
What triggers fatal arrhythmias has largely remained a mystery despite the effectiveness of the
defibrillators. In attempting to understand the causes of SCD, National Institute of Health sponsored the
Triggers of Ventricular Arrhythmias (TOVA) study [17]. It aims to investigate factors that trigger the
discharge of ICDs. In particular, activities such as wake time, time of assuming the upright posture,
eating and taking of medications are hypothesized to relate to onset of arrhythmia. Thus TOVA will
characterize triggering in 2000 episodes of ICD discharge in 3000 patients treated in 44 centers nationwide
over four years to determine if ICD discharges occur more frequently in certain period. These periods
may include the 3 hours after awakening, on Monday, and in winter, and determination can easily be
made from data contained in the ICDs. TOVA will also utilize EGMs recorded prior to ICD discharge to
identify sympathetic activation during triggering.
Our effort to build a web-accessible database system is in support of the gathering and sharing of
such ICD case data. Currently ICD manufacturers provide proprietary hardware and software to retrieve
data contained in ICDs and store them in floppy disks. However, the floppy disks are hardly ideal
because they are difficult to index and unreliable in storing data. Furthermore, sharing of information is
not as convenient and viewing of information is only possible in paper plots. Thus a searchable archiving
system that may be accessed by multiple users from multiple sites is desired. The physicians will be able
to upload and make the data available instantly, and the researchers will be able to access desired data
from wherever they are.
17
1.3
Related Work
The effort to gather ICD cases and make them available over the web started with the TOVA Database
Project in Early 2002 [18]. The TOVA project had several goals. First it transformed the Guidant data in its
original proprietary ZOOM format into PhsioNet's WFDB format, which is a public and well documented
format [19], so that the waveforms can be stored and displayed properly. Secondly a web interface was
created so that viewing and computerized processing of these waveforms and associated parameters is
made possible. Lastly, other proprietary ICD data have to be deciphered, converted, and adapted for web
access.
It was found that input file formats differed between models and manufacturers, so the same codes
cannot be applied quid pro quo. However, the similarities between models for a particular manufacturer
were large enough that considerable code reuse was possible. Eventually inputting a directory containing
the ZOOM format data into the toolchain could output waveforms in WFDB with their annotations, txt
files with parameters, and a data descriptor file that itemizes all generated files.
Another important consideration is that since the ICD data will be provided publicly, de-identification
of data is necessary to protect patients' privacy. This was also made possible in the TOVA project. By
September 2002, there is a complete system capable of processing ICD data from all Guidant ICD devices
in active use. Data from more than 500 patients have also been uploaded and archived.
1.4
The paper
This document outlines the design and implementation of an automated web-based searchable
archive for ICD data. Chapter two will cover the overall goals and design of the archive system. Chapter
three will detail the implementation of the archive. Chapter four will present the potential effects of the
system. Chapter five will conclude with any future work that can be done to enhance the system.
18
Chapter 2
The Current Archive System
At the inception of my participation in the project, a working system designed around Guidant data
has been implemented [181. Guidant data can be uploaded from the clinic, properly de-identified and
sent to the server at MIT, further processed and archived, and provided to researchers for searching and
viewing over the web. Medtronic data can also be uploaded from the clinic, de-identified, and sent to
MIT, but it has not progressed further than being converted into some waveforms and textual data. This
chapter has been dedicated to describe how the overall system functions, with details pertaining to
Medtronic data.
2.1 System overview
The system can be described by its two major components, the client systems generally located in
clinical facilities, and the shared archive presently located at MIT. The design of the system is shown in
Figure 5.
Shared Archive
Client System
ICD disk data are:
" Generated
" Indexed and
archived
" De-identified
" Uploaded to the
server side
ICD disk data are:
0
0
Converted
Merged
Archived
Data retrieved are:
0 Searchable
*
Displayable by
waveforms
I
Figure 5. System overview diagram.
19
The data will reside in the shared archive while the interface of the client system is used to upload and
download these data. A client-server architecture for the archive has been chosen because it is more
efficient and can handle simultaneous requests from multiple users who may wish to gain access to the
shared archive. In addition, the interface will be web-based because the danger of information leak over
the web has essentially been eliminated by first stripping away any personal information before the data
leaves the clinic. Thus for the purpose of an ICD archive, a web-based client-server model will enjoy all of
the benefits and none of the downfalls.
This section follows the flow of data from the device to the eventual search result displayed on the
web interface. It is organized around the clients and the server, and details the various stages within these
components, with their specific roles and functions. The flow of data starts from its transfer from the ICD
into the clinic system, then to the insertion from the clinic into the MIT database, and finally to the search
result displayed on users' computer screens. Particular attention has been made to describe the working
of the system's Medtronic portion.
2.1.1
Client system
The client systems are designed around an internal Linux clinic PC that performs the tasks of ICD
disk indexing, archiving and de-identification. The clinic PC runs a web server and provides the internal
network within the clinic. The customized software for receiving, indexing, archiving and de-identifying
ICD data runs on the clinic PC.
One or more Windows user PCs can be connected to the clinic PC via internal network, working as
client machines running web browsers. The web server provides pages to guide users in uploading or
retrieving ICD disk data.
20
User PC
Clinic PC
Internal
Web Server
Web Browser
o Indexing
o Archiving
o De-identifying
File System
(HTML)
De-IDed
Data
Internet
Diskette
1se
Figure 6. Client site ICD disk index/archive system.
The programmer interrogates the ICD
The ICD implanted in the patient's body holds all of its data in binary format. This data includes
various settings on the device, information about the patient, and waveform or other related information
when an episode occurs. Since the recording of data is an ongoing process, the content of this data can
always change before a downloading session at the clinic is made by the physician when the patient goes
for a visit. The physician downloads data from the patient's ICD device with the help of a programmer
that interrogates the device with radio waves. After the download, unless the physician specifically erases
the data, the already downloaded data will remain inside the ICD.
Diskette holds programmer output
After the programmer interrogates the ICD, it can print paper copies of the data and save the result of
its interrogation into a diskette. The resulting files saved in the diskette are of manufacturer-specific
format, and we will refer to them as the raw data files. For Guidant, the raw data files include a number of
overview, text, and binary graphical files. For Medtronic, a single binary file with a .ppd extension is
saved in the diskette as the sole raw data file. Thus each downloading session will produce one binary
21
raw data file that combines all of the text and graphical data inside the diskette. It is also possible for the
diskette to hold multiple raw data files, either for the same patient or different patient.
Since the data would stay in the ICD unless the physician erases it intentionally, there can be repeated
data contained in multiple files. Every downloading session furthermore gives its resulting raw data file a
different name to prevent overwriting of old data by new data, making distinction by name infeasible.
Thus this repeated data must be handled, which will be discussed later in this chapter. For our system, a
diskette containing the raw data files is required for the next step.
User PC translates data and uploads resulting files to clinic PC
The user PC is used to translate the binary raw data files in the diskettes into text files, and upload
both the binary and text files to the Clinic PC where they are archived in their unprocessed forms. The
translation is done with proprietary programs supplied by the manufacturers, and these programs may
require the user PC to be run on certain platform. On the other hand, for uploading to the Clinic PC, as
long as a local connection to the Clinic PC can be made, there is no platform restriction for the user PC.
For Medtronic, the translation utility program is called Save to Disk Translation Utility. The utility takes
the binary raw data file as input and outputs a text file that can be read and understood by humans; we
will refer to this textual output as the original datafile. The utility has to be run under a Windows
environment where it can be run with a graphical interface or under the command prompt. For the
graphical interface option, the names of the files contained in the diskette will appear in the left window
of the interface as soon as the diskette is inserted into the floppy drive of the user PC. The user can then
select into the right window desired files to be translated. Only the files that appear in the right window
will be translated at the end upon the click of a button. An output directory where the resulting text files
with .txt extension are to be placed can also be chosen at this time.
After the text file is outputted, the user places the .txt file with its .ppd counterparts in the same
zipped file to save memory, and sends the zipped file to the clinic PC. This is a manual step that is a bit
cumbersome if there are multiple raw-original data file pairs to be dealt with since every pair has to be
matched one-by-one. However, the utility can also be run in the command prompt, so we may be able to
22
run the translation and zipping steps with one single program as a possible extension of the system in the
future.
The user PC can be based on any platform as long as it is connected to the Clinic PC via local network,
but the translation utility program supplied by the manufacturer can only be run under the windows
environment. Thus a windows-based PC is preferred to save the trouble of having to use two different
PCs. The user has to select the zip file, and uploads it to the clinic PC via an html interface.
To upload the zip file, the user has to follow the instructions on the upload page. A username,
password, and the TOVA patient study code have to be entered along with the file to be uploaded. The
usemame and password are necessary to establish the authenticity of the user and prevent abuse of the
system by people without proper authority. The patient study code is used to identify the patient in order
to organize the data with other data from the same patient in the clinic PC. After all the information is
supplied, the upload button will trigger action to archive the zip file into clinic PC.
Clinic PC de-identifies data and archives
The clinic PC serves as the raw data archive for ICD data downloaded from patients and is run on a
Linux platform. It unzips the zip files that contain the raw-original data file pairs, indexes them, makes a
de-identified copy of the original data file, and archives them locally.
To protect the patient's privacy, de-identification is carried out on the clinic PC and from this step on
all of the data will be de-identified. De-identification before the data leaves the clinic avoids complexity of
web security and the possible compromise of the patient's identity through any names (of the patient
himself or his physician), dates (birthday or implant date, shifted by a constant amount but preserving
the time intervals), or other data that could reveal who the patient might be. The original data file is taken
as input, and the output is a zip file containing a de-identified version of the original data file (also of .txt
format) and an overview file named ICD-id-info.txt. The overview file will be used to identify the patient
at the server side, and it includes five vital pieces of information for doing so: patient ID alias, device
manufacturer, device model, device serial number alias, and disk data format.
23
After the de-identification process, an index table is created that maps the patient's real name to an
alias code. Other fields of the table include an index number, the study code, patient's birthday, and
patient's gender. Upon clicking on the patient's name, a patient page is shown. This page lists the
multiple devices and zip files associated with this patient. For the device, manufacturer, model, serial
number, serial number alias, and implant date are provided. For the actual interrogation data,
interrogation disk number, disk name, save date, format, programmer model, programmer serial
number, zip file, and its associated de-identified output file are provided.
User PC downloads de-identified data and uploads to Physio-Arch
After clinic PC processes the data, user can access the archived de-identified zip file, download it
and upload it to Physio-Arch, the server that resides at MIT. Both the download and upload are done for
one single file at a time. This is a manual step at the moment, pending on hospital approval that will
make external connection for the clinic PC possible. Once the approval is granted, direct connection from
the clinic PC to Physio-Arch will automate this manual download and upload process.
The user downloads the data via the same internal site that he uses to upload data into the clinic PC.
For uploading into Physio-Arch, the user PC has to have external connection and employs the use of the
World Wide Web.
2.2.1
Shared Archive
A Linux PC running a web server and a relational database hosts the archive. Customized software
is used for converting, inserting, and displaying ICD data. The structure of the system is shown in Figure
7.
24
Linux PC (Physio-Arch)
Web Server
Internet
Retrieve data
Convert data
* Search data
Generate file for
EGM/Middleware
Create tables
9 Display waveforms
i
Insert data
File System (Linux)
Relational Database
(PostgreSQL)
oseQ
Figure 7. The shared ICD data archiving system.
Physio-Arch runs automated data processing events
The upload of a de-identified zip file by user at the clinic triggers an automated chain of events that
includes EGM file generation and database insertion, which eventually leads to the archiving of ICD data
at Physio-Arch. The end results are files that can be used to generate EGMs on web browsers and
database entries specific down to the individual field level. Both the EGM generation and database
insertion phases take the same de-identified zip file as input.
The EGM generation phase unzips and looks at the de-identified data file, extracts sections with
EGM waveform and beat interval data, and converts them into WFDB format to be used for graphical
display on the web later. During this phase, beat interval data has to be synchronized carefully with the
actual EGM data. Also, every single EGM episode has to be properly indexed according to patient's
name, device model, and device SN. The end results are groups of files stored in a temporary directory,
with each group representing a particular episode. The unzipped de-identified data file and the overview
file are also contained in this directory. This temporary directory will be cleared as another upload
session begins.
The database insertion phase takes the temporary directory from the EGM generation phase as
input, generates a middleware file that contains field-value pairs from the non-graphical sections and file
25
names of EGM data, and inserts them into the database. The EGM files are also copied to a permanent
location to be accessed by the interface.
Researchers search for data on Physio-Arch website
Access to ICD data will be conducted over the web at the Physio-Arch website dedicated to ICD
data. Researchers will be able to search the data by patient or by episode. All of the information contained
in the ICDs is displayed, including any text and EGM data. A utility provided by PhysioNet takes the
EGM files stored in Physio-Arch directories and displays them in annotated and unannotated formats.
Other textual data are displayed in tabular format according to their respective sections. Comments can
also be attached to the EGMs by authorized researchers or physicians.
2.3
Technology choices
There were several choices we could make to implement the system described above. Here the choices
and alternatives are discussed.
2.3.1
Information storage
There were several choices for storing ICD data. Firstly, information can be processed into text and
graphical files, and accessed through Perl-based Common Gateway Interface (CGI) programs. Secondly,
information can be stored in serialized JAVA objects and accessed through Java. Thirdly, information can
be processed via Perl into files in Extensible Markup Language (XML), and displayed by Extensible
Stylesheet Language Transformations (XSLT). Finally, information can be stored in relational databases
and accessed through Perl- or PHP-based programs that connect the database with a web interface.
Out of all the choices, the relational database approach is employed, the reasons being the database's
robustness, versatility, and efficiency in accessing data. Programming is easy and structural, and once the
data is stored in the database, statistics can be easily performed or groups formed according to the needs
and requests of the users. The particular relational database chosen to carry on the task of information
26
storage is a PostgreSQL database. It is an open-source freeware that works in conjunction with Linux
operating systems. Linux is an extremely stable platform that is superior to Windows and comparable to
Unix, and being an open-source freeware it requires no monetary investment. Although MIT provides
free use of Unix to researchers within its community, we need to consider the possibility that the server
will be hosted elsewhere, perhaps in a hospital or clinic that may not be on a Unix system.
The open-source nature of the system's underlying architecture keeps the operating cost low, an
important facet of non-profit services. Also, it ensures that in the case of any problems with the
architecture, there would be plenty of support in the PostgreSQL and Linux communities. Any possibly
useful future extensions to the architecture will also be free of charge to obtain.
2.3.2
Web server
Apache web server has been adopted for the purpose of handling data for the web. It has provided
open-source HTTP server support for many UNIX and Windows users since April of 1996. The fact that it
has stood the test of time proves its reliability and popularity. In July 2003, the Netcraft survey found that
63% of the web sites were being run on Apache [19].
2.3.3
Software
With the exception of utility programs provided by the manufacturers, software used by the system
is developed with open-source Perl, Perl CGI, C, SQL and the WFDB software package in PhysioToolkit3 ,
the software repository of PhysioNet, an NIH-funded Research Resource for Complex Physiologic Signals
[201.
All of the text parsing programs were written in Perl for its powerful manipulation of strings, and
the underlying CGI for web pages was also written in Perl. Conversion of graphical data was done in C,
and display of graphical data was made possible by the WFDB software package. SQL was used to access
the database.
3
http:/ /www.physionet.org
27
2.4
Incorporation of existing and future manufacturers
ICD data are of manufacturer-specific formats, making data storage in separate manufacturer-
specific databases the most efficient solution. However, in searching for episodes and patients of interest,
manufacturers are often not a concern for the researchers. This poses a difficulty in attempting to
integrate these separate databases for different manufacturers. Furthermore, it is possible for a patient to
own ICDs from different manufacturers.
As a result, it has been decided that separated searches would be run for the different databases on
the same set of criteria. Integration of data from different manufacturers will then be done on the
interface. Even though this interface-level integration yields a less elegant solution than a complete
integration of data for all manufacturers, it avoids a lot of the problems in attempting to match differently
named fields and missing fields across all manufacturers.
28
Chapter 3
Goals and Design
The success of this system depends on how useful it will be. It has to be user-friendly and serve its
purpose well. The researchers should be able to quickly search for data that they want to see and data
that they need.
This chapter will outline the goals and the details of design for the Medtronic portion of the system. It
will include a description of the data model for the Medtronic database, discussions on the designs of the
interface and database, and issues related to integration with Guidant data and any other future
expansions to be incorporated into the system.
3.1 Goals
To make this system truly useful for the researchers, great care has to be given in the following areas
to guide the design and implementation:
*
Data shall be automatically handled to the maximum extent
*
Data shall be properly converted, parsed, and stored in the database
"
Data shall be readily and easily searchable by researchers
"
Data shall be correctly retrieved and displayed on web browsers
"
A mechanism should exist for data from yet unseen models to be handled appropriately
*
A mechanism should exist for certain authorized researchers to attach comments to certain
specific pieces of data
29
The system design should allow integration with the existing system and future systems of
*
similar purpose and usage
3.2 Medtronic Data structure
My contribution to the project starts in the shared archive phase of the system, with particular focus
on the handling of Medtronic data. At this point, an overview has been generated and is available to me
to identify the patient, and EGM files are also available after the EGM generation step, along with the
original de-identified data file. All of these files should be parsed for information, generated into
middleware, and inserted into the database. Afterwards, the web interface has to be written to retrieve
data from the database, and integration of data display with the Guidant database that has previously
been built needs to be carried out also.
It is thus imperative to be familiarized with the underlying data that is the focus of the archive
system.
De-identified text file
3.2.1
Data contained in the de-identified text files are divided into sections. As mentioned earlier, some of
these sections contain only text information while some other sections contain information that can be
converted into EGM displays.
The very first section is the header section. It specifies information such as program version, model
number, file type, and other mega-data about the file itself. After the header section are the numbered
sections presenting information on device settings, episode records, log entries, and waveform data.
Although all of the data files for various Medtronic models have the same section structure, the section
names vary in a few cases, placing doubts that the ordering of the sections may vary across different
models as well. This introduced some complications in processing the data files.
'An example file can be found in the Appendix
30
Following is a list and brief descriptions of sections present in Medtronic data files listed by their
section numbers. Missing sections are result of unavailable models.
1.
Parameters: features of the ICD such as Detection being turned on or off and Therapy Modes and
strengths.
2.
Counters and Status: status of the ICD itself such as timestamps and energy level.
3.
Tachycardia Log Entries: data about tachycardia episode start time, type, etc.
4.
SVT/NST Log Entries: data about supraventricular and non-sustained tachycardia episode start
time, type, etc.
6.
Episode Records: numerical values that can be graphed into waveforms. The entry numbers
correspond to entry numbers in Sections 3 and 4. The numbering for data related to different
sections is done separately, so the entry numbers sometimes overlap. The content of this section
has been converted into EGM files.
10. Patient Alert Log: episode information or trouble session information.
11. Mode Switch Log: any mode switch episode data.
12. Dual Chamber R-R Intervals (Single Chamber R-R Intervals): numerical values that can be
graphed into waveforms. The content of this section has also been converted into EGM files and
are separated according to related entry type and entry number. For dual chamber ICD models,
R-R, R-P, P-R, and P-P data are stored. For single chamber lCD models, only R-R and P-P data are
stored.
13. Daily Log: levels of ICD battery, impedance, and other measures on a daily basis.
14. Weekly Log: levels of ICD battery, impedance, and other measures on a weekly basis.
15. Patient Information: patient ID, birthday, ICD device and lead information of which private
items have been de-identified.
20. Long Term Clinical Trends: an log entry of arrhythmic episode information.
The sections can roughly be grouped into two groups. For some sections they are stand-alone, and for
others, they are inter-related. Specifically, the graphical sections are related to text sections whose names
contain the word "Entries", while other text sections that do not contain "Entries" in their names are
31
stand-alone sections of which data can be simply listed in tabular format on an individual page. This
classification into stand-alone and EGM-related sections will help greatly in trying to design a site linkage
structure and the database.
3.2.2
Intra-section structure
To process data contained in various sections, a closer look at the structure within each individual
section of the raw data is essential. Below is a description of how the data look within each section.
Section Beginning and Ending
Every section, regardless of its content, always starts with
"Section", [section_ number]
,"
[sectionname]", [sectionformat_version]
and end' with
"End of Section", [sectionnumber]
This convention is very useful in determining the section beginnings and ends and searching for
appropriate sections for proper handling of data contained in them, so I made the assumption that the
sections will always start and end in the same fashion even for a new model that was not seen previously.
Section Meta-Data
After the section beginning line, one or more lines are devoted to describe the section instead of the
data contained in them. Example of such lines are
"Number of Parameters", 211
"Last Session Time","Nov 14, 2001"
5The exception is the header section which begins with " File Header" and end with "End of File
Header".
32
Data Presentation Format Declaration
After the meta-data lines, how the data will be presented in the section is declared. There are
basically two kinds of presentation for data.
1.
All lines of data will be presented in "Name","Value","Units". For example, the Parameters
section has the following format for its data:
"VF Detection Enable","On"
"VF Detection Interval",320,"ms"
Depending on the particular piece of data, it is possible that there is no unit specification for the
line as in the case of "VF Detection Enable".
2. There are several possible formats, each declared on a separate line. Fields for the data will be
determined by the first element of the data line. For example, the Patient Alert Log section has
the following lines to declare their data format6.
[1] "Low Battery Voltage" ,"Date/Time", "Measured(V) ", "Tolerance(V) "
[21 "V. Pacing lead impedance", "Date/Time", "Impedance (ohms)
",
"Tolerance
Minimum(ohms) ", "Tolerance Maximum(ohms) "
[3] "Defibrillation lead impedance", "Date/Time", "Impedance (ohms)",
"Tolerance Minimum(ohms) ", "Tolerance Maximum(ohms) "
[4] "Charge time", "Date/Time", "Charge Time (sec) ", "Tolerance (sec)"
[51 "ICD Electrical Reset occurred", "Date/Time"
[6]"All therapies exhausted for Episode", "Date/Time", "Therapy
Type", "Episode Number"
[7] "Shocks delivered for Episode", "Date/Time", "Number of
Shocks", "Episode Number", "Tolerance (shocks)"
[8] "Invalid data received for event", "Date/Time"
6
Line numbers are labeled in square brackets and not part of the raw data.
33
Data from this section can take any of the 8 formats declared above. To determine which field the
data would correspond to, we need to look for the first element of the line. The following data line will
correspond to format 5:
"ICD Electrical Reset occurred","Jan 25,
2002 03:01:20"
Data Content Lines
The real data for the sections is displayed after the data format declaration lines and a blank line.
Thus the real data can be found by finding the Section beginning and counting one blank line after that.
At the end of the data content lines, the section ending line is presented to signal the end of this section.
Overview file
3.2.3
The overview file is the output of the clinic PC and is named ICD-id-info.txt for all of the ICD files. It
is used to identify the patient. The format of the overview file stays the same regardless of which
manufacturer the data comes from, and includes five pieces of information:
1. Patient ID Alias: will be used to identify patient since the patient name has been removed
2. Device Manufacturer: Guidant, Medtronic, or other manufacturers
3. Device Model: manufacturer-specific model numbers
4. Device SN Alias: will be used to identify the ICD since the serial number can be exploited to
identify the patient
5.
3.2.4
Disk Data Format: was used to help facilitate EGM conversion process
EGM files
EGM files will be later used to display EGMs on the web. They are generated by the EGM conversion
utility written in C from the overview and de-identified data files. They are grouped systematically
according to episode numbers for each download session and for each patient and device. Every file in
34
the group will contribute a component to the final EGM output on the web. For example, the .ann file
contains annotation data while the .dat file contains the actual waveform data.
Every download session will generate a group of Current EGM files, in addition to any group of
Tachycardia (Tachy) or SupraventricularTachycardia (SVT) EGM files that are identifiable by their entry
numbers. All the graphical sections have been singled out and processed by the EGM conversion utility.
Thus in obtaining graphical data to generate the middleware, I can skip these sections and simply grab
the names of these EGM files in the file system instead as my graphical data.
3.3 Interface design
Having a working Guidant prototype greatly facilitated the interface design for displaying Medtronic
data. However, adaptations were still necessary, since Medtronic data has a different presentation from
that of Guidant. Although the general linkage structure can be kept the same, the details may differ. Here
the design of the interface is described. Only when we keep the structure of the interface in mind, can we
design a useful and fitting database with the appropriate table relations.
3.3.1
Present site structure for Guidant data
The present lCD archive site is designed to display ICD data from Guidant devices. However, the
general site structure can be taken to display data from other manufacturers, with modifications on
individual pages. The site is organized by a search on the top page, followed by the result displaying
page, patient page, ICD page, then finally the detailed log or EGM pages.
The search page
The top page for the site is the search page. There is a button that will retrieve and display all of the
patients in the database. Otherwise, two types of searches are possible: search for patients, and search for
episodes. The search criteria for each of them are presented below, with screen shot shown in Figure 8 on
the next page.
35
The search for patient can be carried out via the following criteria:
1.
Patient ID: alias given during de-identification.
2.
Year of Birth: Before/On/After a certain year or Any.
3.
Gender: Male, Female, or Any.
4.
Implant Date: Before/On/After a certain year or Any.
5.
ICD Manufacturer: a choice of all ICD manufacturers contained in the database. In this case,
Guidant was the only choice.
6.
ICD Model: a choice of all ICD models contained in the database.
The search for episodes can be carried out via the choices outlined below, in addition to all of the
criteria found in the search for patients:
1.
Type of Episode: manufacturer-specific choices that will depend on the selection of ICD
manufacturer.
2.
Therapy Type: manufacturer-specific choices that will depend on the selection of ICD
manufacturer.
3.
Comment Search: Search for episodes marked by a certain comment. These comments are from a
fixed pool of pre-set comments that can be modified by authorized users. Multiple selections for
this criterion are allowed.
36
http:f/physio-arch.mit.educg-
Archive of EGM & Related Data from
Implanted Cardioverter Defibrillators (ICDs)
imthe d ttabpe
of all patiqntwmrr ai
View lftltt A
Search For Patients
Patient_ID:
Year of Birth:
After
1969
[After
2001
Gender:
Implant Date:
ICD Manufacturer:
ICD Model:
[1860%
Search For Episodes
Patient Search Parameters
Year of Birth:
[After
Gender:
Male
1969
Implant Date:
ICD Manufacturer:
ICD Model:
186
B
Episode Search Parameters
Type:
Therapy Type:
|Any
Any
testing testing
I Search Episodes
Figure 8. Current search page screen shot.
37
Other pages
After the search criteria are selected, users can click on the Search Patientsor Search Episodes buttons,
and the results will be displayed in their respective result pages. Following are descriptions of each of the
pages within the site.
Patient Search Result Page. All of the records that meet the criteria are displayed along with some
basic information on the patients such as their device count, gender, birth year, and implant year. Links
are provided to link to the Patient Page. These pieces of information were chosen to be displayed to help
identify subject of interest and refine further search if necessary.
Ardive
of the EGM & Related Data from Implanted (Pacemaker->efibrillator) Devices
List of Subjects Meedng Your Search Criteria:
Subjects whose Gender Is Male, Year of Birth Is After 1969, Year of
inplantation is After 2001, ICD Manufacturer is Guidant, ICD Model is
1860.
No.
1
2
PatientD
Device
Gender
Birth Year
Implant Year
002 000136
002 000417
1
2
Male
Male
1975
1976
2002
2002
Figure 9. Patient result page screen shot.
Episode Search Result Page. All of the records that meet the criteria are displayed along with some
basic information on the episode such as its type, number of attempts, therapy information, and the
existence of graphical data to be examined. Links are provided to link to the ICD page that contains this
episode information, the patient, and the particular episode page. These pieces of information were
chosen to be displayed to help identify subject of interest and refine further search if necessary, and the
indication of existence of graphical data will help researchers to decide in pursuing further to look at the
patient's details.
38
..
.....
.....
...
Archive ifth
I
tt&
GM
...
..
..
...
..
.
4
Iated Lint, front 1iplantedt (PncemrAkvr;1)etibrilhitor) IDevicec
List of
EDisodes Meetina Search Criterla
Figure 10. Episode search result screen shot.
Patient Page. The very first table shows the subject ID, birth year and gender of the patient. Then
each ICD this patient has carried is presented in a table by itself with certain basic information and link to
the ICD page.
EGMI
& Related
Data froi (GRdat
Pcenaker Defibrall,1t-
SabJect ID: 002_000417
Birth Year: 1976
Male
Gender:
13
A
Number of EpIsodes
l~brof Bak
Record: 002 * 11417 2: EGM & Related Data From ICD Device 2
Gidant
Device Mnufacter:
1860
Device Model:
002000045
Device Serial Number
1
Namber of Episodes:
2
NUmber of Baks:
Figure 11. Patient page screen shot.
ICD Page. Information about the device itself is displayed on this page. Specifically, on the left
hand side are the episode sections containing EGM data. On the right hand side are the bank sections
containing parameters and other information about the device at each time of download.
39
EGM
& Related Data from
Vacemaker/Defibrillator
Guoidaut
Record 0020004171
(EGM & Related Data from ICD device 1, subject 002 000417
Last Save Date: 2003-01-31
Summary of EGM
-
Summary of Device
Eisodes:
Banks:
Figure 12. ICD page screen shot.
Episode Page. The episode page displays information about one particular arrhythmia episode,
presented with each attempt to cure it (Figure 13). At the bottom of the episode page, researchers and
physician can make comments on the patient. EGMs are also accessible by clicking on the provided links.
When these links are clicked, the EGM is displayed in the window as in Figure 14.
EGM
For
& Related Data from Guidant Pacemaker-Defibrilator
Record: 002 000417 1
of subject 002 000417
Episode: 22
Overview
Attempt 1:
(Chckheto
(Chk
Onset
download
hee to downloo4
ECMA
pro-shock EG:A
post-shock EGM:
-
The Whole SGM:
Figure 13. Episode page screen shot.
40
Record: 002_000417_1
f
Download ahigh-resooeson PostScript version of this chart
erd. oooj417 t.P22A.ons
Figure 14. EGM page screen shot.
Bank Page. All of the textual information for Guidant are contained in what is called a bank. These data
can be displayed as field-value pairs in tabular format.
EGM
&
Relaled
Data
fromx Guidant
Phssak
r'Dsfibrsflaror
For Recard: 002 000350 1 of subject 002 000350
Bank: 003927E1
Bank Parameters:
ihklsereto
I
download)
IN
Figure 15. Bank page screen shot.
3.3.2
Modifications for Medtronic data
Although the present site structure can be applied, there are necessary modifications to be made for
the individual pages to fittingly display ICD data coming from Medtronic devices. These modifications
are introduced and discussed below.
41
The search page
While much of the information for the various search criteria can be found for Medtronic data, some
are missing or have to be modified. Obviously, the device model numbers would constitute an entirely
different set, and the choices for episode and therapy types are also different. Thus for these criteria, the
choices would be labeled as being either Medtronic or Guidant, as shown in Figure 16.
In addition, gender information is missing for Medtronic data, thus the gender criterion is essentially
obsolete in attempting to select patients of a particular gender when Medtronic ICDs are all that the
patients have worn. A scheme has to be designed to obtain gender information from hospital records, and
perhaps include it as part of the ICD-id-info.txt file to be sent along with the de-identified data files.
However, this has not been implemented so there cannot be gender search for Medtronic patients. A note
will appear on the search result page as a reminder that there is no gender information available for
Medtronic data, and that results are obtained from a gender-unspecific search.
Search For Patients
M90,
Patient_ID:
Before J 11953
Year of Birth:
ii
Male
Gender:
NoteThae is no goean Vpacfloti onfo Meduoo daO
Implant Date:
ICD Manufacturer:
[Alter
12002
Any
M
ICD Model:
7274 (Medtronic)
Search
d
Patients
Search For Episodes
PatientSearch Parameters
Year of Birth:
Isetre g j1953
j
Gender:
IMa]e
Implant Date:
ICD Manufacturer:
PAny
ICD
17274 (Medtronic) 2.
After
Model:
N 12002
M-
,
Episode Search Parameters
Type:
I VF (Medtronic)
Therapy Type:
IDefib (Medtronic)
y
TsiNoeAn
Attached Notes:
@
i
A
Testing Note 3
SeaWch EpisodqM
Figure 16. Medtronic and Guidant integrated search.
42
ICD Page
Header information is displayed on this page. Then based on the existence of certain sections, the
EGM data sections - Tachycardia and SVT/NST Log Entries sections and the Current Entry EGMs - are
displayed on the left hand side, and the text sections are displayed on the right hand side. For the
Tachycardia and SVT/NST episodes, the number of records with EGMs and the total number of records
are displayed. For the current EGMs prior to the ICD interrogation sessions, they are listed by time of
interrogation. Links are provided to access the individual sections. For the text sections, there are
individual links to access the non-log based section content. For the log-based sections, there is only one
link.
EGM & Related Data from Medtronic Pacemaker/Defibrillator
Record: 001 000038_1
(EGM & Related Data from ICD device 1, subject: 001 00003)
Back to Search Page
Figure 17. Medtronic ICD page screen shot.
43
Tachycardia and SVT/NST Episode Overview Page
Episodes in the Tachycardia Log Entries and SVT/NST Log Entries sections are displayed on a
similar page. Some fields have been selected and displayed to give the researchers an overview of the
detailed content on each individual episode, and the existence of EGMs is indicated. Links are provided
to see each episode in its entirety along with the EGMs. An example of the Tachycardia Log Entries page
is shown in Figure 18. For an SVT/NST page, the section title of Tachycardia Log Entries would change
to SVT/NST Log Entries, and the selection of the fields for overview is different. However, existence of
EGMs is still indicated and links to view full details are also provided.
r
i bri l ato
onr/D efTakhe
i
:
ec t 001 000038
For Record: 001 000038 1 of subject:
t fr o
D
d
e l
EGI &
Section: Tachycardia
Log Entries
Brief Overview:
.
'
_4 L3 c g
,
1
Document: Done
Figure 18. Tachycardia Log Entry page screen shot.
44
1
Full Detail and Comment Page
The page is organized into two halves that display all the available information on a particular
Tachycardia or SVT/NST episode. It is shown in Figure 19. There is a table of fields and values from the
episode of interest on the left. Some information in this table has been displayed in the previous overview
page. On the right there is a table with links to view EGMs and interval plots or download files
containing numerical values for the graphs. The EGMs can be viewed with or without annotations just as
the Guidant EGM in Figure 14. The RR and PP plots are available depending on if the ICD had recorded
such data, and the RP and PR plots are available only when the ICD is a dual-chamber device. It may also
be possible to view interval data prior to the episode if the ICD recorded such data. When graphical data
is not available for this particular episode, no links will be shown and a note will appear indicating that
graphical data is indeed unavailable.
Below the EGM table are forms for attaching comments to this episode. A table will display any
fixed comments that have already been associated, and any authorized user will be able to add or remove
more fixed comments from the table. The choices for these fixed comments have been predefined. To
attach free comments to the episode, the free text note editor is to be utilized. The free text will then
appear above the free note editor text area.
45
Figure 19. Full detail and comment page screen shot.
46
Current Entry at Time of Interrogation Page
The current entry page shows a table with links to view and download EGM data. The same
comment functionalities available to the Tachycardia and SVT/NST episode detail page are also provided
here. Thus the current entry page looks precisely like the EGM and comment portion of the full detail and
comment page shown in Figure 19.
Beat Interval Plot Page
The beat interval plots of R-R, P-R, P-P, and R-P intervals can be viewed over the web when the
provided links are clicked from the Tachycardia and SVT/NST full detail page or the current episode
page. A screen shot of this plot page is shown in Figure 20.
Record: 001_000038_7274_001_0000 o1/Tachy3_V
Download ahigh-resolution Postscript version of this chart
Recoad: 0010000387274_ 10
00JO1/Tachy3V
1500,
1000A4
5-
0
L,
20000
10000
Time (ms)
4% r
De4
CUt4
Done P,71
Figure 20. Beat interval plot page screen shot.
47
3000
rzffiiam-
61433WWVQ -
-
;t--
-
-
Text Section Page
These text sections include Parameters, Counters & Status, Patient Alert Log, Mode Switch Log,
Daily Log, Weekly Log and other sections that can be displayed simply in tabular format. Upon clicking
on the links given on the ICD page, a new page will open up that shows a table with data contained in
these sections.
There are two basic layouts for this page. For the non-log entries, only one single table is displayed.
This table includes all the data within the section (Figure 21).
i-:iu i tfjI
-'
111
t 1 t
r i rt
EGM & Related Data from Guidant PacemakerlDefibrillator
For Record: 001 000038 1 of subject: 001 000038
U
Section: Parameters
U
fri
4C'1MAn (nnfant-
Figure 21. Non-log ext section page screen shot.
For the sections that are log-based, a table will display data contained in the section header. The log
entries will be contained in a separate table under the same heading (Figure 22).
48
EGNI & Related D1at; from Guidant Pacemaker/Defibrillator
For Record: 001 000038 1 of subject: 001 000038
Section: Daily Log
Figure 22. Log-based text section page screen shot.
Other Designs and Considerations
I had some flexibility in deciding where the users of the system can make comments and attach these
comments to any patient or specific episodes. I decided to include the commenting functionality on the
page where EGMs and details of an episode are shown. The reason for having comments here is that
most of the comments will be episode specific, so instead of having all the comments at the patient page,
it is probably better to have them at the episode page. If in the future there are needs to have patientrelated comments, the commenting functionality can be implemented on the patient page.
3.4 Database design
In designing the database, the case of new models and new fields have to be considered. Then, the
table relations can be formed based on what is best for the existing data and possible future data.
3.4.1
Handling of new models and fields
Making this database system as automatic as possible will reduce the effort to maintain it and avoid
human errors, but a greater effort has to be put in to design and build the database in the first place. One
49
thing that I had to keep in mind in designing the database is that new models are constantly being
introduced. These new models may not have the same data structure as what has previously been seen.
The section ordering and numbering can be different, and the sections can even be named differently.
Existing models can also be modified and enhanced by the manufacturer, which presents the possibility
of new sections or fields for an existing model. If it is a section not before seen, I also need to come up
with a scheme to identify if this section has to be converted to waveforms or create a new table to store it
in the database.
With the possibility that new fields may be added to the database, I can build section-specifc tables in
which regardless of the models, all data from a particular section will go into a particular table. This
design comes as a natural alternative after rejecting the possibility of building model-specifc tables in
which all of the data from a certain model is stored in the same table. Model-specific tables may not work
too well because there would be too many pieces of ore, and there are size limitations on the tables. After
all, there should be a reason why the data were originally divided into sections, so why not take
advantage of that?
The section-specific table design also has the advantage that all possible fields from a certain section
will be included in the table already, so the probability of a foreign field that is not previously
encountered is minimized. However, there can be a chance that the same field name is used to mean
different things for different models, or the field name is changed from one version to another. Thus this
design may have future complications in presenting confusing or wrongly placed data to the researchers.
Thus to minimize the impact of new and foreign data, I decided to place the data in model- and-sectionspecific tables. This will ensure that changes in a table will involve only an individual section in a
particular model. There is the trade-off that more table modifications may have to be made, but with an
effective database modification routine, this problem can become no problem at all.
3.4.2
Table relations
Having the site designed and the decision for model and section specific tables made, the table
relations in the database can now be determined. The relation map for the different tables is shown in
50
Figure 23.
PATIENT
PatientID (PK)
0
SECTION
sectionlD (PK)
patientID
COMMENT
commentID (PK)
entryID
icdID
recorddate
ICD
icdID (PK)
patientID
SECTIONENTRY
sectionentryID (PK)
patientID
icdID
sectionlD
recorddate
X
ENTRY
entryID (PK)
patientID
icdID
senctionentryID
entry-type
recorddate
4-_
t
Figure 23. Relationships in the database.
The PATIENT and ICD tables are the main tables in the database. They serve as primary
identification for data and every other table will include their primary keys (PK) as foreign keys for easy
access and search in the future. The PATIENT table stores patient-related information from the overview
file and part of the data from the de-identified data file's patient information section if this section is
available. The ICD table stores ICD-related information from the overview file and the de-identified file's
header information for all the devices. With this design, the present patient search can be based solely on
these two tables to enhance query efficiency.
Next, the SECTION and SECTION ENTRY tables will store data from the other sections in the deidentified data file. These two tables are generated automatically by the table-generation utility program
and are named by their section and model number, with the SECTIONENTRY table having the string
"entry" appended to the name of the SECTION table. An example would be tachylog7227 and
51
tachylog7227entry.With the exception of foreign keys and date information, fields contained in these
tables are taken from the data files directly. Data in every section of the de-identified file will be held in a
SECTION table that is reserved exclusively for that particular section. Sections from different models also
have their own tables, so these SECTION tables are section and model specific. In addition to the
SECTION table, if a section is log-based, meaning that there are repeated sets of data matched to the same
set of fields, a SECTIONENTRY table will be associated with the SECTION table, and hold these log data.
Whether the section is EGM related or not does not influence the fact that they can still be stored in these
tables.
However, if a section does turn out to be an EGM-related section, it will be linked to the ENTRY table
designed to store EGM data. Since EGM files have been generated, a decision was made to simply store
the file names of these EGM files in the ENTRY table rather than their actual content. In displaying the
EGM information, search on this table will indicate the names and presence of these EGM files. For each
file in the group of EGM files, a field is created to hold the file name.
Finally, there is a comment table to store the comments made by authorized users. Every comment
will be linked to an entry in the SECTIONENTRY table to relate the comment to the specific entry.
52
Chapter 4
Implementation
In our efforts to bring the ICD data online, we built the archive system guided by the goals and
design outlined in Chapter 3. In this chapter, the implementation for the database and interface of the
archive's Medtronic component is detailed.
The data insertion process starts with a target directory containing all input data files. These data
will eventually be stored within the database or for the case of EGM data, stored in a permanent
repository directory systematically. This process is roughly shown in Figure 24.
Temporary Directory containing:
" De-identified File
" Overview File
" Directory of EGM Files
EGM File
Copying
Permanent Directory
Middeware
Table
Generation
Generation
Middleware File
Table File
Data Insertion &
Table Modification
for EGM Files
Table
Creation
Database
Figure 24. Insertion process of data.
4.1 Middleware generation
As the first step of the insertion process, a middleware is generated from the overview, de-identified,
and the EGM files. Specifically, the middleware generation utility program will take as input a source
directory containing all of these files, with the EGM files under another subdirectory within the source
53
directory. As output, a file named newmiddleware.txt will be generated inside the source directory, and
will be used for insertion during the data insertion step. This source directory, however, is only for
temporary storage. After the data in the directory is inserted into the database, the directory will be
cleaned upon the arrival of a new set of data.
The middleware file will have an xml-like format that encloses each section in tags and matches all
the values with their respective fields so that the database insertion process can be facilitated. This step is
essential especially for sections that declare all the data formats before presenting the actual data. The
middleware generation utility program is written in Perl, and takes a directory containing all the
overview, de-identified, and EGM files as input.
4.1.1
Algorithm
The middleware file is generated section-by-section from the input data files. Every section is
preceded and followed by tags. Between the first set of tags is patient information that will be used to
identify the patient. The second set of tags specifies device information that is taken from both the
overview file and the header section of the de-identified file. After the first two sets of tags are the section
tags. Between each set of tags, the data for each section is displayed with commas between every fieldvalue pair. However, in the case of log-based sections, there will be no data between the tags if there are
no recorded records.
Since there are different formats for different sections, the format of the section has to be identified in
order to decide the proper parsing of the particular section. Here, section names rather than section
numbers are used as indicators for how the sections should be handled. The format declaration lines are
also useful sources in identifying section format. Sections identified as graphical sections will not have
their content written in the middleware file. This is because their data have been converted into EGM files
already, so only the entry numbers and entry types are kept temporarily in two arrays - one for
tachycardia EGMs and one for SVT/NST EGMS - as they will be used to generate a graph list within the
middleware file later.
54
After all the sections are processed, the program searches the subdirectory containing all the EGM
files and obtains the EGM file names of the files under the subdirectory. Then according to the entry
numbers and types stored in the arrays, files related to the same entry are enclosed together in
corresponding entry tags. This graph list will be inserted into the graph table according to their entry
numbers. Furthermore, for every download session some "current" EGM data are generated. These EGM
data will also be stored and are identifiable by their date of download.
4.1.2
Notable specifics
Splitting Fields
All of the fields are separated by commas with either no space or two white spaces in between them,
and may or may not be enclosed in double quotation marks. When commas appear in double quotation
marks, they need to be ignored, as in the case for dates like "Apr 5, 1989". An algorithm has been devised
to successfully split the fields.
Fields with the Same Name Under the Same Section.
A field name can appear multiple times under the same section. For example, the field name
"Sensitivity" appeared 3 times in the Parameters section, each with the same value. However, they were
actually sensitivities associated with different modes of the ICD. Thus all field names encountered thus
far within the section have to be stored, and new field names have to be checked one by one against the
old ones. If a match is found, the new one has to be appended to a number in order to distinguish it from
the old one.
Repeated lines for model 7272
There was one unusual and yet systematic error that occurred for Model 7272. At the end of its
header for the de-identified data file, the two last lines are repeated. Model 7272 was the only model
55
where this problem was found, and it is suspected that a bug either from the device itself or the
translation utility was to blame. To handle this situation, an exception rule was written to ignore these
two repeated lines specifically for model 7272.
4.2 Table generation
To create tables in the database, a program was written to automatically generate table creation
commands in SQL and write them into a file. It processes the files section-by-section and identifies the
treatment for each section according to their section names and section declaration format. Thus the table
generation utility has generally the same codes as the middleware generation utility, but it does not skip
log-based sections with no records because its focus is on processing the fields rather than their values.
As input, the program takes the target directory containing all input data files. It then outputs a
newtables.table file in the same directory. This table file will be used during the data insertion step later
to create tables in the database.
In addition to this table file generated within the target directory, individual table files are also
created and placed under a permanent directory. These table files contain the field names of each field in
the table. These field names will be used later to check the presence of fields in the database and
facilitates any automatic modifications to the database. The reason for existence of these files is to reduce
the time in querying for field names in the database during the insertion stage, as missing fields will
result in insertion errors.
4.2.1
Algorithm
The table generation utility program is very similar to the middleware generation program. All of the
section and section entry tables are generated by this program. The fields for other tables are created by
the data insertion program to be introduced in the next section.
The utility program generates a main section table, as well as a section entry table if the section turns
out to be log based. As mentioned earlier in section 3.4.2, the main section tables will be named by section
56
name and model number. The section entry tables will be named with "entry" appended to the name of
their associated main section tables. The section entry tables are generated upon the detection of presence
for sections with a log entry format. Otherwise, one single main section table is generated for the section.
All of the tables are generated under one single file named newtables.table in the target directory.
As the table file is generated in the target directory, individual section table files are also generated
in the permanent directory. These section table files contain fields in each table, and every individual
table will have a table file associated with it. The section table files will be used late during insertion to
check the presence of a field. These files occupy minimal storage space, and will greatly facilitate the
speed of the checking process as query does not have to be run each time the check is performed.
4.2.2
Issues and sacrifices
Database Field Names Under 31 Characters
PostgreSQL databases place a limit on the length of field names to be under 31 characters. However,
many of the existing field names have lengths exceeding this number. Thus it was decided to truncate the
length of the field names. This is done on a per-word basis. Every word that appears in the field name
will be processed and truncated according to a list of words that appear in all of the field names. This
truncation scheme is better than simply cutting off after the 31" character of the field name string because
the first 31 characters can be identical for multiple fields.
Extracting Data Type Information.
Attempt was made to extract data type information from the values contained in the de-identified file
directly. However, this proved to be infeasible since data type determination is based on the very file that
the table generation program is run on, so any future values that do not conform to the assignment will
produce an error during the insertion process. For example, a field that has originally been identified as
being the data type DATE (because it is associated with a value of "Apr 5, 1989") may have a value of
57
"N/A" in a later download session. Since "N/A" is not of acceptable date format for the database, it will
get rejected and cannot be properly inserted into the database.
My solution is to just assign all the fields the data type TEXT. This comes as a last resort since it will
be less efficient to search through textual data than other formats. However, to implement a scheme
where the data type is checked and the field modified may take too long for all of the values to be
inserted. Thus sacrifice is made to assign all fields to the most general TEXT data type.
4.3 Data insertion
The data insertion step aims to insert data contained in the middleware file and creating tables or
modifying them as needed. Thus it is built upon the two previously mentioned middleware and table
generation utility programs.
The insertion program first starts by making a connection to the database and getting a list of tables
contained within it. Afterwards, the program calls the middleware generation utility to create a
middleware file. Following the middleware file, it checks the presence of the table to which data should
be inserted. If there is no such table, the table generation routine is called and the tables are generated
before the actual data insertion proceeds. If a table is present, it checks if the field to be inserted is present.
If not, it will modify the table to add the field. Finally, if both the table and the field are present, data is
inserted.
4.3.1
Insertion detail
The insertion is based on the data in the middleware file. Each section in the middleware file is to be
treated separately, and the preceding tag of the section indicates the table this section of data is to be
inserted into. The value for each field-value pair within the section will then be inserted under their field
in the table. The insertion program runs through the entire middleware file line by line, and makes
modifications to the database as needed. This process is roughly shown in Figure 25.
58
Middleware File
Section Data Handling
Check for patient
Check for table existence
No
No
Yes
Insert patient
record
Call table generation
utility & Create tables
Yes
Check for ICD
existence
Move EGM files to
permanent
repository
Check for field existence
No
,No
Insert ICD record
Insert EGM file
names to table
Alter table
Yes
to include field
Yes
Insert value into section table if no
previous record exists
Figure 25. Insertion details.
4.3.2
Database modification routine
Before each piece of data is inserted, checks are performed to ensure that the table and field this data
is to be placed into are present. The check for table presence is made at the beginning of insertion for each
section of data, and the check for field is performed for every item in the middleware file against the
section table file previously stored under the permanent directory when the table is first created.
Upon detecting the absence of a table, the table generation program will be called. The file containing
all SQL table-making commands for this data file will be generated, and the file will be used by the
insertion program to create tables in the database. Since all of the fields are generated based on the data
file itself, all of the data should have a place to be inserted into at the end of the table creation process.
This routine can cover the case of a new model and a new section for an existing model as the tables have
been designed to be model and section specific.
If the table is already present for a section of data, checks still need to be performed to ensure that
the fields these data should be inserted into are present. The checks are performed against the section
table files stored in the permanent directory. These section table files contain field names of their
59
associated section tables, so verifications made against them are essentially verifications made against the
database, but time can be saved as the database does not to be queried for a list of field names. Only
when the field to the value to be inserted is found in the section table file, will the data be allowed to be
inserted. Otherwise, the table is modified to include the field before the data have a place to go in the
database and is actually inserted.
When any of these scenarios arise, the changes to the database are logged into an error log in the
permanent directory. Although the process is allowed to proceed automatically, the data may not have
been handled correctly. Thus human intervention is needed to check the validity of how the situation is
handled.
4.3.3
Generation of non-section tables
For the other tables that are not generated by the table generation program, they are created when
data have to be inserted into them for the first time. This means that patient, ICD, entry, and comment
tables are all created by the insertion program. This design keeps the autonomous nature of the system,
so manual steps do not need to be taken to create these tables. Similarly, any values contained in the
sections to be inserted into these tables are checked before they are inserted. Thus any new data will have
a field to be placed under in the database.
4.4 Data retrieval and display
In retrieving the data, the CGI and PostgreSQL modules of Perl are used in creating the user interface
over the web. Searches are first performed according to the criteria set by the user, and based on these
criteria, data can be retrieved from the database via the use of SQL queries.
4.4.1
Guidant integration
To perform searches on the archive system, a scheme needs to be devised to include results from
both the Guidant and the Medtronic databases. This can be done on the search page according to which
60
manufacturer is selected. The database connection to the database of that particular manufacturer will be
made, and results will be displayed.
All of the choices for each criterion that is manufacturer-specific have been labeled according to their
respective manufacturer. For example, the choice of 7227 being a device model is shown as "7227
(Medtronic)", since Guidant has no such model number. It is important to note that certain choices are
manufacturer-specific, because a search based on a Medtronic model number will most likely yield no
results from the Guidant database as the numbers do not overlap. Similarly, the episode type and therapy
type do not overlap as well. Thus even if the manufacturer is not specified, certain choices may still limit
the result for search.
Searches without specific manufacturer and model number will display a table containing results
from both of the manufacturers. This table is sorted by manufacturer, and will contain all of the results
that meet the criteria for Medtronic, then all of the results for Guidant. This is because the searches have
to be carried out separately on the two databases, and results of one are displayed before the query
commences for the other database. To be able to sort the results by other means will require a sorting
functionality that can be implemented later.
4.4.2
Special considerations
Care has been taken to recover truncated field names from the database, and these fields can be
displayed in order on the web pages with the use of arrays instead of hashes.
61
Chapter 5
Conclusion
In our efforts to bring the ICD data online, we have implemented the Medtronic component as
detailed in Chapter 3 and 4. As a result, the following tasks have been achieved:
Automatic insertion of data into the database for all available models. As of August, 2003, the
system is able to process data for 8 Medtronic models and 31 patients who carry them. Proof of concept
was also done for the proper insertion of four additional models. The actual insertion is pending on the
step of generating their EGM files.
Automatic database modification routine for new fields and future models.
As long as file
format of data files does not change drastically, new fields and models can always be handled by the
automatic database modification routine. In case of drastic change in file format, the system administrator
will have to examine the new format and make necessary modifications to the insertion routine.
Interface level integration of Medtronic and Guidant data. Both Medtronic and Guidant data can
be searched and displayed on the same interface, despite residing on different databases. The users can
specify a manufacturer or be indifferent during their search. In case of a non-specific manufacturer
search, results from both the Medtronic and Guidant databases will be displayed.
Search for patients and search for episodes for Medtronic data. Search for patients and for
episodes can be carried out for all Medtronic data in the system through the specified set of criteria. Upon
user request, any data presented on the web pages can furthermore be incorporated into the search, since
all of the data are stored separately under their perspective fields.
62
Online EGM and interval displays of Medtronic data. The EGMs, R-R intervals, P-R intervals, P-P
intervals, and R-P intervals are all viewable on the user interface. Previously the only means to see these
graphs was to obtain paper copies from the programmers. The data contained in the diskettes are purely
numerical and had to go through a painful conversion process.
Commenting functionalities on the Interface. Fixed comments and free comments can be attached
to any episodes with EGM data. Search on fixed comments has been implemented, and the possibility of
searching for free comments exists as well. Upon request, commenting functionality can also be added to
other pages on the user interface.
In addition, the goals outlined in Chapter 3 have been fulfilled in the following ways.
Data shall be automatically handled to the maximum extent . Most of the data will be
automatically handled even if they are from a yet unseen model or section.
Data shall be properly converted, parsed, and stored in the database.
All of the data can be
parsed and stored in the database.
Data shall be readily and easily searchable by the researchers. The interface has been
implemented and provides the same set of search criteria as what has been provided by Guidant data.
The only missing information is the patients' gender, which is not available from the data files
themselves. However, effort can be made to obtain them from the hospital.
Data shall be correctly retrieved and displayed on the web browsers. Tests have been run to
verify that the data displayed on the web pages are similar, if not identical, to the original data files. The
differences are only due to capitalization and results in no loss of information.
A mechanism should exist for data from yet unseen models to be handled appropriately. The
data insertion process is able to insert data from new models and fields. However, its autonomous nature
will require an administrator to check the results of the automatic insertion to ensure proper handling of
data.
A mechanism should exist for certain authorized researchers to attach comments to certain
specific pieces of data.
The comments can be made on the log entry pages and will be shown to any
future users of the system.
63
The system design should allow integration with existing system and future systems of similar
purpose and usage. The integration of Medtronic and Guidant databases proves that the system design
is feasible, although there room to implement more functionalities, such as sorting based on criteria other
than manufacturer.
With this system, physicians around the country or even the world can upload ICD data originally in
diskettes to the web-based archive. Researchers will then be able to access the large amount of data stored
in the automated and searchable archive. Data of interest can be obtained easily and more significant
analyses on ventricular arrhythmias and sudden cardiac deaths can be facilitated.
5.1 Future work
We have made noteworthy progress with the archive, but there are still improvements that can be
made to the system. The following additions would make a considerable improvement to the system.
Template sections
5.1.1
A possible extension of the design includes creating a template file of all the fields that are possible
under a particular section (so regardless of the model number) with its matching data type. This template
file will assist in identifying the data type of some new data in the case that its associated value is
missing. Rather than mapping the default data type to TEXT, it may be mapped to something else if in
other models the same field name has come up before. Also, the determination of graphical vs. text
sections can also be based on this template file if the format of a new section falls under the known format
of a section in another model.
5.1.2
Text file download
Another possible extension will allow the users of the system to download a text copy of the data
contained on each page so that data manipulation can be done more easily. Researchers may want to
have the original data available to process them themselves. There are two options in providing these text
64
files. They can be generated from the database, in which case no additional copies need to be stored.
There are also further complications with respect to when these files are generated and how long these
files are to be kept and if they should be kept on the server or on the client system. As the second option,
the text files can be zipped and archived copies of the original de-identified and overview files, but
additional memory is required to archive these files. The details for implementing this functionality thus
require more planning and considerations.
5.1.3
Sorting function
Sorting functions may be provided on the webpage to display the search results as the users please.
This can be done with an open connection to the database or locally by rearranging the content of the
page.
5.1.4
Statistical analysis tools
Statistics can be gathered on the data if the selections are implemented on the user interface. SQL
queries can be written to access and display information such as the number of patients, their mean and
standard deviation, and other aggregate data that fit a specific criteria.
5.2 Lesson learned
It is envisioned that data from ICDs manufactured by other companies will be included in the
archive system. From working on this project, I sincerely hope that there would be a standard of how
data should be named and what kind of information should be included in the ICD devices. If such
standard exists, the work I have done for the Medtronic data would be applicable to devices from the
other manufacturers.
65
Appendix
1.
Sample De-Identified File Content
"File Header",1.1
"Program Version" ,3.8
"Binary File ID" , "a:\samplefile.pdd"
Saved on", "07/23/02 11:17:45"
"Binary File
"Medtronic Model","7275"
"Serial Number", "XXXXXX"
"File Type", "Text"
"Number of Data Sections",11
"End of File Header",1.1
"Section" ,l, "Parameters",1.8
"Number of Parameters",241
"Name", "Value", "Units"
"VF Detection Enable", "On"
"VF Detection Interval",270, "ms"
"FVT Detection Enable","Off"
"FVT Detection Interval", " ","ms"
"VT Detection Enable","On"
"VT Detection Interval",330, "ms"
"VF Initial NID","12/16"
"VF Redetect NID", "9/12"
"VT Initial NID",12
"VT Redetect NID",8
"Atrial Sensitivity", 0.3,"mV"
"Ventricular Sensitivity" , 0.3,1"M"
"VT Stability", "Off", "ms"
"SVT Limit",290, "ms"
"AFib/AFlutter", "On"
"Other 1:1 SVTs", "Off"
"Sinus Tach". "On"
"VF Therapy 1 Status", "On"
"VF Therapy 1 Energy",20,"J"
"VF Therapy 1 Pathway","AX>B"
"VF Therapy 2 Status", "On"
"VF Therapy 2 Energy",30, "J"
"VF Therapy 2 Pathway", "AX>B"
"VF Therapy 3 Status", "On"
"VF Therapy 3 Energy",30, "J"
"VF Therapy 3 Pathway", "AX>B"
"VF Therapy 4 Status", "On"
"VF Therapy 4 Energy",30, "J"
"VF Therapy 4 Pathway", "B>AX"
"VF Therapy 5 Status", "On"
"VF Therapy 5 Energy",30, "J"
"VF Therapy 5 Pathway","AX>B"
"VF Therapy 6 Status", "On"
"VF Therapy 6 Energy", 30, "J"
"VF Therapy 6 Pathway", "B>AX"
"Reconfirm VF after Initial Charge", "Yes"
"FVT Therapy 1 Status",""
66
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"'FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
"FVT Therapy
Type", "None"
Smart Mode","'"
Initial # Pulses","'
R-Sl Interval","","%RR"
S1S2 (RAMP+) ", "", "RR"
S2SN(RAMP+) ", "", "%RR"
Interval Dec","","ms'"
# Sequences",""
Energy" , "","J
Pathway",'"'"
Status", "i"
Type", "None"
Smart Mode",""
# Pulses",'""
Initial
R-Sl Interval",''", "%RR"
S1S2 (RAMP+)", "" , "%RR"
S2SN(RAMP+) ", ","%RR "
Interval Dec","", "ms"
# Sequences",""
Energy", "","J"
Pathway",'"'"
Status",'"
Type", "None "
Smart Mode",""
Initial # Pulses",'"
R-Sl Interval ", "","%RR"
SlS2 (RAMP+) ", "", " %RR"
S2SN(RAMP+) ",
"",
" %RR"
Interval Dec","", "ms"
# Sequences"'"
Energy" , " " , "J"
Pathway",""
Status"', "i"
Type", "None"
Smart Mode","'"
Initial # Pulses",""
R-Sl Interval", "","%RR"
S1S2(RAMP+)",1"", "%RR"
S2SN(RAMP+) ", " ","%RR "
Interval Dec ", " " , "ms1"
# Sequences",""
Energy", "",'"J"
Pathway",'"'"
Status",'"'"
Type", "None"
Initial
# Pulses',""
R-Sl Interval", "","%RR"
S1S2 (RAMP+)", "" , "%RR"
S2SN(RAMP+)","1",
"%RR"
Interval Dec","","ms'"
# Sequences",""
Energy", "","J"
Pathway",'"'"
Status", "i"
Type", "None"
Initial
# Pulses","
R-Sl Interval", "", "%RR"
S1S2 (RAMP+) ", "" , "%RR"
S2SN(RAMP+) " ,"", "%RR"
Interval Dec", "" , "ms"
# Sequences",""
Energy", " ", "J"
Pathway",""
67
"Anti-tachy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
"VT Therapy
Pacing Minimum Interval",200, "ms"
1 Status", "On"
1 Type","Burst"
1 Smart Mode", "On"
1 Initial # Pulses",8
1 R-Sl Interval",84,"%RR"
1 S1S2 (RAMP+)","","%RR"
1 S2SN(RAMP+) ", "","%RR"
1 Interval Dec",10, "ms"
1 # Sequences",3
J"
1 Energy","" ,1"
1 Pathway", ""
2 Status", "On"
2 Type", "CV"
2 Smart Mode",""
2 Initial # Pulses","'"
2 R-Sl Interval","","%RR"
2 S1S2(RAMP+)","","%RR"
2 S2SN(RAMP+)"," ", "%RR"
2 Interval Dec ","" ,"ms"
2 # Sequences","'
2 Energy",20, "J"
2 Pathway", "AX>B"
3 Status", "On"
3 Type", "CV"
3 Smart Mode","'"
3 Initial # Pulses","'
3 R-Sl Interval","","%RR"
3 S1S2(RAMP+)","","%RR"
3 S2SN(RAMP+)","","%RR"
3 Interval Dec ","","ms"
3 # Sequences",""
3 Energy",30,"J"
3 Pathway", "AX>B"
4 Status", "On"
4 Type", "CV"
4 Smart Mode",""
4 Initial
# Pulses",""
4 R-Sl Interval",1"", "%RR"
4 SlS2 (RAMP+)","","%RR"
4 S2SN(RAMP+) ","","%RR"
4 Interval Dec ","" ,"ms"
4 # Sequences",""
4 Energy",30, "J"
4 Pathway","B>AX"
5 Status", "On"
5 Type", "CV"
5 Initial # Pulses",""
5 R-Sl Interval","","%RR"
5 S1S2(RAMP+)", "","%RR"
5 S2SN(RAMP+)", "","%RR"
5 Interval Dec ","" ,"ms"
5 # Sequences",""
5 Energy",30, "J"
5 Pathway", "AX>B"
6 Status", "On"
6 Type","CV"
6 Initial # Pulses","'
6 R-Sl Interval","","%RR"
6 S1S2(RAMP+)","","%RR"
6 S2SN(RAMP+)","" ,"%RR"
6 Interval Dec","","ms "
6 # Sequences",""
68
"VT Therapy 6 Energy",30, "J"
"VT Therapy 6 Pathway", "B>AX"
"Shared Anti-Tachy Pacing V. Pulse Width",1.6, "ms"
"Shared Anti-Tachy Pacing V. Amplitude",8, "V"
"Shared Anti-Tachy Pacing V. Pace Blanking",240, "ms"
"Progressive Episode Therapies", "Off"
"Mode", "DDD"
"Lower Rate",50, "ppm"
"Upper Tracking Rate",140, "ppm"
"Upper Sensor Rate","","ppm"
"Mode Switch", "Off"
"A. Detect Rate", "", "bpm"
"Rate Response",""
"Activity Threshold",""
"Activity Acceleration", " ","sec"
"Activity Deceleration", "","min"
"Single Chamber Hysteresis" , "", "bpm"
"Atrial Amplitude", 3, "V"
"Ventricular Amplitude", 3, "V"
"Atrial Pulse Width",0.4, "ms"
"Ventricular Pulse Width",0.4, "ms"
"Atrial Pace Blanking",240,"ms"
"Ventricular Pace Blanking",200, "ms"
"Paced AV",250, "ms"
"Sensed AV" ,210, "ms"
"Rate Adaptive AV", "Off"
"Rate Adaptive AV Start Rate", "", "bpm"
"Rate Adaptive AV Stop Rate", "", "bpm"
"Rate Adaptive AV Minimum Paced AV", "", "ims"
"Rate Adaptive AV Minimum Sensed AV", "", "ims"
"A. Refractory", "","ms"
"PVARP",310, "ms"
"PVAB",150, "ms"
"Non-Competitive Atrial Pacing", "On"
"V. Rate Stabilization","Off"
"V. Rate Stabilization Minimum Interval", ", "ms"
"V. Rate Stabilization Interval Increment","","ms"
"PMT Intervention", "Off"
"PVC Response", "On"
"V. Safety Pacing","On"
"Post Shock Pacing A. Amplitude",4, "V"
"Post Shock Pacing A. Pulse Width",l.6, "ms"
"Post Shock Pacing A. Pace Blanking",240, "ms"
"Post Shock Pacing V. Amplitude",6,"V"
"Post Shock Pacing V. Pulse Width",1.6,"ms"
"Post Shock Pacing V. Pace Blanking",200, "ms"
"Lead Impedance Out of Range Abort Urgency", "On-High"
"A. Pacing Lead Impedance Out of Range Enable", "On"
"A. Pacing Lead Impedance Threshold Low",200,"ohms"
"A. Pacing Lead Impedance Threshold High",2000, "ohms"
"V. Pacing Lead Impedance Out of Range Enable", "On"
"V. Pacing Lead Impedance Threshold Low",200,"ohms"
"V. Pacing Lead Impedance Threshold High",2000,"ohms"
"Defibrillation Lead Impedance Out of Range Enable","On"
"Defibrillation Lead Impedance Threshold Low",10, "ohms"
"Defibrillation Lead Impedance Threshold High",200, "ohms"
"Low Battery Voltage Enable-Urgency", "On-High"
"Low Battery Voltage Threshold" ,2.55, "V"
"Excessive Charge Time Enable-Urgency", "On-High"
"Excessive Charge Time Threshold",18, "sec"
"Number of Shocks Delivered in an Episode Enable-Urgency", "Off"
"Number of Shocks Delivered in an Episode Threshold",""
"All Therapies in a Zone Exhausted Enable-Urgency", "Off"
69
"Alert Time","10:00"
"Store EGM Before Tachycardia Starts", "No"
"Store EGM During Charging", "Yes"
"Device Date/Time","Jun 21, 2001 10:21"
"Premature Event Threshold",69,"%"
"Holter Telemetry", "Off", "hr"
"Store EGM2", "Yes"
"Store EGM1", "Yes"
"EGM2 Source","Vtip to Vring"
"EGM1 Source","Atip to Aring"
"EGM2 Range","+/- 8","mV"
"EGM1 Range", "+/- 8", "mV"
"Minimum Auto Cap Formation Interval", 6, "months"
"End of Section",l
"Section",2,"Counters and Status",1.8
"Number of Counters and Status Variables",223
"Name", "Value", "Units"
"Battery and Lead Measurement Last Interrogated Timestamp","Jun 21, 2001 10:21:15"
"Battery Voltage Timestamp", "Jun 21, 2001 10:20:47"
"Battery Voltage",3.11, "V'
"Last Charge Timestamp","Jun 20, 2001 14:31:15"
"Last Charge Start Energy",0.0,"J"
"Last Charge End Energy",20.0, "J"
"Last Charge Charge Time",3.40,"sec"
"Last Charge To Full Energy Timestamp","Jun 14, 2001 17:09:04"
"Last Charge To Full Energy Start Energy",0.0,"J"
"Last Charge To Full Energy End Energy",30.0,"J"
"Last Charge To Full Energy Charge Time",7.57,"sec"
"Last Capacitor Formation Timestamp","Jun 14, 2001 17:09:04"
"Last Capacitor Formation Start Energy",0.0, "J"
"Last Capacitor Formation End Energy",30.0, "J"
"Last Capacitor Formation Charge Time",7.57,"sec"
"Last High Voltage Therapy Timestamp","Jun 20, 2001 14:31:16"
"Last High Voltage Therapy Waveform","Biphasic"
"Last High Voltage Therapy Pathway", "AX>B"
"Last High Voltage Therapy Delivered Energy",19.7,"J"
"Last High Voltage Therapy Measured Impedance",56,"ohms"
"Lead Impedance Timestamp", "Jun 21, 2001 03:00:04"
"A. Pacing Lead Impedance" ,410, "ohms"
"V. Pacing Lead Impedance",481,"ohms"
"Defibrillation Lead Impedance",17, "ohms"
"Episodes Last Interrogated Timestamp","Jun 21, 2001 10:21:15"
"Episodes Last Cleared Timestamp","Jun 14, 2001 18:03:19"
"VF Since Last Cleared",0
"FVT Since Last Cleared",0
"VT Since Last Cleared",30
"AFib/AFlutter Since Last Cleared",5
"Sinus Tach Since Last Cleared",0
"Other 1:1 SVTs Since Last Cleared",0
"NST and Others Since Last Cleared",13
"Mode Switch Since Last Cleared",0
"AS-VS Since Last Cleared",84,"%"
"AS-VP Since Last Cleared",15,"%"
"AP-VS Since Last Cleared",1,"%"
"AP-VP Since Last Cleared",0,"%"
"Single PVCs Since Last Cleared",52638
"Runs of PVCs Since Last Cleared",7170
"V. Rate Stabilization Paces Since Last Cleared",0
"Runs of V. Rate Stab. Paces Since Last Cleared",0
"Last Session Timestamp","Jun 14, 2001 18:03:19"
"VF Since Last Session",0
70
"FVT Since Last Session",0
"VT Since Last Session",30
"AFib/AFlutter Since Last Session",5
"Sinus Tach Since Last Session",0
"Other 1:1 SVTs Since Last Session",0
"NST and Others Since Last Session",13
"Mode Switch Since Last Session",0
"AS-VS Since Last Session",84,"%"
"AS-VP Since Last Session",15,"%"
"AP-VS Since Last Session",l,"%"
"AP-VP Since Last Session",0,"%"
"Single PVCs Since Last Session",52638
"Runs of PVCs Since Last Session",7170
Paces Since Last Session",0
"V. Rate Stabilization
"Runs of V. Rate Stab. Paces Since Last Session", 0
"VF Device Lifetime Total",3
"FVT Device Lifetime Total",0
"VT Device Lifetime Total",30
"AFib/AFlutter Device Lifetime Total",5
"Sinus Tach Device Lifetime Total",0
"Other 1:1 SVTs Device Lifetime Total",0
"NST and Others Device Lifetime Total",16
"Mode Switch Device Lifetime Total",0
"AS-VS Device Lifetime Total",84,"%"
"AS-VP Device Lifetime Total" ,15,"%"
"AP-VS Device Lifetime Total",l,"%"
"AP-VP Device Lifetime Total",0,"%"
"Single PVCs Device Lifetime Total",52957
"Runs of PVCs Device Lifetime Total",7192
Paces Device Lifetime Total",0
"V. Rate Stabilization
"Runs of V. Rate Stab. Paces Device Lifetime Total",0
"VF Therapy 1 Delivered Since Last Session",0
"VF Therapy 1 Successful Since Last Session",0
"VF Therapy 1 Unsuccessful Since Last Session",0
"VF Therapy 1 Intervention Since Last Session",0
"VF Therapy 2 Delivered Since Last Session",0
"VF Therapy 2 Successful Since Last Session",0
"VF Therapy 2 Unsuccessful Since Last Session",0
"VF Therapy 2 Intervention Since Last Session",0
"VF Therapy 3 Delivered Since Last Session",0
"VF Therapy 3 Successful Since Last Session",0
"VF Therapy 3 Unsuccessful Since Last Session",0
"VF Therapy 3 Intervention Since Last Session",0
"VF Therapy 4 Delivered Since Last Session",0
"VF Therapy 4 Successful Since Last Session",0
"VF Therapy 4 Unsuccessful Since Last Session",0
"VF Therapy 4 Intervention Since Last Session",0
"VF Therapy 5 Delivered Since Last Session",0
"VF Therapy 5 Successful Since Last Session",0
"VF Therapy 5 Unsuccessful Since Last Session",0
"VF Therapy 5 Intervention Since Last Session",0
"VF Therapy 6 Delivered Since Last Session",0
"VF Therapy 6 Successful Since Last Session",0
"VF Therapy 6 Unsuccessful Since Last Session",0
"VF Therapy 6 Intervention Since Last Session",0
"FVT Therapy 1 Delivered Since Last Session",0
"FVT Therapy 1 Successful Since Last Session",0
"FVT Therapy 1 Unsuccessful Since Last Session",0
"FVT Therapy 1 Intervention Since Last Session",0
"FVT Therapy 2 Delivered Since Last Session",0
"FVT Therapy 2 Successful Since Last Session",0
"FVT Therapy 2 Unsuccessful Since Last Session",0
"FVT Therapy 2 Intervention Since Last Session",0
71
"FVT Therapy
Delivered Since Last Session",0
"FVT Therapy
Successful Since Last Session",0
Unsuccessful Since Last Session",0
"FVT Therapy
"FVT Therapy
Intervention Since Last Session",0
"FVT Therapy
Delivered Since Last Session",0
"FVT Therapy
Successful Since Last Session",0
"FVT Therapy
Unsuccessful Since Last Session",0
"FVT Therapy
Intervention Since Last Session",Q
"FVT Therapy
Delivered Since Last Session",0
"FVT Therapy
Successful Since Last Session",0
"FVT Therapy
Unsuccessful Since Last Session",0
"FVT Therapy
Intervention Since Last Session",0
"FVT Therapy f Delivered Since Last Session",0
Successful Since Last Session",0
"FVT Therapy
Unsuccessful Since Last Session",0
"FVT Therapy
Intervention Since Last Session",0
"FVT Therapy
"VT Therapy 1 Delivered Since Last Session",30
"VT Therapy 1 Successful Since Last Session",28
"VT Therapy 1 Unsuccessful Since Last Session",2
"VT Therapy 1 Intervention Since Last Session",0
"VT Therapy 2 Delivered Since Last Session",2
"VT Therapy 2 Successful Since Last Session",2
"VT Therapy 2 Unsuccessful Since Last Session",0
"VT Therapy 2 Intervention Since Last Session",O
"VT Therapy 3 Delivered Since Last Session",0
"VT Therapy 3 Successful Since Last Session",0
"VT Therapy 3 Unsuccessful Since Last Session",0
"VT Therapy 3 Intervention Since Last Session",0
"VT Therapy 4 Delivered Since Last Session",0
"VT Therapy 4 Successful Since Last Session",O
"VT Therapy 4 Unsuccessful Since Last Session",0
"VT Therapy 4 Intervention Since Last Session",0
"VT Therapy 5 Delivered Since Last Session",0
"VT Therapy 5 Successful Since Last Session",O
"VT Therapy 5 Unsuccessful Since Last Session",0
"VT Therapy 5 Intervention Since Last Session",0
"VT Therapy 6 Delivered Since Last Session",0
"VT Therapy 6 Successful Since Last Session",0
"VT Therapy 6 Unsuccessful Since Last Session",0
"VT Therapy 6 Intervention Since Last Session",0
"Total Number of Aborted Shocks Since Last Session",1
"VF Therapy 1 Delivered Since Last Cleared",0
"VF Therapy 1 Successful Since Last Cleared",0
"VF Therapy 1 Unsuccessful Since Last Cleared",0
"VF Therapy 1 Intervention Since Last Cleared",0
"VF Therapy 2 Delivered Since Last Cleared",0
"VF Therapy 2 Successful Since Last Cleared",0
"VF Therapy 2 Unsuccessful Since Last Cleared",0
"VF Therapy 2 Intervention Since Last Cleared",0
"VF Therapy 3 Delivered Since Last Cleared",0
"VF Therapy 3 Successful Since Last Cleared",0
"VF Therapy 3 Unsuccessful Since Last Cleared",0
"VF Therapy 3 Intervention Since Last Cleared",0
"VF Therapy 4 Delivered Since Last Cleared",0
"VF Therapy 4 Successful Since Last Cleared",0
"VF Therapy 4 Unsuccessful Since Last Cleared",0
"VF Therapy 4 Intervention Since Last Cleared",0
"VF Therapy 5 Delivered Since Last Cleared",0
"VF Therapy 5 Successful Since Last Cleared",0
"VF Therapy 5 Unsuccessful Since Last Cleared",0
"VF Therapy 5 Intervention Since Last Cleared",0
"VF Therapy 6 Delivered Since Last Cleared",0
"VF Therapy 6 Successful Since Last Cleared",0
72
"VF Therapy 6 Unsuccessful Since Last Cleared",0
"VF Therapy 6 Intervention Since Last Cleared",0
"FVT Therapy . Delivered Since Last Cleared",0
"FVT Therapy . Successful Since Last Cleared",0
"FVT Therapy . Unsuccessful Since Last Cleared",0
"FVT Therapy . Intervention Since Last Cleared",0
"FVT Therapy
Delivered Since Last Cleared",0
"FVT Therapy
Successful Since Last Cleared",0
"FVT Therapy
Unsuccessful Since Last Cleared",0
"FVT Therapy
Intervention Since Last Cleared",0
Delivered Since Last Cleared",0
"FVT Therapy
Successful Since Last Cleared",0
"FVT Therapy
Unsuccessful Since Last Cleared",0
"FVT Therapy
Intervention Since Last Cleared",0
"FVT Therapy
Delivered Since Last Cleared",0
"FVT Therapy
Successful Since Last Cleared",0
"FVT Therapy
Unsuccessful Since Last Cleared",0
"FVT Therapy
Intervention Since Last Cleared",0
"FVT Therapy
Delivered Since Last Cleared",0
"FVT Therapy
Successful Since Last Cleared",0
"FVT Therapy
Unsuccessful Since Last Cleared",0
"FVT Therapy
Intervention Since Last Cleared",0
"FVT Therapy
Delivered Since Last Cleared",0
"FVT Therapy
Successful Since Last Cleared",0
"FVT Therapy
"FVT Therapy
Unsuccessful Since Last Cleared",0
Intervention Since Last Cleared",0
"FVT Therapy
"VT Therapy 1 Delivered Since Last Cleared",30
"VT Therapy 1 Successful Since Last Cleared",28
"VT Therapy 1 Unsuccessful Since Last Cleared",2
"VT Therapy 1 Intervention Since Last Cleared",0
"VT Therapy 2 Delivered Since Last Cleared",2
"VT Therapy 2 Successful Since Last Cleared",2
"VT Therapy 2 Unsuccessful Since Last Cleared",0
"VT Therapy 2 Intervention Since Last Cleared",0
"VT Therapy 3 Delivered Since Last Cleared",0
"VT Therapy 3 Successful Since Last Cleared",0
"VT Therapy 3 Unsuccessful Since Last Cleared",0
"VT Therapy 3 Intervention Since Last Cleared",0
"VT Therapy 4 Delivered Since Last Cleared",0
"VT Therapy 4 Successful Since Last Cleared",0
"VT Therapy 4 Unsuccessful Since Last Cleared",0
"VT Therapy 4 Intervention Since Last Cleared",0
"VT Therapy 5 Delivered Since Last Cleared",0
"VT Therapy 5 Successful Since Last Cleared",0
"VT Therapy 5 Unsuccessful Since Last Cleared",0
"VT Therapy 5 Intervention Since Last Cleared",0
"VT Therapy 6 Delivered Since Last Cleared",0
"VT Therapy 6 Successful Since Last Cleared",0
"VT Therapy 6 Unsuccessful Since Last Cleared",0
"VT Therapy 6 Intervention Since Last Cleared",0
"Total Number of Aborted Shocks Since Last Cleared",1
"Short Interval Count",2
"Short Interval Count Time Stamp","Jun 20, 2001 02:15:09"
"End of Section",2
"Section",3,"Tachycardia Log Entries",1.9
"Number of Entries" ,30
"Date Last Cleared","Jun 14, 2001 18:03:19"
"Last Session Time",""
"Episode In Progress","No"
"Entry Number", "Time of Episode", "Type", "A. Median Cycle (ms) ", "V. Median
Cycle(ms)","V. Average Cycle(ms)","Last Therapy","Last Therapy Type","Last Therapy
Efficacy", "First
Therapy", "First
Therapy Type","First Therapy Last Scan", "Pre
73
Detection Duration (sec) ", "Post Detection Duration (sec) ", "VT/VF Duration", "SVT
Criterion Met", "Triggered Via Combined
Criterion(ms) " , "Stability
Duration", "Stability
Count","Interval Stability Low(ms)","Interval Stability High(ms)","VT Detection
Status", "TDI(ms) ", "VF Detection Status", "FDI(ms) ", "FVT Detection
Status", "FTI (ms) ", "Monotonic Aggression Status", "SVT Minimum Cycle
Length (ms) ", "Afib/Aflutter Criterion Status", "Sinus Tach Criterion Status","1:1 VT-ST
Boundary(%)", "Other 1:1 Criterion Status", "VTNID", "VTRNID" , "VFNID", "VFRNID", "A.
Sensitivity(mV) " , "V. Sensitivity(mV) ", "Rejection Rule Fired Most Frequent", "Rejection
Rule Fired Second Most Frequent", "Rejection Rule Fired Third Most Frequent", "Mode
Switch Prior to Detection","Mode Switch During Therapy","Therapies Aborted Charge Time
Out", "Therapies Aborted Rate Limit", "Therapies Aborted User", "Therapies Skipped Rate
Limit", "CV Therapies Aborted Sync Fail", "Defib Therapies Aborted Sync
Fail" , "EGM/Episode Record Data"
33, "Jun 20, 2001 22:26:50 ","VT", 290, 290,290, "VT Rx 1", "Burst ", "Yes ", "VT Rx
not
1", "Burst", 1, 0,2, "5 sec ", "NA", "Off", "Stability
Met", "No",0,10, "On", 330, "On" ,270, "Off",270, "Disabled",290, "On", "On", 50, "Off",12,8,1"12/
16", "9/12",0.30,0.30, "NA", "NA", "NA", "No", "No", "None" , "None", "None", "None", 0,0, "Yes"
32,"Jun 20, 2001 14:30:53","VT (+SVT)",150,310,300,"VT Rx 2", "CV", "Yes", "VT Rx
not
1", "Burst", 3,6,24, "24 sec","6 sec", "Off ","Stability
Met", "No" 10,10, "On", 330, "On", 270, "Off", 270, "Disabled", 290, "On", "On", 50, "Off", 12,8, "12
/16"1, "f9/12", 0. 30 ,0. 30 , "AFib/AFlutter" , "INA", "INA" , "No" , "No" , "None ", "None" , "None" , "None" ,
0,0, "Yes"
31,"Jun 20, 2001 14:30:37","VT (+SVT)",150,310,310,"VT Rx 1", "Burst", "Yes", "VT Rx
not
1", "Burst",1, 8, 5, "5 sec', "8 sec", "Off", "Stability
Met", "No",0,10, "On",330, "On",270, "Off",270, "Disabled",290, "On", "On",50, "Off",12,8,1"12/
16", "9/12", 0.30,0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None", 0
,0, "Yes"
30,"Jun 20, 2001 14:29:10","VT (+SVT)",170,310,300,"VT Rx 1", "Burst", "Yes", "VT Rx
not
1", "Burst", 1, 15,3,"3 sec","15 sec", "Off", "Stability
Met", "No", 0,10, "On", 330, "On",270, "Off ",270, "Disabled", 290, "On", "On", 50, "Off", 12,8, "12/
16 ", "9/12", 0. 30, 0. 30, "AFib/AFlutter", "NA", "NA" , "No", "No", "None", "None", "None", "None", 0
,0, "Yes"
29,"Jun 20, 2001 14:28:03","VT (+SVT)",130,310,300,"VT Rx 1", "Burst", "Yes", "VT Rx
not
1", "Burst", 1,4,2,"2 sec ","4 sec", "Off", "Stability
Met", "No",10,10, "On", 330, "On",270,"Off",270, "Disabled", 290, "On", "On", 50, "Off", 12,8, "12
/16", "9/12",0.30, 0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None",
0,0, "Yes"
28, "Jun 20, 2001 14:27:49", "VT (+SVT) ", 160, 300, 300, "VT Rx I", "Burst", "Yes", "VT Rx
not
1", "Burst", 1,4,3,"3 sec", "4 sec", "Off", "Stability
Met", "No", 0, 10, "On", 330, "On", 270, "Off", 270, "Disabled", 290, "On", "On", 50, "Off", 12,8, "12/
16", "9/12",0.30,0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None", 0
,0, "Yes"
27,"Jun 20, 2001 14:27:26", "VT (+SVT)",160,300,300,"VT Rx 1", "Burst", "Yes", "VT Rx
not
1", "Burst", 1, 5,6, "6 sec","5 sec", "Off", "Stability
Met", "No",10, 20, "On", 330, "On", 270, "Off ",270, "Disabled", 290, "On", "On", 50, "Off", 12,8, "12
/16", "9/12",0.30, 0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None",
0,0,"Yes"
26,"Jun 20, 2001 14:27:00","VT (+SVT)",160,310,300,"VT Rx 1", "Burst", "Yes", "VT Rx
not
1", "Burst", 1, 6,3, "3 sec", "6 sec", "Off", "Stability
Met", "No", 0,10, "On", 330, "On",270, "Off", 270, "Disabled", 290, "On", "On", 50, "Off", 12,8, "12/
16", "9/12-",0.30,0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None", 0
,0, "Yes"
25,"Jun 20, 2001 14:22:15","VT (+SVT)",150,310,310,"VT Rx 1", "Burst", "Yes", "VT Rx
1", "Burst", 1,4,3,"3 sec","4 sec", "Off", "Stability
not
Met", "No",10,10, "On", 330, "On", 270, "Of f " , 270, "Disabled", 290, "On", "On", 50, "Of f ",12, 8,1"12
/16 ",1"9/12 ", 0.30, 0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None",
0,0,"Yes"
24,"Jun 20, 2001 14:20:23","VT (+SVT)",120,320,320,"VT Rx 1", "Burst", "Yes", "VT Rx
not
1", "Burst", 1, 15,3, "3 sec", "15 sec", "Off", "Stability
Met" , "No", , 10 , "On" , 330 , "On" , 2?0 , "Of f" , 2?0, "Disabled" , 290 , "On" , "On" , 50, "Of f" , 12 , 8, "12/
16", "9/12", 0.30,0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None", 0
,0, "Yes"
74
23,"Jun 20, 2001 14:19:54","VT (+SVT)",150,310,310,"VT Rx 1","Burst","Yes","VT Rx
1", "Burst",1,5,2, "2 sec", "5 sec", "Off", "Stability not
Met" , "No",10,10, "On",330, "On",270, "Off",270,"Disabled",290, "On","On",50,"Off",12,8,"12
/16" , "9/12",0.30,0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None" , "None",
0,0, "Yes"
22,"Jun 20, 2001 14:19:23","VT (+SVT)",140,310,310,"VT Rx 1","Burst","Yes","VT Rx
1","Burst",1,5,3,"3 sec","5 sec","Off","Stability not
Met", "No",0,0, "On",330, "On",270, "Off",270,"Disabled",290,"On", "On",50, "Off",12,8, "12/1
6", "9/12",0.30,0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None",0,
0, "Yes "
21,"Jun 20, 2001 14:17:43","VT (+SVT)",170,300,300,"VT Rx 1","Burst","Yes","VT Rx
1","Burst",1,7,2, "2 sec", "7 sec","Off","Stability not
Met", "No",0,10, "On",330, "On",270,"Off",270, "Disabled",290,"On","On",50, "Off",12,8, "12/
16", "9/12",0.30,0.30, "AFib/AFlutter","NA","NA","No","No","None", "None", "None", "None",0
,0, "Yes"
20,"Jun 20, 2001 14:14:27","VT (+SVT)",160,300,300,"VT Rx 1","Burst","Yes","VT Rx
1","Burst",1,4,2,"2 sec","4 sec","Off","Stability not
Met","No",0,10,"On",330,"On",270,"Off",270,"Disabled",290,"On","On",50,"Off",12,8,"12/
16", "9/12",0.30,0.30, "AFib/AFlutter", "NA","NA", "No", "No", "None", "None", "None", "None",0
,0,"Yes"
19, "Jun 20, 2001 14:06:24","VT (+SVT)",190,310,300,"VT Rx 1","Burst","Yes","VT Rx
1","Burst",1,4,3,"3 sec","4 sec","Off","Stability not
Met", "No",10,20,"On",330,"On",270,"Off",270,"Disabled",290,"On","On",50,"Off",12,8,"12
/16", "9/12",0.30,0.30,"AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None",
0,0, "Yes"
18,"Jun 20, 2001 14:06:07", "VT (+SVT)",190,310,310,"VT Rx 1", "Burst","Yes","VT Rx
1","Burst",1,4,3,"3 sec","4 sec","Off","Stability not
Met","No",10,20,"On",330,"On",270,"Off",270,"Disabled",290,"On","On",50,"Off",12,8,"12
/16", "9/12",0.30,0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None",
0,0, "Yes"
17,"Jun 20, 2001 11:45:04","VT (+SVT)",170,310,310,"VT Rx 1","Burst","Yes","VT Rx
1","Burst",1,5,3,"3 sec","5 sec","Off","Stability not
Met", "No",0,10,"On",330, "On",270, "Off" ,270, "Disabled", 290,"On","On",50,"Off",12,8,"12/
16", "9/12",0.30,0.30, "AFib/AFlutter","NA","NA","No", "No","None","None","None", "None",0
,0,"Yes"
16,"Jun 20, 2001 11:42:37","VT (+SVT)",170,300,300,"VT Rx 1","Burst","Yes","VT Rx
1", "Burst",3,5,19,"19 sec", "5 sec","Off","Stability not
Met", "No",0,10,"On" ,330,"On",270,"Off",270, "Disabled",290,"On","On",50,"Off",12,8,"12/
16", "9/12",0.30,0.30,"AFib/AFlutter","NA","NA", "No","No", "None", "None", "None", "None",0
,0, "Yes"
15,"Jun 20, 2001 11:42:09","VT (+SVT)",160,310,310,"VT Rx 1", "Burst", "Yes","VT Rx
1","Burst",1,5,3,"3 sec","5 sec","Off","Stability not
Met","No",10,10, "On",330, "On",270,"Off",270,"Disabled",290, "On","On",50,"Off",12,8,"12
/16", "9/12",0.30,0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None",
0,0,"Yes"
14, "Jun 20, 2001 11:36:19", "VT",150,280,270,"VT Rx 1","Burst", "Yes", "VT Rx
1","Burst",3,4,41, "41 sec", "4 sec", "Off", "Stability
not
Met","No",10,10,"On",330,"On",270,"Off",270,"Disabled",290,"On","On",50,"Off",12,8,"12
/16", "9/12",0.30,0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None",
0,0,"Yes"
13,"Jun 20, 2001 11:36:02","VT (+SVT)",140,290,280,"VT Rx 1","Burst","Yes","VT Rx
1", "Burst",1,6,6, "6 sec", "6 sec", "Off", "Stability
not
Met","No",10,10,"On",330,"On",270,"Off",270,"Disabled",290,"On","On",50,"Off",12,8,"12
/16", "9/12",0.30,0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None",
0,0,"Yes"
12,"Jun 20, 2001 11:35:41","VT (+SVT)",170,300,300,"VT Rx 1", "Burst","Yes","VT Rx
1","Burst",1,4,3, "3 sec","4 sec","Off","Stability not
et","No",0,10, "On",330, "On",270,"Off",270,"Disabled",290,"On","On",50,"Off",12,8,"12/
16","9/12",0.30,0.30, "AFib/AFlutter", "NA","NA", "No", "No", "None","None", "None", "None",0
,0,"Yes"
11,"Jun 20, 2001 10:50:43","VT (+SVT)",180,310,310,"VT Rx 1","Burst","Yes","VT Rx
1","Burst",1,6,3,"3 sec","6 sec","Off","Stability not
Met","No",0,20, "On",330, "On",270,"Off",270,"Disabled",290,"On","On",50,"Off",12,8,"12/
75
16", "19/12"-,0.30, 0.30, "AFib/AFlutter", "INA", "INA", "No", "No", "None", "None", "None", "None", 0
, 0, "Yes"
10,"Jun 20, 2001 10:26:18","VT (+SVT)",160,310,310,"VT Rx 1","Burst","Yes","VT Rx
not
1", "Burst",1, 5, 3, "3 sec', "5 sec", "Off", "Stability
Met", "No",10,10, "On", 330, "On",270, "Of f ", 270, "Disabled", 290, "On", "On", 50, "Of f",12, 8, "12
/16", "9/12", 0.30, 0.30, "AFib/AFlutter", "INA", "INA", "No", "No", "None" "None", "None", "None"
0,0, "Yes"
9,"Jun 20, 2001 08:40:26", "VT",140,280,280,"VT Rx 1", "Burst", "Yes", "VT Rx
not
1", "Burst", 2, 6, 8, "8 sec", "6 sec", "Off", "Stability
Met", "No",10,10, "On",330, "On",270, "Off",270, "Disabled",290,"On", "On",50,"Off",12,8,1"12
/16", "9/12",0.30,0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None",
0,0,"Yes"
8,"Jun 20, 2001 08:40:08","VT (+SVT)",170,290,280,"VT Rx 1", "Burst", "Yes", "VT Rx
not
1", "Burst", 1, 7, 3, "3 sec", "7 sec", "Of f ", "Stability
Met", "No",10,10, "On", 330, "On", 270, "Of f ", 270, "Disabled", 290, "On", "On", 50, "Of f " ,12,8, "12
/16", "9/12", 0.30, 0.30, "AFib/AFlutter", "NA", "NA", "No", "No" , "None", "None", "None", "None",
0,0, "Yes"
7, "Jun 20, 2001 08:38:29", "VT (+SVT) ",160,300, 300, "VT Rx 1", "Burst", "Yes", "VT Rx
not
1", "Burst", 2, 4, 15, "15 sec", "4 sec", "Off", "Stability
Met", "No",10,10, "On", 330, "On", 270, "Of f ", 270, "Disabled", 290, "On", "On", 50, "Of f ",12, 8, "12
/16","9/12",0.30,0.30, "AFib/AFlutter","NA", "NA", "No", "No", "None", "None", "None", "None",
0,0,"Yes"
6,"Jun 20, 2001 08:32:33","VT (+SVT)",160,310,310,"VT Rx 1", "Burst", "Yes", "VT Rx
not
1", "Burst", 1,6, 8,"8 sec","6 sec", "Off", "Stability
Met", "No",10,10, "On",330, "On",270, "Off",270, "Disabled",290, "On", "On",50, "Off",12,8, "12
/16", "9/121", 0.30, 0.30, "AFib/AFlutter", "NA", "NA", "No" , "No", "None", "None", "None", "None",
0,0, "Yes"
5,"Jun 20, 2001 02:14:35","VT (+SVT)",150,290,290,"VT Rx 2", "CV", "Yes", "VT Rx
not
1", "Burst", 3,3, 51, "51 sec", "3 sec", "Off", "Stability
Met","No",0,10,"On",330,"On",270,"Off",270,"Disabled",290,"On","On",50,"Off",12,8, "12/
16", "9/12 ", 0.30, 0.30, "AFib/AFlutter", "NA", "NA", "No", "No", "None", "None", "None", "None", 1
,0,"Yes"
4, "Jun 19, 2001 02:01:17", "VT (+SVT) ",140,290,290, "VT Rx 1", "Burst", "Yes", "VT Rx
not
1", "Burst", 1,4,32, "32 sec", "4 sec", "Off", "Stability
Met", "No",0,10, "On",330, "On",270, "Off",270, "Disabled",290, "On", "On",50, "Off",12,8, "12/
16", " 9/12 ", 0.30, 0.30, "AFib/AFlutter", "NA", "NA", "No" , "No", "None", "None", "None", "None", 0
0,"Yes"
"End of Section",3
"Section",4, "SVT/NST Log Entries",1.6
"Number of Entries",18
"Date Last Cleared", "Jun 14, 2001 18:03:19"
"Last Session Time","'
"SVT/NST Entry", "ID# ", "Date/Time", "Class", "V. Average
Cycle (ms) ", "Duration (beats) ", "Duration (time) ", "Reason", "A. Median Cycle (ms) ", "V.
Median Cycle (ms) ","Stability Criterion Met","VT Stability(ms) ", "SVT Criteria Triggered
Most Frequent","SVT Criteria Triggered Second Most Frequent","SVT Criteria Triggered
Third Most Frequent", "Mode Switch During
Episode", "VT", "TDI (ms)", "VF", "FDI (ms) ", "FVT", "FTI (ms)","SVT
Limit(ms)","Afib/Aflutter","Sinus Tach","1:1 VT-ST Boundary(%)","Other 1:1 SVTs","VT
"VF NID Redetect", "A.
"VT NID Redetect", "VF NID Initial",
NID Initial",
Sensitivity(mV) ", "V. Sensitivity(mV) ", "EGM/Episode Record Data"
"SVT/NST Entry",21,"Jun 20, 2001 16:00:07","Class A NST",300,10,"2 sec","NonSustained" ,310,300, "Stability not
Met", ,"Off f", "INA" , "INA" , "INA" , "No" , "On" ,330 , "On" ,270 , "Off " ,270 ,290, ,"On" , "On" ,50 ,"Off ",,12, 8
,"12/16","9/12 ",0.30,0.30,"No"
"SVT/NST Entry", 20, "Jun 20, 2001 14:29:26", "Class A NST", 300,11, "2 sec", "NonSustained", 160, 300, "Stability not
Met", "Of f ", "AFib/AFlutter","NA", "NA",
"No", "On", 330, "On", 270, "Of f ", 270, 290, "On", "On", 50
, "Off ",12, 8, "12/16","9/12", 0.30, 030, "No"
"SVT/NST Entry",19,"Jun 20, 2001 14:29:22", "Class A NST",300,9,"2 sec","Nonnot
Sustained", 120,300, "Stability
76
Met", "Off", "AFib/AFlutter", "NA", "NA", "No","On",330, "On",270, "Off",270,290, "On",
,"Off ",12,8, "12/16","9/12",0.30,0.30, "No"
"SVT/NST Entry", 18, "Jun 20, 2001 14:28:12", "Class B NST",310,16, "4
sec", "AFib/AFlutter",140,310,"Stability not
Met", "Off", "AFib/AFlutter", "NA", "NA", "No","On",330, "On",270, "Off ",270,290, "On",
,"Off",12,8,"12/16","9/12",0.30,O.30,"Yes"
"SVT/NST Entry",17, "Jun 20, 2001 14:26:50", "Class A NST", 300, 8, "2 sec", "NonSustained",150,310, "Stability not
Met", "Off ", "AFib/AFlutter", "NA", "NA", "No", "On", 330, "On", 270, "Off", 270,290, "On",
, "Of f ",12, 8, "12/16","9/12",0.30, 0.30, "No"
"SVT/NST Entry",16, "Jun 20, 2001 14:26:03", "Class A NST", 310, 8, "2 sec", "NonSustained",140,310, "Stability not
Met", "Off ", "AFib/AFlutter", "NA", "NA", "No", "On", 330, "On", 270, "Off", 270,290, "On",
, "Of f ",12, 8, "12/16", "9/12", 0.30, 0.30, "No"
"SVT/NST Entry", 15, "Jun 20, 2001 14:22:55", "Class B NST", 310, 12, "2
sec", "AFib/AFlutter",130,310,"Stability not
Met", "Off", "AFib/AFlutter", "NA", "NA", "No", "On", 330, "On", 270, "Off ", 270, 290, "On",
, "Of f ",12, 8, "12/16", "9/12", 0.30, 0.30, "Yes"
"SVT/NST Entry", 14, "Jun 20, 2001 14:13:44", "Class A NST", 300, 5, "l sec", "NonSustained",160,360, "Stability not
Met" , "off"1,"'NA",,"NA" , "INA" , "No" , "On" , 330,,"On", ,270, ,"Of f"1,270 ,290, ,"On", ,"On" , 50,,"Of
,"12/16","9/12",0.30,0.30,"No"
"SVT/NST Entry",13, "Jun 20, 2001 14:07:55", "Class A NST", 310,7, "l sec", "NonSustained", 180, 320, "Stability not
Met", "Off ", "AFib/AFlutter", "NA", "NA", "No", "On", 330, "On", 270, "Off ", 270,290, "On",
, "Off ",12, 8, "12/16", "9/12", 0.30, 0.30, "No"
"SVT/NST Entry",12, "Jun 20, 2001 14:06:37", "Class A NST", 300, 9, "2 sec", "NonSustained", 190, 310, "Stability not
Met", "Off ", "AFib/AFlutter", "NA", "NA", "No", "On", 330, "On", 270, "Off", 270,290, "On",
, "Of f ",12, 8, "12/16", "9/12", 0.30, 0.30, "No"
"SVT/NST Entry",11, "Jun 20, 2001 11:54:09", "Class B NST", 300,29, "15
sec", "AFib/AFlutter", 170, 300, "Stability
not
Met", "Off ", "AFib/AFlutter", "NA", "NA", "No", "On", 330, "On", 270, "Off", 270,290, "On",
,"Off",12,8, "12/16",1"9/12",0.30,0.30, "Yes"
"SVT/NST Entry", 10, "Jun 20, 2001 11:43:08", "Class B NST", 290, 15, "7
sec", "AFib/AFlutter", 160,290, "Stability
not
Met", "Off ", "AFib/AFlutter", "NA", "NA", "No", "On", 330, "On", 270, "Off", 270,290, "On",
, "Off",12,8,"12/16","9/12",0.30,0.30, "Yes"
"SVT/NST Entry",9, "Jun 20, 2001 09:20:06","Class A NST",300,5,"<1 sec", "NonSustained",130,310, "Stability not
Met", "Off ", "AFib/AFlutter", "NA", "NA", "No", "On", 330, "On", 270, "Off ", 270,290, "On",
"On",50
"On",50
"On",
50
"On", 50
"On", 50
f"1,12 , 8
"On", 50
"On", 50
"On", 50
"On", 50
"On", 50
,"Off" ,12,8,"12/16","9/12" ,0.30,0.30,"No"
"SVT/NST Entry",8, "Jun 20, 2001 09:18:23","Class A NST",290,7,"1 sec","NonSustained", 160,300, "Stability not
Met", "Off ", "AFib/AFlutter", "NA", "NA", "No", "On", 330, "On", 270, "Off ", 270,290, "On",
"On", 50
,"Of f",12,8,"12/16" ,"9/12" ,0.30,0.30,"No"
"SVT/NST Entry",7,"Jun 20, 2001 08:40:52","Class A NST",300,6,"1 sec","NonSustained",170,330, "Stability not
Met", "Of f", "NA", "NA", "NA", "No", "On",330, "On",270, "Of f",270,290, "On", "On",50, "Of f",12, 8
,"12/16", "9/12",0.30,0.30,"No"
"SVT/NST Entry",6, "Jun 20, 2001 08:38:54","Class B NST",300,29, "8
sec", "AFib/AFlutter",160, 300, "Stability
not
Met", "Off ", "AFib/AFlutter", "NA", "NA", "No", "On", 330, "On", 270, "Off ", 270,290, "On", "On", 50
, "Of f ",12, 8, "12/16", "9/12",0.30, 0.30, "Yes"
"SVT/NST Entry",5,"Jun 20, 2001 05:46:47","Class A NST",300,5,"<l sec","NonSustained", 160, 380, "Stability not
Met", ,"Of f"1,"'NA", ,"NA", ,"NA", ,"No", ,"On", ,330, "On", ,2?0, "Of f"1,2?0,290, "On", ,"On", ,50, "Off" ,12, 8
,"12/16",1"9/12",0.30,0.30,"No"
"SVT/NST Entry",4,"Jun 20, 2001 02:16:05","Class A NST",280,5,"1 sec","NonSustained" , 150,360, "Stability not
Met", ,"Of f"1,"'NA", ,"NA", ,"NA", ,"No", ,"On", ,330, "On", ,270, "Off",,270,290, "On", ,"OWn" ,50, "Of f" ,12, 8
,"12/16","9/12",0.30,0.30,"No"
"End of Section",4
77
"Section",6, "Episode Records",1.9
"Number of Episode Records",35
"Start of Tachy Episode",33
8 mV", "No"
"Tachy Episode", "Vtip to Vring", "+/- 8 my", "Atip to Aring", "+"A. Interval Data",530,340,"AS"
"V. Interval Data",530,180,"VS"
"A. Interval Data",530,340,"AS"
"V. Interval Data",530,180,"VS"
"A. Interval Data",530,340,"AS"
"V. Interval Data",530,180,"VS"
"A. Interval Data",530,340,"AS"
"V. Interval Data",530,180,"VS"
"A. Interval Data",540,350,"AS"
"V. Interval Data",540,190,"VS"
"A. Interval Data",530,340,"AS"
"V. Interval Data",530,180,"VS"
"A. Interval Data",530,340,"AS"
"V. Interval Data",530,180,"VS"
"A. Interval Data",530,350,"AS"
"V. Interval Data",540,190,"VS"
"A. Interval Data",540,350,"AS"
"V. Interval Data",540,180,"VS"
"A. Interval Data",540,350,"AS"
"V. Interval Data",530,180,"VS"
"A. Interval Data",540,350,"AS"
"V. Interval Data",540,180,"VS"
"A. Interval Data",540,350,"AS"
"V. Interval Data",540,190,"VS"
"A. Interval Data",540,350,"AS"
"V. Interval Data",540,180,"VS"
"A. Interval Data",540,350,"AS"
"V. Interval Data",540,190,"VS"
"A. Interval Data",540,350,"AS"
"V. Interval Data",540,190,"VS"
"A. Interval Data",540,350,"AS"
"V. Interval Data",540,190,"VS"
"A. Interval Data",550,360,"AS"
"V. Interval Data",550,190,"VS"
"A. Interval Data",540,350,"AS"
"V. Interval Data",540,190,"VS"
"A. Interval Data",540,350, "AS"
ata",3,-l,-3,-4,-2,-1,-1,0,0,-l,-2,-4,-7,-13,-19,-28,-38,-50,-58,-61
"EGM Channel 1 Data",15,19,24,4,-1,-2,-3,-4,-3,-4,-4,-4,-3,-4,-5,-5,-1,-l,-2,12
"A. Interval Data",150,200, "AR"
"EGM Channel 2 Data",-61,-57,-52,-49,-45,-42,-39,-36,-32,-29,-28,-27,-28,-19
"EGM Channel 1 Data",13,13,11,3,-2,-4,-5,-5,-5,-5,-7,-8,-8,-8
"V. Interval Data",310,110,"TS"
"EGM Channel 2 Data",55,54,-59,17,27
"EGM Channel 1 Data",-8,-6,-4,0,1
"A. Interval Data",150,30,"AR"
Interval Data",180,290,"AR"
"EGM Channel 2 Data",-112,-110,-108,-106,-104
"EGM Channel 1 Data",13,25,11,-1,-2
"V. Interval Data",330,30,"VS"
"Rejection Rule Fired", "Aflutter", 0, "No", "No", ">=6", "No", 1
"End of Episode"
"End of Section",6
"Section",10,"Patient Alert Log",1.1
"Last Session Time",""
"Number of Events",0
78
"Low Battery Voltage", "Date/Time","Measured(V)", "Tolerance(V)"
"V. Pacing lead impedance", "Date/Time", "Impedance (ohms) ", "Tolerance
Minimum(ohms) ", "Tolerance Maximum(ohms)"
"A. Pacing lead impedance", "Date/Time", "Impedance (ohms) ", "Tolerance
Minimum(ohms) ", "Tolerance Maximum(ohms)"
lead impedance", "Date/Time", "Impedance (ohms) ", "Tolerance
"Defibrillation
Minimum(ohms) ', "Tolerance Maximum(ohms) ", "Ring Coil (ohms) ", "Ring Can (ohms)"
"Charge time", "Date/Time", "Charge Time(sec) ", "Tolerance (sec)"
Reset occurred", "Date/Time"
"ICD Electrical
"All therapies exhausted for Episode", "Date/Time" ,"Therapy Type", "Episode Number"
"Shocks delivered for Episode", "Date/Time", "Number of Shocks", "Episode
Number", "Tolerance(shocks)"
"Invalid data received for event","Date/Time"
"End of Section",10
"Section",11,"Mode Switch Log",1.0
"Number of Episodes",0
"Last Session Time",""
"Episode In Progress", "No"
"Mode Switch Episode", "Id", "Date/Time", "A. Max Rate(bpm) ","Sensor
Rate(ppm)","Duration","VT/VF Therapy Delivered"
"End of Section",11
"Section",12,"Dual Chamber R-R Intervals",l.0
"Date Last Cleared", "Jun 14, 2001 18:03:19"
"Current Episode", "Yes",1848
"Marker","P-R or R-P Interval(ms)","R-R or P-P Interval(ms)","Event
"Ventricular"
"VS'",190,450,450
"AR",230,290,605700
"AR",230,290,605990
"AR" ,230,290,606280
"AR" ,230,300,606570
"VF Episode","Yes",
,0,
,
"Marker", "P-R or R-P Interval(ms)","R-R or P-P Interval(ms)","Event
"Ventricular"
Time(ms)"
Time(ms)"
"Atrial"
"End of Section",12
"Section",13, "Daily Log",1.2
"Number of Entries",7
"Latest Measurement Time","Jun 21, 2001 03:01:20"
"Daily Log Entry","Battery(V)","Ventricular Pacing Lead Imp(ohms)","Atrial Pacing Lead
Imp (ohms) ", "HV-Can Lead Imp (ohms) ", "HV-Coil Lead Imp (ohms) ", "Ring-Coil Lead
Imp(ohms)","Ring-Can Lead Imp(ohms)"
"Daily Log Entry",3.11,480.78,409.91,16.89,16.89,29.51,47.61
"Daily Log Entry",3.11,480.78,409.91,83.20, 18.29,29.51,114.45
"Daily Log Entry",3.14,563.90,443.93,31.96, 18.29,31.96, 55.84
"Daily Log Entry",3.13,563.90,443.93,27.25, 18.29,31.96,51.56
"Daily Log Entry" ,3.11, 520.68,443.93,27.25, 16.89,29.51,47.61
"Daily Log Entry",3.10,520.68,480.78,29.51, 16.89,31.96,47.61
"Daily Log Entry",3.09,563.90,443.93,29.51, 19.81,31.96,51.56
"End of Section",13
"Section",14, "Weekly Log",1.2
"Number of Entries", 1
79
"Weekly Log Entry","Min Battery(V)","Max Battery(V)","Min Ventricular Pacing Lead
Imp(ohms) ", "Max Ventricular Pacing Lead Imp(ohms)", "Min Atrial Pacing Lead
Imp(ohms)","Max Atrial Pacing Lead Imp(ohms)","Min HV-Can Lead Imp(ohms)","Max HV-Can
Lead Imp(ohms)","Min HV-Coil Lead Imp(ohms)","Max HV-Coil Lead Imp(ohms)","Min RingCoil Lead Imp(ohms)","Max Ring-Coil Lead Imp(ohms)","Min Ring-Can Lead Imp(ohms)","Max
Ring-Can Lead Imp(ohms)","Min HV Lead Imp(ohms)","Max HV Lead Imp(ohms)"
"Weekly Log
Entry",3.09,3.14,480.78,563.90,409.91,480.78,16.89,83.20,16.89,19.81,29.51,31.96,47.61
,114.45,4139.15,22085.59
"End of Section",14
"Section",15, "Patient Information",1.1
"Number of Parameters" ,44
"Name", "Value", "Units"
"Last Update", "Jun 14, 2001"
"Patient", "XXXXXX"
"ID " ,"XXXXXX "
"
"Date of Birth", "XXX XX,
"ICD Number", "XXXXXX"
"Lead 1 Model", "6943 Sprint (tm)"
"Lead 1 Position", "RV"
"Lead 1 Manufacturer", "Medtronic"
"Lead 1 Serial Number", "XXXXXX"
"Lead 1 Implant Date", "XXX XX, 2001"
"Lead 2 Model","5076-52"
"Lead 2 Position","Atrial"
"Lead 2 Manufacturer", "Medtronic"
"Lead 2 Serial Number", "XXXXXX"
"Lead 2 Implant Date","XXX XX, 2001"
"Lead 3 Model",""
"Lead 3 Position",""
"Lead 3 Manufacturer",""
"Lead 3 Serial Number", "XXXXXX"
"
"Lead 3 Implant Date","XXX XX,
"Implant Date","XXX XX, 2001"
"Implant Defibrillation Energy",15,"J"
"Implant Defibrillation Type", "DFT"
"Implant HV Impedance(ohms) ", "61"
"Implant PWave Amplitude (mV)", "6.3"
"Implant RWave Amplitude (mV)","11.1"
"Implant Atrial Slew Rate",1.9,"V/sec"
"Implant Ventricular Slew Rate" ,2.6, "V/sec"
"Implant Atrial Pacing Threshold Amplitude",0.6,"V"
"Implant Ventricular Pacing Threshold Amplitude",0.8, "V"
"Implant Atrial Pulse Width Setting",0.50, "ms"
"Implant Ventricular Pulse Width Setting",0.50, "ms"
"Implant Atrial Pacing Impedance(ohms) ", "621"
"Implant Ventricular Pacing Impedance (ohms)", "913"
"Implant Atrial Threshold Current (mA)", "1.3"
"Implant Ventricular Threshold Current (mA)", "1. 4 "
"Notes",""
"History 1","I"
"History 2",""
"Ejection Fraction", "---",1"%"
"Ejection Fraction Date",""
"Physician", "XXXXXX"
"Phone", "XXXXXX "
"Hospital", "XXXXXX"
"End of Section",15
80
2.
User Guide
Currently the ICD Archive system allows for searches on patients and episodes for Guidant and
Medtronic devices. These searches can be done under the download page of the website by any registered
user. To access the upload and administration portion of the site, further authorization has to be granted.
Upon entering the site, a page as shown in Figure 1 will appear. Links on this page will lead to pages
for viewing/downloading data, uploading data, and site administration.
Archive of EGM & Related Data from
Implanted Cardioverter Delibrillators (ICDs)
Copyright 0 2001
New England Medical Center
750 Washington Street, Boston, MA02111, USA
M assachusetts Institute of Technoloty
77 Massachusetts Avenue, Cambridge, MA 02139, USA
Beth Israel Deconess Medical Center
330 Brookline Anenue, Boston, MA02215, USA
All rights reserved.
Please e-mailyourpboments/ngesdies
to WebMas.t@Ahosi-*rChMied4 orpoettheato:
Physwo-mrh
Room E2-505 MT
77MasshAsem Avenue
Cmobrgt, MA 00)39, MA
Dccu~in
ec3
Dun (q15E
Figure 1. Top Page of the ICD Archive Site.
81
Search for ICD Data
To view or download data, click on the View or Download data link and a search page as shown in
Figure 2 will appear.
Archive of EGM & Related Data from
Implanted Cardioverter Defibrillators (ICDs)
Search For Patients
PatientID:
Year of Birth
joefore
Male
Gender:
1953
e
Not: Thzc is n
genda spedfiationfor Mcdtonic dta
jjj2002
Implant Date:
jAfter
ICD Manufacturer:
Any
A
J7274 (Medtronic)
ICD Model:
Search
ki
2
d
PallendsI
Search For Episodes
PatientSearch Parameters
Before h1953
Year of Birth:
jMaie
Gender:
Implant Date:
After
j
iti
12002
[n7y
17274 (Medtronic) 1
ICD Manufacturer:
ICD Model:
Episode Search Parameters
Type:
VF (Medtronic)
Therapy Type:
Defib (Medtronic)
g
Any
Testinc Note 1
Attached Notes:
Testing Note 3
Search
Episodes
Figure 2. Search Page.
A list of all patients currently in the database can be viewed by clicking on the View a list of all
patients currently in the database button. Otherwise, the search can be carried out as a patient search or
an episode search.
For a patient search, enter the desired characteristics under the corresponding criteria of Patient ID,
Year of Birth, Gender, Implantation Date, ICD manufacturer, and/or ICD model, then press the Search
Patients button. For an episode search, additional parameters of Episode Type, Therapy Type, and
Attached Comments can be specified.
82
Please note that for certain criteria, the choices are manufacturer-specific. These choices have been
labeled as either being Guidant or Medtronic in prentices, e.g. VF (Medtronic).If the manufacturer is set to
Any but VF (Medtronic)is chosen as an episode type, the results will be displayed for those that fit the
criteria from Medtronic data only. Please also note that Medtronic data does not specify patient gender,
so any gender selection in searching for Medtronic data will be ignored.
The Search Result Pages. Search results will be displayed with links to access data for the
individual records, as shown in Figure 3 and Figure 4.
Archive
of the
EGM & Related Data from Implanted (Pacemaker/Defibrillator) Devices
List of Subjects Meeting Your Search Criteria:
Subjects whose Gender is Male, Year of Birth is Before 1953, Year of
Implantation is After 2002, ICD Model is 7274.
Note: Medtronic mdeli do not containgenderiofomaaof all Medtrouic etodels that fit the ctitetaare diqslA.
NOW
.
1"INNWNU
M"N
W
Figure 3. Sample result for patient search.
Archive of the EGM & Related Data from Implanted (Pacemaker/Defibrillator) Devices
List of Medtronic Episodes Meeting Search Criteria
Figure 4. Sample result for episode search.
From the result pages, Patient Page, ICD Pages, and Episode Pages can be accessed.
83
The Patient Page. The Patient Page displays information about a particular patient, and is shown in
Figure 5.
Figure 5. Sample Patient Page. All ICDs belonging to this particular patient will be displayed.
The first table on the page is the patient information table, and it displays the patient's subject ID,
birth year, and gender. Below the patient table, all ICDs belonging to this patient are displayed in
individual tables. Thus two tables will be shown if the patient has had two ICDs, three tables will be
shown if the patient has had three ICDs, and similarly for other cases. A brief overview on the ICD device
is given, and a link is provided to access the ICD Page in every table.
84
The ICD Pages. ICD Pages are different for different manufacturers, but the general layout is kept
consistent. The ICD page for a Medtronic device is shown in Figure 6.
EGM & Related Data from Medtronic Paemaker/Defibrillator
Record: 001_000038_1
(EGM & Related Data from ICD device 1, subject: 001 000038)
Back to Search Page
ag o
M
1 Document Done (0,105 secs)
Figure 6. Sample ICD Page. All sections available in this ICD will be displayed.
The first table on the page is the ICD information table. Below the ICD information table, sections
related to any EGMs appear on the left while other sections appear on the right.
Specifically, the first table on the left-hand side contains information about the tachycardia log entries
and the supraventricular/non-sustained tachycardia log entries. Number of entry records with EGM
information is displayed along with the total number of records in each section. Links are provided to
access the sections in more detail.
The second table on the left-hand side contains information about current beat intervals at time of
interrogation. Links in this table will lead to the Current Beat Interval Page.
The table on the right-hand side contains all the other sections not related to any graphical
information. For the non-log sections, links are provided to view their contents at the time of each
download session, and these records are listed chronologically from earliest to latest. For the log-based
sections, only one link is given per section. All of the data for these sections will be accessible from these
links.
85
The Log Entry Page. The Log Entry Page appears after the link for either Tachycardia Log Entries or
SVT/NST Log Entries is clicked in the Summary of EGM Records table on the ICD Page. It will resemble
Figure 7.
EGM
& Related Data
For Record:
from
Guidant PacemakenrDefibrillator
001 000038 1 of subject:
001 000038
Section: Tachycardia Log Entries
Document, Done (U166 Stecs)
Figure 7. Sample Log Entry Page. All records for this section will be displayed
along with links to access full details on each record and any related EGM data.
The first table on the page presents information about the section. Below the section information
table, an overview of each record in this section is displayed in a second table. This table makes a
complete listing of all the records associated with the section even if these records were downloaded on
different dates.
Full details on an individual record can be accessed via the link provided under the last column "Full
Details". If EGM data are available for the particular record, EGMs will also be accessible by clicking on
the link for full details. The existence of EGM data is indicated by a "Yes" or "No" in the cell just to the
left of the full details link.
86
The Episode Page. The Episode Page can be accessed from the episode links on the episode search
result page or from the Full Details links on the Log Entry Page. If EGM data is available for the
particular episode, the page will resemble Figure 8.
Figure 8. Sample Episode Page. An SVT/NST episode would be displayed similarly.
On the left entry content is displayed in a table. On the right EGMs can be downloaded and viewed
with the provided links, and comments can be made and attached to this particular episode. Instructions
for attaching comments to the episode will be presented later in this document.
87
The Current Beat Interval Page. The Current Beat Interval Page can be accessed from the links
provided in the Current Beat Intervals at Time of Interrogation Table on the left-hand side of the ICD
page. This page resembles Figure 9.
Figure 9. Sample Current Beat Interval page.
Interval plots can be viewed by clicking on the corresponding links in the table, and comments can be
attached to this page as well.
88
The Section Pages. The Section Pages can be accessed from the links provided on the right-hand
side of the ICD Page. For the non-log sections, they resemble Figure 10. For the log-based sections, they
resemble Figure 11.
For Record: 001 000038 1 of subject: 001 000038
Section: Parameters
Figure 10. Sample Non-Log Section Page.
EGM & Related Data from Guidant Pacemaker/Defibrillator
For Record: 001 000038 1 of subject: 001 000038
Section: Daily Log
";
4
I-Z
oE,'
Document Drine (0 103 sec )
Figure 11. Sample Log-Based Section Page.
All of the information contained in the section will be presented in tabular format.
89
Commenting
Commenting functionalities are available on the Episode Pages and the Current Beat Interval Pages.
There are two types of comments: fixed form and free form. The fixed comments have to be selected
from a list of pre-defined comments set by authorized users in the Administration area of the website.
How these comments are made available will be introduced later.
Fixed Comments. To attach a fixed comment to the episode, highlight the desired comment and hit
Add Notes button. Multiple selections are can be made by clicking on the selections while holding down
the control key (Ctrl). This step is shown in Figure 12.
Clinical Notes Attached:
Select new episode clinical notes to attach:
Testin Note 2
EURWW
Ad Noe
Figure 12. Selecting fixed comments to be added.
A page will appear indicating that the addition has been successful or unsuccessful, and a link is
provided to go back to the original episode page (Figure 13).
Figure 13. Successful Addition.
90
The change should now appear in the table of comments as shown in Figure 14. If the change cannot
be seen, refresh the browser window and it should appear.
Nnfpc Atfnehpd-
Select new episode clinical notes to attach:
Testing Note 1
Testing Note 2
Testing Note 3
Select episode clinical notes to remove:
Testing Note 1
Testing Note 3
Figure 14. Result of adding fixed comments.
Similarly, a note can be selected and deleted by hitting the Delete Notes button.
Free Comments. The free form comments can be anything the user desires. There is no word limit to
it. After entering the free form comment in the textbox as shown in Figure 15, hit the Edit Free Text
button and the comment should be now attached.
Free Text Notes Editor:
ere's an example for free note.I
Edit Free Tex-A
I-L
4z,
ocument Doe.
Figure 15. Adding a free comment.
91
The successful attachment of the note is indicated on a page that resembles Figure 16.
Figure 16. Successful attachment of free note.
Click on the link provided by the page to return to the Episode Page, and refresh the browser to view
the change if necessary. The note should now appear above the box where the comment was originally
entered into as shown in Figure 17.
Figure 17. Result of attaching a free comment. Refresh the browser if the note cannot be seen.
Please be aware that the new comment will save over an old one. The old free note will not be kept,
so it has to be included in the new text to be submitted in order to stay with the episode.
92
Data Upload
To upload ICD data, click on the Upload Data link and a page that resembles Figure 18 should
appear. Follow the instruction on the screen to enter user name, password, and browse the file to be
uploaded and hit the Upload File button.
Archive of EGM and Related Data From
ICD Devices made by Guidant Inc.
Copyright @ 2002
To upload data and get them processed successfully, you will need:
" A valid e-mail address (as user ID) pre-registered in the system.
" A password pre-registered in the system.
" To zip or winzip all the files on the floppy disk into one file and upload this file.
It may take a few seconds to upload the file and get it processed. Be patient and wait for the
process to be completed; when it is complete, some information reflecting the result of the
upload/processing will be presented.
Figure 18. The Upload Page.
93
Comment Management
To add, delete, or alter any fixed comments as selection to be attached to an episode or choices for the
comment search, click on the Administration link on the top page, then click on the Manage Episode
Clinical Notes link. A page that resembles Figure 91 should appear.
Figure 19. The Note Management Page.
To add a comment, type the new episode clinical note in the corresponding textbox and hit the Add
Note button. To alter an existing comment, select a clinical note to rename and enter the desired note,
then hit the Rename Note button. To delete an existing note, select the note and hit the Delete Notes
button. Multiple selections are allowed while holding the control key (Ctrl). Back at the Search Page and
any pages with the fixed comment functionality, changes to the comment choices should now be seen.
94
Bibliography
NIH News Release. NHLBI Stops arrhythmias study - implantable cardiac defibrillators reduce
deaths. NIH, 1997.
[21
Ernoehazy, W., Ventricular Tachycardia. Emedicine,
http://www.emedicine.com/emerg/topic634.htm, 2001.
[3]
American Heart Association Online. Ventricular fibrillation.
http://www.americanheart.org/presenter.jhtml?identifier=4784, 2002.
[41
Huikuri HV, Castellanos A, Myerburg R. Sudden Death Due to Cardiac Arrhythmias. N Engl J
Med 2001; 345:1473 - 1482.
[5]
Bigger JT. Expanding indications for implantable cardiac defibrillators. N Engl J Med 2002;
346:931-933.
[61
Cummins RO, Hazinski MF, eds. Guidelines 2000 for cardiopulmonary resuscitation and
emergency cardiovascular care: an international consensus on science. Circulation 2000;
102:Suppl 1:1-1.
[7]
Bocka, J. Automatic external defibrillation. Emedicine,
http:/ /www.emedicine.com/emerg/topic698.htm, 2003.
[8]
Page RL, Joglar JA, Kowal RC, et al. Use of automated external defibrillators by a U.S. airline. N
Engl J Med 2000; 343:1210-1216.
Valenzuela TD, Roe DJ, Nichol G, Clark LL, Spaite DW, Hardman RG. Outcomes of rapid
[9]
defibrillation by security officers after cardiac arrest in casinos. N Engl J Med 2000; 343:12061209.
[10] Caffrey, SL, Willoughby, PJ, Pepe, PE, Becker, LB. Public use of automated external
defibrillators. N Engl J Med 2002; 347:1242-1247.
[11] Mirowski M, Mower MM, Staewen WS et all. Standby automatic defibrillator: an approach to
prevention of sudden cardiac death. Arch Intern med 126:158, 1970.
[12] Oconnor SA, Drysdale M. Ventricular fibrillation and implantable defibrillators. Cardiac
Pacing and Electrical Stimulation of the Heart Colloquium by IEE Professional Group S9, 1996.
[13] Fromer M, Brachmann J, Block M, et al. Efficacy of automatic multimodal device therapy for
ventricular tachyarrhythmias as delivered by a new implantable pacing cardioverterdefibrillator: results of a European multicenter study of 102 implants. Circulation. 1992; 86:363374..
[141 Moss AJ, Zareba W, Hall WJ, et al. Prophylactic implantation of a defibrillator in patients with
myocardial infarction and reduced ejection fraction. N Engl J Med 2002; 346:877-883.
[15] Buxton AE, Lee KL, Fisher JD, Josephson ME, Prystowsky EN, Hafley G. A randomized study
of the prevention of sudden death in patients with coronary artery disease. N Engl J Med
1999;341:1882-90. [Erratum, N Engl J Med 2000;342:1300.]
[16] Pratt CM, Greenway PS, Schoenfeld MH, Hibben ML, Reiffel JA. Exploration of the precision of
classifying sudden cardiac death: implications for the interpretation of clinical trials.
Circulation 1996; 93:519-24.
[17] Triggers of Ventricular Arrhythmias Study Sponsored by National heart, Lung, and Blood
Institute (NHLBI). At http:/ /www.clinicaltrials.gov/ct/gui/show/NCT00005243.
[181 Zong W, Wang P, Leung B, Moody GB, Mark RG. An automated, web-enabled and searchable
database system for archiving electrogram and related data from implantable cardioverter
defibrillators.
[19] Netcraft Web Server Survey. http:/ /news.netcraft.com/
[20] Goldberger AL, Amaral LAN, Glass L et al. PhysioBank, PhysioToolkit, and PhysioNet:
Components of a new research resource for complex physiologic signals. Circulation2000;
101:215-220.
[1]
95