|
This document is available in PDF format.
Data import and processing
The following is a list of differences between the LTAS.NET Import process
and the PC-LTAS.
Verify step:
- Work History File and Exposure File are combined into a single import
file: History.
- A History File is required.
- Demographics File is split into two files: Person and Outcome.
- A mapping function allows users to adjust the import for different
input file formats.
- There is no DOD (Date of Death) field. The DLO (Last Observation Date)
is used to hold this information for deceased persons.
- Each record in the Outcome File may contain the following indicators:
- terminal indicator (T for terminal-death, F for not terminal),
- underlying indicator (T for underlying cause, F for
multiple-cause); only underlying=T will be used for an underlying-cause
analysis, and only underlying=F will be used for a multiple-cause
analysis.
- If the indicators are not included, outcomes are assumed to be
underlying and terminal (see Appendix D of the user
documentation).
- Non-cancer COD, 'PCMR error' not issued.
- 'Too many histories' error not issued because the system limit has been
removed.
- 'Default exposure used' warning not issued. A 'No history accepted'
rejection replaces this warning.
- 'Invalid DLO for VS = dead' warning not issued.
- '2 Histories Rejected' error is now just a warning.
- Date validation is more complete, generating exceptions for
non-existent dates.
- 'DLO < Rate File Begin' is now just a warning. This is because in an
"End of Study" run, subjects with a DLO occurring before the rate begin
date should be included - the program assumes their person-time ends at the
end of study date.
- Any Vital Status code other than the Alive or Deceased code is treated
as Unknown instead of defining a specific Unknown code. All Person records
with Unknown codes are redeemed as Alive.
- 'Age at Risk Begin Date < Lowest Age Category in Rates' is now just
a warning. The Risk Begin Date is not redeemed like it used to be.
- COD (Cause of Death) validation operates differently to support non-ICD
codes. Codes >= 3 characters no longer generate an exception as long as
they are defined in the mapping table. Codes that aren't defined are still
mapped to a residual although the process is different. See Disease Code
Mapping section for more details.
- History periods can now be 1 day long. PC-LTAS required all periods to
be 2 or more days long.
Disease Code Mapping
In PC-LTAS, outcomes must be coded either to the ICD revision in effect at
the time of death or to a single ICD revision. In LTAS.NET, ICD coding may be
to the revision in effect at the time of death, to a single revision, or
specified individually for each outcome in the Outcome File.
Similar to PC-LTAS, LTAS.NET translates the cause of death from the
outcome file from ICD code to NIOSH (or user-defined) minor. While PC-LTAS
uses ICD code ranges, LTAS.NET maps each ICD code individually in order to
improve the precision and accuracy of the mapping. As a result, you may
notice the following differences when comparing the mapping of your data
using PC-LTAS and LTAS.NET:
- In LTAS.NET, ICD codes require a decimal if a fourth digit is
present.
- LTAS.NET may detect invalid ICD codes that PC-LTAS does not.
- LTAS.NET may map a specific ICD code to a different and more
appropriate minor than PC-LTAS does.
Stratify Processing
The following is a list of differences between the LTAS.NET Stratify
process and the PC-LTAS
Stratify step:
- Stratification can be performed on additional confounders (not just
age, race, sex and calendar time, as in PC-LTAS)
- Single day history gaps are now filled with unexposed person time.
PC-LTAS only fills history gaps of 2 or more days.
- A zero value can be used for the first stratification category. PC-LTAS
required all values to be greater than zero.
- Stratification now supports stratification on Time Since Last Exposure
(TSLE). For workers with breaks in exposure, the latest date at which a
worker is exposed (plus any specified lag time) is used to calculate
TSLE.
- Units may be specified for exposure levels.
- Users may stratify on active and inactive work status (the latter may
be lagged by a user-specified length of time), in order to evaluate the
healthy worker survivor effect. This is calculated using the variable that
specifies employment. For workers with breaks in employment, the latest
date at which a worker is employed (plus any specified lag time) is used to
determine the date at which inactive status begins.
- In PC-LTAS, when a non-zero lag is specified, lagged-out events and
person-time are separated into their own group. In LTAS.NET, the user has
the option to include or exclude lagged-out events and person time in the
lowest exposure category.
- There are several other differences in how date calculations are
performed for calculating person time and handling exposure lagging. See
Appendix A - LTAS Date Handling for more details.
Analyze Processing
The following is a list of differences between the LTAS.NET Analyze
process and the PC-LTAS
Analyze step:
- LTAS.NET does not offer a chi-square test as did PC-LTAS
- There are more report options and more report flexibility in
LTAS.NET
- SRR results are now presented in a separate report from the SMRs rather
than reported as an additional row of data in the SMR table as in
PC-LTAS
- LTAS.NET will compute only 2-sided p values
|
Rate File Information