System for Automatically Performing a Clinical Assessment of an Implanted Pacer Based on Information That Is Telemetrically Received

The present invention concerns a novel system for gathering and processing information for the purpose of determining whether or not an implanted cardiac pacer system is functioning properly.

Modern implanted cardiac pacers have the ability to telemeter information to an external programming and/or receiving unit. In this manner, certain information concerning the pacer's characteristics, including mode, rate, battery level, etc. can be obtained. It is very desirable to be able to determine whether the implanted pacer is functioning properly; specifically, to determine whether the implanted pacer is supporting the patient as expected, given the pacer therapy described and programmed by the implanting or patient follow-up clinician. It would be extremely desirable to have the ability to analyze complex pacemaker modified electrocardiograms (ECGs), determine problems, relate the problems to the specific causes, and have the ability to recommend clinically acceptable actions.

In accordance with the present invention, a cardiac pacer analysis system is provided which non-invasively performs a detailed analysis of the functional status of the entire implanted pacemaker/patient system, rather than merely providing an annotated display of the ECG. The illustrative embodiment combines the surface ECG with telemetered atrial and ventricular ICEGs and activity indicators into a common structure for the simultaneous analyses of pacing antifacts to verify pacemaker output, of evoked potentials to verify capture, and of spontaneous cardiac activity to verify pacemaker sensing. It incorporates a detailed model of the specific pacemaker, and adjusts the actions of the model based on telemetered pacemaker programmed parameter values.

The illustrative embodiment analyzes the functions of and identifies problems with the entire pacemaker system, including the leads and the pacemaker's interactions with the patient. It combines the abnormal functionings observed on different beats into a structure of common underlying problem causes, using a knowledge base which includes both clinical and engineering expertise. It incorporates information stored in and telemetered from the pacemaker (such as lead location and implant date) as well as the telemetered results of automatically performed pacemaker measurements (such as battery voltage and lead impedance) in identifying problems.

The illustrative embodiment uses its clinically derived knowledge base plus patient and pacemaker information to recommend specific corrective actions that could be taken to rectify problems that have been identified.

The illustrative embodiment provides an English language annotated description of the analysis results, along with conventional graphics ECGs.

The illustrative embodiment receives data about the pacemaker and its interaction with the patient from both surface ECG signals and telemetric communications with the pacemaker. The telemetered data include programmed parameter vales, atrial and ventricular intra-cardiac electrograms, pacemaker activity indicators, the results of automatically performed pacemaker measurements, and patient history informaation previously stored in the pacemaker. These data are combined with a pre-stored knowledge base which encompasses the functional characteristics of the implanted pacemaker and the clinical interpretation of paced cardiac events.

The illustrative embodiment uses these data as information about the specific pacemaker/patient interactions, and via a combination of digital signal processing, emulation (modeling) of the pacemaker functions, and application of published and rules-of-thumb heuristic clinical interpretations of paced cardiac events, produces a comprehensive analysis of a patient's pacemaker modified ECG. It identifies normal and abnormal functional events, and summarizes these for the clinician; for any abnormal events, it identifies probable causes and lists appropriate possible diagnostic and therapeutic procedures.

A more detailed explanation of the invention is provided in the following descriptions and claims, and is illustrated in the accompanying drawings.

FIG. 1 is a block diagram of a cardiac pacer analysis system constructed in accordance with the principles of the present invention;

FIG. 2 is a typical device hard copy output of the system of FIG. 1;

FIG. 3 illustrates the structure needed to implement the system of FIG. 1 in a microprocessor-based instrument;

FIG. 4A illustrates a surface ECG;

FIG. 4B illustrates a normal acceptable atrial ICEG signal;

FIG. 4C illustrates an unacceptable atrial ICEG signal;

FIG. 4D illustrates an unacceptable atrial ICEG signal;

FIG. 4E illustrates an unacceptable atrial ICEG signal;

FIG. 5A illustrates an atrial ICEG with a pacing spike and repolarization atrifact;

FIG. 5B illustrates an atrial ICEG after removal of the spike and atrifact;

FIG. 6 illustrates the identification of cardiac activity;

FIG. 7 illustrates the event list formatting;

FIG. 8 illustrates an example event list;

FIG. 9 is an overall flow chart for the paced ECG event analysis unit;

FIG. 10 is a flow chart showing the initialization step of the paced ECG analysis;

FIG. 11 is a flow chart showing the missing event determination step of the paced ECG event analysis;

FIG. 12 is a flow chart showing the updating step of the paced ECG event analysis;

FIG. 13 is a flow chart showing the clinical analysis and advisor unit;

FIG. 14 is a flow chart showing the data reduction and summarization step of the clinical analysis and adviser unit;

FIG. 15A illustrates an event status summary record that would be produced for the surface ECG illustrated in FIG. 15B;

FIG. 15B is an illustration of a sample (stylized) surface ECG;

FIG. 16 is a flow chart showing the problem identification step for the clinical analysis and advisor unit; and

FIG. 17 is a flow chart showing the step of determining problem causes and providing clinical advice by the clinical analysis and advisor unit.

Referring to FIG. 1, the cardiac pacing analysis system of the present invention is embodied in a device including five major functional units:

The device consists of five major functional units:

1. A signal receiving and storage unit 20,

2. A digital signal processing unit 22,

3. A paced ECG event analysis unit 24,

4. A clinical analysis and advisor unit 26, and

5. A results output unit 28.

The signal receiving and storage unit 20 accepts surface ECG and telemetrically transmitted information from the pacemaker and stores it for later use by the remaining units. The next three units analyze the received information; the digital signal processing unit 22 identifies and characterizes the events in the received ECG data, the paced ECG event analysis unit 24 determines if the pacemaker functioned correctly at each event, and the clinical analysis and advisor unit 26 summarizes these results and identifies and observed problems and provides probable causes and possible corrective actions for them. The final unit, the results output unit 28, presents the results of the analyses to the clinician.

FIG. 1 shows how the information flows among the five units of the device, while FIG. 2 shows a typical device hard copy output. FIG. 3 shows the structure needed to implement the device in a microprocessor-based instrument.

The signal receiving and storage unit accepts and stores two types of information.

The first is an array of digital information transmitted from the pacemaker. This includes pacemaker programming information (the specific programmed values of all the pacemaker's programmable parameters), pacemaker stored patient related information (such as implant date, lead type and location, pre-implant symptoms, etc.), and results of automatically performed pacemaker measurements (such as lead impedance or battery level).

The second type of information is a predetermined length of N seconds (up to 30, 8 in preferred implementation) of synchronously sampled electrocardiographic signals, including atrial and ventricular intra-cardiac electrograms, a surface ECG signal, and pacemaker generated activity indicators (telemetered signals which identify specific actions taken by, or changes of state in, the implanted pacemaker, such as paced, sensed, end of refractory, etc.).

The atrial and ventricular intra-cardiac electrograms are sampled by the pacemaker, and digitally transmitted, along with the pacemaker activity indicators, to the device. The surface ECG signal is presented to the device as an analog signal. The devide samples this synchronously with the intra-cardiac electrogram sampling by taking a surface ECG sample at the time of receipt of every other intra-cardiac electrogram sample. The signal sampling sequence is: receive an atrial ICEG sample, receive a ventricular ICEG sample, take a surface ECG sample, receive an atrial ICEG sample, and so on.

The pacemaker activity indicators are transmitted by the pacemaker in lieu of ICEG samples, with a unique identifying code. Each activity indicator takes the place of one sample, so synchrony is maintained. (Note: The digital signal processing unit extracts each indicator from the ICEG data stream, and replaces the "missing" ICEG sample value with an interpolated value.

The pacemakeer stored information is received first, the the combined ICEG, ECG, and activity indicator signals. Processing of the information does not begin until all the signal information has been received and stored. The received ECG/ICEG signals are displayed on a real time analog display for the operator, and are continuously stored in a circular buffer holding N seconds of the digitized signals. When the operator is satisfied with the received signals, he indicates this, and the last N seconds (stored in the buffer) are saved for analysis.

The purpose of the digital signal processing is to convert the continuous stream of digitized analog information into an ordered list of discrete events, and to characterize each event.

An event is defined as any interaction between the pacemaker and the heart, or any cardiac activity which should have caused a pacemaker response. These include (for either channel) spontaneous cardiac activity (whether sensed or not), pacemaker sensing of cardiac activity (whether of valid signal or of noise), pacemaker pacing outputs and cardiac evoked responses.

An event is characterized by a set of quantitative and symbolic metrics, including the time of occurrence, the channel on which it occurred, the presence or absence of spontaneous activity, whether or not the pacemaker sensed, and/or claimed (as shown by an activity indicator) it output a packing pulse, the presence or absence of a pacing pulse in the ECG signals, and the presence or absence of an evoked response. In addition, any other "special" information conveyed by the activity indicators (for example, an PVC indication) is included in the event description.

The presence of other pacemaker state changes which were signaled by an activity indicator (such as the end of a channel's refractory period) are identified, but not as separate events. Every event has appended to it a series of occurrence times, one for each possible pacemaker state change. If a particular state change happened between two events (after event A, but before event B) its time of occurrence in the description of the present event (event A) is set to a positive number, indicating how many milliseconds after the present event it occurred. A time of zero is used to indicate that no such change occurred between the present event and the next one.

The digital signal processing performs a six step process, as follows:

1. Signal sorting, activity indicator identification and removal,

2. ECG (including ICEG) signal verification,

3. Identification and removal of pacing spikes and atrifacts,

4. Detection of cardiac activity,

5. Correlation of cardiac activity and pacing spikes with activity indicators, and

6. Formatting the event list (for further analysis).

The sampled ICEG signals and the pacemaker activity indicators are received as a single multiplexed data stream. This is separated into three signals: the atrial ICEG, the ventricular ICEG, and the activity indicators. This is accomplished based on the known transmission sequence used by the pacemaker, and the unique codes which identify the activity indicators.

Next, since activity indicators are transmitted in place of ICEG signal samples, the ICEG signal timing will be corrected for any missing or time-shifted samples. In addition, since the atrial and ventricular ICEG samples are taken alternately, and the surface ECG samples are taken synchronously with every other transmitted sample (or inserted activity indicator), all sampled data and activity indicators must be corrected to produce a common sampling moment. These two steps are accomplished simultaneously. The result of this step is a set of four synchronously sampled signals; the surface ECG, the atrial and ventricular ICEGs, and the activity indicators. The received signals are sorted and corrected as indicated in the following Chart A:

Before any further processing, the ECG and both ICEG signals are checked to determine if they are "clean" enough for processing. The average and deviation of the signals are checked to determine if the overall signal level and the signal to noise level of each is acceptable, and each signal is checked for amplifier saturation following pacemaker output spikes.

If the signal is unsatisfactory, the user is informed (via the Results Output Unit) that the signal cannot be processed, and why. The device then stops and waits for the user to obtain another time segment of ECG/ICEG signals. FIGS. 4A-4E show examples of acceptable and unacceptable Atrial ICEG signals, with the surface ECG included for reference only. The signals shown are idealized versions for illustrative purposes; they are not real human data.

This step in the process locates and removes from each signal channel the pacing "spikes" and polarization artifacts caused by pacemaker outputs. This enhances the later identification of cardiac activity (either spontaneous or evoked).

Pacing spikes are identified in each channel by the presence of threshold crossings in the signal's derivative with a specified time relationship, based on the known pacemaker output pulse width. These spikes are then matched to pacemaker output activity indicators to determine on which channel the pacemaker output occurred. The time channel and occurrence for each pacing spike is stored, and all the pacing spikes are then removed, with a different method used for each channel.

The pacemaker spiked are removed from the surface channel by subtraction, and then the surface ECG signal is smoothed, by interpolation, to follow the "surrounding" evoked response.

Pacemaker spikes and polarization artifacts are removed from the channel on which the pacing spike occurred in a two step process. First, the pacing spike itself is subtracted. Next, the polarization atrifact is exponentially approximated using a second order linear predictor with a least squares estimator; this exponential is then subtracted. This allows the evoked response to be retained, even through it occurs in the middle of the exponential polarization atrifact.

Finally, pacing spikes due to pacemaker outputs on one channel are similarly removed from the other ICEG channel. In addition, the large "far field" polarization artifacts seen in the atrial channel due to ventricular outputs are exponentially removed.

The result of this sep is a set of ECG/ICEG signals with all pacing artifacts removed, but with all spontaneous and evoked cardiac activity retained. FIGS. 5A-5B illustrate this process. FIG. 5A shows a sampled ICEG (idealized) including a pacing spike and a repolarization atrifact. FIG. 5B shows the results of subtracting the pacing spike and the exponentially approximated repolarization atrifact. The remaining signal (shown as a sine wave) would represent the cardiac activity.

Cardiac activity (either spontaneous or evoked) is detected via a two-step process. First, a simple detector scans each signal channel for possible areas of activity. Next, a "smart" detector scans all three signals simultaneously, looking at each area identified by the simple detector.

The simple detector uses a level threshold to locate areas of possible cardiac activity. It independently scans each signal channel (surface ECG, atrial ICEG, and ventricular ICEG) to locate areas where the signal exceeds a defined threshold. The threshold is determined for each channel based on the mean, deviation, and peak values of the signal in that channel. The locations of these "candidate" areas are stored for use by the "smart" detector. (The primary purpose of this "simple" detector is to reduce the amount of signal the computationally intensive "smart" detector must process.)

The smart detector uses a set of "expectancy" matrices. These prestored matrices essentially contain what the device "expects" each type of event (atrial activity, ventricular activity, and noise) to look like across all three channels over a small sequence of samples. They were obtained by taking the mathematical inverse of "observed" signal matrices. The "observed" matrices were based on the combination of a large number of observations of each type of activity.

The "smart" detector scans each type of expectancy matrix across all three simultaneous signals for each area identified by the "simple" detector, determining a "detector output" for each point in the candidate area. It also determines the first and second moment of the detector output. Based on these results, it selects the most probable identification of each candidate area (atrial activity, ventricular activity, or noise) and identifies the fiducial point (or common time reference point) for each area identified as cardiac activity. FIG. 6 illustrates this process. The upper section shows three (stylized) simultaneous data signals--the surface ECG, the atrial ICEG, and the ventricular ICEG. Immediately below each signal are indicated the "Candidate" areas identified by independently scanning each signal with the simple detector. The lower section shows the output of each of the smart detectors over each identified candidate area. These are obtained by independently scanning each smart detector over all three data signals simultaneously. Note that the outputs of the smart detectors exist only for simple detector identified candidate areas. The bottom line indicates the decision made about each candidate area, based on the relative outputs of the smart detectors. Each candidate area is identified as either atrial activity, ventricular activity, or noise (no cardiac activity).

This step examines each identified occurrence of cardiac activity and attempts to associate it with a previously identified pacemaker action (such as a sense or a pace). For example, cardiac activity on a particular channel immediately following a pacemaker output on that channel would be considered as an evoked response, and would be evidence that the pacemaker output had "captured" the chamber. Those occurrences of cardiac activity which cannot be associated with an appropriate pacemaker activity indicator are retained as separate events. An example of this would be an unsensed P wave.

The last step in the digital signal processing unit is to sequentially sort the identified events, and to write them in a standard format into the "event list". It is this list of discrete events that will be analyzed by the paced ECG event analysis unit. FIG. 7 shows the (stylized) surface ECG and the activity indicators for that section of the data. FIG. 8 is an event list corresponding to the data section of FIG. 7.

The purpose of the paced ECG event analysis unit is to examine each individual event and determine if the pacemaker functioned properly. For example, did it sense (or not sense) spontaneous cardiac activity when it was supposed to, did it output a pacing pulse at the correct time, did the pacing pulse capture the heart (produce an evoked response in the paced chamber), did the refractory periods end on time, were there any occurrences of PVCs, PACs, or special pacemaker mediated events, etc.

As each event is analyzed, several status indicators are determined for each event. These include sensing status, pacing (timing) status, capture status, state change timing (such as end of refractory period) status, and special (PVC, anti-PMT dropped beat, ventricular safety pace beat, etc.) statuses. The possible values for each status indicator include all possible normal and abnormal functional conditions for that pacemaker function. For example, the possible values for sensing status include three normal conditions (OK) and five abnormal conditions (NG), as follows:

Since is is possible for several abnormal conditions to occur at the same time (for example, an oversense in the blanking period), the unit identifies the most serious problem, and assigns that status indicator value for the event.

The paced ECG event analysis unit is based on a detailed model of the functioning relationships incorporated in the pacemaker's hardware and software, expressed as a set of logical rules. These rules predict exactly what the pacemaker is expected to do in any situation, based on the programmed parameter values. The unit compares the expected functioning (as predicted by the model) with the observed functioning (as evidenced by the event list) to determine the status of each pacemaker function for each event.

The paced ECG event analysis unit performs a five step process, with the last four steps repeated sequentially for each entry in the event list, as follows:

1. Initialization,

2. "Missing" event detection,

3. Status indicator determination,

4. Update the model, and

5. Check for ("non-event") state change indicators. FIG. 9 shows the overall flow of information in this unit.

In order to determine how the pacemaker should act at a given moment it is necessary to know the "state" of the pacemaker; i.e., the value of every variable in the pacemaker at that moment in time. For example, to determine if the pacemaker should sense a P-wave, it is necessary to know if atrial sensing is on or off, and, if it is on, is the channel blanked, refractory, alert, or in a noise window. The values of these internal pacemaker variables depend on both the programmed parameter values and the past experience (history) of the pacemaker. While all programmed parameter values are known, the history of the pacemaker is not known at the beginning of the ECG/ICEG data segment. Initialization establishes its state.

Initialization is accomplished by assuming that the pacemaker is functioning properly, and examining how it acted in response to the heart's actions early on in the data segment. For example, if a DDD pacemaker's first action was to pace the atrium, then it is assumed to have been in the atrial escape interval at the start of the data segment. Since both the number of possible pacemaker states and the number of first actions are finite (though large), an exhaustive analysis of the responses to initial actions allows the pacemaker's state at the start of the data to be uniquely determined. Once the initial state of the pacemaker has been determined, each subsequent event can then be sequentially analyzed. FIG. 10 shows the sequence of information flow for this unit.

The analysis of each event begins by checking to see if any event should have occurred after the last analyzed event and prior to the specific event that is about to be analyzed; i.e., is any expected event "missing." This can occur for two reasons, pacemaker malfunction or unobserved pacemaker state changes. If a "missing event" is identified, it is inserted into the event list ahead of the event about to be analyzed. The inserted "missing" event will be analyzed next, before the event that was about to be analyzed. Examples of each type of "missing event" follow. FIG. 11 shows the decision structure for identifying "missing" events.

Suppose that a VOO pacemaker is programmed to 60 beats per minute, and that the interval from the previous event (a ventricular pace) to the event about to be analyzed in the event list is 1,200 milliseconds. Obviously, the pacemaker should have output a pulse 1,000 milliseconds after the previous event, and did not--it malfunctioned. This is accommodated by adding an event to the event list at 1,000 milliseconds after the previous event (200 milliseconds before the event that was about to be analyzed). When this "added" event is analyzed, it will indicate a failure to pace when expected.

However, "missing events" can also occur during normal pacemaker functioning. For example, consider a VDD pacemaker. Assume that following a ventricular pace, no atrial activity is detected for the entire minimum rate determined beat to beat interval. The pacemaker would then correctly pace the ventricle. However, the atrial escape interval has ended and the ventricular escape interval (or AV delay) has started with no activity indicator. To allow the model to correctly process this state change, an event would be added to the event list at the expected end of the atrial escape interval. (This is identified as a "phantom" event and is only used internally for analysis; it is not identified as an event to the user.)

Knowing the state of the pacemaker, it is possible to determine if it functional properly at each event. Each event is analyzed, based on the metrics determined by the digital signal processing unit. A single value is assigned to each status for every event.

Separate rules evaluate the various functions and determine the value of each status indicator for the event. A typical rule from the evaluation of capture status might read:

The rules used are based on a rigorous, exhaustive analysis of all possible combinations of relevant event metrics and pacemaker programmed parameter values, and were verified by clinical experts. The rules are independent of the channel where the event occurred, except for events such as premature ventricular contractions or retrograde P waves, which can occur only on a specific channel.

Each event may change the state of the pacemaker. This will affect the way in which it responds to the next event. This step in the paced ECG event analysis determines the way in which the state of the pacemaker has been changed by the event just analyzed. In essence, it "updates" the running model of the pacemaker, and prepares it to evaluate the next event. The following Chart B shows the input variables used by, and the possible outcomes for, each set of event status determination rules--sensing, pacing (timing) and capture. Note that the same rules apply to both the atrial and ventricular channels, and are applied independently to each.

It is based on the detailed model of the pacemaker functional relationships and the programmed parameter values. However, the model has been expended to allow for uncertainties due to both real world timing tolerances and imprecise or incomplete history.

For example, the duration of the AV delay may be a function of whether or not the two previous atrial events were paced or sensed. If this is not shown (such as on the second beat), the model would be updated to show a range of allowable AV delays, based on however much history is known. When the next ventricular event is analyzed, AV delays falling anywhere in this range would be considered correct functioning. FIG. 12 shows the steps involved in updating the pacemaker model, depending on the type of event that has occurred. Note that the process is similar, regardless of the channel on which the event occurred.

Certain state changes within the pacemaker are signaled by telemetered activity indicators, but are not considered as pacemaker/patient events. They were indicated in the event list by noting the time they occurred after the immediately preceding true event. The last step in the analysis of a single event is to look for any such indicators and verify their function and timing. The following Chart C shows the input variables and possible outcomes for a typical state change activity indicator status determination, the end of refractory period activity indicator. Note that the same rules apply to both the atrial and ventricular channels, and are applied independently to each.

This completes the analysis of an event in the event list. The last four steps are repeated until the end of the event list is reached.

The purpose of the clinical analysis and advisor unit is to combine the results of the analyses of the individual events into a single comprehensive evaluation of the implanted cardiac pacemaker system.

Following the paced ECG event analysis, the event list contains the signal analysis metrics and statuses for each patient/pacemaker interaction or event. The clinical analysis and advisor unit uses expert system techniques to combine the information in the event list with patient and pacemaker data, and a knowledge base of clinical expertise in ECG problem solving to produce a summary analysis of the functional condition of the implanted pacemaker; including any identified problem(s), their probable cause(s), and clinically acceptable actions to correct them.

The clinical analysis and advisor unit uses a clinical knowledge base organized into a series of frame-like structures; that is, separate structures for problems relating to pacing leads, pacing rate, pacemaker electronic malfunctions, pacing and sensing thresholds, pacing lead configurations, etc. This allows the unit to search the knowledge base much as a clinician would analyze a paced ECG in actual practice.

This structuring also allows each step of the analysis to be individually examined and validated. Because each structure covers a limited and defined domain (set of possible inputs, problems, and causes) it can be rigorously validated, often by exhaustive search of all possible input combinations and their resulting outputs. This is typically not possible in most expert systems which do not employ such a frame-like structuring.

The clinical analysis and advisor unit uses a four step process, as follows:

1. Data reduction (and summarization),

2. Problem identification,

3. Determination of problem causes, and

4. Provision of clinical advice.

FIG. 13 shows the sequence of events in this unit.

In the present implementation, steps three and four of this process were combined into a single step. Therefore, in the following descriptions, the purposes of these last two steps will be separately described, and then their implementation as a single step will be described.

To allow the clinical analysis and advisor unit to examine and sort out the large amount of information presented to it in any reasonable time, data reduction is necessary. This is accomplished in four separate areas; reduction of programmed parameter and stored patient information values, reduction of strings of events into the larger clinical P-QRS complexes called "beats," identification of clinically significant ECG patterns over multiple events, and summarizing of common event status values. These reductions are accomplished by the sequential application of a series of pre-stored rules or "Productions" in an "IF (FACTS) . . . THEN (ACTIONS) . . . " format, and random access memory search and update methods.

The number of programmable parameter values stored in the pacemaker can cause a combinatorial explosion, results in an unmanageable number of logic tests being needed to arrive at a single analysis result. These programmable parameter values are reduced to a manageable number by symbolic representations. For example, a pacemaker may have up to 128 possible combinations for pacemaker output amplitude and pulse width. This is first reduced by combining the two values into a single value representing the total charge delivered by the output. This might reduce the 128 values by more than half. Next these charge values are ordered and identified as falling into one of five clinically significant symbolically labelled categories. A set of 40 charge values might be labelled as follows:

A similar example is the reduction of the stored implant date and the present date into a single designation of whether the implant is "acute" or "chronic."

The second data reduction is performed primarily to reduce the amount of information that will have to be presented to the clinician. Separate events are combined into larger P-QRS complexes identified as "beats." This allows the conversion of references from the exact time domain into the clinical terms normally used in discussing ECGs. Thus, rather than reporting an atrial event which occurred at 2895 milliseconds into the data segment, the device can refer to the atrial part of P-QRS beat 3. This reduction is accomplished by a set of rules that examine the order and type of atrial and ventricular events within specific time limits.

Productions are also used to combine the order and timing of individual events to identify ECG occurrences that happen over several beats, such as retrograde P waves, premature ventricular contractions, or pacemaker mediated tachycardia. These identifications are added to the individual event descriptions in the Event List before summarization.

At the same time, questionable occurrences are examined and verified. For example, it is not always possible to directly verify atrial capture, since the atrial evoked response is not always clearly identifiable in the ECG or ICEG. Digital signal processing may fail to identify it, with the result theat atrial capture status is classified as "unknown." However, by examining a series of events, there may be "further evidence" indicating atrial capture. If there are instances where atrial paced events are consistently followed by spontaneous ventricular contractions within a normal AV delay range, then atrial capture can be assumed to have occurred, and the atrial capture status is changed to "OK--Captured."

Finally, the entire list of individual events and their separate status values are summarized to produce a single event status summary record. This summary contains, for each channel, the type of event (sensed, paced, etc.) and the common status values found in the different beats. It is this event status summary record, in combination with pacemaker and patient data, which is primarily used for problem identification. FIG. 14 shows the sequential flow of these activities. FIG. 15 shows the event status summary record that would be produced for the sample (stylized) surface ECG shown in FIG. 15B. The record is based on the analysis of all the signals, not just the surface ECG. The surface ECG is included here for illustrative purposes only.

Once the event status summary record has been produced, it is scanned via a computed "key" access (based on the channel, the number of records, and status indicator) to the record, to determine the operational status of each of the pacemaker's functions (sensing, pacing, timing and capture) for each channel. The productions examine the status indicator values for each particular function for all events. Functions are identified as having one of four operational states, as follows:

Unobserved: The particular function was never observable during the ECG data segment. (Example: Atrial sensing when no P waves were present.)

Normal: The particular function was observable at least once during the ECG data segment; and its status was OK every time it was observed. (Example: Proper atrial sensing of intermittent P waves with no over-sensing when P waves not present.)

Abnormal-Intermittent: The particular function was observable at least twice during the ECG data segment; its status was OK at least once and No Good at least once. (Example: Multiple paced atrial beats, with the atrium captured on some beats and not on others.)

Abnormal--Complete (or Constant): The particular function was observable at least once during the ECG data segment; its status was No Good every time it was observed. (Example: One or more paced atrial beats, none of which captured the atrium.)

In addition, any special status indicators are reviewed for possible improper functioning.

Where any abnormal functioning is identified, the beats on which the function's status was No Good are noted. These will be reported to the clinician.

At this stage in its analysis, the device has simply "reviewed" the ECG and "reported" its findings, "flagging" any abnormalities. There has been no identification of the possible causes of any of the observed abnormalities, and no determination of future clinical actions, either diagnostic or therapeutic. In certain applications, this would be the appropriate termination of the analysis. In those cases, the remaining stages in the clinical analysis and advisor unit would be disabled, and the present coded analysis results would be directly passed to the results output unit.

FIG. 16 shows the sequential identification of problems with each of the different pacer functions.

Once individual problems (or malfunctions) have been identified, the device must determine what caused the problem(s). Because of the complex interactions within the implanted system, multiple observed problems may in fact have a common cause. For example, a dislodged atrial lead could cause both intermittent atrial under sensing and complete loss of atrial capture; in the presence of retrograde conduction, this could also yield retrograde P waves. Alternately, consistent atrial undersensing along with complete loss of atrial capture could be due to an atrial lead problem (fracture, dislocation, etc.) or to separately programmed inappropriate values for atrial output and atrial sensitivity.

Problem causes are grouped by engineering system (pacemaker timing control, output circuits, sensing circuits, leads, etc.), with each system being sequentially examined. The stored knowledge base used to identify problem causes is based upon a structured representation of information derived primarily from pacemaker system engineers, and secondarily from experienced clinicians, obtained through both reviews of published material and extensive interviews.

Because specific system malfunctions may cause multiple observed problems, it is necessary to examine not only separate observed problems, but also combinations of problems. To assist in identifying problem causes, stored information (such as pacemaker measurements and stored patient information) as well as programmed parameter values are combined with the information on the observed problems. Where a single cause cannot be positively identified, multiple possible causes are retained.

Once the causes of the observed pacemaker system problems have been identified, possible corrective actions can be identified. Determining the proper action to correct a specific problem is a clinical task, clearly requiring an experienced medical practitioner. The device's ability to recommend actions is severely constrained by both ethical and legal considerations. It is not within the scope of any device to practice clinical medicine. However, it is within the scope of this device to provide the clinician with a set of reminders, encompassing clinically accepted techniques for rectifying each identified problem, along with a list of "relevant" patient and/or pacemaker information.

Another knowledge base (obtained primarily from clinical experts) is used to identify appropriate and generally accepted clinical procedures. These may include both specific actions (such as reprogramming the pacemaker) and diagnostic procedures (such as fluoroscopic examination of the lead). The recommendations are based not only on the observed problem, but also on stored information about the pacemaker and the patient. For example, increasing the pacemaker's output would not be recommended if the pacemaker were already at maximum output, while reducing the pacing rate to attempt to observe atrial sensing would not be recommended if the patient has a pre-pacing history of syncope.

In addition to identifying possible actions, the device also identifies specific facts from the stored information which are relevant to the actions identified. These are passed to the results output unit along with the actions.

In its present implementation, the two separate steps of determination of problem causes the provision of clinical advice have been combined into a single step. The two separate knowledge bases were combined into a common sets of productions with a single inference engine.

As in other units, the productions in this step use the "IF (FACTS) . . . THEN (ACTIONS) . . . " structure. FACTS are the combinations of symbolic representations of the stored pacemaker data, quantitative and symbolic paced ECG event metrics, and the summary of the statuses for each event. Each "FACTS" part of a production essentially represents a possible problem state. The "ACTION" part of a production contains relevant pacemaker programmed variables to be displayed, a statement of both normal and abnormal events and where they occur (P-QRS beats), the probable cause of the abnormal event, some reasoning about the event (if possible) and recommendations for actions to correct the problem.

An example of a production from this step is:

The productions are grouped (framed) into problem categories. That is: pacemaker malfunctioning, pacing leads, pacing and sensing thresholds, pacing rate, etc.

The mechanism to search through the entire knowledge base of productions is called an "inference engine." Each production is examined, and if the "FACTS" part is true, then the production is instantiated and the "ACTIONS" occur. If false, then the search continues to process the other productions. The order of the search through the productions emulates the way in which a clinician would view and analyze a patient's paced ECG. FIG. 17 shows the structure of the Expert System that is used for the joint implementation of these two steps, indicating the types of information stored in each section of the data base.

The purpose of the results output unit is to present the conclusions from the analyses to the clinician. Depending on the capabilities of the output unit, results may be presented either as a single entity or as a sequential series of presentations, either on a visual display or in "hard copy."

Regardless of the output mechanism used, the results output unit performs several functions. First, it combines the stored surface ECG with the derived beat identifications and stored activity indicators to provide an annotated ECG. Second, it provides a display of the summarized results for each channel, identifying all observed and unobserved functional status for each channel, with all abnormal findings clearly labelled. Finally, for every abnormal finding, it lists the relevant pacemaker and patient data, the probable causes, and possible corrective actions.

This unit includes large scale editing and code conversion sections, to convert the internal coded information into specific user readable outputs, tailored to the specific display being used, as well as the connectors and drivers for the actual output unit employed.

Although an illustrative embodiment of the invention has been shown and described, it is to be understood that various modifications and substitutions may be made by those skilled in the art without departing from the novel spirit and scope of the present invention.