|
The Society of Thoracic Surgeons Frequently Asked Questions: Adult
Cardiac Surgery Database Version 2.52.1 August, 2006 How to use the interactive FAQ Document: 1. To
review all clinical questions in an individual section, click on the section
title below. |
|||||||||
|
Section A:
seq# 40-80 |
|||||||||
|
|
|||||||||
|
2.
To review an individual Seq# clinical question, click on the Seq# title
below. 1280 OpCAB
3090-3180 Section R. 3. CC/TM: Corrections/Clarifications to Training
Manual |
|||||||||
|
NEW |
Date |
SeqNo |
FieldName |
Definition |
|||||
|
From version 2.41 |
9/03 |
|
GENERAL QUESTIONS #1 |
-Patient has CABG; while still in hospital has thoracic aortic
dissection, then reop for bleeding then expires while still in hospital. -Another patient has CABG then reop for bleeding on same day during
which time the patient gets another SVG, patient discharged alive. My surgeon thinks that in both these cases, we should complete 2 STS
forms for each patient. |
The |
||||
|
|
2/04 |
|
GENERAL STATEMENT #1 |
Pre-op", "intra-op" and "post-op" defined
according to the STS Adult Cardiac Database. Pre-op: time period prior to
the OR until the patient enters the OR Intra-op: from the time the
patient enter the OR until the patient exits the OR Post-op: from the time the
patient exits the OR until the patient leaves the hospital |
|||||
|
|
3/04 |
|
GENERAL STATEMENT #2 |
ONE PATIENT ADMISSION = ONE DATA
COLLECTION FORM |
|||||
|
|
8/04 |
A patient has an AVR done. Within days a serious perivalvular leak
develops. The patient returns to the
OR during the same hospitalization for a redo AVR- first valve removed, new
valve placed. Does this reoperation
require a new Data Collection Form or is the redo AVR coded as a
complication/return to OR under the original Data Collection Form? |
ONE ADMISSION = ONE DATA COLLECTION FORM. As long as the patient does not leave the
hospital, all complications or postoperative events need to be captured in
the complications section of the original Data Collection Form. If the patient would have been discharged
and readmitted to repair the perivalvular leak, a new Data Collection Form
would need to be started. |
||||||
|
|
9/04 |
Case #1: female patient had an
AVR. Returned to surgery during the
same admission for a repair of the ascending aorta. Is the aorta repair considered a
complication from the first surgery? Case #2: female patient had a 5
vessel bypass. Within a few hours
patient had a sudden cardiac arrest, returned to surgery and had an
additional vein graft placed. |
For both cases the surgeon feels
the second surgeries should be treated as separate surgeries and collected on
a separate Data Collection Form. For the purposes of the STS, both of the second surgeries are
considered complications (or postoperative events) of the first surgery and
should be captured in the "Complications Section" of the Data
Collection Form. The general rule is
ONE ADMISSION = ONE DATA COLLECTION FORM.
If these patients were discharged and then readmitted to return to
surgery, then a new Data Collection Form would need to been completed on the
second surgeries. |
||||||
|
|
01/06 |
the patient has an original avr and
single CABG. the patient returns to the operating room 5 days later for
ishemia and has a double CABG. How do I code this? |
Code the return as a Reop Other
Cardiac |
||||||
|
|
9/04 |
|
GENERAL STATEMENT #3 |
Our cardiothoracic surgeon performed a Thymectomy in the OR as the
primary surgical procedure. Do I fill
out an STS Data Collection Form to track the procedure? |
I would. Obviously, this record
will not be included in the risk models and you will not be able to populate
all of the fields. Including all
procedures that your cardiothoracic surgeon perform into the Adult Cardiac
Database is a great way to keep track of your cardiothoracic surgeons'
procedures. |
||||
|
|
03/06 |
Should the valve repairs done via a
thoracotomy be captured in the database? It is our understanding that a
mediastinal incision should be made to be applicable to the database. |
Yes, any surgery performed on a
structure of the heart or great vessels should be included in the Adult
Cardiac Database. Surgical approach and incisions have changed over time, but
the end result is still the same - repair of a cardiac structure. |
||||||
|
|
11/04 |
|
GENERAL STATEMENT #4 |
The following guideline was
developed to assist your decision of whether or not to include a case in the
Adult Cardiac Surgery Database. 1. Patient enters OR -- no
incision -- no procedure = do not capture this procedure a. Patient in ED with torn aorta, coding as
enters the OR, dies before incision made= do not capture
this procedure 2. Patient enters OR -- with skin
incision and surgical intervention on heart and/or great vessels -- procedure
aborted = capture as "Other
Cardiac Procedure - Other" a. Patient in OR with incision, cannulated,
patient arrests and expires = "Other Cardiac Procedure - Other" b. Patient in OR for redo CABG, while
performing mediansternotomy, aorta is nicked, patient expires = "Other
Cardiac Procedure - Other" 3. Patient enters OR -- with skin
incision and no further surgical intervention -- procedure aborted = capture
as "Other Non Cardiac Procedure - Other" a. Patient enters the OR for AVR, chest
opened, Aorta too fragile, procedure aborted, no AVR = "Other Non
Cardiac Procedure - Other" |
|||||
|
|
1/06 |
What are we accomplishing by collecting the data described in General
Statement #4 from 11/04? We were
informed from STS that the "other cardiac" and "other
non-cardiac" sections were to be used in conjunction with a CAB or a
valve only. This data is not used in
harvest, correct? |
The data is used in harvest, but not for any Risk-adjusted outcomes. These
fields are NOT to be used only in conjunction with CAB or Valve surgeries.
The Adult Cardiac database is intended to include any surgery done on the
structures of the heart and/or great vessels. Advantages of including these
procedures are the ability to monitor outcomes for all cardiac surgeries,
tracking of 100% of CT surgery volume, and, as technology changes, tracking
and trending outcomes of new procedures (i.e. Arrhythmia Correction surgery,
MAZE). |
||||||
|
NEW! |
08/06 |
OpOCard |
General Statement #4 of the FAQ
will help you with decisions to include or not include patients of this type.
This would be close to Scenario #3. Include as an Other-NonCardiac Other. |
||||||
|
|
4/05 |
|
GENERAL STATEMENT #5 |
How do we code an Aortic Edwards Lifesciences Model 2625 Porcine Valve
and a Mitral Edwards Lifesciences 6625LP Porcine valve? |
The Mitral Edwards Lifescience 6625LP is listed in the 2.52.1 mitral
implant list. It is the C-E Duraflex
Porcine Bioprosthesis #76 listed on page 72 of the Version 2.52.1 Data
Specifications, and on the DCF is B28.
The Aortic Edwards Lifescience model 2625 is the C-E standard porcine
bioprosthesis # 23 on page 65 of the V2.52.1 Data Specifications and on the
DCF as B7. Both are stented valves.
Please refere to the Edwards Lifescience web site under products to
view additional information concerning the various types of valves and their
features. If you ever have a question about a specific Model number of a
valve, please refer to the manufacturer's website as most will let you search
by model number. The Valve Key includes all valves that were FDA approved at
the time when the 2.52.1 data specifications went out to the software vendors
to be upgraded back in 2003. If the exact valve name is not on the valve key
list or in the 2.52.1 data specifications and the manufacturer's website says
the valve is not exactly the same as one on the valve key, please code as
777-Other. The valve key will be updated will all FDA approved valve implants
at the time of the next specification upgrade. You might consider adding a
custom field for any time you code 777 to allow you to track devices that are
implanted that do not yet appear on the valve key. |
||||
|
|
|
10 |
Software Vendor Name |
Name (assigned by |
|||||
|
|
|
20 |
Software Version |
Vendor's software product name and version number identifying the
software which created this record.
Vendor controls the value in this field. Version passing certification/harvesting
testing will be noted at warehouse. |
|||||
|
|
|
30 |
|
Version number of the STS Data
Specifications/Dictionary, to which each record conforms. It will identify
which fields should have data, and what are the valid data for each field. It
must be the version implemented in the software at the time the data was
collected and the record was created. This must be entered into the record
automatically by the software. |
|||||
|
|
|
40 |
Participant ID |
Participant ID is a unique number assigned to each database Participant
by the Each Participant's data if submitted to harvest must be in one data
file. If one Participant keeps their data in more than one file (e.g. at two
sites), then the Participant must combine them back into one file for harvest
submission. If two or more Participants share a single purchased software, and
enter cases into one database, then the data must be extracted into two
different files, one for each Participant ID, with each record having the
correct Participant ID number. |
|||||
|
|
|
50 |
Record ID |
An arbitrary, unique number that
permanently identifies each record in the participant's database (note that
unlike the PatID value, this does not identify the individual patient). Once
assigned to a record, this number can never be changed or reused. The value by itself can be used to identify
the record in the participant's database.
When used in conjuction with the ParticID value, it can identify the
record in the data warehouse database.
The data warehouse will use this value to communicate issues about
individual
records with the
participant. This value may also be
used at the warehouse to link to other clinical data. |
|||||
|
|
|
60 |
Cost Link |
A participant specified alpha-numeric
code that can be used to link this record's clinical data with the participant's
cost information for this patient admission.
This information may be used in the future to perform procedure cost
analysis (for which the actual cost data would have to be harvested
separately). The value in this field
must not be the patient's Medical Record Number, Social Security Number or
any other patient identifying value. |
|||||
|
|
|
70 |
|
The unique identification number
assigned by the STS indicating the clinical trial in which this patient is
participating. This field should be
left blank if the patient is not participating in a clinical trial associated
with the STS. |
|||||
|
|
|
80 |
Patient ID |
This is an
arbitrary number (not a recognizable ID like SSN or Medical Record Number)
that uniquely and permanently identifies each patient. Once assigned to a
patient, this can never be changed or reused. If a patient is admitted to the hospital more than once,
each record for that patient will have the same value in this field. |
|||||