| HOME | HELP | FEEDBACK | SUBSCRIPTIONS | ARCHIVE | SEARCH | TABLE OF CONTENTS |
|
|
|
|||||||
|
|||||||||
Eur J Cardiothorac Surg 2004;26:18-37
© 2004 Elsevier Science NL
Invited paper |
a Congenital Heart Institute of Florida (CHIF), Pediatric Cardiac Surgery, All Children's Hospital, University of South Florida School of Medicine, Saint Petersburg, FL, USA
b Childrens Memorial Hospital, Northwestern University, Chicago, IL, USA
c St Christophers Hospital for Children, Drexel University College of Medicine, Philadelphia, PA, USA
d Denver Children's Hospital, University of Colorado, Denver, CO, USA
e Montreal Children's Hospital, McGill University Health Center, Montreal, Que., Canada
f Division of Pediatric Cardiothoracic Surgery, The Cardiac Center at The Children's Hospital of Philadelphia, Philadelphia, PA, USA
g The Children's Memorial Health Institute, Department of Cardiothoracic Surgery, Al. Dzieci Polskich 20, 04-736 Warsaw, Poland
h Pediatric Cardiac Surgery Unit, University of Padova Medical School, Via Giustiniani 2, 35128 Padova, Italy
i The Great Ormond Street Hospital for Children NHS Trust, London, UK
j Duke Clinical Research Institute (DCRI), Duke University Medical Center, Durham, NC, USA
Received 16 October 2003; received in revised form 9 March 2004; accepted 31 March 2004.
* Corresponding author. Tel.: +1-727-822-6666; fax: +1-727-821-5994
e-mail: jeffjacobs{at}msn.com
 |
Abstract |
|---|
 Top Abstract 1. Introduction2. Materials and methods3. Results4. Discussion5. The nomenclature working...6. SummaryAppendix A. Conference...Appendix B. The Aristotle...Appendix C. The Aristotle...2. The International Working...References |
|---|
Key Words: Outcomes analysis • Database • Nomenclature • Society of thoracic surgeons database • Congenital heart surgery database • Congenital heart surgery outcomes analysis
|
1. Introduction |
|---|
|
TopAbstract1. Introduction2. Materials and methods3. Results4. Discussion5. The nomenclature working...6. SummaryAppendix A. Conference...Appendix B. The Aristotle...Appendix C. The Aristotle...2. The International Working...References |
|---|
More than any other medical or surgical subspecialty, cardiothoracic surgeons have led the way with respect to developing a national registry that addresses the needs of the profession with respect to self-improvement and quality assurance while also meeting the administrative needs of the individual contributing members. It has been suggested that the release of raw mortality data for coronary bypass grafts by the federal government in 1986 motivated the database project of the Society of Thoracic Surgeons (STS) [7]. Nearly two decades later, the STS National Adult Cardiac Surgery Database has been adopted as a tool by a significant majority of practitioners and centers throughout the United States. It has been a work in progress, with the ongoing development of risk adjustment tools and data quality measures, as well as data manager education [8]. Clearly, the result of this enormous effort has been positive. The responsible collection and analysis of valid data by a national subspecialty group has enhanced the monitoring of quality of care, contributed to improved outcomes and resource utilization, and in a challenging healthcare economic environment has provided cardiothoracic surgeons with a tool to help protect our patients from overzealous cutbacks in reimbursement. The STS National Adult Cardiac Surgery Database is increasingly utilized by states, healthcare provider organizations, and third party carriers. Of course, it is also increasingly utilized by our colleagues as a tool and platform for the conduct of important clinical outcomes research.
Analogous to the federal government's disclosure of raw mortality data for coronary bypass grafting in 1986 have been several reports both in North America and abroad of judicial inquiries into clusters of deaths after pediatric cardiac surgery. Investigations of this type, such as the Bristol, United Kingdom (UK) Inquiry [9], often follow upon publication in the lay press of raw outcome data, cited out of context, often incomplete if not inaccurate, and virtually never enhanced by information regarding risk stratification. Furthermore, after the inquiry is completed and findings published, the lay press may never correct the original allegations and usually does not publish the findings of the inquiry, which may be favorable towards the surgeons and physicians. In the final analysis, the upshot of lengthy expensive inquiries of this sort uniformly has been the recommendation to establish and maintain a reliable registry database.
The need for our community of congenital heart surgeons to achieve a level of utility and participation comparable to that of the STS Adult Cardiac Surgery Database is obvious. Nevertheless, it may be helpful to restate the obvious, as Dr William G. Williams of Toronto [3] did in an important review of databases for congenital heart disease: ‘One of our responsibilities as physicians caring for patients with congenital heart disease is to know the results of the treatment that we recommend. Our patients and their families have a right to know the risk they will encounter, and what their long-term prognosis might be, with or without surgery. Knowing the results of our treatment may seem self-evident, but attaining this knowledge is a complex and time consuming process.’ In its current form, the STS Congenital Heart Surgery Database has been designed to simplify this complex process, and to reduce to a reasonable modicum the amount of time and energy that are required of a center in order to participate in a multi-institutional registry database. While the goals of this undertaking are analogous to those of the STS Adult Cardiac Surgery Database, the challenges are unique to congenital heart surgery. The existence of a vast spectrum of congenital cardiac anomalies, together with a multitude of surgical approaches (palliation, physiologic repair, anatomic repair, re-repair, etc.) define an enormous theoretical field of data that could be included in the data specifications for a universal congenital cardiac surgical database. Regardless, from a practical standpoint, the success of such an undertaking is largely dependant upon accurate data entry, the potential for data verification, and maximal center participation. This project has evolved, and continues to be a work in progress, all the while respecting the fundamental importance of accuracy and ease of participation.
This current report (The Second Harvest (1998–2001) of The STS Congenital Heart Surgery Database) follows by four years the previous STS Congenital Heart Surgery Database first harvest [10], the summary of which was published in the Annals of Thoracic Surgery in 1999 [11]. This first harvest and report [10,11] of the STS-National Congenital Heart Surgery Database was based on a four-page paper based data entry form and analysis software that was developed in association with STS database committees and Summit Corporation (formerly Summit Medical, Minnetonka, MN) and included data from twenty-four centers which joined the program at various dates of entry between 1994 and 1997. There were 18,894 enrolled patient records from which 8,149 patient records were used to compile the relevant clinical features of eighteen congenital heart categories over the four-year period. Outcome data included operative death, complications, and length of stay, among others. Outcome analyses were segregated for age or weight at operation where appropriate, which varied from diagnosis to diagnosis. The data analysis was largely descriptive in character. Similar to the STS Adult Cardiac Surgery Database, this first report generated a massive amount of data. These data depicted many trends and were largely predictive of the established previous clinical reports from different centers. The analysis also demonstrated the strengths and weaknesses of a database, which, by necessity, limited the data input. On one hand, the four-page data form was readily available and concise; on the other hand, the information was limited and did not allow discriminating features that are necessary to establish risk stratification analysis. Unlike the STS Adult Cardiac Surgery Database, the STS Congenital Heart Surgery Database has numerous disease entities to analyze and by the nature of the subspecialty requires increased complexity in data analysis in order to produce meaningful risk stratification. The first STS-Summit congenital heart surgery database report, while informative and the first of its kind, suffered from a lack of statistical validity checks and institutional feedback to improve data collection. There was a rather high incidence of missing data points (as high as 10%), which prohibited statistically valid conclusions.
In 1997, after the first STS Congenital Heart Surgery Database harvest, CardioAccess (CardioAccess Inc., St. Petersburg, Florida and Fort Lauderdale, Florida: http://www.cardioaccess.com) presented a prototype software package to the STS Congenital Heart Surgery Database Subcommittee. At that time, it became clear, that developing a standardized nomenclature system as well as an agreed upon minimal database dataset for congenital heart surgery represented top priorities to ensure uniformity of language and uniformity of purpose in any database development endeavor. This concept was demonstrated by both the initial STS Congenital Heart Surgery Database (chaired by Constantine Mavroudis) [10,11] and the initial congenital heart surgery database of The European Association for Cardio-Thoracic Surgery (EACTS) and The European Congenital Heart Surgeons Association (ECHSA—formerly The European Congenital Heart Surgeons Foundation [ECHSF]) (chaired by Martin J. Elliott) [12]. To this end, a committee (The International Congenital Heart Surgery Nomenclature and Database Project Committee chaired by Constantine Mavroudis) with representation from congenital heart surgery centers and societies, national and international (including the EACTS, ECHSA, and STS), met on multiple occasions over a 2-year period (1998–2000). A summation of this work was published as the International Congenital Heart Surgery Nomenclature and Database Project report [12]. This Project ensured that the congenital heart surgery community around the world could use the same nomenclature. The Project also was responsible for conceiving a 28-item minimum database dataset that could be used to generate standard outcome reports based on the dataset's preoperative, intraoperative, and postoperative variables. These items became the STS' core specifications for a congenital heart surgery database, published on their web page [13]. The minimum database dataset and international nomenclature were adopted in 2000 by the STS as well as the EACTS and ECHSA (at that time known as the ECHF). CardioAccess, working in concert with the STS Congenital Heart Surgery Database Subcommittee, revised its software to reflect these new initiatives and provided a free downloadable version of the minimum dataset at the STS web site for use by interested surgeons and centers.
This manuscript represents the first publication generated by the STS Congenital Heart Surgery Database working in collaboration with the Duke Clinical Research Institute (DCRI) (Duke University Medical Center, Durham, NC, USA). It also represents the first publication of data from the STS Congenital Heart Surgery Database since the database converted from paper based data entry to electronic data entry in 1998. This manuscript will present the analysis of the second harvest of the STS Congenital Heart Surgery Database and discuss the data harvest's production of meaningful outcome data and several critical lessons relevant to congenital heart surgery outcomes analysis worldwide.
|
2. Materials and methods |
|---|
|
TopAbstract1. Introduction2. Materials and methods3. Results4. Discussion5. The nomenclature working...6. SummaryAppendix A. Conference...Appendix B. The Aristotle...Appendix C. The Aristotle...2. The International Working...References |
|---|
The initial harvest was restricted to data spanning 1998 through 2001, and 16 centers submitted their data for analysis, covering all or parts of the inclusive period. This de facto beta site group included centers that used either the comprehensive CardioAccess database or the free CardioAccess minimum dataset version available at the STS web site.
Creating the format of the data harvest report was our next major undertaking. Members of the STS Congenital Heart Surgery Taskforce, along with DCRI, prepared a Report with three sections:
2.1.1. Executive summary
The Executive summary provided descriptive text written by members of the STS Congenital Heart Surgery Taskforce and DCRI that summarized the report and pointed out its strengths and weaknesses.
2.1.2. Data summary section
The STS Congenital Heart Surgery Taskforce opted to fashion the Data Summary portion of the report after The EACTS Congenital Database Report created under the chairmanship of Bohdan Maruszewski, with some modification, for ease of comparison of our aggregate data from the 16 centers with that of the European congenital heart surgery community. Our Data Summary includes an analysis of all cases and further analysis broken down by three age groupings based on the age at the time of surgery: (1) Neonates (0–28 days), (2) Infants (29 days—1 year), and (3) Other (over 1 year).
The second harvest of the STS Congenital Heart Surgery Database is the first STS Congenital Database Report to utilize the international standardized nomenclature and minimum database dataset requirements adopted by the STS and EACTS (April 2000 Annals of Thoracic Surgery) [12]. Furthermore, the second harvest of the STS Congenital Heart Surgery Database is the first STS Congenital Database Report to utilize a methodology of Complexity Adjustment. This Complexity Score and Level is based upon the work of the Aristotle Committee founded and chaired by Francois G. Lacour-Gayet [14–16] (Appendix B and C). The Data Summary Section of this STS report incorporates a Mean Aristotle Basic Complexity Score and Mean Aristotle Basic Complexity Level in the discharge mortality analyses. These Aristotle Basic Complexity Scores and Levels are reported by year, center, age group, and procedure. The complexity analysis represents a basic complexity-adjusted method to evaluate surgical results. (Complexity is a constant precise value for a given patient at a given point in time; performance varies between surgeons and centers.) The Aristotle project, based on a panel of expert surgeons, started in 1999 and included 50 pediatric heart surgeons from 23 countries and included representatives of the EACTS, STS, ECHSA and the Congenital Heart Surgeons' Society (CHSS) (Appendix B and C). The complexity scoring was based on the Primary Procedure as defined by the Short List of procedures of the EACTS–STS International Nomenclature [12] and was evaluated in two steps. The first step was the Aristotle Basic Complexity Score, defining basically the complexity through three factors: the potential for mortality, the potential for morbidity, and the technical difficulty, using a questionnaire filled out by 50 congenital heart surgeons international centers. Only the Aristotle Basic Complexity Score (1.5–15) and Aristotle Basic Complexity Level (4 levels: 1–4) are used in the second harvest of the STS Congenital Heart Surgery Database (Table 1) . Future harvests hopefully will incorporate the second step, the Aristotle Comprehensive Complexity Score, which will add two sorts of complexity modifiers: Procedure Dependent Factors (including anatomical factors, associated procedures, and age at procedure) and Procedure Independent Factors (including General Factors, Clinical Factors, Extracardiac Factors, and Surgical Factors). Utilization of these additional patient specific complexity factors (modifiers) will allow a more precise complexity adjustment. The Aristotle Committee is currently involved in ongoing research to validate this complexity adjusted scoring system on a multi-institutional basis.
|
In Section 2.1.2, concerns about site-level comparisons led to blinding of participant IDs, converting these to consecutive letters. Furthermore, for the Data Summary Section of the report, sites are assigned to case volume categories. Only operation types ‘CPB’ and ‘No CPB Cardiovascular’ are included in site volume categorizations and in all the analyses in this report. Operations coded as operation type ‘CPB Standby’ are converted to ‘operation type ‘No CPB Cardiovascular’ by the software vendor prior to analysis. Other operation types (‘ECMO’, ‘CPS’, ‘Minor Procedure’, ‘Bronchoscopy’, ‘Other Endoscopy’ ‘Thoracic’, ‘Interventional Cardiology’ and ‘Other’) are not included in site volume categorizations and in all the analyses in this report. Sites are categorized as low volume if they perform up to 100 cases per year on average, medium volume if they perform between 101 and 250 cases per year on average and high volume if they perform more than 250 cases per year on average.
For this report, no sites or observations were removed from analyses because of missing data. The most troublesome missing data elements were in the Noncardiac Abnormality and Risk Factor sections, where each had six sites (out of 16) that had over 10% missing data. Mortality data had only three sites with over 10% missing data, and Diagnosis and Procedure data were missing from two centers for over 10% of their submitted cases. On a more positive note, Discharge Mortality was 100% complete in the data from 11/16 centers, greater than or equal to 99.5% complete for 12/16 centers, and greater than or equal to 95.9% complete for 13/16 centers.
Because of the need to determine a reliable measure of mortality, for this report mortality was determined by ‘Discharge Status’. Data from other mortality fields (including ‘30 Day Status’, ‘Operative Mortality’, and ‘Mortality Assigned to this Operation’) was not complete enough for meaningful analysis. If a patient had more than one operation during a hospitalization, assignment of mortality was made to the first operation of the given hospitalization. (Assigning mortality to the first operation of a given hospitalization will correctly assign the mortality in most but not all clinical situations. Examples of where this assignment is problematic and potential solutions to this problem are presented in the Discussion section of this manuscript as part of the discussion of the term ‘Mortality assigned to this operation’.) Because mortality status at discharge is the chosen measure of mortality for this Congenital Heart Surgery Database analysis report, records with a missing value for discharge mortality and sites for which the level of missing mortality status at discharge exceeded 10% were removed from mortality analyses. These records were included in all other areas of the report.
We hope that this report will alert our contributing centers to the necessity of mandatory data field completion, and help us to develop appropriate strategies for more complete data collection and presentation of the data in the future.
2.1.3. Site specific—lesion specific report section
In addition to the aggregate report (Data Summary Section – Section 2.1.2), a Site Specific—Lesion Specific Report was fashioned for the eight most common disease entities. When preparing the Report from this data harvest, it became apparent that a number of challenging issues needed to be resolved. It was obvious from the start that the world of congenital heart surgery had too many types and subtypes of disease entities for complete inclusion. For this Site Specific—Lesion Specific Report, we therefore chose the eight most common disease entities, which represented 80% of the entered patients in the system: atrial septal defect, ventricular septal defect, atrioventricular canal defect, coarctation of the aorta, transposition of the great arteries, hypoplastic left heart syndrome, tetralogy of Fallot (two reports, one for palliative procedures, one for repair), and aortic stenosis-aortic insufficiency.
The next hurdle was to choose the inclusionary and exclusionary criteria so as to assign appropriately the harvested records to the proper disease entity. This task turned out to be more daunting and vexing than originally thought. After several trial runs through the system, we were able to adjust the inclusionary and exclusionary criteria to establish groups, which were materially similar with respect to primary and secondary diagnoses.
For these eight lesions analyzed, the decision was made to report on the five most frequently occurring Risk Factors for each lesion and the three most frequently occurring Noncardiac Abnormalities (excluding ‘none’, ‘missing’, or ‘other’). Although collecting risk factor and complication data is an important objective for the congenital database, it could not be a priority for the present analysis. It was decided to restrict analysis of Complications to 10 complications that were of clinical interest and were not subjective. These complications include reoperation (unplanned), postoperative cardiac arrest, mechanical circulatory support, AV block with permanent pacemaker placement, sternum left open, acute renal failure requiring dialysis (temporary or permanent), bleeding requiring reoperation, mediastinitis, neurologic deficit persisting at discharge, and new onset seizures.
|
3. Results |
|---|
|
TopAbstract1. Introduction2. Materials and methods3. Results4. Discussion5. The nomenclature working...6. SummaryAppendix A. Conference...Appendix B. The Aristotle...Appendix C. The Aristotle...2. The International Working...References |
|---|
This STS report produced a huge amount of data, some of which has been published on the Internet (http://www.sts.org/, accessed October 5, 2003). A small portion of this data will be summarized in this report in order to illustrate the type of data collected and provide a basis for the subsequent discussion.
For the purposes of this manuscript, three brief tables of data will be presented. Table 2 shows aggregate data for all patients documenting the number of operations submitted, discharge mortality, and complexity information by year and in total. Table 3 shows the number of patients and operations submitted, discharge mortality, and complexity information, by age group. Table 4 shows the top 30 (by frequency) primary procedures, with incidence, discharge mortality, and complexity information.
|
|
|
|
4. Discussion |
|---|
|
TopAbstract1. Introduction2. Materials and methods3. Results4. Discussion5. The nomenclature working...6. SummaryAppendix A. Conference...Appendix B. The Aristotle...Appendix C. The Aristotle...2. The International Working...References |
|---|
In addition to the utilization of the international nomenclature and minimal database and the application of complexity adjustment, the second harvest of the STS Congenital Heart Surgery Database has many other advances and new features when compared to the first harvest. The initial European Congenital Heart Defects Database (using PATS [Patient Analysis and Tracking System] software [Axis Clinical Software, Inc., Portland, OR; http://www.axisclinical.com]) as well as the initial STS-Summit Medical Systems National Congenital Heart Surgery Database (Summit Medical, Minnetonka, MN) were both non-relational databases—in other words, flat files. The concept of the difference between a flat file spreadsheet and relational database must be understood in order to develop software for medical database solutions [23]. An example of a non-relational flat file is a simple Excel spreadsheet. An example of a relational database is an Access database. Medicine is best represented in a database by a relational database that is made up of multiple tables linked to one another by a variety of connections. For example, a table could contain basic ‘Demographic Data’. This demographic table could then be linked to a table containing information about hospitalizations (‘Hospitalization Data’) through a one to infinity relationship (each one record in the Demographic Data Table could be linked to an infinite number of records in the Hospitalization Data Table). Similarly, this Hospitalization Data Table could be connected to an ‘Operative Data’ Table by a one to infinity relationship (each one record in the Hospitalization Data Table could be linked to an infinite number of records in the Operative Data Table). Meanwhile, each record in the Operative Data Table could be linked to a ‘Perfusion Record’ Table on a one to one relationship. The second harvest of the STS Congenital Heart Surgery Database represents the first STS database to function in the environment of a computer based relational database.
Analysis of the data of the second harvest of the STS Congenital Heart Surgery Database by members of the STS Congenital Heart Workforce and Congenital Heart Surgery Database Taskforce also has resulted in several lessons learned:
4.1. Death must be clearly defined
‘Operative Mortality’ and ‘Mortality Assigned to this Operation’ were defined by the STS and EACTS [12]; these definitions were not utilized uniformly. The STS and EACTS initially defined two types of mortality for the minimum database: (1) operative mortality, and (2) mortality assigned to this operation.
‘Operative mortality’ is any death during the period of data collection for the minimum database, regardless of whether or not the mortality is related to surgery. (The period of data collection for the minimum database ends when both of the following two criteria have been satisfied: (1) the patient has been discharged from the hospital after the operation, and (2) 30 days have passed since the operation.) In other words, operative mortality designates any death that occurs before both of the following two criteria have been satisfied: (1) the patient has been discharged from the hospital after the operation, and (2) 30 days have passed since the operation. This definition is the same definition of operative mortality that has been widely accepted and used for reporting postoperative death.
‘Mortality assigned to this operation’ is a database field to deal with the problem of reoperations during the same hospital admission. The difficulty is how to assign death. Under traditional systems, it is possible to assign death to all operations that were done during the same admission, which would increase the overall mortality inappropriately. The STS and EACTS International Congenital Heart Surgery Nomenclature and Database Project addressed this problem by creating a field called ‘mortality assigned to this operation.’ Thus, a patient undergoing multiple operations during a given hospitalization may have the field ‘operative mortality’ answered ‘yes’ for each operation; however, the field ‘mortality assigned to this operation’ will be answered ‘yes’ for only one operation. The surgeon will therefore assign the operative mortality to the most appropriate operation.
Many examples of this problem exist. In most, but not all examples, the mortality is assigned to the first operation of the hospitalization. For instance, consider a patient with atrioventricular canal who undergoes complete repair, then during the same admission undergoes reoperation for mitral valve replacement, which is followed by heart block, pacemaker insertion, and subsequently ends in the patient's death. To which operation is the death assigned? Most would say that the death should be assigned to the first operation. In the aforementioned scheme, death is assigned only once and the data analyzer can make the decision.
This system also works for the less common situation where the mortality would not be assigned to the first operation of the hospitalization. For example, a patient with transposition of the great arteries who presents late for an arterial switch operation can undergo a preparatory pulmonary artery band and a systemic-to-pulmonary artery shunt. During the same admission, this patient can have an arterial switch operation and die from a coronary artery problem. Where does one assign the death? Under the aforementioned scheme, most surgeons would assign the death in this case to the arterial switch operation. A similar example is a patient with cardiomyopathy who has surgery for placement of a ventricular assist device, then undergoes heart transplantation during the same hospitalization, and then dies from acute rejection during the same hospitalization. Under the aforementioned scheme, most surgeons would assign the death in this case to the heart transplantation operation. Clearly, the data analyzer can easily segregate these cases and others like it (cases involving preparatory operations and planned reoperations during the same admission) by appropriate inquiries. The tenet, in this case as with all the others, holds true to the idea that only one death can be assigned to any one patient regardless of the number of operations that he/she had during the same admission.
Unfortunately, although ‘Operative Mortality’ and ‘Mortality Assigned to this Operation’ were defined by the STS and EACTS [12], these definitions were not utilized uniformly. ‘Thirty Day Mortality’ was problematic because some centers did not track mortality after hospital discharge. Only ‘Mortality Prior to Discharge’ was consistently reported. Each form of mortality measurement has both advantages and some associated problems.
‘Mortality Prior to Discharge’ has the advantage of being easy to measure. Two disadvantages of this measurement exist. First, patients may die in the hospital several months after a given operation from completely unrelated reasons. The most notorious example is the premature neonate who undergoes a PDA ligation and dies 5 months later, prior to discharge, from completely unrelated problems. Second, ‘Mortality Prior to Discharge’ can lead to gaming the system by transferring the patent from the hospital so that the mortality occurs at a rehabilitation facility. For example, it is possible that a patient can have postoperative respiratory failure after cardiac surgery and become ventilator dependent; if this patient then dies of pneumonia, the mortality would obviously count if the patient remains in the hospital. Should this mortality count if the patient dies after transfer to a chronic ventilator facility 100 miles away? Should this mortality count if the patient dies after transfer to a chronic ventilator facility located in the same hospital as the cardiac surgery unit but in another building? What if this chronic ventilator facility located in the same hospital as the cardiac surgery unit is reclassified as a separate hospital even though it is on the same campus or even in the same building? Each individual institutional setup is different. ‘Mortality Prior to Discharge’, while being easy to measure, can unfairly penalize hospitals that do not transfer patients to outlying centers or rehabilitation facilities but instead keep chronic patients in their own facilities. The argument can be made that ‘Mortality Prior to Discharge’ should mean ‘Mortality Prior to Discharge to home’, but even this approach becomes problematic when one operates on a patient transferred into the operating institution from a chronic ventilator facility—does one then consider the chronic ventilator facility to be the patient's home or does one wait until the patient is actually discharged to home from the chronic ventilator facility.
‘Thirty Day Mortality’ has the advantage of being less likely to allow gaming of the system. Nevertheless, some centers state that they are unable to report ‘Thirty Day Mortality’ because they do not have the resources to track mortality after discharge, especially from patients referred from remote locations.
The STS–EACTS definition of Operative Mortality has the advantage of being the time honored standard definition of mortality. The disadvantages of this definition include the disadvantages of both ‘Mortality Prior to Discharge’ and ‘Thirty Day Mortality’.
One potential solution is to measure ‘Mortality Prior to Discharge only within 30 days of surgery’. ‘Mortality Prior to Discharge only within 30 days of surgery’ designates any death that occurs before one of the following two criteria have been satisfied: (1) the patient has been discharged from the hospital after the operation, or (2) 30 days have passed since the operation. In other words, ‘Mortality Prior to Discharge only within 30 days of surgery’ provides a definition whereby a patient is counted as a survivor once one of the following two events has occurred: (1) the patient has been discharged from the hospital after the operation, or (2) 30 days have passed since the operation. Application of this definition provides a solution that would eliminate many of the problems associated with both ‘Mortality Prior to Discharge’ and ‘Thirty Day Mortality’. It would prevent potential gaming of the system by transferring a patient to a chronic facility 30 days after surgery and prior to death on postoperative day 31. It would also prevent increasing measured mortality when patients die in the hospital several months after a given operation from completely unrelated reasons, such as the previously discussed case involving the premature patient who undergoes a PDA ligation. Finally, it would eliminate the need for creating the resources to uniformly track thirty day mortality after discharge, especially from patients referred from remote locations. One might argue that investigators analyzing the outcome data will realize that most neonates with PDA who die several months after surgery are deaths not truly related to the surgery; however, if this argument is true, why include these deaths in the measured mortality in the first place. Furthermore, one might argue that it is the moral responsibility of every surgeon to track thirty day mortality after discharge, even from patients referred from remote locations; however, in a time of limited resources, this task might be both difficult for some institutions and not justifiable secondary to the miniscule number of patients dying after discharge but within 30 days. Obviously, for detailed analysis of some subgroups of patients (such as neonates discharged after Norwood Stage 1), tracking of thirty day mortality after discharge is critical; however, mandatory tracking of thirty day mortality after discharge may not be appropriate or feasible for all patients in a multi-institutional outcomes database (registry). The only potential methods of gaming the system with the methodology of ‘Mortality Prior to Discharge only within 30 days of surgery’ is the technique of artificially and unnecessarily prolonging the life of a clearly dying patient so that he dies on day 31 and the technique of transferring a patient out of the hospital to die elsewhere within 30 days of surgery; these two morally reprehensible possibilities seem less likely to be employed on a large scale basis compared to the other techniques of system gaming applicable to other mortality definitions that were discussed earlier.
Clearly, the ideal information about mortality is not ‘Mortality Prior to Discharge’ or ‘Thirty Day Mortality’, but rather mortality over the long-term as defined by a Hazard Function curve or Kaplan-Meier curve. Unfortunately, tracking this type of mortality over the long-term is not suitable or reasonable for a multi-institutional registry type database [3]. Tracking this type of mortality over the long-term is more appropriate for individual institutional databases or an academic type multi-institutional database focusing on specific pathological subgroups, for example, the CHSS database (http://www.chssdc.org/). For a surgically driven registry like the STS database or the EACTS database, perhaps the most appropriate mortality measurement would simply be ‘Mortality Prior to Discharge only within 30 days of surgery’. Furthermore, in situations with multiple operations within a given hospitalization, one could assign the mortality to the operation with the highest Basic Aristotle Complexity Score during the given hospitalization. This assignment of mortality would negate the problems associated with assigning the mortality to the first operation of the given hospitalization and would negate the problems associated with the lack of completeness of the field ‘Mortality assigned to this operation’.
Finally, in addition to examining the definition of the numerator for mortality, one must examine the denominator. Most database currently report mortality with the denominator being the number of cases or operations. It is possible that a more important mortality calculation is established when one uses the number of patients undergoing surgical procedures as the denominator instead of the number of cases or operations. This conversion of mortality calculation from cases to patients will in all likelihood result in a higher calculated mortality, but also a mortality calculation more in line with parental values. Future harvests of the STS database plan to report both case based and patient based mortality, realizing that patient based mortality is most likely higher and also more valuable to know.
4.2. The primary procedure in a given operation must be documented
Designation of Primary Procedure for a given operation determines its location for analysis. The importance of this concept and the necessity of complete end accurate data reporting for this field have been discussed previously [12,24]. Until Complexity Scores lead to automated methodology for choosing the Primary Procedure, the surgeon must designate the Primary Procedure.
The STS Congenital Database will mandate that the next generation software will REQUIRE the input of a PRIMARY DIAGNOSIS and a PRIMARY PROCEDURE for each operation. During the Fall 2002 Harvest (THE SECOND HARVEST (1998–2001) OF THE SOCIETY OF THORACIC SURGEONS (STS) CONGENITAL HEART SURGERY DATABASE), the software analyzed the first diagnosis and procedure entered as the primary diagnosis or procedure. During this Fall 2002 Harvest, the STS Congenital Heart Database Taskforce urged all participants to enter the first diagnosis and procedure as a choice from the drop-down menu and never as free text, with the first entry indicating the primary diagnosis or procedure. In the current Spring 2003 Harvest (THE THIRD HARVEST (1998–2002) OF THE SOCIETY OF THORACIC SURGEONS (STS) CONGENITAL HEART SURGERY DATABASE), the designation of a PRIMARY DIAGNOSIS and a PRIMARY PROCEDURE is required and the user is required to select a choice from the drop-down menu and never use free text.
DCRI actually used the first diagnosis and procedure entered as the primary diagnosis or procedure when assigning cases to diagnostic and procedural groups in the in Section 2.1.2. The assignments made in the Lesion Specific Reports were based on the inclusionary and exclusionary criteria discussed below.
In the future, this point will be less problematic because all software vendors will be required to include in their software a field which clearly assigns the primary diagnosis and procedure. In fact, the recent version of CardioAccess now does clearly assign the primary diagnosis and procedure.
Also in the future, it may be possible to develop a system where the database software itself assigns the Primary Procedure based on a methodology of labeling the component procedure in a given operation with the highest Aristotle Basic Complexity Score as the Primary Procedure for that operation. While this methodology would solve the problem of assigning Primary Procedure, it would not address the issue of Primary Diagnosis, which would still need to be assigned by the surgeon.
4.3. Inclusionary and exclusionary criteria for all diagnoses and procedures must be agreed upon
Inclusionary and exclusionary criteria for all diagnoses and procedures have been developed in an effort to define acceptable concomitant diagnoses and procedures for each analysis. These criteria have been applied to the Lesion Specific Report Section of the report in order to perform analysis on a more pure grouping of cases. For example, for a VSD, one would allow acceptable concomitant diagnoses of ASD and PDA. For and ASD, one would allow acceptable concomitant diagnoses of PDA but not VSD. For a tetralogy of Fallot, one would allow acceptable concomitant diagnoses of VSD, ASD, and PDA.
After reviewing the data from the second harvest of the STS Congenital Heart Surgery Database, the STS Congenital Heart Surgery Database Taskforce discussed improvements we needed to make on the inclusionary and exclusionary criteria. For example, PA Plasty needed to be added to the list of Allowable Concomitant Procedures for Hypoplastic Left Heart Syndrome (HLHS), so that we do not exclude from the HLHS analysis HLHS patients that undergo heart transplant after a Fontan who often require extensive PA Plasty. An extensive review of suggested improvements to the lists for Allowable Concomitant Diagnoses and Procedures is now planned by the STS Congenital Heart Surgery Database Taskforce.
An alternative method of dealing with Case Selection for the Lesion Specific Report is to utilize the Aristotle Basic Complexity Score from the EACST/STS Aristotle Committee. This method would involve not using a list of Allowable Concomitant Diagnoses and Procedures, but instead considering any Procedures with an Aristotle Basic Complexity Score less than or equal to the Primary Procedure to be an Allowable Concomitant Procedure.
4.4. Missing data values remain an issue for the database
We hope that this report will alert our contributing centers to the necessity of mandatory data field completion, and help us to develop appropriate strategies for more complete data collection and presentation of the data in the future. Improvements in data completeness can be achieved using a variety of techniques. Developing more functional techniques of data entry at individual institutions can go a long way towards addressing this problem. However, software improvements will also help achieve more complete data. For example, the STS Congenital Database will mandate in the future that the fields for ‘Diagnoses’ and ‘Procedures’ do not accept free text. Until all user software is updated to comply with this regulation, we urge database participants to use the choices in the nomenclature drop-down menus and avoid the alternative of a write-in diagnosis or procedure, which for purposes of analysis becomes missing data.
4.5. Generic terms in the nomenclature lists, that is terms ending in NOS, are redundant and decrease the clarity of data analysis
Future versions of the STS Congenital Database will request that the coding of diagnoses and procedures avoid the terms ending in ‘Not otherwise specified’ (NOS). We ask all participants to code these diagnostic and procedural terms to more detail. For example, the term ‘TGA, NOS’ should not be utilized—instead, one should specify whether the diagnosis is actually ‘TGA, IVS’ or ‘TGA, VSD’ or ‘TGA, VSD-LVOTO’ etc. This change will add much greater clarity for diagnostic groups such as TGA, where at present TGA NOS is the most prevalent diagnosis.
4.6. Methodology needs to be developed and implemented to assure and verify data completeness and data accuracy
As stated above, four items are necessary to create a meaningful outcomes analysis system: a common language or nomenclature, a mechanism of data collection or database with an established minimal database dataset, a mechanism of evaluating case complexity, and a mechanism to assure and verify data completeness and accuracy. The common language or nomenclature has been created by the International Congenital Heart Surgery Nomenclature and Database Committee [12] and is being further enhanced by the creation of the International Pediatric and Congenital Cardiac Code (IPCCC) by the Nomenclature Working Group discussed below. The mechanism of data collection or database has an established minimal database dataset used by both the STS and EACTS [12,13]. The mechanism of evaluating case complexity is now functional and undergoing validation under the direction of the Aristotle Committee [14–16]. The greatest remaining challenge is the fourth requirement: developing a mechanism to assure and verify completeness and accuracy of the data set.
The STS must develop and implement techniques to assure and verify that the data set is both complete and accurate. Validation of the complexity scoring system must also occur on two levels: First, one must verify that the outcomes data set is both complete and accurate. Second, one can then begin to validate the technique of stratification of case complexity.
Multiple potential solutions exist to aid in developing a mechanism to assure and verify data completeness and accuracy. The United Kingdom utilizes a database, The United Kingdom (UK) Central Cardiac Audit Database (CCAD), which verifies mortality through a separate National Death Database. The STS might follow this model of external database verification. Another potentially complementary option for verifying data is the creation of a system of site visits whereby STS Database Representatives can visit each others programs and perform standardized data verification to assure both data completeness and accuracy. These site visits would ideally be conducted by surgeons who are knowledgeable and experienced in the specialty. Site visits by surgeons might be challenging secondary to the financial expense and time commitments necessary. A more realistic option might be hire a full time nurse practioner (ARNP) with expertise in congenital heart disease and have this full time dedicated professional make multiple site visits throughout the year to verify data completeness and accuracy. This STS Database Representative, either surgeon or ARNP, would work closely with the STS Congenital Heart Surgery Database Taskforce and report to its members.
|
5. The nomenclature working group |
|---|
|
TopAbstract1. Introduction2. Materials and methods3. Results4. Discussion5. The nomenclature working...6. SummaryAppendix A. Conference...Appendix B. The Aristotle...Appendix C. The Aristotle...2. The International Working...References |
|---|
The first International Summit on Nomenclature for Congenital Heart Disease was held on 27 May, 2001, in Toronto, Canada, just prior to the Third World Congress of Pediatric Cardiology and Cardiac Surgery. The first meeting of the International Nomenclature Committee for Paediatric and Congenital Heart Disease was held immediately after the Summit. At this meeting, a subcommittee entitled ‘The International Working Group for Mapping and Coding of Nomenclatures for Paediatric and Congenital Heart Disease’ was formed, to have the abridged name of the Nomenclature Working Group (chaired by Christo I. Tchervenkov) (Appendix D). Included in the subsequent publications of the Nomenclature Working Group [25–29] are several rules for nomenclature that deal with some of the ‘lessons learned’ discussed in this manuscript.
The primary goal of the Nomenclature Working Group is to create a comprehensive and all-inclusive international nomenclature system for pediatric and congenital heart disease through the process of cross-mapping existing nomenclature lists including the following (alphabetically listed):
This comprehensive and all-inclusive international nomenclature system will be named the International Pediatric and Congenital Cardiac Code (IPCCC). Mapping the AEPC and EACTS–STS nomenclature is an enormous project and a number of surgeons and physicians are spending a great deal of time doing it. Concerns exist that the IPCCC would add to the complexity of data collection and make data verification very difficult. This concern is without merit because the IPCCC will allow users to utilize both the EACTS–STS nomenclature Short Lists and Long Lists. The Short Lists will continue to be used in the EACTS and STS database. These Short Lists will serve the purpose of multi-institutional outcomes analysis with a simple nomenclature system designed to facilitate straightforward data entry and data verification. The Long Lists, on the other hand, will not play a role in the multi-institutional outcomes analysis of the EACTS and STS database. Nevertheless the Long Lists are extremely important for multiple other purposes such as electronic medical record software and echocardiography software. Clearly, development of the IPCCC Short Lists and Long Lists in parallel is beneficial.
The efforts of the Nomenclature Working Group have allowed further clarification of several issues concerning nomenclature and databases that have been difficult to resolve. These issues directly relate to some of the ‘lessons learned’ discussed in this manuscript. Four of these issues that have been further clarified by the proceedings of the Nomenclature Working Group are discussed in this manuscript:
Optimal performance from systems of nomenclature and a database only can be expected in an environment where the database, or system for entry of data, has certain standard regulations and requirements. The person entering the data, the nomenclature coder, must be forced to choose from the choices in the list of nomenclatures, and not be allowed to type free text directly into the fields for ‘Diagnoses’ and ‘Procedures’. A separate ‘Comments’ field will then allow further free text to add additional description to any individual diagnosis or procedure that has been chosen. The nomenclature systems, and databases themselves, will work effectively in environments that follow this basic rule or principle. This fundamental principle also leads to logical solutions for the first two issues above.
All terms in the nomenclature lists theoretically end in NOS or (unspecified), in that one can always create further subdivisions for virtually any diagnosis or procedure. The generic term on its own is self explanatory, without the need for other clarifying nomenclature, such as NOS or (unspecified) being affixed. These suffixes are consequently not necessary.
The terms ending in Other in the EACTS–STS nomenclature lists are problematic for several reasons. The appendage Other could confer different meanings to a term depending on the list in which it is included, and any entry containing the appended term Other may change meaning over time as additional terms are added to the parent list from which the term is derived. The purpose and original intent of these appended terms in the EACTS–STS lists was to allow for the further description of related terms or choices not appearing in the list, similar to the use of the suffix (DESCRIBE) in the AEPC lists. The initial proposed solution for the discrepancy between terms ending in Other in the surgical lists, and (DESCRIBE) in the European lists, was to convert the terms ending in Other in the surgical lists to (DESCRIBE), as this would circumvent the above shortcomings and implications inherent in the word Other. It is apparent, however, that there is no longer a requirement to specify that a family of terms can have further items added, when the database environment follows the rule discussed above; namely, that no free text is permitted in the fields for ‘Diagnoses’ or ‘Procedures’, whilst a separate ‘Comments’ field exists to allow further description of any chosen item. Thus, theoretically, all terms in the lists are suffixed with (DESCRIBE), and the coder has the option to add further detail to any selected term. As a consequence, generic family terms ending in (DESCRIBE) or Other become redundant.
When discussing cardiac chambers, such as atriums and ventricles, and spatial relationships, the words left and right can be confusing. Rules were therefore created to provide consistency and accuracy of descriptive terms of anatomical phenotypes. For cardiac chambers, unless otherwise stated, left refers to morphologically left, and right refers to morphologically right. Thus, left ventricle means the morphologically left ventricle, left atrium refers to the morphologically left atrium, and right atrial appendage refers to the morphologically right atrial appendage, and so on. When discussing cardiac chambers, the words left and right do not imply sidedness or position. If one wishes to describe the position or sidedness of a cardiac chamber, it is necessary to use terms such as left-sided ventricle. The term left ventricle, therefore, merely means the morphologically left ventricle, and does not mean or imply left-sidedness or right-sidedness. Similarly, it does not imply connections to the right or left atrium, or the pulmonary or systemic circulations. In contrast, when describing the superior caval vein, and using the prefix left or right, it is the spatial position that is being alluded to, rather than any other connection or phenotypic variation that may exist.
A final issue is that the structure of the two systems for nomenclature (the AEPC Nomenclature Lists and the EACTS–STS Nomenclature Lists) differs fundamentally, this being most apparent when comparing the two Long Lists. The International Congenital Heart Surgery Nomenclature and Database Project uses a tree for its hierarchical structure, with an incrementally more complex diagnostic or procedural combination of terms. Each combination is considered a single diagnostic unit, which theoretically would have its own numerical code, had the system adopted one. These combination terms are analogous to molecules made up of individual atoms. In contrast, the European Paediatric Cardiac Code of the AEPC is largely constructed in an ‘atomic’ way, so that a complex diagnosis would have separate numerical codes for each element. This means that a map between the two systems often leads to a series of codes in the ‘atomic’ European Code being equivalent to one ‘unit’ of diagnosis or procedure in the ‘molecular’ Surgical Code. Thus, the combination term from the surgical nomenclature TGA, VSD-LVOTO is equivalent to the three entries in the European Paediatric Cardiac Code: Discordant VA connections (01.05.01), VSD (07.10.00), and LV outflow tract obstruction (07.09.01). In the mapping of the nomenclature Short Lists, this has been addressed by ‘boxing’ together groups of terms from the European Paediatric Cardiac Code, and listing them at the end of the crossmap of the European Paediatric Cardiac Code to the International Congenital Heart Surgery Nomenclature and Database Project Short Lists as an Appendix, whilst integrating them into the structure of the reverse crossmap. Exceptions to this configuration are a few common combinations of lesions that are so routinely associated with each other that they have been grouped as one discrete diagnosis or procedure in both systems. Examples are: ‘Pulmonary atresia with VSD’ or ‘Arterial and atrial switch procedures (double switch)’. In these examples, the molecular form of the nomenclature appears in both lists.
|
6. Summary |
|---|
|
TopAbstract1. Introduction2. Materials and methods3. Results4. Discussion5. The nomenclature working...6. SummaryAppendix A. Conference...Appendix B. The Aristotle...Appendix C. The Aristotle...2. The International Working...References |
|---|
Disclosure
Jeffrey P. Jacobs, MD is the medical advisor for CardioAccess, Inc.
|
Acknowledgments |
|---|
We also acknowledge the contributions of DCRI, the Aristotle Committee (Appendix B and C), and The International Working Group for Mapping and Coding of Nomenclatures for Paediatric and Congenital Heart Disease (Nomenclature Working Group) (Appendix D).
|
Footnotes |
|---|
1 http://www.heartsurgery-csa.com. 
Nomenclature Mapping Group Executive Committee Members.
Appendix A. Conference discussion
Top
