US 7,654,965 B2Grant
Method and system for processing electrocardiograms
Issue Date:2010-02-02
•12 Claims
•10 Drawing Sheets
Abstract
In a method and system for processing an electrocardiogram (ECG), digital ECG data are received. The digital ECG data evinces a plurality of a patient's heartbeats detected during an ECG. Digital annotation data are generated representing marking to be shown on an ECG tracing of the plurality of heartbeats. An annotated ECG tracing image is produced using the digital ECG data and the digital annotation data.
Metadata
Assignee
- eResearchTechnology, Inc.
Inventor
- Joel Morganroth
Application Information
Application Number:US 11/423,255
Filing Date:2006-06-09
Priority Date:2001-11-20
Art Unit:3762
Classifications
IPC:
A61B5/0452
Patent Drawings (10 sheets)
Description
Cross-Reference to Related Application
[0001] This application is a continuation-in-part of, and claims priority to, U.S. patent application Ser. No. 10/738,427 filed Dec. 17, 2003, which is a continuation-in-part of, and claims priority to, U.S. patent application Ser. No. 10/045,843, filed Jan. 10, 2002, to Joel Morganroth, entitled “Method and System for Processing Electrocardiograms”, now U.S. Pat. No. 6,708,057, the entirety of which are hereby incorporated by reference herein, which claims priority to U.S. Provisional Patent Application No. 60/331,839, filed Nov. 20, 2001.
Field of the Invention
[0002] This invention relates to methods and systems for processing electrocardiograms, and more particularly to methods and systems for collecting and interpreting electrocardiograms developed during clinical trials.
Background of the Invention
[0003] Over the past several years, the United States Food and Drug Administration (FDA) and the United Kingdom regulatory authority (CPMP) have recommended that all new drugs have electrocardiogram (ECG) testing to determine any effects of the new agent on humans, particularly the effects on the QTc interval of a patient's ECG. Several companies support these clinical trials by serving as centralized collection and interpretation points or laboratories for the handling, analysis and data reporting of these ECGs (hereinafter referred to as “processing companies”). Most processing companies rely on ECG machines programmed with algorithms for measuring the important ECG intervals (such as the heart rate, PR, QRS, QT and QTc durations), and a cardiologist later reviews the intervals and interprets the ECG's morphology. Reliance on ECG machines for determining interval duration leads to inconsistent and potentially less accurate results, intrinsically as well as between different machine programs. Further, ECG machines have difficulty identifying low frequency waves, leading to false positive and false negative readings, especially with respect to the QT intervals.
[0004] For several years, the assignee of the present application—eResearchTechnology, Inc. (eRT) of Philadelphia, Pa.—has been in the business of supporting clinical drug trials by providing centralized collection and interpretation of ECG services. The assignee, however, does not rely upon ECG machine measurements in measuring ECG intervals, but instead uses manual measurement techniques. This practice, although very accurate and reliable, further complicates the already cumbersome and paper-intensive process of generating regulatory-grade research data from ECG tracings for a sponsor of a clinical trial (i.e., data that are supported by an audit trail and are 100% verifiable by a government agency such as the FDA). An overview of this process is provided hereafter.
[0005] A sponsor, such as a pharmaceutical company, conducts clinical trials that typically include patients throughout the world. Each patient in a trial normally undergoes a series of ECG tests conducted during a series of visits to a study site (e.g., a doctor's office or hospital). The visits generally must occur during time periods specified by the sponsor in the research protocol. At several of these visits, an ECG machine is used to perform an ECG test and an ECG tracing is produced. The site collects ECG tracings from several patients in the clinical trial and forwards the ECG tracings to eRT, along with demographic data associated with each ECG. The demographic data usually include information such as a patient identifier, a study site identifier, the date of the test, the time of the test, a clinical trial identifier, the drug being tested, and the visit number for the patient (e.g., baseline, first visit, second visit, etc.). The demographic data are generally recorded on a label attached to the ECG reading. Alternatively, the demographic data and the ECG tracing are sent to eRT via electronic communications through a telephone network. In this alternative, the tracing and demographic data are then printed by eRT for later processing.
[0006] Once an ECG tracing is received, a source processing department manually enters the demographic information into a computer database via a computer and through a standard data entry screen. The screen is generic for all trials handled by eRT and, therefore, often includes data entry windows or areas that are extraneous and not pertinent to a particular trial. After the data are saved to a database, it must be confirmed that there have been no data entry mistakes. If a mistake is noted on the demographic information on the label, for example the patient's age was entered incorrectly on the label, or if a piece of demographic information is missing from the label, then a regulatory grade query must be conducted and documented. A query is forwarded to the query resolution department in the form of a paper copy of the ECG along with a note indicating the required query. A member of the query resolution department then telephones a study site or a site investigator associated with the study site to try to resolve any discrepancy or obtain any missing information from the demographic data. Telephone logs are maintained, and corrections are made directly onto the source document (the combined ECG and demographic label), initialed and dated. While the query resolution team conducts queries, the source document must be kept within the interpretation process so that the process can continue in parallel with the query resolution process; hence, copies of the source document are provided to the query resolution team.
[0007] A file associated with the ECG tracing is then forwarded to a diagnostic specialist. The diagnostic specialist verifies the analysis requirements of the clinical trial from a protocol book. The protocol book includes the analysis requirements and any updates to these requirements for each clinical trial supported by eRT. Analysis requirements typically include information identifying how many heartbeats must be measured for QT intervals per individual ECG tracing and permissible time periods when patient visits may occur.
[0008] The diagnostic specialist typically identifies the heartbeats that are to be measured with pen marks placed on each individual ECG tracing. The ECG tracing is then mounted on a magnetic board, and intervals are measured. A pointer device is placed on top of the ECG tracing. A first edge of an interval is visually identified using the assistance of a magnifying glass, and the pointer device is aligned over the first edge. A button is then depressed on the device, and a data point is registered with a dedicated, stand-alone computer connected to the pointer device. A second edge of the interval being measured is then identified in a like manner, and a second data point is registered. This process is typically repeated for PR, QRS, RR, QTc and QT intervals in order to compile separate interval duration measurements (IDMs) associated with at least three heartbeats. The interval data are then saved to the stand-alone computer, and the interval data are then transferred to a central computer server. A work sheet identifying a calculated mean of the measurement data for each interval is then printed and attached to the ECG tracing in its file. The diagnostic specialist then sorts worksheets and ECG tracings for the assigned cardiologist's review. If an ECG tracing is somehow separated from its file, the ECG tracing and worksheet are placed in a “return to file” bin. Any ECG tracings and worksheets in the “return to file” bin are then matched with the appropriate file by a member of the source processing team.
[0009] Once an ECG and its associated worksheet are placed in the correct file, the diagnostic specialist forwards the file to the assigned cardiologist for review. The cardiologist reviews the ECG and completes the worksheet. The cardiologist indicates his or her medical interpretation of the measured intervals and the ECG morphology on the worksheet. Some studies require the cardiologists to also review ECG tracings from prior patient visits and a baseline visit along with the current ECG tracing being evaluated. Satisfying this preference requires the physical retrieval of files from a filing system and the concomitant local storage of hardcopy files throughout the duration of a clinical trial.
[0010] Some of the ECG tracings are then forwarded to the quality control department based upon predetermined quality control criteria. For example, every ECG tracing associated with a worksheet that indicates that an abnormal interval is present is sent to quality control for review. These files are identified for the quality control department with POST-IT notes, produced by 3M Corp., affixed to each file. Also, 5% of all other ECG tracings are pulled for quality control. Additionally, a member of the quality control team telephones a sponsor, or a member of the source processing team faxes a sponsor, when certain criteria are met, e.g., a measured QT interval for an individual ECG tracing falls within a predefined dangerous range. After an ECG has been quality controlled or passed over for quality control, a member of the source processing group faxes a preliminary reporting of the cardiologist's evaluation to the study site and/or the sponsor, as dictated by the trial protocol. The source processing department then sorts the worksheets and ECG tracings for data entry. The cardiologist's comments and analysis from each worksheet are entered into a database by a source processing member. Source processing then prints a final report and clips it to the worksheet and ECG tracing. The query resolution department then quality controls the data entry on the final report. Next, source processing photocopies the final report for the site and the sponsor. The final report is then sent to the site or sponsor by Federal Express or other courier according to the protocol for the clinical trial. This reporting is typically accomplished approximately ten days after the initial facsimile reporting. Source processing then files the patient's file on-site. All of the files associated with a clinical trial are archived at the end of a clinical trial.
[0011] It should be apparent from the above description that the current collection, interpretation and reporting process is very paper and task intensive. While the process ultimately produces regulatory-grade research data, there remains a need for an improved method and system that increases the efficiency and flexibility of the collection, interpretation and reporting process while generating regulatory-grade research data that is supported by an audit trail.
Summary of the Invention
[0012] In a method and system for processing an electrocardiogram (ECG), digital ECG data are received. The digital ECG data evince a plurality of a patient's heartbeats detected during an ECG. Digital annotation data are generated representing markings to be shown on an ECG tracing of the plurality of heartbeats. An annotated ECG tracing image is produced using the digital ECG data and the digital annotation data.
[0013] The above and other features of the present invention will be better understood from the following detailed description of the preferred embodiments of the invention that is provided in connection with the accompanying drawings.
Brief Description of the Drawings
[0014] The accompanying drawings illustrate preferred embodiments of the invention as well as other information pertinent to the disclosure, in which:
[0015] FIG. 1 is a stylized overview of a system of interconnected computer networks;
[0016] FIG. 2 is a block diagram illustrating exemplary functional software modules of the present invention;
[0017] FIG. 3 is a flow diagram illustrating an exemplary Trial Setup module;
[0018] FIG. 4 is a flow diagram illustrating an exemplary Query Resolution module;
[0019] FIG. 5 is a flow diagram illustrating an exemplary interval duration measurement (IDM) module;
[0020] FIG. 6 is a flow diagram illustrating an exemplary Cardiologist Evaluation module.
[0021] FIG. 7 is an example of an exemplary cardiologist graphical user interface;
[0022] FIG. 8 is an example of an annotated ECG image; and
[0023] FIG. 8A illustrates the ECG image of FIG. 8 without annotation.
Detailed Description of the Invention
[0024] The Internet is a worldwide system of computer networks—a network of networks in which a user at one computer can obtain information from any other computer and communicate with users of other computers. The most widely used part of the Internet is the World Wide Web (often-abbreviated “WWW” or called “the Web”). One of the most outstanding features of the Web is its use of hypertext, which is a method of cross-referencing. In most Web sites, certain words or phrases appear in text of a different color than the surrounding text. This text is often also underlined. Sometimes, there are buttons, images or portions of images that are “clickable.” Using the Web provides access to millions of pages of information. Web “surfing” is done with a Web browser; the most popular of which presently are Netscape Navigator and Microsoft Internet Explorer. The appearance of a particular website may vary slightly depending on the particular browser used. Recent versions of browsers have “plug-ins,” which provide animation, virtual reality, sound and music.
[0025] FIG. 1 shows a system 100 of interconnected computer system networks 102. Each computer system network 102 contains a corresponding local computer processor unit 104, which is coupled to a corresponding local data storage unit 106, and local network user terminals 108. A computer system network 102 may be a local area network (LAN) or part of a wide area network (WAN), for example. The local computer processor units 104 are selectively coupled to a plurality of user devices 110 through Internet 114 described above. Each of the plurality of user devices 110 and local user terminals 108 may have various devices connected to their local computer systems, such as scanners, barcode readers, printers, finger print scanners, mouse devices and other interface devices 112.
[0026] A user device 110, programmed with a Web browser or other software, locates and selects (such as by clicking with a mouse device) a particular Web page, the content of which is located on the local data storage unit 106 of a computer system network 102, in order to access the content of the Web page and the services provided therethrough. The Web page may contain links to other computer systems and other Web pages.
[0027] The user device 110 may be a microprocessor-based computer terminal, a pager that can communicate through the Internet using the Internet Protocol (IP), a Kiosk with Internet access, a connected personal digital assistant or PDA (e.g., a PALM device manufactured by Palm, Inc.) or other device capable of interactive network communications, such as an electronic personal planner. User device 110 may also be a wireless device, such as a hand-held unit (e.g., cellular telephone) that connects to and communicates through the Internet using the wireless access protocol (WAP).
[0028] The system and method of the present invention may be implemented by utilizing at least a part of the system 100 described above in connection with FIG. 1 . It should be apparent to one of ordinary skill that the system may be incorporated in a LAN, in a WAN, or through an Internet 114 based approach, such as through a hosted or non-hosted application service, or through a combination thereof. The functionality of the method may be programmed and executed by a computer processor unit 104, with necessary data and graphical interface pages as described hereafter stored in and retrieved from a data storage unit 106. A user can access this functionality using a user device 110 or user terminal 108.
[0029] The functionality of the electrocardiogram (ECG) processing system and method are described hereafter with the aid of functional blocks. It should be understood that each functional block may be a program module that directs a computer processor unit 104 and/or terminal 108, 110 to perform specific functions. In one embodiment, this functionality is programmed in a computer processor unit 104 and is accessed via a terminal 108 and 110, either through the Internet 114 or through local computer network 102.
[0030] FIG. 2 illustrates in block form exemplary program modules of the processing system 100. Trial Setup module 200 of FIG. 2 is utilized to set the necessary parameters of each trial that is supported by the system. At 202 of FIG. 3 , the Trial Setup module 200 is accessed using a terminal 108 or 110. Access to this module should be limited to authorized personnel in order to ensure that setup of initial trial parameters and all modifications to established trial parameters are authorized. Access may be restricted in any conventional manner, such as through requiring a username and password to gain access.
[0031] Trial parameters preferably are selected at 204 from a master list of parameters. The trial parameters represent data that must be collected pertaining to each processed ECG tracing within a specific clinical trial and the governing protocol and rules for the clinical trial. Examples of data that may be collected relative to each ECG within a trial include patient identifier, patient ethnicity, patient gender, patient date of birth, trial identifier, visitation date, time and number, study site identifier, etc. (collectively referred to herein as “demographic data”). Graphical interfaces created by the system for interacting with users are customized according to the parameters established at step 204. For example, if particular data are not required for a trial, a data entry graphical interface generated by Data Entry module 400 of the system does not prompt a user to enter that data. The interface is also preferably customized, for example, as to the format of the data to be entered, e.g., the number of characters that a sponsor uses in a trial identifier or patient identifier and the like. This feature increases the speed, efficiency and accuracy of the data entry process and, therefore, facilitates the generation of regulatory grade data.
[0032] The governing protocol for the trial is also established at 204. The governing protocol includes the set of rules established by the trial sponsor (e.g., a pharmaceutical company) for the trial and the processing company and other information that generally pertains to the clinical trial (e.g., sponsor name, title of the trial, target population, etc.). Examples of protocol rules include requirements for site identifiers and patient identifiers (e.g., the format of the identifiers), total number of ECGs required per patient, time and date restrictions or requirements for patient visits and ECG tests, parameters to be measured for each ECG tracing (e.g., kinds of intervals to be measured and number of interval measurements), alarm conditions (e.g., specific measured interval duration ranges that trigger an emergency reporting to the study site and/or sponsor), evaluation conclusions to be provided by a cardiologist, and reporting methods and times, and query methods. Contact information is also provided for the sponsor, each participating study site, and each investigator associated with each participating study site. Contact information may include a person's name, address, telephone number, facsimile number, electronic mail address, preferred contact method, office hours, and the like. The module 200 may also be accessed after the initial setup process in order to modify or update any trial parameters that are changed by the sponsor during the course of a trial.
[0033] Any trial parameters that are not contained in the master list of trial parameters may be created or added at 206 using the module 200. These parameters may also be added to the master list if desired. After the trial parameters are established for a particular trial, the trial setup data are stored to data storage unit 106, e.g. an Oracle standard database, at 208. The clinical trial is essentially registered into the system, and ECGs associated with that trial may be accepted for processing in the system.
[0034] The system may utilize protocol templates in order to further streamline the trial setup process. For example, the system may handle several trials for a single sponsor, with only minor protocol, data and/or process flow differences between respective trials. A template can be established for a trial sponsor in advance and then be retrieved and modified (i.e., customized) for each trial handled for the sponsor, rather than preparing each trial from scratch. Templates provide for the ability to pre-define standards for each facet of the protocol definition and then when ready to apply such template for use by an individual study any and all of the predefined steps may be modified to meet the exact needs of a particular customer and/or trial. The setup process can involve over twenty steps and each step involves a wide number or configurable parameters. As a large number of parameters can be defined once and then applied to many studies, the ability to create and store templates and then retrieve and customize any parameters to meet study unique needs provides for fewer manual steps being taken each time a protocol is defined and thus higher quality.
[0035] In one embodiment, the Trial Setup module 200 preferably includes a self check function which flags problems in a protocol programmed using the Trial Setup module 200. As noted above, in setting up a trial a user can establish rules, such as rules associated with specific age groups. For example, in a pediatric study the protocol may call for flagging ECGs based on exceeding a certain interval measurement level. This threshold value, however, may be vary per age group, e.g., 0-3 months, 3-6 months, etc. If the protocol programmed using the module 200 skips an age range or has overlapping age ranges, the module 200 alerts the user so that this discrepancy can be corrected or brought to the attention of the sponsor. As an alternative embodiment, a protocol may be set up to define pediatric age groups from 0 to 1 year and 2 to 3 years. In this example, the system notifies the user of the gap between the ranges of 1 to 2 years for correction.
[0036] The Trial Setup module 200 also preferably allows for the capture of a visit schedule and a window of plus or minus a number of days by which a patient visit should have occurred and a resulting ECG transmittal should have been received. For example, a sponsor's schedule may require a site visit every three months for a patient, plus or minus one month. If this schedule is not rigidly adhered to, the subject may be excluded from the study, resulting in the loss of valuable data, time and resources. After the first ECG is received, the system dockets expected date ranges for future visits. For example, if ECG musts be taken within three months from the previous ECG plus/minus one month, a system reminder can be set for three months plus two weeks from the previous ECG test. If the ECG is received before the expiration of this period, the reminder is automatically closed out and the system dockets future reminders for future visits based on the date of the ECG received by the system. If no new ECG is received, the system automatically sends an alert to the sponsor and/or the ECG site in order to remind them to contact that subject and/or to inquire into the status of the visit. Additional alerts can also be sent. This automated reminder capability provides for the ability to identify potential issues before a drop dead deadline after which a missed visit cannot be cured. This feature also preferably accounts for different sub-groups within a study that may be subject to different visit schedule criteria. When a subject's visit schedule is available at the trial set up stage, the entire schedule can be docketed along with appropriate reminders.
[0037] In one embodiment, the Trial Set Up module 200 also enables authorized users to define changes to the study parameters/protocol after a study has gone live, i.e., commenced. These changes or amendments can be defined in the system and a comparison report generated by the system comparing the before and after specifics of the parameter/protocol definitions. Once the comparison report has been reviewed and the changes approved by an authorized user, the changes are enabled for production use. Preferably, until the changes are approved they are maintained in the system but are not activated. This functionality may also be accessed through the Sponsor/Study Site Access module 1000 described below.
[0038] Preferably, the parameter/protocol changes are applied in one of two ways selected by the user or automatically by the system. In a first way, the changes are applied only prospectively to new ECGs. This may be utilized when, for example, it is determined that the protocol changes do not significantly affect, if at all, the data that will be accumulated by the study or its effectiveness. In a second way, the changes may be applied retroactively to ECGs that have already been processed, either completely or partially, by the system This option can be selected, for example, when it is determined that the protocol change is important to data quality and study results. An example of such a change would be a protocol change from machine measurements of intervals to manual measurement of intervals. In one embodiment, if the change requires re-queuing of ECGs for measurement, the re-queuing is implemented intelligently to only those ECGs that are affected. For example, a protocol change may modify age ranges for which certain measurement must be taken or for which certain alert conditions are triggered. In this example, only those ECGs that are affected are re-queued (i.e., that fall within the affected age range(s)).
[0039] In an alternative embodiment, the ECGs associated with the protocol of an on-going study can be used with a new or modified protocol. For example, assume a sponsor wants to modify age ranges for a pediatric study, but is still interested in continuing the study using the original study parameters/protocol. In this event, the original protocol is simply copied and then modified to create the new protocol. Analysis of incoming ECGs continues with the old protocol. The ECGs that have been analyzed under the original protocol are re-queued to the appropriate module depending upon the differences between the new and old protocol for analysis, measurement or other operation and any new ECGs are also analyzed using the workflow of the new protocol, in parallel with analysis under the old protocol. The nature of the changes determine to what modules the ECGs must be queued. For example, if only data changes are required (e.g., use of a subjects middle name), the ECGs may only be queued to a data specialist for operation. In this example, the ECGs need not be reevaluated by a cardiologist (if already evaluated). However, if the new protocol requires, for example, that the patient's age be displayed to the cardiologist during evaluation, then the ECGs must be requeued for evaluation.
[0040] ECGs can also be automatically re-queued for measurement, cardiologist review, reporting or other operation in the system based on changes that are made to the data associated with an ECG of a subject after or while the ECG is being processed by the system. For example, if a data correction is made to the age of a subject, and the ECG is processed differently for different age ranges under the governing protocol, the system will automatically re-queue the ECG for processing if the age change moves the ECG into a different age range that has different processing steps or rules (e.g., alarm conditions, measurement criteria, etc.).
[0041] This protocol set up process also preferably allows for the selection between workflows that define the means by which ECGs can be processed. The workflows that can be selected are consistent with FDA regulatory guidance as to how ECGs should be processed. For example, a workflow can be established in compliance with FDA guidance for semi-automatic handling of ECGs, i.e., where machine developed ECG interval measurements are provided, which can then be accepted or rejected by a reviewing cardiologist. A second workflow can be established for manual ECG measurement as described below.
[0042] Workflows defined by the system are preferably embodied as a state machine work flow engine that detects the status of ECG transmittals and determines the next step that is required in the processing cycle. By defining and implementing an intelligent work flow engine, new workflows can be defined by means of end users choosing steps in the trial setup process from Trial Setup module 200. When compared to hardwiring/programming of pre-defined workflows, this flexible workflow engine enables new workflows to be implemented without the need to develop significant changes to the technology platform saves months of programming work. In one embodiment, the workflow engine is implemented using a JAVA script application that looks at data in real time and compares the data to rules for decision making.
[0043] In an exemplary processing system, ECG tracings and related demographic data may be received from a study site in several manners. A hard copy of an ECG tracing may be mailed or otherwise forwarded from a study site to a processing company. Each ECG preferably has affixed thereto a data sticker that includes a barcode. The barcode preferably includes data identifying the trial and the study site. In an exemplary system, these barcodes are pre-printed by the ECG processing company and forwarded to the various study sites that are participating in a specific trial. The data entry sticker also preferably includes sufficient space for handwritten or typed entry of data required by the trial parameters and protocol, such as patient identifier, site identifier, date of birth of the patient, visit number, etc.
[0044] If a hard copy of the ECG tracing is received, the heartbeats associated intervals that are to be analyzed are identified by hand placed marks made on the ECG tracing by an analyst. Each protocol requires a specific number of heartbeats from an ECG tracing to be analyzed. If the analyst needs to identify or reconfirm the total number of intervals to be measured or the type of intervals to be measured, as dictated by the clinical trial, the analyst can access the Trial Information Retrieval module 300 and retrieve this information (entered through Trial Setup module 200) from a data storage unit 106. The analyst then identifies the heartbeats to be analyzed with, for example, a pen mark made above or below each selected heartbeat. Trial Information Retrieval module 300 provides access to the protocol parameters of a trial, as established in Trial Setup module 200. The Trial Information Retrieval module 300 is preferably searchable, thereby relieving the need for examination of a hardcopy protocol book.
[0045] An image of the marked hard copy is then entered into the system with a scanner device 112, and the image is stored in data storage unit 106 as digital ECG data. The barcode is also read with a barcode reader, and the image is correctly associated with the trial and study site identified by the data contained in the barcode. This information is also used to retrieve a graphical data entry interface, with Data Entry module 400, that is customized to the identified trial based upon the parameters entered with the Trial Setup module 200. The graphical data entry interface prompts a user to enter data dictated by these parameters. The data specialists visually reads data identified on the data sticker, and the data specialist enters the data into the data entry interface using a terminal 108 or 110 for storage in data storage unit 106. Additional details of the data entry process and Data Entry module 400 are provided below.
[0046] Alternatively, a digital ECG file is received via a network, such as the Internet 114 or a telephone network, in an appropriate file format. The digital ECG file may be received along with a data file including digital demographic data identifying, for example, the patient and the study site. The digital ECG file may include either an image of an ECG tracing (e.g., an image file such as a portable document format (PDF) file, a portable neutral graphics (PNG) file or a Bit Map (BMP) file) or digital data representative of an ECG waveform (e.g., data points evincing a plurality of a patient's heartbeats detected at at least one lead of an ECG). ECG tracing images can be generated from image files using plug-ins, such as ADOBE ACROBAT, WINDOWS Image Viewer, or other viewers. An ECG tracing can be generated from either type of digital file for printing. An analyst can then mark the heartbeats for analysis as described above. The tracing is then scanned into the system, and data entry proceeds using Data Entry module 400, if a demographic data file is not included. Alternatively, demographic data can be exported from any accompanying digital demographic data file and stored in database 106.
[0047] More preferably, though, when a digital ECG file is received (either an image file or a data point file), a software program as described below is utilized to create linked files that may be used to produce an annotated ECG tracing image on a display (e.g., a monitor) using the original and unmodified digital ECG file and an associated and linked digital annotation file including digital annotation data representing markings to be shown on an ECG tracing image evinced by the digital ECG data. Essentially, image overlays are created.
[0048] In one exemplary embodiment of the present system, digital ECG files are received from one or more ECG machines 116 at a receiving station 118. The receiving station 118 is a dedicated, stand-alone computer that includes proprietary software for receiving data files via modem communications from ECG machines 116 through telephone network 120. Each ECG machine 116 is made by a specific manufacturer, which typically develops its own receiving station 118 for communicating with its ECG machine 116. Examples of companies that provide ECG machines and corresponding receiving stations include Marquette Medical Systems (which provides the MUSE receiving system), Mortara (which provides the E-SCRIBE receiving station), and Card Guard (which provides the TELEMEDICINE receiving station). In this embodiment, the processor 104 includes code for directing the processor to export these data files from the receiving stations 118 into database 106. In one embodiment, this code is provided as an XML (extensible markup language) export file that exports digital data points for the ECG waveform and digital demographic data into database 106. This code may also be provided to export data in a HL-7 format, or any other format that might be required by the FDA or other regulatory agencies. An ECG waveform can then be generated on a monitor of a terminal 108 or 110 from data in the digital file.
[0049] In one embodiment, the XML file also includes digital Interval Duration Measurement (IDM) data received by the receiving station 118 from the ECG machine 116 and digital annotation data representing the heartbeats measured and measurement lines, assuming the ECG machine 116 that provides the data to the receiving station 118 is capable of automatically generating the IDM data according to its programmed algorithms and provide the annotation data. In this embodiment, assuming this IDM data are deemed acceptable for purposes of the clinical trial, the retrieved digital IDM data take the place of the IDM data generated via the IDM module 600 described below. For example, the retrieved IDM data and/or annotation data may be used in Cardiologist Evaluation module 700 and Reporting and Alerting Module 900 described below instead of the IDM and annotation data generated by the IDM module 600.
[0050] A software program as discussed in connection with IDM module 600 within processor 104 and/or terminals 108, 110 enables on-screen measurement of intervals displayed on a display of a terminal 108, 110. The original digital ECG data and demographic data are preserved in the database of data storage unit 106. The program displays markings, such as marks indicating the intervals that are measured, actual interval duration measurement data, and interval endpoints, on an ECG image in an annotated ECG image. As described above, any such annotations that are to be shown on an ECG image generated from digital ECG data are recorded as digital annotation data in data storage unit 106 in a linked file, but the original digital ECG data remain unchanged in order to maintain the integrity of data for audit purposes.
[0051] Whenever data associated with an ECG tracing are entered into the system 100, the accuracy of the data must be confirmed. Accuracy of data, such as demographic data, is extremely important in clinical trials that are to be reviewed by an agency such as the FDA. All data entry is preferably accomplished via double data entry, as opposed to single data entry that requires manual quality control and editing as described in connection with the prior processing system. The Data Entry module 400 preferably prompts a data specialist to enter data a first time. After the data are entered, the Data Entry module 400 preferably prompts another specialist to enter the data a second time. The module 400 then compares the data entered the second time with the data entered the first time. If the data are identical, it is assumed that the data have been accurately entered. The data are then stored in data storage unit 106. Time and date stamp data are also preferably stored for each data entry session. If the data are not identical, the module prompts a specialist to enter the data a third and final time. The module also preferably alerts the data specialists when data for a required data category have not been entered. If the data specialists has simply forgotten to enter the data, the specialists can enter the data as indicated above. If the data are unavailable, e.g., the data are absent from the data sticker on the ECG tracing or are not included in the received digital demographic data, the data specialist flags the data as unavailable or missing with Data Entry module 400.
[0052] The system preferably assigns each subject/patient entered into the system a unique identifier that is internal to the system and associated with any identifier assigned to the subject by the sponsor or site. This feature greatly enhances the ability to make global changes to data associated with a subject because changes can be cascaded through the system to each ECG or record associated with this internal unique identifier. Making such changes represents a non-trivial problem, as sponsors due not use hard identifiers (such as social security number) to identify subjects. Rather, sponsors typically use combinations of identifiers, such as name, sex, date of birth, middle initial) etc., that are subject to data errors that may be corrected in the system. Correction of these data errors destroys the link between the subject and the identifier. Further, sponsors or sites sometimes change criteria for developing the identifier or use multiple identifiers to identify the same subject. Using a single internal identifier generated by the system for a subject avoids this problem as data changes do not affect the identifier's relationship to a subject and this unique identifier can be associated with multiple identifiers used to identify a single subject.
[0053] After data have been entered for an ECG tracing or group of ECG tracings (whether manually through Data Entry module 400 or as exported from a digital file), the Query Resolution module 500 reconciles any apparent data errors, absences, or inconsistencies using the digital parameter data provided via the Trial Setup module 200 and/or digital demographic data provided via the Data Entry module 400. Referring to step 502 of FIG. 4 , the Query Resolution module 500 identifies data errors, absences or inconsistencies based upon the demographic data and/or parameter data. For example, if data, such as the age of a patient, are “unavailable” as indicated above, the Query Resolution module 500 automatically generates an electronic mail query, a facsimile query or a postal query at 504 to a contact identified for the study site and trial associated with the ECG tracing. This contact information, such as the name of a doctor, administrator, or investigator associated with the trial and the study site, and address information, e.g., postal address, electronic mail address or facsimile number, are preferably provided as trial parameter data to the Trial Setup module 200 in the trial setup process of FIG. 3 and are retrieved from database 106. Of course, if a postal query is to be sent to the contact, the system may alert a query resolution specialist of the processing company by electronic mail, for example, or through a query queue accessible to the specialist when the specialist logs into the system, so that the specialist is alerted to send the postal query to the identified contact. Regardless of the query method, a query resolution specialist is preferably alerted by the Query Resolution module 500 each time a query is sent. The preferred query method (e.g., electronic mail, facsimile or postal) is also identified during the trial setup process using Trial Setup module 200. Data errors and inconsistencies are also identified for query resolution at 502. For example, demographic data identifying a patient visit date may be entered for a date that precedes the beginning date of the associated trial, as identified from the parameter data. Because the date likely was entered into the system correctly (because of the double data entry feature), it may be assumed that the date was entered incorrectly on the data sticker attached to the ECG tracing at the study site or in the digital demographic data received by computer processor unit 104. A query may then be sent to the site in order to identify the correct date. In another example, multiple ECG tracings may be processed for the same patient within the same trial. Patients are typically identified by a patient identification number. If data associated with a first ECG for the patient identification number indicate that the patient is male and data for a second ECG indicate that the patient is female, this inconsistency in the demographic data can be resolved via a query generated by the Query Resolution module 500 at 504. In still another example, if demographic data entered for an ECG indicate that the ECG was taken during the patient's third visit, the query resolution module 500 generates an appropriate query if it is identified at 502, for example, that no ECG has been received and processed for the second patient visit and no demographic data has been entered for the second visit. The query is directed to resolving whether the demographic data identifying the visit as the third visit are incorrect (i.e., the visit was actually the second visit) or whether the ECG data and demographic data for the second patient visit have not been received.
[0054] In one embodiment, types of data errors or inconsistencies are pre-classified based on whether customer interaction is necessary to resolve the data error or inconsistency. The corrective action can take one of two possible workflows through the system based upon the classification of the data error or inconsistency. The first workflow is associated with the class of data issues that are deemed as being repairable by means of self-evident corrections. Examples of these data conditions are certain missing demography data (for example, if a patient identification number was defined such that it required leading zeroes, and the zeroes were not entered by the test site, the data entry staff can insert the leading zeroes), improperly formatted fields (for example, if a first ECG is received for a patient with the initials “A.B.” and a subsequent ECG is received where all of the demography matched by the initials are “AB”, the data entry staff would be authorized to insert the periods in the initials) and out-of-sequence visit data. In this embodiment, the system merely alerts the query resolution specialist to the data condition at step 504, and the query resolution specialist attempts to resolve the data condition without interactions with representatives at the ECG test sites. If the resolution is successful, the query resolution specialist updates the data in the database 106 at step 508 based on the resolution. The second workflow is associated with the class of data issues that are deemed as requiring interaction with outside contacts, e.g., representatives at trial sites, for resolution. Data conditions such as missing patient identifiers, investigator information (e.g., the name of an investigator), protocol number or site identification may be classified for this second workflow. In this second workflow, the system authentication generates a query for the customer at step 504 as described above, or the system prompts the query resolution specialist at step 504 to contact the customer to resolve the issue.
[0055] In one embodiment, queries are batched together before being transmitted to a site or sponsor for resolution. For example, queries can be organized by sponsor, site, time and/or time period or the like for transmittal as a batch. Multiple queries are sent to the clinical site or sponsor in a single communication for the convenience of the recipient. Follow up reminders can also be docketed by the system.
[0056] Responses to queries are received at 506 in the form of return electronic mails, facsimiles, postal correspondence, or telephone calls placed to a query resolution specialist of the processing company. The system preferably does not automatically update the data in the database of data storage unit 106 with resolution data that it receives (such as by electronic mail), but rather, a query resolution specialist preferably examines the response data and enters the data and updates the data in the database 106 based upon the response (Step 508). This step allows for the generation of an audit trail for the modified or supplemented data. For example, when data associated with an ECG tracing are modified by a specialist based upon a query response, the Query Resolution module 500 preferably requires the query resolution specialist to enter his or her initials and a date of the change or affix an electronic signature, as discussed below. The specialist also preferably updates the status of the query in the system as “resolved.”
[0057] As indicated at 502, the Query Resolution module 500 may also identify queries related to a study site, a trial, an investigation, or other query related parameter. A query identification routine may be run periodically, such as weekly or monthly, for example. All outstanding queries for a single study site identified by the query identification routine can then be forwarded together to the correct contact at the site. Alternatively, each time a query is identified for a study site, the Query Resolution module 500 can identify all queries for the site having a status that is “unresolved.” The module can then generate reminder queries along with the new query.
[0058] The Query Resolution module 500 may also be used to generate query status reports. This function may be performed periodically as programmed or be manually initiated by a query specialist. For example, status reports for queries identifying the type of query, query date and status can be generated based upon an investigator, a study site, a doctor, a trial, a specific time period, a query type or any combination thereof.
[0059] An ECG tracing is preferably not released for further processing unless all outstanding queries have been resolved, as indicated by the Query Resolution module 500. If a query cannot be resolved satisfactorily, e.g., the resolved ECG date does not fall within the date limits of the trial and, therefore, violates a rule of the clinical trial or the information is not available, the ECG tracing is preferably flagged as such after the query resolution process. The ECG is withheld from processing within the clinical trial until some form of query resolution occurs. Even if the ECG is flagged as violating trial rules, however, it is still preferably processed after query resolution to evaluate whether the ECG reveals any abnormalities.
[0060] After an ECG tracing is released for further processing, i.e., it was the subject of no queries or all outstanding queries have been resolved, the ECG tracing is ready for interval duration measurement (IDM), e.g., measurement of PR, QR, QT, QTc, RR, and/or QRS intervals as dictated by the study rules. Each ECG is preferably identified in a queue and may be assigned to a specific diagnostic specialist. This assignment may be made based upon protocol rules or parameters established with the Trial Setup module 200 or be based upon availability of the diagnostic specialist. The queue may also list a priority level for each ECG, e.g., “Stat” for high priority. This priority level may be set during the data entry process or be set automatically by the system based on a schedule or deadline rule entered with the Trial Setup module 200. The diagnostic specialist accesses the queue of ECGs using the IDM module 600 and selects an ECG from the queue for measurement.
[0061] The diagnostic specialist can measure intervals by the magnetic board method described in the background section. Of course, for this measurement method, the original paper copy of the marked tracing or a copy of the image must be used. Alternatively, if an ECG file is received as a digital file including digital ECG data evincing a plurality of heartbeats of a patient detected during an ECG test, or if an ECG is received as paper that is scanned to create a digital image file, the same measurements may be generated using images displayed on a monitor of a terminal 108 or 110. A calibration line generated on the monitor of a terminal is controlled by a pointer device, such as a mouse and is moved to identify interval edges. Data points identifying interval edges are generated when the pointer device is “clicked” or triggered. In either case, interval duration data associated with each heartbeat are developed and stored in database 106 for each ECG. The duration data and the annotation data (such as marks identifying specific heartbeats or intervals, marks showing duration data, and/or marks indicating interval endpoints) are saved as digital measurement data and digital annotation data, respectively. The original digital files (whether they be image files or data point files) are not modified in order to show an annotated ECG image on a monitor. Rather, files including the annotations are linked to the original digital ECG data, thereby preserving the integrity of the original data. Further, the annotations enable an agency such as the FDA to identify exactly what points on the ECG waveforms were used to take the measurements. In an exemplary embodiment, software that provides the measurement and annotation data features is developed from the CALECG software product provided by A.M.P.S., LLC of New York, N.Y. The terminal 108 or 110 used to perform and record these measurements is preferably networked as shown in FIG. 1 , such that access to a common database 106 of the system is provided and access to the functionality of the other modules described herein is also provided.
[0062] FIG. 5 illustrates a flow chart of the functionality of the IDM module 600. At 602, an ECG is selected by a diagnostic specialist from the queue as described above, and at 604, interval durations are measured. The interval duration for a measured heartbeat is preferably displayed to the specialist by a terminal 110 or 108 in connection with the annotated ECG image. The IDM module 600 examines the measured data for indications of bad or impossible measurements at 606 and prompts the specialist to re-measure an interval or group of intervals if a bad or impossible measurement flag is triggered. For example, a second edge of a first measured interval may not have properly registered prior to identifying the first edge of a second measured interval. An abnormally large interval is then recorded. Such an abnormally large interval measurement may trigger a re-measurement flag. At 608, identification of non-measured intervals and reasons therefor are registered in a graphical interface by the specialist. Reasons may include poor tracing quality or flat intervals, or lack of clear interval endpoints. The measurement data and any data entered at 608 are then stored in database 106 at 610 along with any digital annotation data (e.g., annotation data representing interval endpoints, measurement markings, etc.).
[0063] The system preferably checks that all measurements are made on beats from the same lead from the measured ECG. If the diagnostic specialist takes measurements from different leads, an error alarm is triggered alerting the specialist of the error.
[0064] After a diagnostic specialist has measured the IDMs, the evaluation is eligible for quality review. Some of the ECGs are identified in the quality control queue of the Quality Control module 800 according to a predefined set of rules. For example, a particular percentage, such as 5%, of all ECGs may be selected for quality control. Also, any ECG associated with digital IDM data indicating an abnormal or dangerous interval duration, based upon a predefined range of abnormal or dangerous interval durations, may be automatically selected for quality review. The intervals measured for the marked heartbeats of ECGs selected for quality control are reviewed by a quality control specialist and may be queued for remeasurement, if desired, prior to evaluation by a cardiologist.
[0065] After the interval measurements have been recorded into the system, the ECG is released to the queue of the cardiologist assigned to the ECG. A single cardiologist or small group of cardiologists is preferably assigned to a clinical trial in order to maintain optimal consistency in the ECG evaluation process, with an alternate cardiologist or alternates being assigned in case the first cardiologist or group of cardiologists is unavailable. The cardiologists and alternates may be assigned using the Trial Setup module 200. Each cardiologist registered in the system is assigned a queue that identifies any ECGs assigned to the respective cardiologist that are ready for evaluation, i.e., ECGs for which intervals have already been measured as described in connection with IDM module 600.
[0066] As an alternative to or in addition to assigning a specific cardiologist to a protocol using the Trial Setup module, subjects or patients can automatically be assigned to a cardiologist by virtue of the first cardiologist to review an ECG for the subject or patient. In addition to already assigned ECGs, a cardiologist's queue can also contain ECGs that have not been assigned to any specific cardiologist. These unassigned ECGs would be shown in the queues of several cardiologists (or in a separate community queue accessible to the cardiologists). Once one of the cardiologists selects the unassigned ECG for review, the system assigns all future ECGs for that subject to the reviewing cardiologist. Subsequent ECGs for that subject, or other ECGs in the queue for that subject, are then assigned to the cardiologist and identified as such in the cardiologist's queue. This method can enhance the consistency of cardiologic reviews and does so in an automated manner that offers efficiency in managing and assignment of ECGs to cardiologists. A similar approach can be applied to other queues and tasks in the system, such as the assignment of ECGs to diagnostic specialists for review in IDM module 600.
[0067] The cardiologist may access the processor 104 and database 106 through a local area network, a wide area network, or through the Internet 114. This feature allows remote viewing and evaluation of ECG tracings and interval data using a terminal 110, 108 remote from a processor 104 and database 106. This in turn allows for ECGs to be evaluated by cardiologists, who have appropriate security access, throughout the world and, therefore, in different time zones. Cardiologists can work from their homes or offices, and cardiologists from different areas of the world can be assigned to a single trial, thereby allowing evaluations to be prepared “around the clock.”
[0068] FIG. 6 illustrates the functionality of the Cardiologist Evaluation module 700. At 702, the cardiologist logs into the Cardiologist Evaluation module 700, preferably using a username and password. As described above, the system assigns a queue to each cardiologist with ECGs that are ready for evaluation. The queue is preferably provided with a reverse turn around time (RTAT) clock that automatically configures the queue according to the contract terms for each clinical study, which are provided to the system through the Trial Setup module 200. The delivery time requirements for ECG evaluations may differ (e.g., 24 hour turnaround v. 2-day turnaround) from study-to-study and from sponsor-to-sponsor. Through this feature, the cardiologist automatically is guided to work on the ECGs that are most near to the required delivery dates. As part of the display of the queue, the module retrieves the contract terms from the storage 106 of the system for each ECG in the cardiologist's queue. The module then identifies due dates for the ECG, calculates the remaining time until the due date for each ECG and orders the ECGs in the queue based on the time remaining for each respective ECG, i.e., in an order reflecting the order in which the ECGs should be completed based on their respective due dates. Time data are preferably normalized to a time zone, such as the eastern standard time zone for comparison purposes in calculating the remaining time until the due date for each ECG. A time status for each ECG can also be displayed for each ECG revealing the number of days overdue or days until due for each ECG. This feature can also take into account “rush” orders placed on certain ECGs through the system that would fall outside of the normal contract parameters with each sponsor.
[0069] The ordering of the queue is also preferably configurable by other parameters associated with the ECGs in the queue, such as study site, patient identifier, sponsor, detected abnormality, etc., through a selectable option (e.g., selectable header or other interface), though the RTAT order is preferably the default (rather than a FIFO or WIFO) ordering. Ordering the queue in such a manner may be used to allow a cardiologist to, for example, view all pending ECGs for a single patient in one batch, so as to complete review and analysis of one patient at a time, thereby providing consistency in the evaluation of a subject's ECGs.
[0070] Though this RTAT feature has been described in connection with the cardiologist queue, it should be understood that the RTAT feature may be used for task queues of other users of the system. For example, the RTAT feature can be used for the diagnostic specialist's IDM queue, query resolution queue or a quality assurance queue. This feature removes administrative work associated with prioritizing tasks of users using the system.
[0071] At 704, the cardiologist selects an ECG for evaluation. The marked ECG image is retrieved from database 106 and is displayed to the cardiologist along with the measurement data described above. More specifically, an annotated ECG image is developed using the digital ECG data evincing a plurality of a patient's heartbeats detected during an ECG and the associated digital annotation data representing marking to be shown on an ECG tracing image of the plurality of heartbeats, unless the marked image is a scanned copy of a hand-marked ECG tracing.
[0072] Oftentimes, cardiologists prefer to examine ECGs of prior patient visits in conjunction with the ECG currently being evaluated. Assuming the cardiologist is examining an ECG taken during a patient's fourth study site visit during a trial, the cardiologist can retrieve the ECG images, measurement data, and evaluation data for visits one through three from database 106, as well as a baseline image and associated data. This feature greatly simplifies the evaluation process and allows for remote, paperless cardiological evaluations.
[0073] At 706, the cardiologist prepares a summary of his or her medical evaluation of the ECG and the interval measurement data reviewed by the cardiologist. The evaluation may be entered through an evaluation sheet graphical user interface that prompts the cardiologist to respond to specific questions dictated by the trial, such as whether the ECG is normal or abnormal and questions pertaining to heart rhythm, heart conduction, previous myocardial infarction, ST-T wave changes, presence of u waves, etc. The Cardiologist Evaluation module 700, while not providing medical evaluations of the ECGs, preferably checks that evaluation data provided by the cardiologist are consistent. For example, if the cardiologist indicates that a specific abnormality is present, the module 700 does not allow the cardiologist to release or certify an evaluation that also proclaims that the ECG is “normal.”
[0074] If the cardiologist feels that the intervals that were marked for evaluation were not representative of the patient's heart rhythm or that a re-measurement should be taken for any reason, the cardiologist can digitally tag the ECG at 708 and note the heartbeats associated with intervals that should be measured. The ECG is then forwarded to or identified in a re-measurement queue of IDM module 600 and the measurement process continues as described above.
[0075] FIG. 7 illustrates one exemplary graphical user interface provided a terminal 110, 108 by the Cardiologist Evaluation module 700 for display to a cardiologist. As can be seen in the interface, the cardiologist can enter evaluation data by way of selectable options pertaining to the cardiologist's interpretation of the ECG and interval duration data (“normal”, “abnormal” or “not able to interpret”), the heart rhythm, arrhythmia, conduction and morphology, ST-T wave changes, presence of u waves, etc. The interface of FIG. 7 also displays a “thumbnail” image of an annotated ECG image of the current ECG being evaluated—the ECG taken during a patient's second visit, for example,—and, if requested, at least one ECG image pertaining to a prior ECG—such as the patient's first visit. The interface allows the cardiologist to re-queue the ECG being evaluated for remeasurement of specific intervals through the IDM module 600. For example, the cardiologist can request verification of the RR, PR, QRS, QTc or QT intervals or confirmation of ECG to patient assignment. The cardiologist can send the ECG back to the diagnostic specialist to remeasure the same beats through the IDM module 600, or the cardiologist can send the ECG to the Query Resolution module 500 if the cardiologist thinks that the ECG is not really from the patient identified by the ECG.
[0076] By selecting one of the thumbnail images, the annotated ECG image is displayed to the cardiologist and is generated from digital ECG data and associated digital annotation data. For purposes of example not by way of limitation, FIG. 8 shows an ECG tracing displayed to a cardiologist evincing a heart rhythm detected by two leads of an ECG machine. Preferably, the cardiologist can view six to twelve leads at a time. Each lead tracing in FIG. 8 shows three heartbeats associated with various interval duration measurements made as described above. Several markings are shown on the image and are generated from digital annotation data associated with the various interval duration measurements. These markings pertain to, for example, measurement of the PR, RR, QRS, QTc and QT intervals as shown in FIG. 8 . Actual interval measurement data (e.g., the measured time duration of an interval or intervals) may also be shown on the ECG tracing as markings or, alternatively, displayed to the cardiologist in an interface such as is shown in FIG. 7 .
[0077] FIG. 8A illustrates an unannotated ECG image generated from the digital ECG data utilized in generating the annotated ECG image of FIG. 8 . Such an unannotated ECG image may also be displayed to a cardiologist by the Cardiologist Evaluation module 700 if desired. A comparison of FIGS. 8 and 8A clearly shows the annotated markings displayed on the ECG image in FIG. 8 .
[0078] After the cardiologist has entered his or her evaluation, the cardiologist preferably must certify the evaluation. Regulatory agencies generally require two forms of verification if verification is provided digitally and one form of verification if the signature is provided biometrically (e.g., a fingerprint). In the present system, a digital signature for the cardiologist is stored in database 106 and is affixed to the completed evaluation data sheet. A fingerprint (or thumbprint) reader may be connected to a cardiologist's terminal 108, 110 as a device 112. The terminal 108, 110 is also programmed with software for interfacing the terminal with the reader. An exemplary reader and accompanying software are available from, for example, from Digital Persona of Redwood City, Calif. The system reads the cardiologist's fingerprint or thumbprint using the reader. The print can be compared to a stored copy of the cardiologist's fingerprint or thumbprint in data storage unit 106, for example, in order to verify the cardiologist's identity. If a positive identification is made, the evaluation is certified, and the certified evaluation is stored in database 106 at 712. If the cardiologist logs into the Cardiologist Evaluation module 700 using a terminal that does not have a fingerprint scanner attached thereto, the cardiologist can enter a secure Personal Identification Number (PIN) to certify the results.
[0079] After a cardiologist has certified an ECG evaluation, the evaluation is eligible for quality review through the Quality Assurance module 1100. The ECGs are identified in the quality assurance queue of the Quality Assurance module 1100 according to a predefined set of rules. These rules optionally can be defined as part of the protocol set up using the Trial Setup module 200. For example, a particular percentage, such as 2%, of all ECGs may be selected for quality assurance, along with each ECG associated with digital evaluation data representative of an evaluation indicating that an abnormality in an interval or intervals is present. The intervals measured for the marked heartbeats of ECGs selected for quality assurance by the Quality Assurance module 1100 are then re-measured using the process described above in connection with the IDM module 600. The ECG is then posted to the queue of a reviewing cardiologist for re-evaluation in Cardiologist Evaluation module 700. This Quality Assurance module can also be used to re-queue the ECG to other modules for other tasks, such as measurement using IDM module 600, if appropriate.
[0080] The rules can also be defined for, for example, review of a higher percentage of the initial ECGs processes for a study, such as the first “X” number of ECGs. Further, the rule can be set up to define review on an employee-by-employee basis. For example, the system could be configured to require review of a higher or even 100% of a new employee's measurements or analysis for a defined period of time.
[0081] The Reporting and Alerting module 900 automatically reports certified evaluations and results to sponsors and/or study sites by either electronic mail or facsimile. In the facsimile example, a facsimile server sends the report to a fax machine identified for a study site or sponsor. Additional reporting to the sponsor may include a digital file including the annotated image of the ECG, the measurement data and the cardiologist evaluation data. The reporting occurs in a form and at a time dictated by digital parameter data established in the initial trial setup using Trial Setup module 200. For example, reporting may occur on an individual ECG or group of ECGs basis batched daily, weekly or monthly, or be based upon the number of evaluated and certified ECG evaluations.
[0082] A portion of the functionality of the Reporting and Alerting Module 900 is dedicated to alerting a sponsor and/or Study site when predefined conditions are detected by an ECG interval duration measurement. Alerts can be triggered by sponsor defined criteria, internally defined review criteria, general clinical safety standards or other selected criteria. For example, some sponsors prefer to be notified immediately when an Interval measurement falls outside of a predetermined time range. An interval measurement outside of this range may identify a potentially dangerous heart condition. An electronic mail or facsimile is automatically generated by the Reporting and Alerting module 900 after the measurement data are released from the IDM module 600 to data storage unit 106, with an indication that the data are only preliminary results that have not been evaluated by a cardiologist or quality controlled. Alerts can also be generated based upon negative (e.g., medically alarming) evaluation data in a certified evaluation report prior to a predefined reporting period if the sponsor so desires.
[0083] Generally, a formal report will take the form of a one page document setting forth the ECG results, e.g., normal, abnormal, etc. and the cardiologists findings. It may be desirable to issue formal reports only when abnormalities are discovered, such as when a study involves a large number of ECG events (e.g., 20,000 ECG readings) and a vast majority or all of those readings are normal. This feature can be selected as part of the protocol set up. The cardiologist's findings can be compared against a set of criteria for issuing a report. For example, if the cardiologists evaluation data identify a cardiac arrhythmia, and cardiac arrhythmia is a condition that is identified as requiring immediate reporting (i.e., before a regular reporting period or before the conclusion of the study), then the system will automatically send the report to the identified ECG site contact and/or study sponsor as identified in the system reporting data. Similarly, a report may also be triggered if a clinical alert is triggered, such as a measurement determined to be outside of a pre-defined tolerance range. It should be understood that different reporting conditions can apply to ECG sites and to sponsors, e.g., study sites receive reports of all ECGs but the sponsor receives only abnormal ECGs. In this manner, the reporting mechanism is intelligently tailored to the results of the cardiologist evaluation.
[0084] A sponsor or a study site representative may access the system using Sponsor/Study Site Access module 1000. This module allows the sponsor to reconfigure reporting options and formats and contact information, as well as trial parameters, such as protocols governing the number of intervals that must be measured for each ECG tracing and alerting parameters. Of course, precaution should be taken to ensure that only authorized personnel have access to this module, such as through usernames and passwords and encryption/key software, as should be familiar to those of ordinary skill.
[0085] The system preferably maintains a complete audit trail in database 106 of users that make data entries and particularly data changes. User names and dates are preferably associated with each entry and change. Changes to data entered into the system may also require a certification as described above. These features help ensure that the data accumulated by the system meet regulatory standards. The audit data are stored in database 106 and are activated as needed.
[0086] In one embodiment, in addition to reporting evaluation results to study sites and sponsors, accumulated data, particularly interval duration measurement data, demographic data, digital ECG data, digital annotation data and/or digital evaluation data are directly accessible by a regulatory agency such as the FDA or CPMP. A standard for this data has been proposed by the FDA and available at the FDA website as visited Nov. 20, 2001. Once a standard is established, the data may be provided directly to an agency via storage mediums such as CD ROMs or uploaded through a network such as Internet 114 to an agency processor 104 remote from processor 104 of the ECG processing company or a processor of the sponsor. Alternatively, the agency may be provided access through a Web page interface to the data in the database 106. In still another embodiment, this data may be provided to the sponsor in an appropriate digital format for reporting to the regulatory agency by the sponsor. In one exemplary embodiment, the data are provided in XML format.
[0087] The present invention can be embodied in the form of methods and apparatus for practicing those methods. The present invention can also be embodied in the form of program code embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. The present invention can also be embodied in the form of program code, for example, whether stored in a storage medium, loaded into and/or executed by a machine, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the program code segments combine with the processor to provide a unique device that operates analogously to specific logic circuits.
[0088] Although exemplary embodiments are described in detail above, the invention is not limited thereto. Rather, the invention should be construed broadly to include other variants and embodiments, which may be practiced within the scope and range of equivalents of the appended claims.
Claims
Certificate of Correction present
The claims shown below may not include correction changes. Use the corrected PDF for authoritative text.
What is claimed is:
1. An ECG processing management system for processing electrocardiograms (ECGs), comprising:
means for receiving protocol data for a first clinical trial;
means for receiving and storing ECG data for a plurality of ECGs associated with the first clinical trial;
means for processing said ECGs to receive interval measurements for said ECGs;
means for processing said ECGs after measurement to receive a cardiological evaluation for each of said ECGs;
means for receiving protocol data for a second clinical trial for use with said ECGs associated with the first clinical trial, and for receiving modified protocol data for said first clinical trial; and
means for identifying ECGs from said plurality of ECGs associated with the first clinical trial that require re-measurement and reevaluation based on said protocol data for the second clinical trial and modified protocol data for said first clinical trial,
wherein ECGs identified by the identifying means to require re-measurement and reevaluation are automatically reprocessed by said means for processing said ECGs to receive interval measurements and said means for processing said ECGs after measurement to receive a cardiological evaluation as needed to comply with the protocol data for the second clinical trial or modified protocol data for the first clinical trial.
2. The ECG processing management system of claim 1, further comprising:
means for receiving ECO data for a second plurality of ECGs for evaluation after receipt of said protocol data for the second clinical trial; and
means processing said second plurality of ECGs in parallel to obtain interval measurements and cardiac evaluations in accordance with said protocol data for said first clinical trial and said protocol data for said second clinical trial.
3. The ECG processing management system of claim 1, further comprising:
means for receiving modified demographic data associated with said ECG data for at least one of the plurality of ECGs;
means for comparing said modified demographic data against protocol data to determine if said ECG requires re-measurement and reevaluation.
4. The ECG processing management system of claim 1, further comprising:
means for automatically generating a report relating to evaluations of said ECGs.
5. The ECG processing management system of claim 1, wherein said means for receiving protocol data for said first clinical trial identifies a sponsor of said first clinical trial, retrieves a protocol template associated with said sponsor and customizes said protocol template for said first clinical trial.
6. The ECG processing management system of claim 1, further comprising means for determining if additional demographic or patient data is required for said ECGs based on said protocol data for the second clinical trial and modified protocol data for said first clinical trial, wherein ECGs for which it is determined additional demographic or patient data is required are made available to means for processing said ECGs to obtain said additional demographic or patient data.
7. A computer-implemented method of processing electrocardiograms (ECGs), comprising the steps of:
receiving into an ECG processing management system protocol data for a first clinical trial;
receiving and storing into the ECG processing management system ECG data for a plurality of ECGs associated with the first clinical trial;
processing the ECGs with the ECG processing management system to receive interval measurements for the ECGs;
after receiving interval measurements of the ECGs, processing the ECGs with the ECG processing management system to receive a cardiological evaluation for each of the ECGs;
receiving into the ECG processing management system protocol data for a second clinical trial for use with the ECGs associated with the first clinical trial;
receiving into the ECG processing management system modified protocol data for the first clinical trial; and
identifying with the ECG processing management system ECGs from the plurality of ECGs associated with the first clinical trial that require re-measurement and reevaluation based on the protocol data for the second clinical trial and modified protocol data for the first clinical trial,
wherein ECGs identified by the identifying step to require re-measurement and reevaluation are automatically reprocessed with the ECG processing management system to receive interval measurements and to receive a cardiological evaluation as needed to comply with the protocol data for the second clinical trial or modified protocol data for the first clinical trial.
8. The method of claim 7, further comprising the steps of:
receiving ECG data for a second plurality of ECGs for evaluation after receipt of the protocol data for the second clinical trial; and
processing the second plurality of ECGs in parallel to obtain interval measurements and cardiac evaluations in accordance with the protocol data for the first clinical trial and the protocol data for the second clinical trial.
9. The method of claim 7, further comprising the steps of:
receiving modified demographic data associated with the ECG data for at least one of the plurality of ECGs;
comparing with the ECG processing management system the modified demographic data against protocol data to determine if the ECG requires re-measurement and reevaluation.
10. The method of claim 7, further comprising the step of automatically generating with the ECG processing management system a report relating to evaluations of the ECGs.
11. The method of claim 7, wherein the step of receiving in the ECG processing management system protocol data for the first clinical trial includes the steps of identifying a sponsor of the first clinical trial, retrieving a protocol template associated with the sponsor and customizing the protocol template for the first clinical trial.
12. The method of claim 7, further comprising the step of determining with the ECG processing management system if additional demographic or patient data is required for the ECGs based on the protocol data for the second clinical trial and modified protocol data for the first clinical trial, and processing ECGs for which it is determined additional demographic or patient data is required to obtain the additional demographic or patient data.
Patent Citations (29)
| Patent | Date | Inventor | Cited By |
|---|---|---|---|
| US4388759(A) | 1983-06-01 | Orejola | Applicant |
| US4601291(A) | 1986-07-01 | Boute et al. | Applicant |
| US4936022(A) | 1990-06-01 | Grayzel | Applicant |
| US5305202(A) | 1994-04-01 | Gallant et al. | Applicant |
| US5469858(A) | 1995-11-01 | Osborne | Applicant |
| US5515176(A) | 1996-05-01 | Galen et al. | Applicant |
| US5605158(A) | 1997-02-01 | Snell | Applicant |
| US5701894(A) | 1997-12-01 | Cherry et al. | Applicant |
| US5724985(A) | 1998-03-01 | Snell et al. | Applicant |
| US5792065(A) | 1998-08-01 | Xue et al. | Applicant |
| US5819741(A) | 1998-10-01 | Karlsson et al. | Applicant |
| US5891049(A) | 1999-04-01 | Cyrus et al. | Applicant |
| US6004276(A) | 1999-12-01 | Wright et al. | Examiner |
| US6141584(A) | 2000-10-01 | Rockwell et al. | Applicant |
| US6233395(B1) | 2001-05-01 | Bee | Applicant |
| US6325756(B1) | 2001-12-01 | Webb et al. | Applicant |
| US6463320(B1) | 2002-10-01 | Xue et al. | Applicant |
| US6575901(B2) | 2003-06-01 | Stoycos et al. | Applicant |
| US6580817(B2) | 2003-06-01 | Badilini | Applicant |
| US6650932(B1) | 2003-11-01 | Menzie et al. | Examiner |
| US6708057(B2) | 2004-03-01 | Morganroth | Applicant |
| US6839678(B1) | 2005-01-01 | Schmidt et al. | Examiner |
| US6934578(B2) | 2005-08-01 | Ramseth | Applicant |
| US2002/0172404(A1) | 2002-11-01 | Badilini | Applicant |
| US2003/0097077(A1) | 2003-05-01 | Morganroth | Applicant |
| US2004/0051721(A1) | 2004-03-01 | Ramseth | Applicant |
| US2004/0054296(A1) | 2004-03-01 | Ramseth | Applicant |
| US2004/0249664(A1) | 2004-12-01 | Broverman et al. | Examiner |
| WO98/50873(A1) | 1998-11-01 | Applicant |
Non-Patent Literature (33)
- Joel Morganrot and Steven S. Silber. “How to obtain and analyze Electrocardiograms in Clinical Trials: Focus on Issues in Measuring and Interpretting Changes in the QTc interval Duration.” A.N.E. Oct. 1999, vol. 4, No. 4.Examiner
- Morganroth, Joel et al. “How to Obtain adn Analyze Electrocardiogrrams in Clinical Trials: Focus on Issues in Measuring and Interpretting Changes in the QTc Interval Duration” University of Pennsylvania Symposium on ECGs in Clinical Drug Development, Mar. 30, 1999 in Philidelphia.Examiner
- United States PTO Office Action, U.S. Appl. No. 10/738,427, filing Date Dec. 17, 2003, First Named Inventor (Joel Morganroth), Mail Date Feb. 17, 2009.Applicant
- CORDIGITAL™ Telemedical Solutions, Micro12ECG+ Manual (16 pages), at least as of 1998.Applicant
- TM 2000 Patient Monitoring System, System Requirements Specification, Card Guard Scientific Survival Ltd. Document No. 590043 (46 pages), Jan. 30, 1997.Applicant
- The Card Guard CG-7000 DX, 12 Lead ECG Recorder/Transmitter Physician's Guide (22 pages).Applicant
- Muse CV® Information System Operator's Manual, Software Version 005B, PN 421619-001, Revision C, GE Marquette (510 pages), Sep. 8, 1999.Applicant
- Marquette® HL7 Interface Professional Toolkit Operator's manual, Software Version 5A PN 40852-30 Revision D (392 pages), Aug. 9, 1999.Applicant
- Muse CV® Messaging Installation & Configuration—005A & 005B, GE Marquette (16 pages), Jul. 13, 1999.Applicant
- Muse CV® Web Server Instruction Guide to Enabling SSL, GE Medical Systems Information Technologies, Muse CV Information System 2003934-001, Revision B (24 pages), Dec. 7, 2001.Applicant
- Muse Cv® Information System Conversions, Forklifts, New Systems, Pre-Quote Survey, Software Version 005C, PN 2002783-029, Revision A, GE Marquette, May 31, 2000.Applicant
- Muse CV® Information System, CPU-CPU/DHCP Interface Installation (Versions 005A, 005B & 005C), GE Marquette (16 pages), Mar. 31, 2000.Applicant
- Department of Health and Human Service's, Food and Drug Administration, Electronic Interchange Standard for Digital ECG and Similar Data; Public Meeting, (4 pages), published Oct. 24, 2001.Applicant
- MUSE Version 5C.04 Release Overview, Jan. 14, 2001 (6 pages).Applicant
- Three (3) screen shots of ECGs produced by G.E. MUSE.Applicant
- Willems, Jos L. et al., “The Diagnostic Performance of Computer Programs for the Interpretation of Electrocardiograms,” The New England Journal of Medicine vol. 325, No. 25, pp. 1767-1773, Dec. 19, 1991.Applicant
- The CSE Working Party, “Recommendations for Measurement Standards in Quantitative Electrocardiography,” European Heart Journal, (1985) 6, pp. 815-825 © 1985 The European Society Society of Cardiology.Applicant
- Willems, J.L., et al., “Common Standards for Quantitative Electrocardiography: The CSE Pilot Study.” In: Lecture Notes in Medical Informatics, Lindberg, D.A.B. and Reichertz P.L., eds. New York: Springer Verlag, 11 (1981), pp. 319-326.Applicant
- Willems, J.L., et al., “Influence of Noise on Wave Boundary Recognition by ECG Measurement Programs,” Computers and Biomedical Research, 20, Dec. 1987, pp. 543-562.Applicant
- Willems, J.L., et al., “Development of a Reference Library for Multi-Lead ECG Measurement Programs,” J. Electrocardiology Supplemental Issue, Oct. 1987, pp. 56-61.Applicant
- Willems, J.L., et al., “A Reference Data Base for Multilead Electrocardiographic Computer Measurement Programs,” J American College of Cardiology, vol. 10, No. 6, Dec. 1987, pp. 1313-1321.Applicant
- Willems, Jos. L. M.D., CSE Project Leader, “Assessment of the Diagnostic Performance of ECG Computer Programs and Cardiologists,” Common Standards for Quantitative Electrocardiography, Commission of the European Communities, CSE 10th and Final Progress Report, Dec. 31, 1990, pp. 148-261.Applicant
- “Physician's Guide to Marquette® Electronics Resting ECG Analysis,” © Marquette Electronics, Inc., Milwaukee, WI, 1988, 1989, 1990, 1991.Applicant
- “Magellan ECG Research Workstation Software Operator's Manual,” Software Version 2.0, PN 421681-001 Revision C, GE Marquette Medical Systems, Inc., Jan. 10, 2000.Applicant
- European Communication Pursuant to Article 94(3) EPC dated May 26, 2009, Application 02 789 738.8-1265.Applicant
- European Communication—Supplementary European Search Report dated Jan. 26, 2009, Application No./Patent No. 02789738.8-1265/1455645 PCT/US0237047.Applicant
- Joel Morganroth, M.D. and Steven S. Silber, M.D., “How to Obtain and Analyze Electrocardiograms in Clinical Trials: Focus on Issues in Measuring and Interpreting Changes in the QTc Interval Duration,” From the Department of Medicine, University of Pennsylvania, Presented at the University of Pennsylvania Symposium on ECCs in Clinical Drug Development in Philadelphia, Pennsylvania, Mar. 30, 1999, pp. 425-433.Applicant
- Eugene Lepeschkin, M.D. and Borys Surawicz, M.D. “The Measurement of the Q-T Interval of the Electrocardiogram,” From the Division of Experimental Medicine, University of Vermont College of Medicine and the Bishop De Goesbriand Hospital, Burlington, Vermont, Circulation, vol. VI, pp. 378-388, Sep. 1952.Applicant
- Bland, Martin J., et al., “Statistical Methods for Assessing Agreement Between Two Methods of Clinical Measurement,” Department of Clinical Epidemiology and Social Medicine, St. George's Hospital Medical School, London, The Lancet, pp. 307-310, Feb. 8, 1986.Applicant
- Savelieva, Irina M.D., et al., “Agreement and Reproducibility of Automatic Versus Manual Measurement of QT Interval and QT Dispersion,” Excerpta Medica, Inc., pp. 471-536, 1998.Applicant
- Murray, Alan, et al., “Errors in Manual Measurement of QT Intervals,” Br Heart Journal, vol. 71, pp. 386-390, 1994.Applicant
- Lawson, W.T., et al., “New Method for Digitization and Computerized Analysis of Paper Recordings of Standard 12-Lead Electrocardiograms,” IEEE-Computers in Cardiology, pp. 41-44, 1995.Applicant
- Bhullar, H.K., et al., “A Computer Based System for the Study of QT Intervals,” Departments of Engineering and Cardiology, University of Leicester, Leicester, UK, IEEE, pp. 533-536, 1992.Applicant