|
|
The Year 2000 Issue
Implications for Public Health Information
and Surveillance Systems
Centers for Disease Control and Prevention
White Paper - May 1996
Background
A phenomenon exists in the Information Technology (IT) industry because historically many computer programs make use of dates represented by only two digits (for example, 95 rather than 1995). However common this practice might be, it causes programs (both system and application) that perform arithmetic operations, comparisons, or sorting of date fields to yield incorrect results when working with years outside the range of 1900-1999.
The scope of the Year 2000 challenge spans the entire IT industry. A data mismatch can exist in any level of hardware or software from microcode to application programs, in files and databases, and is present on ALL platforms. In recent years, the IT trade press has given ever greater attention to this phenomenon with increasingly ominous predictions.
However dramatic all this may sound, consider the following scenarios to help put the phenomenon and its business ramifications into perspective. Imagine if in the first quarter of the year 2000 your company cannot process its 1999 end-of-year billing or end-of-year payroll properly; your corporate credit card holders are refused most transactions because their accounts appear delinquent; your 1999 year-end profit data cannot be calculated properly; and your utility companies cut off their services due to your apparent late bill payments. Similarly, your household and personal financial situation could encounter a similar dilemma if your creditors do not also strive to meet this challenge.
Although referred to as the Year 2000 issue, this is really a 2-digit-year problem. Your IS organization needs to plan for and address the date changes well in advance of 1 January 2000. This is not only a future challenge; it has existed in the banking industry since as early as 1970 when application programs encountered problems with amortization and interest table calculations for the standard 30-year mortgage. Consider also, a 5-year automobile loan, a 15-year mortgage, a long-term insurance policy, a data base that retains birth dates (which includes an ever increasing set of dates over 100 years). Now, as each month passes, more applications are uncovered that have to start immediately handling dates with the Year 2000 or beyond.
Implications for Public Health
All organizations are affected by this issue from a business and administrative perspective. However, public health information and surveillance systems at all levels of local, state, federal, and international public health are especially sensitive to and dependent upon dates for epidemiological and health statistics reasons. Date of events, durations between events, and other calculations such as age of people are core epidemiologic and health statistic requirements.
Moreover, public health authorities are usually dependent upon primary data providers such as physician practices, laboratories, hospitals, managed care organizations, etc., as the source of original data upon which public health analyses and actions take place. CDC, for example, maintains over 100 public health surveillance systems all of which are dependent upon external sources of data. This means that it is not sufficient to make internal systems compliant to the Year 2000 to address all of the ramifications of this issue. To illustrate this point, consider the following scenario: in April 2000, a hospital sends an electronic surveillance record to the local or state health department reporting the death of an individual who was born in year "00"; is this a case of infant mortality or a geriatric case?
------------------------------------------------------------------------
It is vital that the public health community begin aggressively addressing this issue
to avoid serious negative programmatic effects across public health.
------------------------------------------------------------------------
Frequently Asked Questions About the Year 2000 Issue
Q1. What is the Year 2000 issue and how did it happen?
•A1. The scope of the Year 2000 issue spans the entire Information Technology industry. The phenomenon exists because for decades it has been common practice to use two digits instead of four when storing or processing the year component of dates. This carried over when writing computer programs, especially when it comes to minimizing expensive memory space and data entry time. However common this practice, it causes computer software performing arithmetic operations, comparisons, or sorting of data fields to yield incorrect results when working with years beyond 1999. It will also cause failures of systems when using dates as triggers for process events to occur.
Q2. Whom does this impact?
•A2. It is a significant challenge across the IT industry -- for any company, social or government agency, institution or individual using computers to accomplish a task. Any system or program, including desktop software, could be affected if two digits are used for year representation.
Q3. Can't a user just switch from using two digits to four?
•A3. The process of making the change is fairly straightforward, but very time consuming. Users must first determine whether the data that represents "year" is stored as two digits and then find all the applications that use this data. If only two digits are used, the file format must be changed to four digits. Every application program that stores or references this data must also be changed. Finding all the programs that reference this data and coordinating the change are what takes time.
Q4. What actually happens if the Year 2000 issue isn't corrected?
•A4. Any computer calculation or process that involves a date -- such as a consumer credit card transaction, payroll, billing, a mortgage calculation, a time sorting routine, a timed trigger event, and so forth could yield incorrect answers or abort the process.
Q5. Why haven't we heard about this before now?
•A5. Until recently, little publicity was focused on this issue. Many companies, organizations and individuals are still not aware of the Year 2000 issue but need to start preparing for it as quickly as possible.
Q6. Why did this two-digit practice continue for so long?
•A6. For decades frugality has been the rule for programmers trying to save storage space by using only two digits to represent a year when writing or executing an application. Even when memory became relatively inexpensive the problem was never viewed as critical. Also, once established it was difficult to initiate a four-digit format because it would mean changing all existing software. Spending money on a "software maintenance" issue may not have been given high priority.
Q7. Is this a hardware or system software problem or both?
•A7. While this is primarily a software application problem, hardware clocks that generate date stamps in applications or are used for timing of application events will be problematic as well.
Q8. What should systems managers and computer users do?
•A8. System managers and users need to update applications and data fields that do not handle century markers or dates beyond 1999. Specifically they should:
•Assessment - Determine the magnitude of the problem by assessing the entire portfolio of system and application software source code and hardware platforms, including any shrink-wrapped, off-the-shelf applications, and data sources to determine what needs to be updated and made Year 2000 compliant and who should be contacted to ascertain their level of compliance. •Strategy -- Decide the best way to make the updates -- most likely on an individual, program-by-program basis. •Implement -- Make the updates to the source code; test to make sure it handles both 199X and 2XXX data correctly; and establish a procedure to ensure the source code can't be inadvertently changed back to a two-digit format. •Validate & Certify -- Move systems back into production, monitor and validate proper outcomes. Certify compliance and update the system compliance inventory. Develop any necessary bridges or conversion routines to allow for old non-compliant archived data or new non-compliant data coming from external sources to be converted into compliant format.
Q9. Why the rush -- why can't customers fix their problems and become Year 2000 Ready in 1998 or 1999?
•A9. Many customers may run out of time and not be able to alter their application portfolio if they wait. Also, the Year 2000 problem is already beginning to surface for some customers and will occur more frequently as we approach the year 2000.
Q10. Are there estimates on how difficult, how long and how much it will cost a company or individual computer user to make the transition and become Year 2000 Ready?
•A10. Making applications and system software Year 2000 Ready is a type of redevelopment project, the scope of which depends upon the size and amount of software being used. Gartner Group consultants have estimated that a typical mid-size company could spend as much as $3 million to $4 million in personnel and computer resources to make the changes. They add that large companies or organizations could spend ten times that or more. It is estimated to be a $300-600 billion world-wide problem. It is also estimated that no companies are ready now, only half will be ready by January 1, 2000, and that 20% of companies will go out of business because of the cost, liability, or catastrophic results from not being Year 2000 compliant.
Additional Information Resources Available
Most information technology vendors and consulting companies have white papers or detailed planning guides available on the subject.
•The Information Technology Association of America has produced a Year 2000 survey, buyer's guide, vendor directory, and position paper. Information can be obtained on their Internet home page or by calling (703) 522-5055. •The Information Week publication dated February 5, 1996 contained a cover story on the issue. The article and other resources are available on their Internet home page. •A Year 2000 home page on the Internet run by an independent consultant is dedicated to this issue and contains many resources including links to major I/T vendors, position papers, etc. •The National Institute for Standards and Technology, U.S. Department of Commerce, has an article entitled "MILLENNIUM ROLLOVER: THE YEAR 2000 PROBLEM". Other information is available through the NIST Internet home page. •The U.S. General Services Administration has established a Year 2000 Information Directory Home Page which provides information and connections to various Year 2000 resources. •The American National Standards Institute (ANSI) has information through their Internet home page. •IBM has a 500+ page publication entitled "THE YEAR 2000 AND 2-DIGIT DATES: A GUIDE FOR PLANNING AND IMPLEMENTATION." •The Defense Information Systems Agency provides a page dedicated to the Year 2000 Customer Off The Shelf (COTS) Products Compliance Catalog. •The Social Security Administration provides a list of Vendor Products and their Compliance Status.
Gauging Your Readiness
Ask these questions of your information management or information systems organization:
1.Are you aware of the Year 2000 issue? 2.Are you actively addressing the issue with established plans, milestones, timelines, and resources? 3.What state of compliance do you expect to reach by January 1, 2000? What contingency plans are in place? 4.Are you actively engaged with your providers of vital data to assess and address their compliance?
What New Standard for Date Should be Adopted?
The U.S National Institute of Standards and Technology (NIST) strongly recommends the use of the 4-digit year represented as: century century/year year (CCYY).
Likewise, the U.S. Social Security Administration (SSA) has adopted as a general approach an expanded record format to acommodate century information when exchanging data with outside organizations. For example, where a date previously contained 'year year (YY),' it will now contain 'century century year year (CCYY).' They will be providing this format in records sent to outside organizations and they will need to receive year information in this format from external sources. They plan to be fully compliant no later than the end of 1998.
For More Information and Coordination
If you have questions or wish to discuss issues related to public health information systems and Year 2000 issues, you may contact your programmatic counterpart at CDC or:
James Seligman, phone: (404) 639-7601; e-mail: JDS1@CDC.GOV