18: Implementation of the National Electronic Disease Surveillance System in South Carolina

Implementation of the National Electronic Disease Surveillance System in South Carolina

Eric Brenner

South Carolina Department of Health and Environmental Control, Columbia, SC, USA

Background: Organization of Public Health in South Carolina

In South Carolina, a single agency, the Department of Health and Environmental Control (DHEC) is responsible for public health at the statewide level, and county health department (CHD) level. In South Carolina, unlike a number of other states, the CHD staff in all 46 counties are also DHEC employees. Most often, each county (or large municipality) has its own independent health department, and the state health department assumes an indirect role for coordination (see Chapter 3). One of the largest organizational units within DHEC is the Bureau of Disease Control. As shown in Table 18.1, this bureau is comprised of several divisions, each of which has traditionally maintained its own disease surveillance system. Most of this chapter will focus on surveillance systems used by the Division of Acute Disease Epidemiology (DADE), but advantages and disadvantages of combining all systems used by other disease control programs into a single system will also be discussed.

Table 18.1 Divisions of the DHEC Bureau of Disease Control with responsibilities related to disease surveillance and control.

Division	Primary Function	Information system used in the 1990s
Division of Tuberculosis Control	Surveillance and control of tuberculosis	TIMS (Tuberculosis Information Management System)
Division of HIV and STD Control	Surveillance and control of HIV and STDs	HARS (HIV-AIDS Reporting System STD-MIS (STD Management Information System)
Division of Acute Disease Epidemiology (DADE)	Surveillance and control relating to ∼60 reportable conditions, including vaccine preventable diseases, vector-, food-, and waterborne infections, meningococcal infections, potential bioterrorism agents, etc.	NETSS (National for National Electronic Telecommunications System for Surveillance)

Surveillance Versus Surveillance Systems

Discussions regarding adoption of a new surveillance system may sometimes semantically cloud essential distinctions between the terms “surveillance” and “surveillance system.” Concepts of surveillance are discussed in various sections of this book. Surveillance broadly refers to the core function of public health practice focused on monitoring trends in reportable diseases for purposes of program planning and evaluation, and identification of disease outbreaks requiring a public health response. However, the term “surveillance system” may be used not only to describe the detailed operational and administrative manner in which particular surveillance activities are carried out, but also more narrowly to refer to a computer software system which supports surveillance activities. It must be emphasized that adoption of a new surveillance software system does not in and of itself imply any changes in a jurisdiction’s legal basis or requirements for public health surveillance, its list of officially reportable diseases, or broad objectives and functions. Nonetheless, as will be discussed in this chapter, some features of a software system may offer opportunities to improve or expand the surveillance process, thus improving the surveillance system itself.

Historical Perspective: The NETSS Era

The National Electronic Telecommunications System for Surveillance (NETSS) was used by the majority of public health jurisdictions in the United States throughout much of the 1990s [1]. NETSS was built around early DOS-based versions of Epi Info, a widely used free software developed by the Centers for Disease Control and Prevention (CDC) for analysis of surveillance and other epidemiologic data [2]. Advantages of the NETSS system were its extremely low cost, ease of installation, and ease of use. Surveillance jurisdictions received troubleshooting assistance through the CDC Help Desk and the CDC-provided system updates. Typically, no in-house information technology (IT) support was required. Nevertheless, surveillance systems experienced several technical difficulties during the NETSS era:

System fragmentation: Surveillance data were fragmented into several incompatible systems (see Table 18.1) that lacked interoperability. Further, these systems, each of which had been designed separately, were built on different technical and software platforms and sometimes even ran on different operating systems.
Slow data flow and double data entry: Transmission of data from NETSS systems within jurisdictions was largely paper-based and thus inefficient and often delayed. For example, a positive laboratory test for a reportable disease, often already computerized in a hospital’s own laboratory computer system, might then be transcribed by hand onto an official DHEC paper reporting form and mailed to DHEC. Upon receipt, the same information would then be entered by hand into the NETSS database in a DHEC computer.
Older technologies: Though the Internet was well established by 2000, NETSS was not Web based; rather, it relied on stand-alone, personal computer (PC)–based software built on technologies that were typically 10 years or more old.

Beginning of the NEDSS Era

By the late 1990s, it had become clear both at the CDC and in many state health departments that a more modern approach to surveillance informatics was needed. The CDC, in consultation with numerous partners, initiated efforts to modernize the nation’s disease control surveillance systems [3–6], via an initiative that came to be known as the National Electronic Disease Surveillance System (NEDSS). NEDSS was not conceived of as a software system, but rather as a set of technical standards on which any number of NEDSS-compatible systems could then be based. Although many details of individual software applications might vary from jurisdiction to jurisdiction, standardization of multiple features across jurisdictions’ systems was essential to ensure that data transmitted to the CDC from surveillance sites could easily be merged into a single standardized national surveillance data stream. For example, though the look and feel of data entry screens might vary from state to state, coding schemes used to specify names of specific diagnostic tests important for surveillance purposes (e.g., immunological assays to diagnose measles or hepatitis B) would be standardized across states, as would be the technical specifications for construction of the electronic messages sent from states to CDC. Early NEDSSS standards proposed that system architecture elements should:

be Web-browser based,
be built on an integrated relational database,
emphasize secure data storage and transmission,
use HL-7 messages between computers, and
be written using accepted contemporary programming practices.

Funding Early State Preparations for NEDSS

Because of the complexity of the emerging NEDSS specifications, it was clear that states would need both time and financial assistance to transition from NETSS to NEDSS. CDC thus arranged an initial 3-year series of funding cycles during which states could apply for grant funds needed to begin their internal NEDSS planning process. These initial cycles (2000–2002) were funded via federal-state collaborative funding mechanisms involving the Council of State and Territorial Epidemiologists (CSTE), then the CDC Epidemiology and Laboratory Capacity (ELC) grant and federal bioterrorism grants.

Options for Deployment of NEDSS-Compatible Software Systems

States with IT resources could opt to develop systems that were compatible with NEDSS. States lacking significant IT expertise contracted with private IT companies or, as South Carolina did, chose to adopt the NEDSS-based system (NBS) provided by CDC. The NBS was developed by the CDC and made available at no cost to interested states. States selecting this option became known as “NBS states” and by the mid-2000s these numbered nearly 20. Epidemiology and IT staff from these states soon began to share system information and technical tips and tricks with one another via email and periodic conference calls. This shared experience was especially important early on, as the NBS package initially delivered to states typically required extensive customization and IT infrastructure preparation before deployment was possible.

Early Administrative and Technical Challenges

In South Carolina, DADE initially faced considerable technical challenges associated with customization and deployment of the NBS. DHEC disease control professionals, though experienced with public health surveillance, consultation, and outbreak investigation, had not previously needed to manage a large complex IT project, and at that time DADE did not have a professional IT team of its own. Consequently, DADE initially opted to use CDC NEDSS grant funds to contract with a private IT company with expertise in development, customization, and deployment of large complex relational databases. By 2002, there were five major partners in the project:

1. DHEC’s DADE group, who would be the end users of the software
2. CDC’s own NEDSS-team
3. The private IT contractor employed by CDC to develop the system
4. The private IT group hired by DHEC to customize the system and make it operational
5. DHEC’s own Bureau of Information Services (BIS)

Though the BIS did not have sufficient staff to manage the NBS customization and deployment effort, it did have considerable experience with complex relational databases, and as the unit charged with broad oversight over informatics for the entire agency, it played a strong technical advisory role and was consulted regarding all major decisions.