Life Table Analysis System

The NIOSH Life Table Analysis System (LTAS.NET) is a software tool used to analyze groups (“cohorts”) of people (usually workers) who are followed over time to determine if disease incidence or mortality is higher than expected among the group, either compared to a referent population or internally to compare higher- with lower- exposed people. In life table analyses, person-time and observed events are grouped into strata; standardized event rates are calculated among the strata to produce a standardized event ratio (compared to either a general population or to a group within the cohort). The standardization variables generally include age, sex, race, and calendar year. NIOSH has developed and distributed Life Table Analysis programs since the 1970s. The new system, LTAS.NET, was released in August 2007; version 3.0 was released in May 2010; and version 4.0 was released in January 2016.

The previous version, PC-LTAS, was created in the mid-1990s as a DOS-based program for the personal computer. There were several reasons why NIOSH has created a new version for Windows, called LTAS.NET. The DOS environment has become unreliable in modern personal computing environments. There were also requests by users for new features that could not be accommodated in PC-LTAS. Lastly, minor discrepancies were noted in date handling and some statistical calculations that have been resolved in LTAS.NET.

The most obvious difference is the computing platform. LTAS.NET is a stable, user-friendly and reliable NIOSH life table analysis system for the Windows environment. It is written in Microsoft® database engine platform, developed using Microsoft® Visual Studio®.NET and Microsoft® SQL Server Desktop Edition.

Other differences include:

• LTAS.NET has more flexible options than PC-LTAS for importing and analysis of data and reporting of results.
• The user can stratify on any number of user-defined fixed and time-dependent covariates and can analyze more than a single exposure simultaneously.
• The user can include a global categorical indicator variable that changes for everyone at the same time point
• The user can stratify workers by active and inactive employment status, with inactive status lagged by any length of time desired.
• There are two options for handling events and person-time that lag to zero. The user can include these in the lowest exposure category (default), or choose to include them in a separate category, as was done in PC-LTAS.
• The user can export stratified event and person-time data for more complex analyses (e.g., Poisson regression) in other software.
• Slight errors and inconsistencies in handling of dates and flagging of significance were corrected in LTAS.NET.

The major change in LTAS 3.0 was to make it compatible with Windows Vista and Windows7. We also changed the way the rate files are loaded in (we combined the cause map with the rate file). All changes are listed in Major Changes in LTAS.NET version 3.0 on the NIOSH/LTAS website.

The major change in LTAS 4.0 was to make it compatible with Microsoft SQL Server 2014. We also updated the data requirements for non-terminal outcome studies, corrected the algorithm for computing SMR p-values; addressed some issues with the personal cumulative dose reports, and disabled the standardized rate ratio reports when the horizontal variable (column variable) reflects time since first/last exposure. All changes are listed in Major Changes in LTAS.NET version 4.0 on the NIOSH/LTAS website.

LTAS.NET version 2.0 supports Windows 98/NT/2000/XP and projects will have a “*.ltas” extension.

LTAS.NET version 3.0 supports Windows XP/Vista/7 and projects will have a “*.ltas3” extension. If you have Windows XP, you may operate LTAS.NET 2.0 and 3.0 side-by-side.

LTAS.NET version 4.0 supports Windows 7 SP1/8/8.1/10 64-bit and projects will have a “*.ltas4” extension.  If you have Windows 7 SP1/8/8.1/10 64-bit you may operate LTAS.NET 3.0 and 4.0 side-by-side.  The 32-bit version of Windows 7/8/8.1/10 is not supported.

Please direct all inquiries about the software to nioshltas@cdc.gov.

With the release of LTAS.NET, NIOSH will no longer provide access to the older, DOS-based version of the Life Table program, PC-LTAS. NIOSH will no longer create new rate files for PC-LTAS. However, existing rate files for PC-LTAS will still be made available for download, for the benefit of current users of PC-LTAS.

With the release of LTAS.NET 4.0, NIOSH will no longer support older versions of LTAS.NET.  This is because older versions of LTAS.NET use Microsoft SQL Server 2005 and Microsoft will stop providing security updates after April 12, 2016.

To convert a project saved in LTAS.NET 3.0 to a LTAS.NET 4.0 project, click File, Open Project, and use the drop down arrow in the bottom right hand corner to change the default setting from “LTAS 4.0 projects (*.ltas4)” to “LTAS 3.0 projects (*.ltas3)”.  Navigate to the project file (with extension .ltas3) and click Open.  LTAS.NET 4.0 will prompt you to create an upgraded version of the project.  Click Yes and proceed to specify the new project filename.  It is highly recommended that you re-import and re-stratify your data prior to generating Analyze reports.

We found there were too many variants based on the objectives of each cohort study to provide a generalized conversion program (for example, the user may need to make a new history file that incorporates several time-dependent covariates, as well as a person file that includes fixed additional covariates like SES).

The PC-LTAS demographic file can generally be used as the source of the Person file in LTAS.NET, selecting the variables needed as directed in the file input wizard in LTAS.NET. One can also easily create the Outcome file from the demographic file provided one recodes the ICD codes to include the decimal, if it exists in that code, and also adds variables to indicate whether the outcome is terminal (i.e., a cause of death) and whether it is underlying (see example SAS code below for a study using underlying causes of death only).

Data outcome;
set demogr;
length ucod $ 5;
term = ‘T’;
und = ‘T’;
if substr( ucod, 4, 1) = ‘X’ then
ucod1 = substr( ucod, 1, 3);
else if length( trim( ucod)) > 3 then
ucod1 = substr( ucod, 1, 3) || ‘.’ || substr( ucod, 4, 1);
else
ucod1 = ucod;
run;

The PC-LTAS personal dose file can also generally be used as the history file without problem, if just a single time-dependent exposure (say, badge dose) is of interest. If use of duration of employment is also desired, then a “1” should also be included as the exposure level during the time periods over which employment occurs. This assigns a daily “exposure” of 1 day for each day of work (assuming a 365.25-day work-year). If one wishes to use area dose or include more than one time-dependent exposure, it is best to start fresh because each line within the history file is a time period over which each time-dependent exposure is presumed to be a constant daily exposure.

When I run a cohort through LTAS.NET when the NIOSH 119 minor rate file is specified and the outcome file option to use the ICD revision “In Effect at the Time of Death” is selected, I noticed that ICD codes for all deaths occurring 1940-1949 are listed as an outcome file redemption with exception type “Unknown ICD”; however, the ICD codes for deaths occurring 1950-1959 are not described in this way. Is something wrong?

The NIOSH 119 minor rate file begins in 1960 and includes codes from the 7th, 8th, 9th, and 10th revisions of the ICD. Deaths in 1940-1948 are assigned to the 5th revision of the ICD and deaths in 1949 are assigned to the 6th revision of the ICD. Since LTAS.NET verifies ICD codes for all outcomes against the rate file prior to rejecting outcomes for “Occurrence Date not in rates”, outcomes with codes under the 5th and 6th revisions of the ICD will be flagged as “Unknown ICD”. The user should be cautioned to check codes flagged as “Unknown ICD” for outcomes coded to the 7th, 8th, 9th, and 10th revisions of the ICD when the NIOSH 119 minor rate file is used; however, 5th and 6th revision codes flagged as “Unknown ICD” are not necessarily invalid.

When I run a cohort through LTAS.NET using the NIOSH 119 minor rate file and the time at risk option to end risk accumulation for workers lost to follow-up at the “Earlier of Date Last Observed or End of Study” is selected, I noticed that workers who are lost to follow-up prior to 1960 are not “rejected”, rather they receive a warning “rates not available – DLO”. In addition, these workers are “counted” in the LTAS.net import data processing window although they contribute 0 person-years at risk. Is something wrong?

The NIOSH 119 minor rate file begins in 1960. Workers lost to follow-up prior to 1960 will not contribute person-years at risk to the analysis, unless the user specifies “End of Study” for the time at risk option to end risk accumulation. The user should be cautioned that, in LTAS 3.0 (and earlier versions), when “Earlier of Date Last Observed or End of Study” is specified, when “Earlier of Date Last Observed or End of Study” is specified, workers who are lost to follow-up prior to 1960 are not rejected per se and therefore, the number of persons described as “available” at the end of import includes workers lost to follow-up prior to the rate begin date. Users may wish to subtract persons lost- to-follow-up prior to 1960 from the number of persons reported as “available”. However, the reported person-years at risk are correct for the cohort.

This has been corrected in LTAS 4.0 (i.e., rule PC100x enforces the requirement that the DLO be in the rate file). 

In looking at the import history file warnings report I am getting the message “> 1 history exception” for several workers. When I review their history data I can find no reason for exceptions. Why am I getting this message?

When you receive this message look first at the person file rejection report. It is possible that the person has been rejected and that is why their history data is receiving the exception.

In developing LTAS.NET, we discovered some inconsistencies in the way that PC- LTAS handles dates and transition days between stratified categories. The method used by LTAS.NET and how it differs from PC-LTAS are described in detail in Appendix A of the documentation (it can be found easily by searching on “date handling” from the Help pulldown menu). Extensive testing has confirmed that LTAS.NET is correctly stratifying data according to the description in Appendix A of the User’s Guide.

LTAS.NET imposes a limit during stratify, but the limit is a function of both (a) the number of stratifier variables selected and (b) the number of categories associated with each variable. There are separate limits for fixed categorical variables and temporal variables (including global categorical, temporal categorical, and accumulating exposure agents). The intrinsic stratifier variables (usually gender, race, age and calendar period) are NOT included in the limit.

Let n₁ be the number of fixed categorical variables selected during stratify; F_i be the number of categories associated with the i^th fixed categorical, i = 1, 2 … n₁; n₂ be the number of temporal variables selected during stratify; and T_j be the number of categories associated with the j^th temporal variable, j = 1, 2 … n₂. The limit imposed by LTAS.NET is that both

Σ _i ⌈ log₂ F_i ⌉ < 64 and Σ _j ⌈ log₂ T_j ⌉ < 64

where ⌈ x ⌉ denotes the “ceiling” function. ⌈ x ⌉ is the smallest integer that is greater than or equal to x. Some examples:
⌈ 1 ⌉ = 1
⌈ 1.1 ⌉ = 2
⌈ 1.99 ⌉ = 2
but ⌈ 2.0000000001 ⌉ = 3.

For example, suppose that in addition to gender, race, age, and calendar period, the user selects a global categorical variable for decade (7 categories), a fixed categorical variable that denotes facility (24 facilities), a temporal categorical variable fo r smoking status (3 categories), and a single accumulating exposure agent. Further suppose that the user selects duration, level, TSFE, and TSLE for the exposure agent and specifies cutpoints that result in 3, 30, 5, and 3 categories, respectively. Then F₁ = 24, T₁ = 7, T₂ = 3, T₃ = 3, T₄ = 30, T₅ = 5, and T₆ = 3. Since both log₂ 24 = 5 < 64 and log₂ 7 + log₂ 3 + log₂ 3 + log₂ 30 + log₂ 5 + log₂ 3 = 3 + 2 + 2 + 5 + 3 + 2 = 17 < 64, both limits are satisfied.

Next suppose that in addition to the previous 7 stratifier variables, the user selects 6 additional exposure agents, each with attributes level (30 categories) and TSFE (5 categories). Since log₂ 30 = 5 and log₂ 5 = 3, the new sum for T_j is 17 + 6(5 + 3) = 65, which exceeds the limit. In this case, LTAS.NET will display the warning message: “Arithmetic operation resulted in an overflow.” The user is prompted to select “OK” to this message, at which time stratify terminates.

Users who encounter this scenario should not attempt to create analyze reports because there will be no person-time or observed deaths to analyze. The user will need to step through the stratifier wizard a second time, reducing the number of stratifier variables and/or the number of cutpoints associated with each variable, until both sums are less than 64.

Recall that exposure agents and temporal categorical variables are used to represent variables that are associated with a particular person but may change over time. Exposure agents are used to represent numeric, non-negative (accumulating) exposures (e.g., a daily average asbestos exposure level in fibers/ml); whereas, temporal categorical variables are used to represent categorical (non-accumulating) variables (e.g., smoking status: non-smoker, current smoker, and former smoker). In order to understand how LTAS.NET assigns numerical exposure agents and temporal categorical variables to time periods that are not explicitly specified in the history file, it is necessary to first understand how LTAS.NET treats history records with invalid or unexpected values for these variables: ” Any history file record that includes an imported exposure agent with a missing, character, or negative value will be rejected during Import. The Import Exceptions Report will list the rejection long with the reason “Invalid value”.

Any history file record that includes an imported temporal categorical variable with a missing value will be rejected during Import. The Import Exceptions Report will list the rejection along with the reason “Stratifier is blank”.

Other reasons for which history file records are rejected during Import are described in Appendix C of the LTAS Manual (e.g., Begin Date after End Date results in a rejection of the history record). If two or more history file records for the same person are rejected during Import, the Import Exceptions Report will contain a warning (“> 1 history exception”). Any person with all history records rejected during Import will also be rejected during Import and identified in the Import Exceptions Report along with the reason “No history accepted”.

The “LTAS-derived risk begin date” is the latest of the rate begin date, the qualifying birth date, and any optional dates specified in the Time at Risk Options screen during the Import Wizard. LTAS.NET stratifies all person-time from the “LTAS-derived risk begin date” through the risk end date into groups defined by the intrinsic stratifiers (e.g., gender, race, age group, and calendar period) plus any extrinsic stratifiers (e.g., asbestos-duration, asbestos-level, and smoking status). In order to do this, LTAS.NET must assume values for any exposure agent and temporal categorical variable included during Import for periods of time that are not explicitly included in the history file. Time periods that are not explicitly specified in the history file are called gaps. There are three types of gaps:

1. Anterior gaps represent time from the LTAS-derived risk begin date through the earliest history begin date. Anterior gaps are not “explicitly” filled and will only be present when the LTAS-derived risk begin date is prior to the history begin date.
   • Exposure agents are assumed to be zero for anterior gaps.
   • Importing temporal categorical and subsequently selecting one or more temporal categorical during the Stratify step will cause LTAS.NET to exclude all time in the anterior gap interval. The Stratify Rejects Report will identify persons with rejected person-time at risk because a temporal categorical variable was undefined.
2. Interior gaps represent time periods between the history end date for a given record and the history begin date for the next consecutive history record. Interior gaps are explicitly “filled” during Import. The number of interior gap fills will be enumerated in the Import Dialog Box.
   • Exposure agents are assumed to be zero for interior gaps.
   • Temporal categorical variables are assumed to be the most recent value for interior gaps.
3. Posterior gaps represent time from the latest history end date through the date last observed (DLO). Posterior gaps are not explicitly filled.
   • Exposure agents are assumed to be zero for posterior gaps.
   • Temporal categorical variables are assumed to be the most recent value for posterior gaps.

Temporal categorical variables are useful for representing exposure status variables that change over time, but that are not quantitatively accumulating.

Examples of temporal categorical variables include

• Ever/never type exposure variables (e.g., ever exposed to asbestos could be included as a temporal categorical variable with values “yes” and “no”)
• Peak or highest exposure group (e.g., suppose employment periods were rated for potential to exposure using three categories: low, medium, and high. A temporal categorical variable could be included with values of “low”, “medium” and “high” to represent a worker’s highest category to-date)
• Exposure monitoring status (e.g., for a particular study, workers were classified as not monitored; ever monitored, but exposure was negative; ever monitored with some positive exposure)
• Cigarette smoking status (e.g., a temporal categorical variable could be used to represent cigarette smoking status using categories of non-smoker, current smoker, and former smoker).
• Exposure that should not be considered qualitatively cumulative (e.g., in a study examining risk of falls from a ladder, a temporal categorical variable could be used to indicate periods of active employment in construction separately from periods of other employment and periods of unemployment),

Depending on study objectives, for some variables it may be important to maintain a particular ordering of the categories. For example, if a temporal categorical variable was used to represent cigarette smoking status with three categories – non-smoker, current smoker, former smoker – a person could not become a non-smoker if they had previously been a current or former smoker. LTAS.NET, however, does not require any particular ordering, nor does it check for deviations from any assumed ordering. Gaps in the exposure history file (both interior gaps and an assumed gap between the exposure history end date and the risk end date) are assigned the most recent value of the temporal categorical; researchers should ensure that this is a valid assumption when interpreting results stratified by a temporal categorical variable.

When a lag period is applied to an exposure agent, the user is given the option to “use a separate category for exposure lag time.”

If the box is checked (i.e., requesting that LTAS.NET use a separate category for exposure lag time), then a worker with zero exposure to that agent will have person-time occurring between the “LTAS-derived risk begin date” (see Q-S3 for a definition) and this date plus the lag time length assigned to the “lagged time” category. Any subsequent person-time for such a worker is assigned to the lowest exposure category.

If the box is not checked, then a worker with zero exposure to that agent will have all person-time assigned to the lowest exposure category.

This is due to an unresolved bug in LTAS.NET (versions 3.0 and earlier) that occurs when a lag of more than 265 days is used. There is no problem in using lags of more than 265 days if the units are in years rather than days. Until this bug is resolved, users should employ units of years rather than days for lags of longer than 265 days.

This bug has been fixed in LTAS.NET version 4.0.

When I used quartiles of cumulative exposure from decedents as cutpoints when stratifying on that exposure level, I expected to get the same number of deaths in each of the categories defined by the quartiles.  For some outcomes this was the case, but for others, the numbers were slightly off.  Is LTAS.NET doing something wrong? 

There are a couple of reasons that could explain this behavior in LTAS.NET.  

The first explanation involves the concept of transition dates which are explained in detail in Appendix A (LTAS Date Handling and Lag) in the LTAS User’s Guide.  A transition date for an accumulating exposure is defined as the first day that the accumulated exposure (at the beginning of the day) is greater than or equal to the threshold value for that category. Supposed the 25th percentile for cumulative exposure among all decedents is 1000 unit-days based on one decedent with a single exposure history record:

Note that for this subject, the number of days of exposure is 500 (5/14/2001 – 1/1/2000 + 1) and cumulative exposure is 1000 unit-days (500 days × 2 units = 1000 unit-days).  Specifying cutpoints of 0 and 1000 unit-days in the Stratify Wizard creates two cumulative exposure categories:  0-<1000 unit-days and 1000+ unit-days.  The date that this subject transitions from category 1 to category 2 is 5/15/2001 (the transition date is not 5/14/2001 because cumulative exposure at the beginning of the day on 5/14/2001 is only 998 unit-days).   If this subject died on 5/14/2001, the death (and all person-time) would be assigned to the first cumulative exposure stratum; however, if the subject died on 8/1/2005, the death (and person-time from 5/15/2001 to 8/1/2005) would be assigned to the second cumulative exposure stratum.  Consequently, if any of the cutpoints specified in the Stratify Wizard are based on percentiles from subjects who died while they were actively being exposed, the distribution of outcomes in the exposure categories may not be uniform, even if percentiles are used to define the categories.

Another explanation involves small sample sizes and non-unique cumulative exposure values (i.e., more than one case with the same cumulative exposure).  For example, suppose there are 20 decedents with the following cumulative exposure values:

      10 10 10 10 10 20 20 20 20 20 30 30 30 30 30 40 40 40 40 40

In this situation, specifying the quartiles (15, 25, and 35) would evenly divide the decedents into four groups with five decedents in each group.  Next suppose that the cumulative exposure values were instead:

      10 10 10 10 10 10 10 20 20 20 30 30 30 40 40 40 40 40 40 40

In this situation, specifying the quartiles (10, 25, and 40) would not evenly divide the decedents; rather there would be 0 decedents in category 1, 10 decedents in category 2, 3 decedents in category 3, and 7 decedents in category 4.  With this distribution of cumulative exposure, it is not possible to select cutpoints to evenly divide the decedents.

In LTAS.NET 4.0, when I attempt to create an SRR grid report with a TSFE (or TSLE) type variable as the horizontal axis variable, I get a warning message that states “Function disabled due to a potential issue (“sparse data bias” not related to LTAS algorithm) with TSFE/TSLE in SRR analyses.” and I am not able to specify this variable as the horizontal axis variable. What does this mean?

A potential issue (“sparse data bias”) has been found in SRR analyses that are available in LTAS.NET (3.0 and earlier) – this relates primarily to time since first/last employment/exposure (TSFE/TSLE). The issue isn’t the LTAS algorithm, as different similar approaches (e.g., M-H) led to the same problem; consequently, in LTAS 4.0, the capability of producing SRR analyses with TSFE/TSLE as the horizontal axis variable has been removed.

In LTAS.NET 4.0, after upgrading an LTAS.NET 3.0 project to 4.0, when I click on Analyze Data, sometimes I get a warning message that states “Function disabled due to a potential issue (“sparse data bias” not related to LTAS algorithm) with TSFE/TSLE in SRR analyses.”. What does this mean?

In all likelihood, the most recently run report (in LTAS 3.0 or earlier) prior to upgrading involved either time since first exposure (TSFE) or time since last exposure (TSLE) on the horizontal axis of a grid report.  These reports are now prohibited in LTAS 4.0.  Continue specifying the desired report in Analyze Data taking care to not specify TSFE/TSLE as the horizontal axis variable.

In LTAS.NET 4.0, sometimes when I attempt to run a report that was created in LTAS.NET 3.0, I get an unhandled exception error.  What does this mean?

In all likelihood, the previously saved report (in LTAS 3.0 or earlier) is now prohibited because it specified either time since first exposure (TSFE) or time since last exposure (TSLE) as the horizontal axis variable.  Use the Manage Reports utility under Analyze Data to either delete the prohibited report or customize the report to remove TSFE/TSLE as the designated horizontal axis variable.

If you have access to the rate description (input) file (*.xml), you can use the Manage Rates utility.  Click Manage Rates, Import Rate Set, and navigate to the rate set description file (*.xml). Click OK, and LTAS.NET 4.0 will convert the rate description  file to a rate set file that can be used in LTAS.NET 4.0 projects.  This file will have an extension .rateset4 and will be located in the Rates folder (usually C:\My LTAS Projects\Rates).

If you do not have access to the rate description file, you can copy the LTAS.NET 3.0 .rateset file to a new file, and change the extension to .rateset4.  As long as this file is located in the Rates folder (usually C:\My LTAS Projects\Rates), it will be available for LTAS.NET 4.0 projects.

Currently, the LTAS.NET software contains underlying cause of death (UCOD) rates for the U.S. population from 1940-2014 (NIOSH-92) and an expanded set of rates for the U.S. population from 1960-2014 (NIOSH-119). These rate files currently contain actual data through 2009, with the rates for the five-year period 2010-2014 copied from 2005-2009. Further information about these rates is provided in Robinson et al. (2006). J Occ Environ Med 48:662-667. Multiple cause-of-death rate and proportion files for the U.S. population are also included in LTAS.NET version 4.0.

I would like to import a rate file containing updated rates through 2014, but I have already previously imported the same rate file containing rates through 2002 or 2005. How do I accomplish this?

The answer to this depends on whether you are using LTAS.NET version 4.0, 3. 0 or 2.0. LTAS.NET 4.0 contains updated rates through 2014. To delete any obsolete rate files from LTAS.NET 3.0 or 4.0, simply go to the storage location for the rate files (default location is C:\My LTAS Projects\Rates) and delete the rate file that is no longer needed.

If, however, you are using LTAS.NET version 2.0, a more complicated procedure is required. The file name for the rate file, and the “name” and “description” within the XML file should all be different from those used in the previous version of the rate file. In creating the updated rate files, the “description” includes the year range from which rate file was created (e.g., 119 Underlying cause Death Rates 1960-2005), which differs from the previous version of the rate files. This “description” is how the file will be listed in the pull-down menu of the Import wizard of LTAS.NET. The “description” for any previously imported version of the rate file (e.g., 119 Underlying cause Death Rates 1960-2002) will still be listed as well in the pull-down menu of the Import wizard of LTAS.NET, so users should choose rate files carefully from the pull-down menu.

Yes, if you are using LTAS.NET version 3.0 or higher (but no if you are using version 2.0). For this reason, we recommend users upgrade to the most recent version (i.e., 4.0). See the Q-R3 for an explanation of the best way to handle re-uploading of new versions of rate files with the two different versions.

Rate files may be created easily by the user for LTAS.NET. This is done most easily in LTAS.NET version 3.0 or higher. In the rate file, the user must first create a cause map is created (this may be copied from the two default maps in the LTAS.NET 3.0 NIOSH-92 and NIOSH-119 rate files), and a rate set is created with the actual rate data. This process is described in Appendix E of the documentation for LTAS.NET.

I noticed that some of the rate file categories appear to differ between the standard (92-cause) and expanded (119-cause) rate files. Why are they different?

The following table documents the differences between the two rate files. Further information is provided in Robinson et al. (2006). J Occ Environ Med 48:662-667. The NIOSH-92 and -119 categories are described on the rate file information page on the NIOSH/LTAS website.

I just read about the updated version, and it appears that the mortality rates included in the program run through 2014. Do the rate data actually go through 2014?

All NIOSH rate and proportion files released with LTAS.NET 4.0 currently contain data through 2009. The rates in LTAS.NET 3.0 for the five-year period 2005-2009 (and any period beyond it) are estimated by the rate for 2005-2007. For the most recent rate updates, please visit the Rate File Information on LTAS.NET website or our ftp site at http://ftp.cdc.gov/pub/LTAS-NET/.

Multiple cause-of-death (MCOD) rate and proportion files are pre-loaded in LTAS.NET version 3.0 or higher. If you would like to conduct MCOD analyses, we recommend upgrading to the latest version of LTAS.NET.

In testing the 1960-2002 US MCOD rates, we compared them to the 1960-2002 US UCOD rates for the 119 NIOSH minors. Generally, and as expected, the MCOD rate was greater than or equal to the UCOD rate; however, there were some instances for which the MCOD rate fell below the UCOD rate (approximately 4.5% of the rates):

• (a) A majority of these (78%) involved calendar periods 01 (1960-1964) and 02 (1965-1969). Since MCOD information was not available prior to 1968, the 1965-1969 rate was based on data from 1968-1969 (1968 data was used for 1965-1967) and the 1960-1964 rate was assigned the 1965-1969 estimated rate. Consequently, for diseases that were rapidly increasing or decreasing in the 1960s, the 1960-1964 rate (and possibly the 1965-1969 rate) are somewhat inaccurate.
• (b) The remaining instances (22% or about 1% of the overall rates) involved calendar periods in 1970 and later, but the reasons for these are not clear. Some instances involved calendar period 05 (1980-1984) and could have resulted from the lack of 100% MCOD coding in the years 1980 and 1982. Other instances involved Minor 014 (MN of Peritoneum and other and unspecified of digestive organs) for calendar period 09 (2000-2004) and could have resulted from changes in coding rules (e.g., a death certificate with C23 (MN of gall bladder) and C259 (MN of pancreas- unspecified) was assigned a UCOD of C269 (malignant neoplasm of other and ill- defined digestive organs – Ill defined sites within the digestive system), even though this cause, per se, did not appear on the death certificate). Still others involved age category 15 (85+ years). We will further investigate these apparent errors as we update the MCOD rate files in the future.
• (c) In November 2011, we fixed problems discovered in our multiple-cause of death (MCOD) rate files included in previous versions of LTAS.NET. To see more detailed descriptions of the problems, click MCOD Problems on the rate file information page. Users can download the updated MCOD rate files from http://ftp.cdc.gov/pub/LTAS-NET/. The updated MCOD rate files are also included in the latest LTAS.NET version 3.0.5 or higher.

When re-importing a custom rate file that I had previously imported (e.g., entitled MyCustomFilename), I receive the following error message:

“Cannot associate files with different databases.
Log file ‘C:\Program Files\NIOSH\LTAS.NET\Data\MyCustomFileName_log.LDF’ does not match the primary file. It may be from a different database or the log may have been rebuilt previously.
Deleting database file ‘C:\Program Files\NIOSH\LTAS.NET\Data\MyCustomFilename.MDF’.”

What is wrong and how do I fix it?

A rate log file has become corrupted. The solution is to navigate to the subfolder named “C:\Program Files\NIOSH\LTAS.NET\Data\” in Windows Explorer, and to delete the referenced file with the .LDF extension (e.g., MyCustomFileName_log.LDF). You should then be able to re-import the MyCustomFilename rate file without further problem.

Yes. The lines within the RateData element must be sorted by Gender, Race, Age, Calendar Period and Minor ID (i.e., the order specified by the intrinsic variables in the cause map).