WO2006078785A2 - Feature-based editing for electrocardiography - Google Patents

Abstract

A method and system for generating electrocardiogram reports allows for the editing of features in the electrocardiogram interpretation process. This improves the accuracy of machine interpretation of the ECG data thereby facilitating the analysis and generation of the final report by the physician. The present method and system are most useful in host-based ECG interpretation systems where the physician accesses the ECG data at a workstation including a machine interpretation that is generated typically at the ECG cart. The physician is then provided with the ability to modify the features in the ECG data and generate a new host-based interpretation based on the original ECG data and the features specified by the physician.

Description

TITLE OF THE INVENTION

FEATURE-BASED EDITING FOR ELECTROCARDIOGRAPHY

RELATED APPLICATIONS This application claims the benefit under 35 USC 119(e) of U.S. Provisional Application

Nos. 60/644,888, filed on January 18, 2005; 60/644,875, filed on January 18, 2005 and 60/644,876, filed on January 18, 2005, all three of which are incorporated herein by reference in their entirety.

BACKGROUND OF THE INVENTION

Electrocardiography is a technology for the detection and diagnosis of cardiac conditions. An electrocardiograph is a medical device capable of recording the potential differences generated by the electrical activity of the heart. An electrocardiogram (ECG or EKG) is produced by the electrocardiograph. It typically comprises the ECG wave data that describes the heart's electrical activity as a function of time.

The heart's electrical activity is detected by sensing electrical potentials via a series of electrode leads that are placed on the patient at defined locations on the patient's chest and limbs. Systems with ten (10) separate ECG leads and digital data capture/storage are typical. During electrocardiography, the detected electrical potentials are recorded and graphed as ECG wave data that characterize the depolarization and repolarization of the cardiac muscle.

ECG interpretation is performed by analyzing the various cardiac electrical events presented in the ECG wave data. Generally, the ECG wave data comprise a P wave, which indicates atrial depolarization, a QRS complex, which represents ventricular depolarization, and a T-wave representing ventricular repolarization.

State-of-the-art ECG systems provide for the machine interpretation of the ECG data. These systems are designed to measure features of the ECG wave data from the patient. The various features of portions of the ECG, such as intervals, segments and complexes, including their amplitude, direction, and duration of the waves and their morphological aspects, are measured. Then all of the feature information is analyzed together. From this feature information, these systems are able to generate machine ECG interpretations diagnosing normal and abnormal cardiac rhythms and conduction patterns. These interpretations are often used by the physician/cardiologist as the basis of an ECG report for a given patient.

SUMMARY OF THE INVENTION

With advances in technology, including more accurate ECG machines and increased sophistication in the software interpretation algorithms, machine-generated ECG interpretations

-i- have become increasingly accurate. Despite this trend, however, a nontrivial number of these machine-generated ECG interpretations will be incorrect. And, these incorrect ECG interpretations often represent a frustration to the physician/cardiologic, since the physician will be forced to function in a clerical role using text-editing tools to correct the machine-generated interpretations in the process of drafting the patient's ECG report.

Even though algorithms for computer-based ECG interpretation are generally quite accurate, errors are commonly made by the computer in making measurements and determining the low-level and high-level features in the first place. When these are made available for review and correction, the cardiologist can interact at a higher level of sophistication, acting more as a domain expert and less like a clerk or secretary. In addition, all of the internal checks for mutually exclusive conditions can remain in place (done during the final generation step of the interpretation process), thereby greatly reducing inadvertent errors and/or inconsistencies.

The present invention is directed to a method and system for generating electrocardiogram reports. It allows for the editing of features in the electrocardiogram interpretation process. This improves the accuracy of machine interpretation of the ECG data thereby facilitating the analysis and generation of the final report by the physician.

The present method and system are most useful in host-based ECG interpretation systems where the physician accesses the ECG data at a workstation including a machine interpretation that is generated typically by the host system or workstation. The physician is then provided with the ability to modify the features in the ECG data and generate a new host-based interpretation based on the original ECG data and the features specified by the physician.

In general, according to one aspect, the invention features a method for generating an electrocardiogram report. This method comprises receiving ECG data at a physician workstation and enabling the physician to review, specify, and, if needed, correct the values for features of the ECG data. An interpretation of the ECG data is then generated based on the values of the features specified by the physician. Finally, the interpretation is stored after physician editing in a patient database.

In the typical implementation, the ECG data include the ECG wave data and an ECG machine interpretation of that ECG wave data. Typically, the ECG wave data are generated at an ECG cart that is operated by a nurse or technician and the interpretation is generated by the host system.

Then, in the preferred interpretation process, the physician selects whether to edit the final host machine interpretation and finalize the report or specify new values for the features. Typically, the physician will select to edit the final machine interpretation if it is determined to be basically or largely accurate after having reviewed the ECG wave data.

In the typical implementation, the step of enabling feature value specification comprises presenting machine-generated values for features of the ECG wave data and enabling the physician 5 to specify different values for at least one of the features. Then, the final steps of the host-based interpretation are re-performed in which a new interpretation of the ECG is generated using the specified values for the features from the physician and the machine-generated values for other features.

In general according to another aspect, the invention features a system for generating an l o electrocardiogram (ECG) report. The system comprises a workstation that receives ECG data and enables specification of values for features of the ECG data and an interpretation system for evaluating of the ECG data based on the values of the features specified by a user and generating an inteipretation for storage in a patient database. Typically the interpretation system runs on the workstation or host system.

15 In general according to another aspect, the invention features a computer software product for generating an electrocardiogram (ECG) report. The product comprises a computer-readable medium, such as a compact disk, in which program instructions are stored. These instructions, when read by a computer, cause the computer to receive ECG data at a physician workstation, and enable a user to specify values for features of the ECG data. The instructions also provide for the

20 generation of an interpretation of the ECG data based on the values of the features specified by the user, and store the interpretation after possible editing in a patient database.

The above and other features of the invention including various novel details of construction and combinations of parts, and other advantages, will now be more particularly described with reference to the accompanying drawings and pointed out in the claims. It will be understood that 25 the particular method and device embodying the invention are shown by way of illustration and not as a limitation of the invention. The principles and features of this invention may be employed in various and numerous embodiments without departing from the scope of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings, reference characters refer to the same parts throughout the 30 different views. The drawings are not necessarily to scale; emphasis has instead been placed upon illustrating the principles of the invention. Of the drawings:

Fig. 1 is a schematic diagram illustrating the electrocardiogram (ECG) workflow in a typical hospital; Fig. 2 is a flow diagram illustrating the machine interpretation process in a conventional ECG device or host-based interpretation system;

Fig. 3 shows prototypical ECG wave data illustrating the various portions of the wave; Fig. 4 shows a conventional interface in an ECG report editing system;

5 Fig. 5 shows a series of text statements as would be generated by machine interpretation for an exemplary ECG report as is conventional; and

Fig. 6 is a flow diagram illustrating the process for ECG feature specification and ECG report generation according to the present invention;

Fig. 7 is a flow diagram illustrating the process for ECG scoring and complexity sorting i o according to the present invention.

Fig. 8 is a flow diagram illustrating the process for ECG data quality assurance according to the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Fig. 1 illustrates the electrocardiogram (ECG) workflow in a typical hospital.

15 A nurse or ECG technician 112 interacts with the patient 110 to acquire the ECG data. In many modern systems, the ECG machine 114 is an ECG cart that is moved throughout the hospital between patient, examining, and operating rooms.

In operation, the ten (10) leads 118 of the ECG device 114 are placed on the limbs and torso of the patient 110. Then, a printout of the ECG wave data 116 is generated at the cart using twelve 20 (12) combinations of the leads that have been placed on the patient. Also, ECG data 120 including the wave data, identifying information about the patient, and possibly the machine-generated ECG interpretation are digitally stored in the ECG cart 114 and/or transmitted to a central hospital records data storage and host system 130.

The present invention generally applies to a host-based interpretation and editing systems. 25 In these systems, a cardiologist 122 accesses the ECG data 125 from the records database and host systeml30 via a workstation 124. These hospital records will store preliminary ECG data and machine interpretations and the subsequent final reports that are the product of the editing process by the cardiologist 122 at the workstation 124. The final reports will then be entered into the patients' records.

30 The workstation 124 is provided with standard software for accessing and editing the ECG data and machine-generated interpretations reports from the host system 130 and generating the final cardiologist-reviewed ECG reports 126. Fig. 2 illustrates the general process by which these machine interpretations are generated by the host system 130 or possibly by the workstation 124.

Specifically, the digital ECG signals or wave data 150 are acquired in step 150 and stored such as by the ECG cart 114. Measurements of portions of this ECG wave data are made in step 154 and low-level features 152 are typical identified in the wave data at the host system 130. This information is then combined in step 156 when high-level features are determined. Based on these calculated features, the final interpretation is generated in step 158.

The features typically relate to the length and amplitude of the various components of a selected ECG wave from one typical cardiac cycle out of the usually very long wave data set that the machine acquires. In other cases, an average ECG wave is calculated from a series of waves to form the basis of the interpretation. Features can be identified for each of the individual 12 leads, or combined to derive features of the overall ECG.

Fig. 3 illustrates a prototypical ECG wave. It generally comprises a P wave, a QRS wave complex, a T-wave, and a U wave. The features that the typical system uses can be dependent on specific characteristics of that system but will include intervals, segments and complexes, including amplitude, direction, and duration of the waves and their morphological aspects.

Table I below lists a number of exemplary features and feature information that are generated in order to enable the subsequent machine ECG interpretation.

TABLE

Group Label Features

• Pre-RR interval

• Post-RR interval

RR intervals • Average RR-interval Time duration • Local avg. RR-interval between two consecutive R waves of the ECG

• QRS duration (QRS offset - QRS onset) of lead A [B]

Heart-beat • T-wave duration (T-wave offset - QRS Intervals A [B] offset) of lead

A [B]

• P wave flag for lead A [B]

• ECG morphology between QRS onset Morphology and QRS offset

IA [IB] • ECG morphology between QRS offset and T-wave offset

• Normalized ECG morphology between Morphology QRS onset and QRS offset

2A [2B] • Normalized ECG morphology between

QRS offset and T-wave offset

• ECG morphology between FP-50ms to Morphology FP+100ms]

3A [3B] • ECG morphology between FP+150ms to

FP+500ms

• Normalized ECG morphology between Morphology FP-50ms to FP+100ms

4A [4B] • Normalized ECG morphology between

FP+150ms to FP+500ms

Fig. 4 illustrates a typical interface 250 for an ECG report editor running on workstation 124. In the specific example, it displays a window 252 that provides general information on the patient "R, Joseph." It has another window 254 that provides a workspace for creating the final ECG report. Typically, these ECG reports are a set of specific codes, displayed in window 256 that correspond to different conditions.

Fig. 5 illustrates an exemplary draft report 258 as generated by a machine interpretation. It comprises a series of lines that correspond to different conditions. Typically, they are ordered in their relative importance. The physician, at the workstation, will review the specific ECG wave data and revise the draft report generated from the machine-generated interpretation. These series of statements 01-07 (280), providing specific diagnoses, will then be edited in order to generate the final report 126 that is stored in the patient database 130.

Fig. 6 illustrates a process for feature-leveling editing according to the present invention. Specifically, as in the past, the digital ECG data including the interpretation, are received at the workstation 124 in step 210 from the host 130. The ECG data including the interpretations are then displayed in step 212 to the cardiologist or other user/reader 122 on the workstation 124 using interfaces as illustrated in Figs. 4 and 5.

According to the invention, then in step 214, the physician/cardiologist reviews the actual ECG wave data and determines whether or not the interpretations of the report are useful. Most often, the interpretations will be largely correct and only require minor editing. In this case, the physician will simply edit the text statements in step 216 and then store the final ECG report in step 218 in the database 130.

However, in the situation where the interpretation is inaccurate, according to the invention, the workstation 124 displays the ECG data along with the calculated and otherwise determined features in step 230. The inventive feature-based editing permits the cardiologist or other reader/user to review and edit at the intermediate step of the machine-generated ECG interpretation. This is accomplished with a user interface that permits the display, review and editing of the measurements and features derived by the computer analysis (feature-based editing), along with the capability of resubmitting these features and measurements to the interpretive algorithms to generate a new list of interpretive statements. Often, the features are as listed in Table I. According to the invention, the cardiologist or other user edits the specific values for the features. For example, one example may be the length of the QRS complex - in the situation where the interval was improperly measured by the algorithm. The physician manually edits feature or features in step 232. Then, the workstation 124 or host system 130 runs a host-based interpretation based on the cardiologist-edited features and the remaining calculated features in step 234. In one embodiment, the interpretation algorithm is a system licensed by the Glasgow Royal Infirmary. This generates a new ECG draft report, which the, physician edits in step 216 for submission in step 218.

According to another implementation, the system also allows the option of selecting one or more specific pulses in the ECG wave data for analysis. As mentioned previously, features are typically pulled or calculated from a selected ECG wave from one typical cardiac cycle out of the usually very long wave data set that the machine acquires. Other systems calculated features base on an average ECG wave derived a series of waves to form the basis of the interpretation. Unfortunately, these processes do not always create the best basis for the analysis. Also, the cardiologist may want to force analysis of some other, atypical, for example, wave. In one embodiment, as part of the feature selection process, the user/cardiologist is also provided with an opportunity to select a specific wave for analysis of a specific cardiac cycle. This addresses the problem of the system working from an atypical beat, sometimes referred to as a funny looking beat (FLB) or a beat initiated from pacemaker. On the other hand, the user can focus analysis on unusual beats such as beats from premature ventricular contractions (PVC), which are typically infrequent and will not be analyzed by conventional systems.

Example 1: The duration of one portion of the ECG wave, called the QRS complex, is used to determine if there is an interruption in the flow of electricity in the heart's conduction system. The QRS duration is a feature that directly leads to specific diagnoses on the ECG report. If the QRS duration feature is calculated to be greater than 120 milliseconds (and the QRS configuration matches a certain pattern), the condition is referred to as Left Bundle Branch Block, or "LBBB." This means that the electricity is not conducting properly through the Left Bundle of the conducting system. In the presence of LBBB on the ECG report, it is not possible to make any definitive, statements about other clinical conditions such as anterior myocardial infarction ("AMI") or left ventricular hypertrophy ("LVH").

It is not uncommon for a previous ECG report for a patient to show a QRS duration of 118 5 milliseconds (below the cutoff for LBBB), along with an AMI and LVH. When the next ECG on that patient is measured to have a QRS duration of 120 milliseconds or greater, the reading will come out LBBB only.

The cardiologist reviewing the ECG may determine that the two ECGs are nearly identical, and that the pathology in the heart has not changed. On a conventional ECG editing system, for i o example, the cardiologist would have to change the QRS duration, delete the LBBB line, and add the LVH and AMI lines, resulting in excess effort and a time expenditure.

Using an embodiment of the present invention, it is only necessary to change the QRS duration to 118 milliseconds as in step 232 of Fig. 6. The interpretation is then regenerated using the specified QRS duration that would reflect the absence of LBBB, and the presence of AMI and 15 LVH in step 234.

Example 2: P- waves are very tiny, and hard for the computer to distinguish on an ECG, especially if the patient is moving or other noise is present. The computer might also incorrectly think that P-waves are present, getting confused by the presence of noise. In this latter case, the reading might be "Sinus rhythm" and "1st degree AV block." A measurement of the PR Interval 20 will be reported (the time duration between the occurrence of the P-wave and the occurrence of the QRS complex).

In a statement-based editing environment, the cardiologist might change the reading of "sinus rhythm" to "atrial fibrillation." If the reading is left this way, which is very common, there is a conflict. "1st degree AV block" means that the PR interval is longer than 200 milliseconds, but 25 there is no PR interval if the is no P-wave.

The correct next step is for the cardiologist with convention editing systems is to remove measurement of the PR interval, and delete the line that says "1st degree AV block." Here the cardiologist is performing a rather clerical function in the statement-based editing environment.

In an embodiment of the present invention, a feature-based editing environment is provided 3 o that enables the removal of feature data relating to the presence of the P-waves, specifically that the P-waves were found. Then, when the interpretation is re-run on the host, the reading will now automatically be changed to "atrial fibrillation," the PR interval will be removed, and the statement "1st degree AV Block" will be removed. As a result, the cardiologist has been able to interact as a cardiologist, not as a clerk. Inconsistencies and mutually exclusive findings have been avoided in the reading.

The standard clinical practice in most hospitals in the United States and elsewhere is for ECGs to be collected by technicians in the ECG department and presented to the responsible cardiologists to be interpreted. These cardiologists are often tasked with reviewing large numbers of ECGs from many different patients. But to ease this task, it is common that the ECGs will have already been read by a computer algorithm, and the computer's interpretation (a list of interpretive statements) will only need to be reviewed ("over-read") by the cardiologist and any necessary changes noted. In this common model of "batch reading," the cardiologist is often confronted with over- reading a large number of electrocardiograms in one sitting. And, the cardiologist will encounter some degree of mental fatigue after reading for an extended sitting.

In conventional management systems, ECGs are presented for reading based on the patient name or based on the time that the ECGs were recorded. The ECG management system is not able to sort the ECGs in a way that is useful to the cardiologists or facilitate their work.

The present invention is also directed to a system that allows for the prioritization of ECGs. This can be performed by the ECG management system and/or at the instruction .of the cardiologist or other reader. In a current implementation, the system will allow for the sorting of the ECGs so that the more complex interpretations are presented first, when the reader is not suffering from fatigue, saving the simpler readings for later in the session as fatigue might begin to become a factor.

There are a number of potential ways of charactering the complexity of reading ECG data for a given patient. ECGs for a patient are examined and read as a group since the patient often has more than one ECG taken between the last reading session and the current one. In contrast, the simplest over-reading situation is the one where there is only one ECG to read for the patient. The more ECGs that have accumulated for a patient and that need to be read, the more complex the reading task becomes, since as ECGs have to be compared to each other, and this comparison is time consuming. Complexity also increases in direct proportion to the number of interpretive statements on each machine-generated ECG interpretation. Finally, certain diagnoses require more careful review than others do, and these diagnoses can be scored based on the differences in difficulty.

Fig. 7 illustrates a method for presenting electrocardiogram (ECG) data to a reader. Specifically, as in the past, the digital ECG data including the interpretations, typically from the ECG cart, are received at the database and host system 130 for many patients. Then the cardiologists/readers will request a job assignment in step 1210.

The process of requesting the job assignment can be relatively simple or complex depending on the type of system used. In some systems, the reader requests a job assignment simply by accessing a file that has the batch of ECGs that are pending be read. In other examples, the database and host system 130 compiles the batches of ECGs from the different patients and then distributes them among the cardiologists/readers that are working on batch over-reads.

Typically, this distribution of the patients among the cardiologists is based upon which individuals are patients of the various cardiologists. In other examples, the system will assign the ECGs to be read among the various cardiologists to achieve an even workload distribution. In any case, the ECG data for the different patients are then compiled by the database system 130 or by the workstation 1122 accessing the pending jobs based on the cardiologist request in step 1230.

In step 1212, the cardiologist or other reader sets the sorting criteria according to the invention. In the current embodiment, the reader sets sorting criteria that are based on the complexity of the ECG data to be read. Specifically, the reader 122 will often request that the batch of ECG data from the different patients be sorted in decreasing complexity in terms of the process of reading the ECG data from the different patients. In other examples, the reader may present sorting criteria that requests ECG data to be sorted based on increasing complexity.

Then in step 1232, the database or management system sorts the ECG data from the different patients based on the sorting criteria. In one example, where the sorting criteria are based on complexity, the station 122 or database hosting system 130 calculates a complexity score for the ECG data from each of the patients. This complexity score is a metric characterizing the complexity of task of reading the ECG data and generating the report for that patient.

In the preferred embodiment, there are a number of ways of characterizing the complexity of the ECG data for a given patient. In one example, the number of previous ECGs that exist for each of the different patients is used as a metric. Typically, the complexity of reading ECG data increases as the number of other ECG data sets from that patient increases since more ECG data sets must be compared to each other in order to determine how the patient's health is changing. In other examples, the complexity of the ECG report is characterized based on the number of machine-generated interpretive statements present in the ECG data. In still other examples, each of the different potential diagnoses for all of the patients is given a score by a reviewing physician, based on the assessment of the complexity of the different diagnoses. Then, the ECG data for the different patients are sorted based upon that complexity list, and specifically the machine-generated interpretation of the ECG data. Then in step 1234, the ECG data of the patients is presented to the reader in the order generated from the sorting in step 1234.

The reader 122 then reviews the ECG data from the management system database 130 and drafts the ECG reports for the different patients in step 1214. The final interpreted ECG reports 5 from the reader are then stored in the database management system 130 in step 1236.

According to another embodiment, at the time of receipt at the management database host system 130, a complexity scores is assigned to the ECG data, usually based on the result of the machine-generated interpretation. These complexity scores are made available to the cardiologists/readers 122 allowing the readers to thereby sort their reports during a batch reading, o for example, based on this complexity score.

In other examples, the management systems database 130 uses the complexity scores to affect load distribution across a number of cardiologists or other readers working at a hospital, for example. This will allow the system, in some examples, to assign the more difficult reading tasks to the more experienced cardiologists. In other examples, the management system/database 130 5 compares the complexity scores of the ECG data and then creates batches of ECG data to be read by the cardiologist such that all cardiologists have a similar mix of difficult and easy ECG data over-reading tasks.

The following illustrates specific approaches for generating the complexity score.

1. (Number of ECGs x 10) + average number of interpretive statements per ECG — this o formula takes into account the number of ECGs to be read for the patient and the complexity of the expected diagnoses.

2. Sum of diagnostic complexity scores—each interpretive statement is assigned a complexity score between 0 to 4, easy to hard respectively. The score for a given ECG is equal to the sum of the complexity scores of each interpretive statement that has been provided by the 5 computer analysis of the machine-generated interpretation; the complexity score for the patient is equal to the sum of the complexity scores for each of the ECGs to be over-read.

Example: The ECG reading workstation 124 presents a list of ECGs to be reviewed to the over-reading cardiologist or other user 122. The order in which these are presented is based on the ECG reading complexity score, presented in decreasing complexity order in one embodiment. By 0 simply requesting "Next Patient," the patient with the highest complexity score is selected to be reviewed next. This assures that the more difficult interpretive tasks are presented at the beginning of the over-reading session while the cardiologist is still fresh, while the simpler interpretive tasks are saved for the end of the reading session when fatigue may be a significant factor. In the typically hospital, ECGs are taken at carts throughout the hospital or institution and received at a records storage location for filing and possibly over-reading by staff cardiologists. In this process, it is important that the ECGs are associated with the proper patient file. Unfortunately, ECGs are often taken in situations where patient names or identifiers have not been provided to the 5 ECG cart, usually from a central computer facility. This means that the nurse or technician, who operates the ECG cart and does the ECG acquisition, has to enter the patient's demographic information (name, medical record number, etc.). This leads to several possibilities for errors, including, but not limited to: 1) the identifiers are incorrect or incomplete; 2) the identifiers are missing; and/or 3) the identifiers from the previous patient to have an ECG are inadvertently used. o When the identifiers are incorrect or incomplete, it is usually possible to reconstruct the correct information using searches of the hospital's patient database. Whereas, when the identifiers are missing or the identifiers from the previous patient are used, traditional information technology is unlikely to help resolve the problem.

When the identifiers are missing, it would be helpful to be able to find another ECG that 5 looks very similar to the one with the missing identifiers. ECGs taken around the same time could be searched. For example, it would be helpful to know that an unlabeled ECG from the emergency room is a close match to an ECG taken on the Coronary Care Unit one hour later. The paper chart can be reviewed, where a paper copy of the ECG may be hand-labeled (but the identifier had not been entered into the computer); this allows complete resolution of the error. o Similarly, when the identifiers from the previous patient are used, it is sometimes apparent that an ECG labeled as belonging to one patient does not match one recorded for that patient before or after the ECG in question. An ability to confirm the difference automatically assists the technicians, who would then consider the ECG in question to not have a valid identifier, and would undertake a corrective procedure. 5 The present invention can also function as part of a comprehensive ECG management

System to provide a computer-assisted Quality Assurance step in an ECG management system. It involves comparing ECG data for the same and/or different patients to ensure the accuracy of the ECG patient data. This step is preferably performed prior to releasing ECGs to the cardiologists for interpretation and placement in the patient's permanent records. 0 Fig. 8 illustrates a process for ECG quality assurance according to the present invention.

In more detail, the ECG data for different patients are received in step 2210 at the management system 130. Typically, this is a central location typically tasked with filing the ECGs and also distributing the ECGs to cardiologist for batch over-reading. The ECGs will typically be generated throughout the hospital, in such varied environments as the emergency room and patient examining rooms.

This ECG data received at the management system 130 include the ECG wave data and patient identification information. The patient identification information is useful for filing the 5 ECG data with the proper patient's file.

According to the invention, the management system 130 performs quality assurance testing. Reasons that an ECG might fail this test include:

1. Signal quality errors found during the initial interpretation step;

2. Demographic information such as age or gender do not match those on the previous o ECGs;

3. The patient name does not match the name on the previous ECGs;

4. The ECG is substantially different from the previous ECG for that patient.

This last case suggests the possibility that the ECG might be from the wrong patient (due to failure to reset the patient name in the ECG cart between patients). In order to distinguish an ECG 5 from a totally different patient from the situation where a patient's ECG has legitimately changed from its previous state, a metric is required to determine the degree of similarity between two ECGs.

According to the invention, the database management system 130 compares each of the ECGs to prior ECGs of the named patient in step 2212. Specifically, when the ECGs are originally o taken at the cart, typically the nurse or technician enters the patient name or more typically a patient number or the cart receives the information from a centralized system such as the management system 130. This patient number travels with the ECG data to the database as a mechanism for ensuring that the ECGs are put in the correct patient's file. Specifically, in step 2214, a similarity between the new ECGs and prior ECGs for the same named patient is assessed. 5 Generally, the objective is to bias the comparison to generating false negatives. That is, the system should tend to indicate that the named patient on the ECG is or could be wrong even if there is a somewhat strong similarity to previous ECGs from the same patient.

There are several candidate algorithms to assist with computing similarities. Some factors that can be used are based on the actual ECG waveforms (the electrical deflections representing the 0 electrical activity in the heart), and others are based on the interpretation of the waveforms. During the course of a heart attack, for example, the waveform appearance may change considerably from day-to-day, but there are several factors that would remain more constant and therefore more useable for a Similarity Score.

The exemplary algorithms for similarity include:

1. Root Mean Square (RMS) differences between the median beats in each lead of the 5 two ECGs to be compared;

2. Root Mean Square (RMS) differences between the median beats in each lead of the two ECGs to be compared, but restricted to the leading portion of the beats such as the first 40 milliseconds of each beat. This approach looks at the initial electrical vector of each beat, and is most likely to be the same in two ECGs from the same patient, despite ST segment changes that i o occur later in the beat.

3. Root Mean Square (RMS) differences between the median beats in each lead of the two ECGs to be compared, but with additional weighted factors to increase the similarity score for ECGs taken at close to the same time, or in the same part of the hospital, and with increased uncertainty in the presence of intermittent ventricular pacing or rate-related bundle branch block.

15 Often, this may be a first ECG for the specific named patient. Thus, there is no prior ECG to generate a comparison. More often, the patient name/number may be invalid or uses a "John Doe" identifier. In still other cases, demographic information in the ECG data may not match data for the named patient. In each of theses situations, there is possibility of or indication of error. As a result, in step 2216, the incoming ECGs are also compared to ECGs from different named

20 patients using the exemplary algorithms describe above, for example. Typically, these ECG against which the comparisons are made are ECGs that have been received recently at the database/management system 130.

The relevance of this comparison to ECGs of potentially different patients concerns the fact that it is common, especially in the emergency room environment, that the ECG machines will be 25 moved quickly between patients. Especially in an emergency situation, it may not be that the ECG patient data are updated. In other examples, a "John Doe" name is used where the patient's name is unknown. Comparison of the ECGs to recent ECGs allows for these ECGs to be potentially categorized with the correct named patient or the same "John Doe" patient. Generally, this test is structured to generated false positives.

30 In step 2220, a determination is made whether each of the comparisons in steps 212 or 216 suggest error.

In step 2224, the ECG is flagged for review if either of the comparisons suggests possible error. In step 2226, the results of the flagged ECG comparison is presented to a technician or cardiologist. There, the technician or cardiologist will confirm whether there is in fact similarity. It there is a suggestion that the ECG has an incorrectly named patient or a previous ECG has an incorrectly named patient, then a review is begun in step 2228, which can include contacting the individuals responsible for collecting the ECGs to resolve the apparent discrepancy. Finally, if the comparison suggests no error in step 220, or after research as to whether or not the ECG is correct, the ECG is filed as normally in step 222, either for the named patient or for the corrected patient name.

While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.

Claims

What is claimed is:

1. A method for generating an electrocardiogram (ECG) report, the method comprising: receiving ECG data at a physician workstation;

5 enabling a user to specify values for features of the ECG data; generating an interpretation of the ECG data based on the values of the features specified by the user; and storing the interpretation after possible editing in a patient database.

2. A method as claimed in claim 1, wherein the ECG data includes ECG wave data and a o ECG machine interpretation of the ECG wave data.

3. A method as claimed in claim 2, further comprising generating the ECG wave data at a cart and the ECG machine interpretation at a host system.

4. A method as claimed in claim 1, wherein the user selects whether to edit the machine interpretation or specify values for the features.

5 . 5. A method as claimed in claim 1, wherein the step of enabling feature value specification comprises presenting machine generated values for features of the ECG wave data and enabling the user to specify different values for at least one of the features.

6. A method as claimed in claim 5, wherein the step of generating the interpretation comprises generating a re-interpretation of the ECG data using the specified values for the o features and the machine-generated values for other features.

7. A system for generating an electrocardiogram (ECG) report, the system comprising: a workstation that receives ECG data and enables specification of values for features of the ECG data; an interpretation system for evaluating of the ECG data based on the values of the 5 features specified by a user and generating an interpretation for storage in a patient database.

8. A system as claimed in claim 7, wherein the ECG data includes ECG wave data and a ECG machine interpretation of the ECG wave data.

9. A system as claimed in claim 8, further comprising an ECG cart for generating the ECG 0 wave data and a host system for generating the ECG machine interpretation. 10. A system as claimed in claim 7, wherein the workstation allows the user to select whether to edit a machine interpretation for specify values for the features.

11. A system as claimed in claim 7, wherein the workstation presents machine generated values for features of the ECG wave data and enables the user to specify different values for

5 at least one of the features.

12. A system as claimed in claim 11, wherein the interpretation system generates an interpretation of the ECG data using the specified values for the features and the machine generated values for other features.

13. A computer software product for generating an electrocardiogram (ECG) report, the o product comprising a computer-readable medium in which program instructions are stored, which instructions, when read by a computer, cause the computer to receive ECG data at a physician workstation, enable a user to specify values for features of the ECG data, generate an interpretation of the ECG data based on the values of the features specified by the user, and store the interpretation after possible editing in a patient database.

5 14. A product as claimed in claim 13, wherein the ECG data includes ECG wave data and a

ECG machine interpretation of the ECG wave data.

15. A product as claimed in claim 14, wherein the instructions cause the computer to generate the ECG machine interpretation at a host system.

16. A product as claimed in claim 13, wherein the instructions cause the computer to enable o the user to select whether to edit the machine interpretation or specify values for the features.

17. A product as claimed in claim 13, wherein the instructions cause the computer to enable feature value specification by presenting machine generated values for features of the ECG wave data and enabling the user to specify different values for at least one of the features.

5 18. A product as claimed in claim 5, wherein the instructions cause the computer to generate the interpretation by generating a re-interpretation of the ECG data using the specified values for the features and the machine-generated values for other features.

19. A method for presenting electrocardiogram (ECG) data to a reader, the method comprising: o scoring ECG data from different patients based on sorting criteria; sorting the ECG data from the different patients based on the sorting criteria; and a reader reviewing the ECG data from the different patients in an order determined by the sorting.

20. A method as claimed in claim 19, further comprising the reader generating ECG reports 5 for the different patients from the ECG data.

21. A method as claimed in claim 19, wherein the step of scoring the ECG data comprises comparing the ECG data from the different patients with respect to the sorting criteria.

22 A method as claimed in claim 19, wherein the sorting criteria includes a metric characterizing a complexity of ECG data.

0 23. A method as claimed in claim 19, wherein the sorting criteria includes a metric characterizing a number of previous ECGs that exist for each of the different patients.

24. A method as claimed in claim 19, wherein the step of scoring the ECG data comprises comparing machine-generated interpretations in the ECG data to list of diagnoses representing the sorting criteria.

5 25. A method as claimed in claim 24, further comprising scoring the list of diagnoses based on a relative complexity of each diagnosis.

26. A method as claimed in claim 19, wherein the sorting criteria is to review more complex ECG data first.

27. A method as claimed in claim 19, further comprising compiling the ECG data from the o different patients to be read by a reader requesting a job assignment.

28. A method for presenting electrocardiogram (ECG) data to readers, the method comprising: compiling ECG data from different patients for presentation to a reader for generation of

ECG reports for the different patients; 5 analyzing the ECG data from the different patients and sorting the ECG data based on a sorting criteria; and presenting the ECG data from the different patients in an order determined by the sorting. 29. A system for presenting electrocardiogram (ECG) data to a reader, the system comprising: a host system for scoring ECG data from different patients based on sorting criteria and sorting the ECG data from the different patients based on the sorting criteria; and 5 a workstation enabling a reader to review the ECG data from the different patients in an order determined by the sorting.

30. A method for verifying electrocardiogram (ECG) data in a management system, the method comprising: l o comparing current ECG data to previous ECG data; determining whether similarities or differences between the current ECG data and the previous ECG data suggest error or correction in patient identification; and indicating review when the similarities or differences suggest error or correction.

31. A method as claimed in claim 30, wherein the step of comparing current ECG data to 15 previous ECG data comprises comparing patient demographic data for the current ECG data and previous ECG data.

33. A method as claimed in claim 30, wherein the step of comparing current ECG data to previous ECG data comprises assessing differences in the ECG wave data for the current ECG data to previous ECG data.

20 33. A method as claimed in claim 32, wherein the differences are determined with respect to leading portions of beats in the ECG wave data for the current ECG data to previous ECG data.

34. A method as claimed in claim 30, wherein the step of determining whether similarities or differences exist comprises determining if the current ECG data are similar to previous

25 ECG data for the same patient.

35. A method as claimed in claim 30, wherein the step of determining whether similarities or differences exist comprises determining if the current ECG data are similar to previous ECG data for a different named patient.

36. A system for verifying electrocardiogram (ECG) data, the system comprising: 30 a patient records database for storing ECG data for patients; and a management system for comparing current ECG data to previous ECG data from the patient records database and determining whether similarities or differences between current ECG data and previous ECG data suggest error in patient identification.