National Electronic Disease Surveillance System (NEDSS ...

Phase II Deliverables #1, 2 and 3 for 

Encumbrance #1000440, Agreement #2575 

National Electronic Disease Surveillance System 

(NEDSS) 

Implementation Project Plan 

Submitted to the 

State of Maine 

Department of Human Services 

Bureau of Health 

September 28, 2001 

Submitted by 

PUBLIC HEALTH RESOURCE GROUP 

120 Exchange Street 

Portland, ME 04101 

(207) 761-7093 

Vendor # 01-0440183

National Electronic Disease 

Surveillance System (NEDSS) 

Phase II, Task #1 and #2 Deliverables: 

Planned IT & Data Management Document 

and 

Detail Plan Documents

NEDSS Phase II, Deliverables 1 and 2 


(NEDSS) Plan – Phase II, Tasks #1 and #2 Deliverables 

Table of Contents 

Table of Contents .......................................................................................................................... 2 

I. Executive Summary ................................................................................................................. 4 

NEDSS Background................................................................................................................... 4 

Purpose....................................................................................................................................... 4 

Constraints.................................................................................................................................. 4 

II. Project Overview..................................................................................................................... 5 

Introduction ................................................................................................................................5 

Purpose, Scope and Objectives .................................................................................................. 5 

Assumptions............................................................................................................................... 5 

Major Project Deliverables......................................................................................................... 6 

Schedule Summary..................................................................................................................... 7 

Evolution of the Plan.................................................................................................................. 7 

References .................................................................................................................................. 7 

Definitions and Acronyms ......................................................................................................... 8 

III. Project Organization............................................................................................................. 9 

External Interfaces...................................................................................................................... 9 

Internal Structure...................................................................................................................... 10 

Roles and Responsibilities ....................................................................................................... 11 

IV. Managerial Process Plans ................................................................................................... 12 

Start-up Plan............................................................................................................................. 12 

Work Plan................................................................................................................................. 12 

Project Tracking Plan............................................................................................................... 12 

Risk Management Plan............................................................................................................. 13 

V. Technical Process Plans........................................................................................................ 14 

Process Model .......................................................................................................................... 14 

Methods, Tools and Techniques............................................................................................... 14 

Infrastructure ............................................................................................................................ 14 

Implementation Acceptance..................................................................................................... 14 

PHRG Page 2 of 35 September 28, 2001


VI. Supporting Process Plans................................................................................................... 15 

Configuration Management...................................................................................................... 15 

Verification and Validation...................................................................................................... 15 

Documentation ......................................................................................................................... 15 

Quality Assurance .................................................................................................................... 15 

Reviews and Audits.................................................................................................................. 15 

Problem Resolution.................................................................................................................. 15 

Subcontractor Management...................................................................................................... 15 

Process Improvement ............................................................................................................... 15 

VII. Migration and Training Plans ........................................................................................... 16 

Migration Plan.......................................................................................................................... 16 

Training Plan............................................................................................................................ 16 

VIII. Summary ............................................................................................................................ 17 

Appendix A – Configuration Management Plan Guideline.................................................... 18 

Appendix B – Quality Assurance Plan Guideline .................................................................... 20 

Appendix C – Project Management Glossary.......................................................................... 22 

Appendix D – Project Plan......................................................................................................... 31 



I. Executive Summary 

NEDSS Background 

The National Electronic Disease Surveillance System project is an initiative supported by CDC 

through a cooperative partnership with many public health stakeholders to improve the 

efficiency, effectiveness and timeliness of public health related surveillance information and 

associated activities. The stakeholders include the CDC, state public health departments, health 

care service organizations, health care product vendors and health care standards organizations. 

Specifically, the NEDSS initiative aims to develop standards that will facilitate the collection, 

storage, and dissemination of disease related data in real-time, from a variety of sources, to assist 

in the monitoring of community health, analysis and detection of emerging public health 

problems, and as a basis for public health policy. Some of the distinct opportunities to be gained 

through this initiative are: 

• Integration of disparate disease reporting systems; 

• Ability to identify national public health threats more promptly; and 

• More timely and accurate disease reporting. 

The standards developed will focus on at least five important areas: data architecture, user 

interface, information systems software architecture, tools for analysis, interpretation and 

dissemination of data, and secure data transfer. The development of these standards, while 

allowing the various State and local health departments enough flexibility to implement systems 

that best fit their specific information systems environment and needs, will assure that data (and 

software) can be easily and securely shared across health programs. 

Purpose 

The purpose of this document is to provide BOH professionals with a comprehensive project 

plan with which to implement NEDSS within the existing information technology infrastructure. 

Utilizing the assessment information gathered in Phase I, this document outlines the necessary 

phases and tasks to fully implement the NEDSS Base system and its functionality, while 

maintaining the integrity of the NEDSS architecture and existing system data. This includes, but 

may not be limited to: data exchange with the State reference laboratory (HETL) along with 

other key laboratory stakeholders, functional replacement of both NETSS and TIMS, and some 

form of integration with IMMPACT. 

Constraints 

This document provides high level detailed implementation phase and task descriptions, without 

the availability of the final NEDSS Base System from the CDC (to be released Fall of 2001). 

Thus, it is not possible to provide complete detail as to all the data management, functionality 

and related tasks. This consequently impacts the completeness of the project plan and should be 

taken into account when the final Base System does become available to the BOH. 



II. Project Overview 

Introduction 

This section of the NEDSS Implementation Plan provides an overview of the purpose, scope and 

objectives of the project, the project assumptions and constraints, a list of project deliverables, a 

summary of the project schedule, and the plan for evolving the Implementation Plan. 

Purpose, Scope and Objectives 

The purpose of the project is to provide BOH and other key stakeholders with the means to 

improve timeliness, completeness and quality of disease reporting. This in turn will allow for the 

rapid detection of public health threats, timely public health responses and facilitate accurate and 

complete public health decision-making processes. 

The core objectives of this project are to: 

• Fully implement the NEDSS Base system in a production environment; 

• Establish reporting and data exchange with the State Health and Environmental Testing 

Laboratory; 

• Establish reporting and data exchange with a large in-state reference laboratory; 

• Establish reporting and data exchange with a hospital laboratory; 

• Replace the existing NETSS functionality with the NEDSS Base system; 

• Replace the existing TIMS functionality with the NEDSS Base system; 

• Interface with IMMPACT; 

• Document the NEDSS system; and 

• Provide Training to appropriate BOH staff and stakeholders. 

This project will be closely tied to the Health Alert Network (HAN) initiative, as both projects 

address similar public health issues and objectives and require cooperation from the same 

stakeholders. As the HAN project becomes further defined, the NEDSS Implementation project 

plan will be modified to describe the specific tasks where the two projects dovetail. 

Additionally, this project will work closely with the ongoing effort of IMMPACT. 

Outside of BOH, this project needs to work in conjunction with ongoing efforts and projects 

within the DHS Technology Services (DoTS), such as implementation of Health Insurance 

Portability and Accountability Act (HIPAA). 

Assumptions 

The following assumptions relate to the objectives of the NEDSS Implementation project as 

stated above: 

• The project and other management plans cannot be finalized until the NEDSS Base 

system is released; 

• The final NEDSS Base System is released by CDC prior to the start of the project 

implementation; 

• CDC resource is available for technical system training; 



• Appropriate laboratory resources are available for implementing data exchange 

functionality; 

• DoTS can assign appropriate resources throughout duration of project; and 

• A suitable development / testing environment is available. 

Major Project Deliverables 

This project will produce the following milestone deliverables: 

Deliverable Date Medium 

Communication Plan (initial) 1/7/2002 - Electronic / hardcopy 

Laboratory Assessment Tool 1/15/2002 Electronic / hardcopy 

Project Plan (initial) 2/7/2002 - Electronic / hardcopy 

Quality Assurance Plan (initial) 2/14/2002 - Electronic / hardcopy 

Lab Requirements Document 2/19/2002 Electronic / hardcopy 

Configuration Management Document 2/14/2002 Electronic / hardcopy 

Requirements Specification Document 3/1/2002 Electronic / hardcopy 

Installation Plan Document (initial) 3/4/2002 - Electronic / hardcopy 

Test Plan Document (initial) 3/14/2002 - Electronic / hardcopy 

Acceptance Test Plan Document (initial) 3/22/2002 - Electronic / hardcopy 

Data Migration Plan Document 4/8/2002 Electronic / hardcopy 

System Logical Model Document 5/7/2002 Electronic / hardcopy 

Data Dictionary (initial) 5/21/2002 - Electronic / hardcopy 

Requirements Traceability Document 5/28/2002 Electronic / hardcopy 

System Design Document 6/4/2002 Electronic / hardcopy 

Training Plan Document (initial) 7/25/2002 - Electronic / hardcopy 

Operations Document 8/9/2002 Electronic / hardcopy 

Support Plan Document (initial) 7/12/2002 - Electronic / hardcopy 

Stakeholders trained in system use 8/222002 Training 

Technical Stakeholders trained in system maintenance 8/27/2002 Training 

Acceptance Test Report 8/30/2002 Electronic / hardcopy 

NEDSS Base System in production 9/2/2002 System 

Review Plan and Results Document 10/17/2002 Electronic / hardcopy 



Schedule Summary 

The following table outlines the project schedule by phase. See appendix for detailed project 

plan which includes all tasks. 

WBS Phase Duration Begin Date End Date 

1 NEDSS IMPLEMENTATION 207.5d Tue 1/1/02 Thu 10/17/02 

1.1 PLANNING PHASE 34d Tue 1/1/02 Fri 2/15/02 

1.2 REQUIREMENTS PHASE 69.5d Fri 1/11/02 Thu 4/18/02 

1.3 DESIGN PHASE 60d Tue 4/16/02 Tue 7/9/02 

1.4 BUILD PHASE 120.5d Tue 2/26/02 Tue 8/13/02 

1.5 TEST PHASE 84.5d Fri 3/29/02 Thu 7/25/02 

1.6 IMPLEMENTATION PHASE 128.5d Wed 3/6/02 Mon 9/2/02 

1.7 REVIEW PHASE 33d Mon 9/2/02 Thu 10/17/02 

Evolution of the Plan 

The structure of this project plan is in compliance with the recommendations of IEEE Std. 1058- 

1998. The project plan will be maintained in Microsoft Project 2000, and will be disseminated 

both electronically and in hardcopy (where needed) by the contracted project manager. The 

contractor for this project will manage the project plan in cooperation with the BOH and be 

responsible for its configuration management process. 

After initial release of the draft plan, the contracted project manager will be responsible for 

maintaining the “master” project plan, and all earlier versions will be retained through the 

configuration process (check in / check out). A review protocol will be developed in the 

communication plan that will outline the process by which the plan is to be modified. 

References 

This document makes references to the following standards: 

IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans 

IEEE Std 828-1998, IEEE Standard for Software Configuration Management Plans 

IEEE Std 1012-1998, IEEE Standard for Software Verification and Validation 

IEEE Std 1012-1998, IEEE Standard for Software Project Management Plans 

IEEE Std 1074-1997, IEEE Standard for Developing Software Life Cycle Processes 



Definitions and Acronyms 

The following are definitions of all acronyms used in this document: 

Acronym 

BOH 

CDC 

DHS 

DoTS 

HAN 

HETL 

HIPAA 

IEEE 

IMMPACT 

NEDSS 

NETSS 

TIMS 

Definition 


Center for Disease Control 

Department of Human Services 

DHS Technology Services 

Health Alert Network 

Health and Environmental Testing Laboratory 

Health Insurance Portability and Accountability Act 

Institute of Electrical and Electronics Engineers 

Maine Immunization Information Service 


National Electronic Telecommunications System for Surveillance 

Tuberculosis Information Management System 



III. Project Organization 

External Interfaces 

The NEDSS Implementation project will have a large number of stakeholders and stakeholder 

organizations throughout the life of the project. The following diagram illustrates the 

stakeholders and their relative importance (sphere of influence) to the success of the project. 

BOH 

Disease 

Control 

NEDSS 

Contractor 

CDC 

HETL 

State Ref. 

Lab / Hospital 

Lab 

DoTS 

Other 

Public Health 

Organizations 



Internal Structure 

The structure of BOH, the primary stakeholder in this project is as follows: 

Dora A. Mills, MD, MPH 

Director 


State Health Officer 

March 2001 

(Draft) 

Philip W. Haines 

Deputy Director 


--Environmental 

Toxicology 

N. Warren Bartlett 

Director 

Office of 

Health Data and 

Program Management 

--Vital Records 

--School Health 

Infrastructure 

--Survey Operations 

--Data and Research 

--Office of Primary 

Health Care 

--Maine Office of 

Rural Health 

Jack Krueger 

Chief, Lab Op. 

Health and 

Environmental Testing 

Laboratory 

Clough Toppan 

Director 

Division of 

Health Engineering 

Community Health 

Programs 

Barbara Leonard 

Director 

Family Health 

Programs 

Valerie Ricker 

Director 

Paul Kuehnert 

Director 

Division of 

Disease Control 

--Chemistry 

--Clinical Microbiology 

--Environmental 

--Clinical Certification 

--Organics 

--Inorganics, Nutrients, 

Microbiology Agents 

--Plumbing Control 

--Radiological Health 

--Eating and Lodging 

--Drinking Water 


Organizational Chart 

--Breast and Cervical 

Health Program 

--Community Health/ 

Chronic Disease 

Prevention Unit 

--Oral Health Program 

--Diabetes Control Project 

--Teen and Young Adult 

Health Program 

--Partnership for a 

Tobacco-Free Maine 

--MCH Medical Director 

--Chronic Epidemiology 

Capacity Building 

--Injury Prevention 

and Control Program 

--Cancer Registry 

--Occupational Health 

Program 

--Healthy Families Program 

--Public Health Nursing 

--Women and Children's 

Preventive Health 

Services Program 

--Lead Poisoning 

Prevention Program 

--Coordinated Care 

Services for 

Children with Special 

Health Needs 

--Genetics Program 

--WIC Program 

--State System 

Development Initiative 

--Nutrition Program 

--HIV/STD Program 

--Tuberculosis Control 

Program 

--Refugee Health 

Assessment Program 

--Epidemiology Program 

--Immunization Program 

--EPSDT 

--Immpact 

A representative from the Division of Disease Control, acting as the project manager from the 

State, will provide the direct interface between the key stakeholders (BOH and CDC) and the 

implementation contractor. This interaction will typically be on a daily basis and will include 

functions such as: resource allocation, plan management, quality assurance, test validation and 

general project administration. Other State programs and divisions will also be involved as 

needed, and will be directed by the contractor with direction and guidance from the Disease 

Control project manager. 



Roles and Responsibilities 

The principle roles in the implementation project plan, as indicated in the project resource plan, 

include the following: 

Role 

NEDSS Project Sponsor 

Contractor Project Mgr. 

Contractor Technical Resource 

Contractor Quality Assurance 

BOH Project Mgr. 

CDC Technical Consultant 

DOTS Sponsor 

DOTS Technical Advisor 

BOH Stakeholder 

Lab. Sponsor 

Lab. Technical Resource 

Abbreviation 

BOH_SP 

CON_PM 

CON_TR 

CON_QA 

BOH_PM 

CDC_TC 

DOT_SP 

DOT_TA 

BOH_SH 

LAB_SP 

LAB_TR 

The roles responsible for the day-to-day management of the implementation project lies with the 

BOH Project Manager (Disease Control) and the Contractor Project Manager. These two 

individuals are responsible for ensuring that the project stays on target as it pertains to 

deliverables and budget. 

Key individuals from the CDC, DoTS and HETL will provide technical assistance throughout 

the project. It will be critical to establish communication with the assigned individuals once 

project commences to disseminate the plan objectives and their specific responsibilities. Both 

project managers will be responsible for these early stakeholder meetings. 

Laboratory (other than HETL) stakeholder meetings will also occur early in the project as to 

ascertain the pilot organizations and begin assessment of their environment. This phase depends 

heavily on the commitment of the laboratory and knowledge of the assigned resource(s). Both 

implementation project managers will also coordinate this section. 



IV. Managerial Process Plans 

Start-up Plan 

As control of the budget is not within the scope of this plan, the only portion of the start-up plan 

that will be addressed in this document will relate to staffing and resource acquisition. 

The required contractor resources allocated during this project will vary from 2 in the initial 

phases, to 3 or 4 during the actual testing and implementation phase. These resources will have 

both technical and project planning skill sets. 

Besides the project manager, which this project will require a significant portion of their time 

(+50%), the BOH will need to allocate some nominal time for resources associated with NETSS, 

TIMS, IMMPACT, and the data contained within these systems. This should amount to 

approximately one person per system for several weeks. 

DoTS will provide a key role in this project, and accordingly this project will rely at times quite 

heavily on that resource. Concerning the acquisition and allocation of technical resources 

(hardware and software), or just familiarizing the project team with the technology standards in 

place, this project will require both highly technical and administrative DoTS resources. 

One of the primary functions of NEDSS is the receipt of laboratory test results. With HETL 

acting as the fundamental supplier laboratory data, a successful interface (data exchange) 

between the NEDSS Base system and the HETL is dependant upon key resources within the 

laboratory. This project will require significant time from technical and laboratory processing 

staff at HETL. These technical resources will not only need the skill set to understand current 

technologies, but have intimate knowledge of the HETL system and all its nuances. 

Additional resources will be identified and reported once the project officially begins and the 

requirements become established. 

Work Plan 

See the attached project plan. 

Project Tracking Plan 

Project tracking will be coordinated between the contractor and BOH project managers. One of 

the first stages of the project will be to define how to implement requirements management and 

schedule control. Without all the details of the NEDSS Base system and consequently the 

specifications of the implementation, this section outlines key areas that will need to be 

established once the project begins: 

• Specify the process for measuring, reporting and controlling changes to the project 

requirements. 

• Specify the processes to be used in assessing the impact of requirements changes on 

product scope and quality, and the impacts of requirements changes on project schedule, 

budget, resources and risk factors. 



• In the configuration management processes, specify change control procedures and the 

formation and use of a change control board. 

• In the processes for requirements management, include traceability, prototyping and 

modeling, impact analysis and reviews. 

With project management as it pertains to Quality Control, the following key areas will be 

defined: 

• Specify the processes to be used to measure and control the quality of the work and the 

resulting work products 

• Specify the use of quality control processes such as quality assurance of conformance to 

work processes, verification and validation, joint reviews, audits and process assessment. 

Risk Management Plan 

As with Project tracking, Risk Management can only be outlined at a high level until further 

details on the NEDSS Base System arrive. The following topics summarize the steps needed 

to create an adequate plan: 

• Specify the risk management plan for identifying, analyzing, and prioritizing project risk 

factors. 

• Specify plans for assessing initial risk factors and for the ongoing identification, 

assessment, and mitigation of risk factors throughout the life cycle of the project. 

• Describe the following: 

o Procedures for contingency planning, 

o Procedures for tracking the various risk factors, 

o Risk management work activities, 

o Procedures and schedules for performing risk management work activities, 

o Risk documentation and reporting requirements, 

o Organizations and personnel responsible or performing specific risk management 

activities, and 

o Procedures for communicating risks and risk status among the various customer, 

project and subcontractor organizations. 



V. Technical Process Plans 

Process Model 

The process model for this project is outlined in the project plan attached (see Appendix). 

Though not all phase tasks flow in a sequential format, the overall flow is from top to bottom, or 

Planning to Requirements to Design to Build to Test to Implement to Review. 

Several of the phases have appropriate review and revision tasks, which allow the appropriate 

stakeholders to be updated on the project status and allow for minor project adjustments. 

Methods, Tools and Techniques 

This project will utilize only established engineering methodologies (e.g. IEEE standards) and 

tools. The specific programming tools will be determined when the NEDSS Base system is 

released. All other standards will be determined at the appropriate time after consultation with 

CDC and DoTS technical resources for compatibility within the respective environments. 

Infrastructure 

The technical infrastructure is dependant on the established standards within BOH, DoTS and 

those that are required by NEDSS. What will need to be determined during the associated 

phases (i.e. Build, Test and Implement) are as follows: 

• Hardware, operating system, network and software 

• Policies, procedures, standards, and facilities 

• Workstations, local area networks, software tools for analysis, design implementations, 

testing, and project management, 

• Desks, office space, etc. 

Implementation Acceptance 

Once the final system specifications are determined (Requirements Traceability Matrix), the 

criteria for both technical and user (stakeholder) deliverable acceptance is established. The 

Traceability Matrix will list every key function point of the system and how it is measured. 

Once the project sponsors and key stakeholders have signed off this document, the appropriate 

standards are in place to determine (measure) the status of the deliverables. 



VI. Supporting Process Plans 

Configuration Management 

See attached Configuration Plan outline (Appendix A) 

Verification and Validation 

The project will be managed by daily communications between the two project managers, and 

weekly status meetings with the active project team members. This weekly status information 

will be used to update the project plan with “% complete” and “actual end dates” at the task 

level. This updated project plan will then be distributed to the key project stakeholders. 

Documentation 

The communication plan will outline the documents used throughout the project management 

process, such as: project status, project issues/concerns, communication protocols, etc., who is 

responsible for each and how they will be distributed. 

Quality Assurance 

See attached Quality Assurance Plan outline (Appendix B). 

Reviews and Audits 

Project reviews and audits will be performed on a weekly basis up to the Implementation phase, 

where the frequency may change to daily depending on the number of critical activities 

scheduled. 

Problem Resolution 

The problem resolution process and protocol will be outlined in the Communication Plan and be 

determined by both project managers. 

Subcontractor Management 

This plan will be defined by BOH / Disease Control Sponsor and Project Manager prior to 

project start. 

Process Improvement 

No activity related to process improvement scheduled at this time. 



VII. Migration and Training Plans 

Migration Plan 

The Migration Plan describes the strategies involved in converting data from the existing 

systems (NETSS and TIMS) to the NEDSS Base system. It is appropriate to reexamine the 

original system's functional requirements for the condition of the system before conversion to 

determine if the original requirements are still valid. Some of the major tasks in a Migration 

Plan are as follows: 

• System Overview 

• System Conversion Overview 

• Conversion Description 

• Type of Conversion 

• Conversion Strategy 

o Data Conversion Strategy 

o Data Conversion Approach 

o Interfaces 

o Data Quality Assurance and Control 

• Conversion Risk Factors 

• Conversion Tasks 

o Conversion Planning 

o Preconversion Tasks 

o Major Tasks and Procedures 

• Conversion Schedule 

Training Plan 

The Training Plan outlines the objectives, needs, strategy, and curriculum to be addressed when 

training users on the new or enhanced information system. The plan presents the activities 

needed to support the development of training materials, coordination of training schedules, 

reservation of personnel and facilities, planning for training needs, and other training-related 

tasks. An example of a Training Plan is: 

• Instructional Analysis 

o Issues and Recommendations 

o Needs and Skills Analysis 

• Instructional Methods 

o Training Methodology 

o Training Database 

• Training Resources 

o Resources and Facilities 

o Schedules 

o Future Training 

• Training Curriculum 



VIII. Summary 

Summary 

The implementation of the NEDSS Base System will provide the electronic processes needed for 

a superior notifiable disease surveillance and analysis system, replacing the functionality 

currently supported by the National Electronic Telecommunications System for Surveillance 

(NETSS) and the Tuberculosis Information Management System (TIMS). Additionally, it will 

provide an environment for increased data quality, timeliness and reporting of laboratory data. 

Though this NEDSS Base System implementation is not intended to represent the complete 

NEDSS solution, it will provide the foundation upon which further BOH program needs, data 

collection, processing and reporting can be built. 

The plan presented in this document proposes several essential components of implementing a 

complex disease reporting system—Organization, Managerial Process Plans, Technical Process 

Plans, Support Process Plans and Migration and Training Plans and several key appendices. 

These documents along with the eBusiness Plan, also attached, were completed with the 

understanding that the state will be using, at least in the first phases of implementation, the Base 

System to be provided by CDC. 

The implementation plan presented in this document, and its associated methodology, serve to 

provide a structured and proven framework to ensure successful deliverables and to meet 

business objectives. More specifically, this plan provides the following benefits: 

• Reduced risk of project failure 

• Consideration of system and data requirements throughout the entire life of the system 

• Early identification of technical and management issues 

• Realistic expectations of what the systems will and will not provide 

• Information to better balance programmatic, technical, management, and cost aspects of 

proposed system development or modification 

• Measurements of progress and status to enable effective corrective action 

• Information that supports effective resource management and budget planning 

• Consideration of meeting current and future business requirements 

Once the CDC Base System is received it will be necessary to develop a more detailed 

implementation plan as part of the implementation process since the parameters of CDC’s Base 

System and the software that comes are not known at this time. However the planning processes 

described in this document will permit the state to move forward with implementation more 

swiftly and take a giant leap forward in its ability to access, transmit and report both disease data 

for the residents of Maine and soon after that bring many of the related datasets in the BOH into 

the system. 



Appendix A – Configuration Management Plan Guideline 

Introduction 

Provide a brief statement that introduces the Configuration Management (CM) plan and 

describes, in general terms, its use in managing the configuration of the specific project, 

or system. 

Purpose 

Describe why this CM plan was created, what it accomplishes, and how it is used. 

Scope 

Define the scope of CM planning. 

System Description 

Briefly describe the system, its history, and the environment in which the project 

operates. Describe the system architecture, operating system, and application languages. 

Definitions 

Define the terms that appear in the CM plan. 

Reference Documents 

List the documents that are referenced to support the CM process including any project or 

standards documents referenced in the body of the CM plan. 

Organization 

Identify the organization in which CM resides and all organization units that participate 

in the project. Define the functional roles of these organizational units within the project 

structure. 

CM Activities 

Identify all CM functions required to manage the configuration of the system. 

CM Responsibilities 

List CM responsibilities in supporting this project. 

Configuration Identification 

Explain that Configuration Identification is the basis on which the configuration items 

(CIs) are defined and verified; CIs and documents are labeled; changes are managed; and 

accountability is maintained. Define the automated tools that will be used to track and 

control the configuration baselines. 

Configuration Item Identification 

Identify the CIs to be controlled and specify a means of identifying changes to the CIs 

and related baselines. 



Identification Conventions 

Describe the identification (numbering) criteria for the software and hardware structure, 

and for each document or document set. 

Naming Conventions 

Provide details of the file naming convention to be used on the project and how file 

configuration integrity will be maintained. 

Configuration Baseline Management 

Describe what baselines are to be established. Explain when and how they will be defined 

and controlled. 

Configuration Control 

Explain that configuration change management is a process for managing configuration 

changes and variances in configurations. 

Change Management 

Define the process for controlling changes to the system baselines and for tracking the 

implementation of those changes. 

Review and Control Board(s) 

Describe any Review Groups that will be established for the project. For each group, 

discuss the members who will participate and their functional representatives. 

Configuration Status Accounting 

Explain that Configuration Status Accounting (CSA) is the process of keeping records of 

all change actions pertaining to a configuration item to generate reports on all decisions 

made and implemented. Also, show that CSA provides a means of storing and crossreferencing 

the collected data. 

Configuration Audits 

Describe how peer review audits and formal audits will be accomplished. 

Reviews 

Describe how the technical reviews relate to the establishment of baselines and explain 

the role of CM in these reviews. 

Version Control 

Describe the processes in place to control the amount and number of versions 

documented by this CM Plan. 

Documentation Management 

Describe the processes in place for documentation management and who is responsible 

for them. 



Appendix B – Quality Assurance Plan Guideline 

The purpose of the Quality Assurance (QA) plan is to ensure that delivered products satisfy 

contractual agreements, meet or exceed quality standards, and comply with the project 

methodology. The delivered QA plan will include a Program Level plan and Project plan. The 

Program Level plan describes all potential activities that QA could apply to a projects task and 

the Project Level QA plan will describe the actual QA activities that will be integrated with the 

project plan and schedule. The level of detail contained in the Project Level QA plan will be 

consistent with the complexity, size, intended use, mission criticality, and cost of failure of the 

system development effort. 

Purpose 

Establish the requirements for QA applicable to all portions of the system's development 

effort. QA activities require effort, resources, and time just like other project activities. 

References 

List documents used in QA reviews with complete citations (title; version number, if any; 

originating organization; date; etc.). References should include all standards that will 

apply to the QA function. 

Objective 

Outline QA objectives of the program as established by the Project Manager. Describe 

the benefits that will be realized by conforming to quality requirements and the 

contributions that QA makes to the success of the program. 

Organization 

Provide an operational organizational chart developed for the program from a QA 

perspective. Describe the tasks in terms of QA activities associated with the project. 

Identify responsibilities for project tasks. 

System Development 

Describe the objectives of QA in monitoring formal development to ensure that the 

concepts and standards applied by QA are implemented at the project and program levels. 

Test and Evaluation 

Describe the role of QA in ensuring that project requirements are satisfied and that formal 

testing is completed in accordance with plans, standards, and procedures. Discuss reviews 

of test plans, test specifications, test procedures, and test reports. 

Configuration Management 

Describe the role of QA in ensuring that CM activities are performed in accordance with 

the CM plans, standards, and procedures. Discuss reviews to verify that baseline control, 

configuration identification, configuration control, configuration status accounting, and 

configuration authentication have been accomplished. 



QA Roles and Responsibilities 

Describe the organizational and functional alignment of the QA staff. Describe the roles 

and responsibilities at the management, team leader, and specialist levels. 

Processes 

Provide an overview of the processes that QA uses to ensure that processes and products 

associated with hardware, software, and documentation are monitored, sampled, and 

audited to ensure compliance with methodology, policy, and standards. 

Peer Review 

Commit to QA participation in the peer review process to identify, document, measure, 

and eliminate defects in a work product. 

Process Review 

Describe audit and assessment reviews that ensure that appropriate steps are taken to 

carry out activities specified by the project plan. Describe methods by which QA 

monitors processes by comparing the actual steps carried out with those in the 

documented procedures. Discuss QA's responsibility to provide review data to 

management to provide an indication of the quality and status of the project. 

Problem Reporting 

Describe the role of QA in identifying problems and recommending corrective actions. 

Identify the requirement for tasks to include QA in problem reporting and corrective 

action functions. Discuss the procedures and formats for the preparation, tracking, and 

management involvement in the use of Quality Action Reports (QARs) used in the 

program. 

QA Escalation Procedure 

Describe the QA escalation procedures that bring high-risk or long-standing, unresolved 

noncompliance-tracking issues to senior management's attention. 

QA Report Formats 

Describe the report formats that formally document and transmit information from QA 

audits and/or assessment reviews. 

Standards 

Describe requirement of QA to ensure that standards are identified that establishes the 

prescribed methods for development of work products. Also discuss QA's role in 

assessing standards for adequacy and applicability. 

Tools 

Describe the tool sets that QA employs in the conduct of administrative and technical 

functions. 



Appendix C – Project Management Glossary 

Acceptance Test - Formal testing conducted to determine whether or not a system satisfies its 

acceptance criteria and to enable the customer to determine whether or not to accept the system. 

See User Acceptance Test. 

Activity - A unit of work to be completed in order to achieve the objectives of a work 

breakdown structure. See Work Breakdown Structure. In process modeling, an activity requires 

inputs and produces outputs. See Input/Output. 

Application - A system providing a set of services to solve some specific user problem. 

Application Model - A model used to graphically and textually represent the required data and 

processes within the scope of the application development project. 

Application Software - Software specifically developed to perform a specific type of work; for 

example, a word processor. Compare to System Software. 

Architecture - The structure of a computer system, either a part or the entire system; can be 

hardware, software, or both. 

Audit - A formal review of a project (or project activity) for the purpose of assessing compliance 

with contractual obligations. 

Availability - The degree to which a system (or system component) is operational and accessible 

when required for use. 

Baseline - A work product (such as software or documentation) that has been formally reviewed, 

approved, and delivered and can only be changed through formal change control procedures. See 

Allocated Baseline, Functional Baseline, Operational Baseline, Product Baseline. 

Benchmark - A standard against which measurements or comparisons can be made. 

Bottom-up - The process of designing a system by designing the low-level components first; 

then integrating them into large subsystems until the complete system is designed; bottom-up 

testing tests these low-level components first, using software drivers to simulate the higher level 

components. See Top-down. 

Build - An operational version of a software product incorporating a specified subset of the 

complete system functionality. See Version. 

Business Process Reengineering - The redesign of an organization, culture, and business 

processes to achieve significant improvements in costs, time, service, and quality. 

Capability - A measure of the expected use of a system. 

Capacity - A measure of the amount of input a system could process and/or amount of work a 

system can perform; for example, number of users, number of reports to be generated. 

Certification - Comprehensive analysis of the technical and non-technical security features and 

other safeguards of a system to establish the extent to which a particular system meets a set of 

specified security requirements. 

Change - In Configuration Management, a formally recognized revision to a specified and 

documented requirement. See Change Control, Change Directive, Change Impact Assessment, 

Change Implementation Notice. 



Change Control - In Configuration Management, the process by which a change is proposed, 

evaluated, approved (or disapproved), scheduled, and tracked. See Change, Change Directive, 

Change Impact Assessment, Change Implementation Notice. 

Change Control Documents - Formal documents used in the configuration management 

process to track, control, and manage the change of configuration items over the systems 

development or maintenance life cycle. See System Change Request, Change Impact 

Assessment, Change Directive, and Change Implementation Notice. 

Client/Server - A network application in which the end-user interaction with the system (server) 

is through a workstation (client) that executes some portion of the application. 

Configuration Control - The process of evaluating, approving or (disapproving), and 

coordinating changes to hardware/software configuration items. 

Configuration Control Board - The formal entity charged with the responsibility of evaluating, 

approving (or disapproving), and coordinating changes to hardware/software configuration 

items. 

Configuration Item - An aggregation of hardware and/or software that satisfy an end-use 

function and is designated by the customer for configuration management; treated as a single 

entity in the configuration management process. A component of a system requiring control over 

its development throughout the life-cycle of the system. 

Configuration Management - The discipline of identifying the configuration of a 

hardware/software system at each life cycle phase for the purpose of controlling changes to the 

configuration and maintaining the integrity and traceability of the configuration through the 

entire life cycle. 

Configuration Management Plan - A formal document that establishes formal configuration 

management practices in a systems development/maintenance project. See Configuration 

Management. 

Configuration Status Accounting - The recording and reporting of the information that is 

needed to effectively manage a configuration; including a listing of the approved configuration 

identification, status of proposed changes to the configuration, and the implementation status of 

approved changes. See Configuration. 

Contingency Plan - A formal document that establishes continuity of operations processes in 

case of a disaster. Includes names of responsible parties to be contacted, data to be restored, and 

location of such data. 

Conversion - The process of converting (or exchanging) data from an existing system to another 

hardware or software environment. 

Conversion Plan - A formal document that describes the strategies involved in converting data 

from an existing system to another hardware or software environment. 

Cost Analysis - Presents the costs for design, development, installation, operation and 

maintenance, and consumables for the system to be developed. 

Cost-Benefit Analysis - The comparison of alternative courses of action, or alternative technical 

solutions, for the purpose of determining which alternative would realize the greatest cost 

benefit; cost-benefit analysis is also used to determine if the system development or maintenance 

costs still yield a benefit or if the effort should stop. 

Cost Estimate - the process of determining the total cost associated with a software development 

or maintenance project, to include the effort, time, and labor required. 

Criteria - A standard on which a decision or judgment may be based; for example, acceptance 

criteria to determine whether or not to accept a system. 



Critical Path - Used in project planning; the sequence of activities (or tasks) that must be 

completed on time to keep the entire project on schedule; therefore, the time to complete a 

project is the sum of the time to complete the activities on the critical path. 

Data Dictionary - A repository of information about data, such as its meaning, relationships to 

other data, origin, usage and format. A data dictionary manages data categories such as aliases, 

data elements, data records, data structure, data store, data models, data flows, data relationships, 

processes, functions, dynamics, size, frequency, resource consumption and other user-defined 

attributes. 

Database - A collection of logically related data stored together in one or more computerized 

files; an electronic repository of information accessible via a query language interface. 

Database Management System - A software system that controls storing, combining, updating, 

retrieving, and displaying data records. 

Data Store - A repository of data; a file. 

Demonstration - A procedure to verify system requirements that cannot be tested otherwise. 

Deliverable - A formal product that must be delivered to (and approved by) the customer; called 

out in the Task Order. 

Design Phase - The period of time in the systems development life cycle during which the 

designs for architecture, software components, interfaces, and data are created, documented, and 

verified to satisfy system requirements. 

Development Phase - The period of time in the systems development life cycle to convert the 

deliverables of the Design Phase into a complete system. 

Disposition Phase - The time when a system has been declared surplus and/or obsolete and the 

task performed is either eliminated or transferred to other systems. 

Disposition Plan - A formal plan providing the full set of procedures necessary to end the 

operation or the system in a planned, orderly manner and to ensure that system components and 

data are properly archived or incorporated into other systems. 

Document - Written and/or graphical information describing, defining, specifying, reporting, or 

certifying activities, requirements, procedures, reviews, or results. See Product. 

Entity - Represents persons, places, events, things, or abstractions that are relevant to the DOJ 

and about which data are collected and maintained. 

Feasibility - The extent to which the benefits of a new or enhanced system will exceed the total 

costs and also satisfies the business requirements. 

Feasibility Study - A formal study to determine the feasibility of a proposed system (new or 

enhanced) in order to make a recommendation to proceed or to propose alternative solutions. 

Functionality - The relative usefulness of a functional requirement as it satisfies a business 

need. 

Functional Baseline - The approved documentation that describes the functional characteristics 

of the system, subsystem, or component. See Baseline. 



Functional Requirement - A requirement that specifies a function (activity or behavior, based 

on a business requirement) that the system (or system component) must be capable of 

performing. 

Functional Requirements Document - A formal document of the business (functional) 

requirements of a system; the baseline for system validation. 

Functional Test - Testing that ignores the internal mechanism of a system (or system 

component) and focuses solely on the outputs generated in response to selected inputs and 

execution conditions. Same as black-box testing. 

Gantt Chart - A list of activities plotted against time, showing start time, duration, and end 

time; also known as a bar chart. 

Implementation - Installing and testing the final system, usually at the user (field) site; the 

process of installing the system. 

Implementation Phase - The period of time in the systems development life cycle when the 

system is installed, made operational, and turned over to the user (for the beginning of the 

Operations and Maintenance Phase). 

Implementation Plan - A formal document that describes how the system will be installed and 

made operational. 

Integration and Test Phase - Life cycle phase during which subsystem integration, system, 

security, and user acceptance testing are conducted; done prior to the Implementation Phase. 

Integration Test - Testing in which software components, hardware components, or both are 

combined and tested to evaluate the interaction between them. 

Integrity - The degree to which a system (or system component) prevents unauthorized access 

to, or modification of, computer programs or data. 

Interface - To interact or communicate with another system (or system component). An 

interface can be software and/or hardware. See User Interface. 

Life Cycle - All the steps or phases a project passes through during its system life; from concept 

development to disposition. There are nine life cycle phases in the SDLC. 

Methodology - A set of methods, procedures, and standards that define the approach for 

completing a system development or maintenance project. 

Metrics - A quantitative measure of the degree to which a system, component, or process 

possesses a given attribute. 

Migration - Porting a system, subsystem, or system component to a different hardware platform. 

Milestone - In project management, a scheduled event that is used to measure progress against a 

project schedule and budget. 

Model - A simplified representation or abstraction (for example, of a process, activity, or 

system) intended to explain its behavior. 



Operational Baseline - Identifies the system accepted by the users in the operational 

environment after a period of onsite test using production data. See Baseline. 

Operations Manual - A formal document that provides a detailed operational description of the 

system and its interfaces. 

Peer Review - A formal review where a product is examined in detail by a person or group other 

than the originator. See Inspection, Walk-through. 

Phase - A defined stage in the systems development life cycle; there are nine phases in the full, 

sequential life cycle. 

Pilot - An alternative work pattern to develop a system to demonstrate that the concept is 

feasible in an operational environment. Pilots are used to provide feedback to refine the final 

version of the product and are fielded for a preset, limited period of time. Compare to a 

Prototype. 

Planning Phase - The period of time in the systems development life cycle in which a 

comprehensive plan for the recommended approach to the systems development or maintenance 

project is created. Follows the Systems Concept Development Phase, in which the recommended 

approach is selected. 

Post-Implementation Review - A formal review to evaluate the effectiveness of the systems 

development effort after the system is operational (usually for at least six months). 

Post-Implementation Review Report - A formal document detailing the findings of the Post- 

Implementation Review. See Post-Implementation Review. 

Post-Termination Review - A formal review to evaluate the effectiveness of a system 

disposition. 

Post-Termination Review Report - A formal document detailing the findings of the Post- 

Termination Review. See Post-Termination Review. 

Procedure - A series of steps (or instructions) required to perform an activity. Defines "how" to 

perform an activity. Compare to Process. 

Process - A finite series of activities as defined by its inputs, outputs, controls (for example, 

policy and standards), and resources needed to complete the activity. Defines "what" needs to be 

done. Compare to Procedure. 

Process Model - A graphical representation of a process. 

Process Review - A formal review of the effectiveness of a process. 

Production - A fully documented system, built according to the SDLC, fully tested, with full 

functionality, accompanied by training and training materials, and with no restrictions on its 

distribution or duration of use. 

Project - The complete set of activities associated with all life cycle phases needed to complete a 

systems development or maintenance effort from start to finish (may include hardware, software, 

and other components); the collective name for this set of activities. Typically a project has its 

own funding, cost accounting, and delivery schedule. 

Project Management - The process of planning, organizing, staffing, directing, and controlling 

the development and/or maintenance of a system. 

Project Management Plan - A formal document detailing the project scope, activities, schedule, 

resources, and security issues. The Project Management Plan is created during the Planning 

Phase and updated through the Disposition Phase. 



Project Manger - The person with the overall responsibility and authority for the day-to-day 

activities associated with a project. 

Quality - The degree to which a system, component, product, or process meets specified 

requirements. 

Quality Assurance - A discipline used by project management to objectively monitor, control, 

and gain visibility into the development or maintenance process. 

Quality Assurance Plan - A formal plan to ensure that delivered products satisfy contractual 

agreements, meet or exceed quality standards, and comply with approved systems development 

or maintenance processes. 

Quality Assurance Review - A formal review to ensure that the appropriate Quality Assurance 

activities have been successfully completed, held when a system is ready for implementation. 

Regression Test - In software maintenance, the rerunning of test cases that previously executed 

correctly in order to detect errors introduced by the maintenance activity. 

Release - A configuration management activity wherein a specific version of software is made 

available for use. 

Reliability - The ability of a system (or system component) to perform its required functions 

under stated conditions for a specified period of time. 

Requirement - A capability needed by a user; a condition or capability that must be met or 

possessed by a system (or system component) to satisfy a contract, standard, specification, or 

other formally imposed documents. 

Requirements Analysis Phase - The period of time in the systems development life cycle 

during which the requirements for a software product are formally defined, documented and 

analyzed. 

Requirements Management - Establishes and controls the scope of system development efforts 

and facilitates a common understanding of system capabilities between the System Proponent, 

developers, and future users. 

Requirements Traceability Matrix - Provides a method for tracking the functional 

requirements and their implementation through the development process. 

Resource - In management, the time, staff, capital and money available to perform a service or 

build a product; also, an asset needed by a process step to be performed. 

Review - A formal process at which an activity or product (for example, code, document) is 

presented for comment and approval; reviews are conducted for different purposes, such as peer 

reviews, user reviews, management reviews (usually for approval) or done at a specific 

milestone, such as phase reviews (usually to report progress). 

Review Report - A formal document that records the results of a review. 

Risk - A potential occurrence that would be detrimental to the project; risk is both the likelihood 

of the occurrence and the consequence of the occurrence. 

Risk Assessment - The process of identifying areas of risk; the probability of the risk occurring, 

and the seriousness of its occurrence; also called risk analysis. 

Risk Management - The integration of risk assessment and risk reduction in order to optimize 

the probability of success (that is, minimize the risk). 



Risk Management Plan - A formal document that identifies project risks and specifies the plans 

to reduce these risks. 

Role - A defined responsibility (usually task) to be carried out by one or more individuals. 

Scope - The established boundary (or extent) of what must be accomplished; during planning, 

this defines what the project will consist of (and just as important, what the project will not 

consist of). 

Security - The establishment and application of safeguards to protect data, software, and 

hardware from accidental or malicious modification, destruction, or disclosure. 

Security Test - A formal test performed on an operational system, based on the results of the 

security risk assessment in order to evaluate compliance with security and data integrity 

guidelines, and address security backup, recovery, and audit trails. Also called Security Testing 

and Evaluation (ST&E). 

Software - Computer programs (code), procedures, documentation, and data pertaining to the 

operation of a computer system. Compare to Hardware. 

System - A collection of components (hardware, software, interfaces) organized to accomplish a 

specific function or set of functions; generally considered to be a self-sufficient item in its 

intended operational use. 

System Concept Development Phase - Phase that starts the life cycle; begins when a need to 

develop or significantly change a system is identified, then the approaches for meeting this need 

are reviewed for feasibility and appropriateness (for example, cost-benefit analysis). 

System Design Document - A formal document that describes the system architecture, file and 

database design, interfaces, and detailed hardware/software design; used as the baseline for 

system development. 

Systems Analysis - In systems development, the process of studying and understanding the 

requirements (customer needs) for a system in order to develop a feasible design. 

System Security Plan - A formal document that establishes the processes and procedures for 

identifying all areas where security could be compromised within the system (or subsystem). 

System Software - Software designed to facilitate the operation of a computer system and 

associated computer programs (for example, operating systems, code compilers, utilities). 

Compare to Application Software. 

System Test - The process of testing an integrated hardware/software system to verify that the 

system meets its documented requirements. 

Task - In project management, the smallest unit of work subject to management accountability; a 

work assignment for one or more project members fulfilling a role, as defined in a work 

breakdown structure. 

Test - The process of exercising the product to identify differences between expected and actual 

results and performance. Typically testing is bottom-up: unit test, integration test, system test, 

and acceptance test. 

Test Case - A specific set of test data and associated procedures developed for a particular test. 

Test Files/Data - Files/data developed for the purpose of executing a test; becomes part of a test 

case. See Test Case. 



Test and Evaluation (T&E) - T&E occurs during all major phases of the development life 

cycle, beginning with system planning and continuing through the operations and maintenance 

phase, ensures standardized identification, refinement, and traceability of the requirements as 

such requirements are allocated to the system components. 

Test and Evaluation Master Plan - The formal document that identifies the tasks and activities 

so the entire system can be adequately tested to assure a successful implementation. 

Test Problem Report - Formal documentation of problems encountered during testing; the form 

is attached to the Test Analysis Report. See Test Analysis Report. 

Top-down - An approach that takes the highest level of a hierarchy and proceeds through 

progressively lower levels; compare to Bottom-up. 

Traceability - In requirements management, the identification and documentation of the 

derivation path (upward) and allocation path (downward) of requirements in the hierarchy. 

Training - The formal process of depicting, simulating, or portraying the operational 

characteristics of a system or system component in order to make someone proficient in its use. 

Training Plan - A formal document that outlines the objectives, needs, strategy, and curriculum 

to be addressed for training users of the new or enhanced system. 

Unit Test - In testing, the process of ensuring that the software unit executes as intended; usually 

performed by the developer. 

User - An individual or organization that operates or interacts directly with the system; one who 

uses the services of a system. The user may or may not be the customer. See Customer. 

User Acceptance Test - Formal testing conducted to determine whether or not a system satisfies 

its acceptance criteria and to enable the user to determine whether or not to accept the system. 

See Acceptance Test. 

User Interface - The software, input/output (I/O) devices, screens, procedures, and dialogue 

between the user of the system (people) and the system (or system component) itself. See 

Interface. 

User Manual - A formal document that contains all essential information for the user to make 

full use of the new or upgraded system. 

Validation - The process of determining the correctness of the final product, system, or system 

component with respect to the user's requirements. Answers the question, "Am I building the 

right product?" Compare to Verification. 

Verifiability - A measure of the relative effort to verify a requirement; a requirement is 

verifiable only if there is a finite cost-effective process to determine that the software product or 

system meets the requirement. 

Verification - The process of determining whether the products of a life cycle phase fulfill the 

requirements established during the previous phase; answers the question, "Am I building the 

product right?" Compare to Validation. 

Verification and Validation Plan - A formal document that describes the process to verify and 

validate the requirements. Created during the Planning Phase and updated throughout the SDLC. 

Version - An initial release or re-release of a computer software configuration item, associated 

with a complete compilation or recompilation of the computer software configuration item; 

sometimes called a build. See Build. 



Walk-through - A software inspection process, conducted by peers of the software developer, to 

evaluate a software component. See Inspection, Peer Review. 

Work Breakdown Structure - In project management, a hierarchical representation of the 

activities associated with developing a product or executing a process; a list of tasks; often used 

to develop a Gantt Chart. 



Appendix D – Project Plan (See following 4 pages) 



Appendix D - Project Plan 

ID WBS Task Name Duration Start Finish Resource Initials 

1 1 NEDSS IMPLEMENTATION 207.5 days Tue 1/1/02 Thu 10/17/02 

2 1.1 PLANNING PHASE 34 days Tue 1/1/02 Fri 2/15/02 

3 1.1.1 Identify the project sponsor and project manager 0.5 days Tue 1/1/02 Tue 1/1/02 BOH_PM,CON_PM 

4 1.1.2 Get the project team in place 1 day Tue 1/1/02 Tue 1/1/02 BOH_PM,CON_PM 

5 1.1.3 Prepare the Requirements Document (RD) 2 days Wed 1/2/02 Thu 1/3/02 CON_PM 

6 1.1.4 Conduct project kickoff meeting 1 day Fri 1/4/02 Fri 1/4/02 CON_PM,BOH_PM 

7 1.1.5 Create Communications Document (draft) 1 day Mon 1/7/02 Mon 1/7/02 CON_PM 

8 1.1.6 Laboratory Stakeholders 3 days Tue 1/8/02 Thu 1/10/02 

9 1.1.6.1 Determine Laboratory Stakeholders 1 day Tue 1/8/02 Tue 1/8/02 BOH_PM 

10 1.1.6.2 Project Kickoff meeting w/ Lab Stakeholders 1 day Wed 1/9/02 Wed 1/9/02 BOH_PM,CON_PM 

11 1.1.6.3 Assign Lab Resources 1 day Thu 1/10/02 Thu 1/10/02 BOH_PM,LAB_SP 

12 1.1.7 DOTS Stakeholders 7 days Tue 1/8/02 Wed 1/16/02 

13 1.1.7.1 Determine DOTS Stakeholders 2 days Tue 1/8/02 Wed 1/9/02 BOH_PM,DOT_SP 

14 1.1.7.2 Project Kickoff meeting w/ Stakeholders 1 day Thu 1/10/02 Thu 1/10/02 BOH_PM,CON_PM 

15 1.1.7.3 Assign DOTS Resources 1 day Fri 1/11/02 Fri 1/11/02 BOH_PM,CON_PM,DOT_SP 

16 1.1.7.4 Review DOTS Activities & Initiatives 3 days Mon 1/14/02 Wed 1/16/02 BOH_PM,CON_PM,DOT_SP 

17 1.1.8 Project Plan (Draft) 16 days Thu 1/17/02 Thu 2/7/02 

18 1.1.8.1 Develop Statement of Scope (SOS) 5 days Thu 1/17/02 Wed 1/23/02 CON_PM 

19 1.1.8.2 Conduct work-breakdown structure meeting 1 day Thu 1/24/02 Thu 1/24/02 CON_PM 

20 1.1.8.3 Build Work Breakdown Structure (WBS) 3 days Fri 1/25/02 Tue 1/29/02 CON_PM 

21 1.1.8.4 Transfer WBS to Microsoft Project 1 day Wed 1/30/02 Wed 1/30/02 CON_PM 

22 1.1.8.5 Outline project plan 1 day Thu 1/31/02 Thu 1/31/02 CON_PM 

23 1.1.8.6 Assign resources to project plan tasks 3 days Fri 2/1/02 Tue 2/5/02 CON_PM,BOH_PM,DOT_SP 

24 1.1.8.7 Review with Stakeholders 1 day Wed 2/6/02 Wed 2/6/02 CON_PM 

25 1.1.8.8 Publish Project Plan 1 day Thu 2/7/02 Thu 2/7/02 CON_PM 

26 1.1.9 Quality Assurance Plan 6 days Fri 2/8/02 Fri 2/15/02 

27 1.1.9.1 Develop document 5 days Fri 2/8/02 Thu 2/14/02 CON_QA 

28 1.1.9.2 Conduct structured walkthrough(s) 1 day Fri 2/15/02 Fri 2/15/02 CON_QA 

29 1.1.10 Revise Communication Plan 1 day Fri 2/8/02 Fri 2/8/02 CON_PM 

30 

31 1.2 REQUIREMENTS PHASE 69.5 days Fri 1/11/02 Thu 4/18/02 

32 1.2.1 NEDSS Base System Specifications 11 days Mon 2/11/02 Mon 2/25/02 

33 1.2.1.1 Acquire NEDSS Base System 1 day Mon 2/11/02 Mon 2/11/02 CON_PM 

34 1.2.1.2 Base System Training (w/ CDC Consultant) 10 days Tue 2/12/02 Mon 2/25/02 CON_TR,DOT_TA 

35 1.2.2 LAB Assessment 28 days Fri 1/11/02 Tue 2/19/02 

36 1.2.2.1 Develop Lab Assessment Tool 3 days Fri 1/11/02 Tue 1/15/02 CON_TR 

37 1.2.2.2 Survey Lab Stakeholder Environment 20 days Wed 1/16/02 Tue 2/12/02 CON_TR 

38 1.2.2.3 Create Lab Requirements Document 5 days Wed 2/13/02 Tue 2/19/02 CON_TR 

39 1.2.3 Configuration Management Plan 6 days Fri 2/8/02 Fri 2/15/02 

40 1.2.3.1 Develop document 5 days Fri 2/8/02 Thu 2/14/02 CON_PM 

41 1.2.3.2 Conduct structured walkthrough(s) 1 day Fri 2/15/02 Fri 2/15/02 CON_PM 

42 1.2.4 Requirements Specification 11 days Mon 2/18/02 Mon 3/4/02 

43 1.2.4.1 Develop document 10 days Mon 2/18/02 Fri 3/1/02 CON_PM 

44 1.2.4.2 Review Requirements with stakeholders 1 day Mon 3/4/02 Mon 3/4/02 CON_PM 

45 1.2.5 Project Test Plan 8.5 days Tue 3/5/02 Fri 3/15/02 

46 1.2.5.1 Develop document 7.5 days Tue 3/5/02 Thu 3/14/02 CON_TR,DOT_TA 

47 1.2.5.2 Conduct structured walkthrough(s) 1 day Thu 3/14/02 Fri 3/15/02 CON_TR 

48 1.2.6 Acceptance Test Plan (draft) 6 days Fri 3/15/02 Mon 3/25/02 

r 1st Quarter 2nd Quarter 3rd Quarter 4th Quarter 1st Quarter 2nd Quart 

Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May 

BOH Project Mgr.,Contractor Project Mgr. 



1/4 




BOH Project Mgr.,Lab. Sponsor 

BOH Project Mgr.,DOTS Sponsor 


BOH Project Mgr.,Contractor Project Mgr.,DOTS Sponsor 

BOH Project Mgr.,Contractor Project Mgr.,DOTS Sponsor 






Contractor Project Mgr.,BOH Project Mgr.,DOTS Sponsor 


2/7 




2/11 

Contractor Technical Resource,DOTS Technical Advisor 







3/4 



Project: NEDSS_Implementation_98_20 

Date: Sun 9/30/01 

Task 

Split 

Progress 

Milestone 

Summary 

Project Summary 

External Tasks 

External Milestone 


Deadline 

PHRG September 28, 2001





49 1.2.6.1 Prepare document 5 days Fri 3/15/02 Fri 3/22/02 CON_QA 


50 1.2.6.2 Conduct structured walkthrough(s) 1 day Fri 3/22/02 Mon 3/25/02 CON_QA 


51 1.2.7 Data Migration Plan 11 days Mon 3/25/02 Tue 4/9/02 

52 1.2.7.1 Prepare document 10 days Mon 3/25/02 Mon 4/8/02 CON_TR 

53 1.2.7.2 Conduct structured walkthrough(s) 1 day Mon 4/8/02 Tue 4/9/02 CON_TR 

54 1.2.8 Data Dictionary Outline 5 days Tue 4/9/02 Tue 4/16/02 CON_TR 

55 1.2.9 Revise Project Plan 2 days Tue 4/16/02 Thu 4/18/02 CON_PM 

56 

57 1.3 DESIGN PHASE 60 days Tue 4/16/02 Tue 7/9/02 

58 1.3.1 Create Data Exchange Interface/Mapping Template 10 days Tue 4/16/02 Tue 4/30/02 CON_TR 

59 1.3.2 Create Logical Model 5 days Tue 4/30/02 Tue 5/7/02 CON_TR 

60 1.3.3 Create Data Flow Diagram (DFD) 5 days Tue 5/7/02 Tue 5/14/02 CON_TR 

61 1.3.4 Produce Data Dictionary 5 days Tue 5/14/02 Tue 5/21/02 CON_TR 

62 1.3.5 Requirements Traceability Matrix 5 days Tue 5/21/02 Tue 5/28/02 CON_PM 

63 1.3.6 Functional Design 7 days Tue 5/28/02 Thu 6/6/02 

64 1.3.6.1 Develop document 5 days Tue 5/28/02 Tue 6/4/02 CON_PM 

65 1.3.6.2 Conduct structured walkthrough(s) 1 day Tue 6/4/02 Wed 6/5/02 CON_PM 

66 1.3.6.3 Conduct Functional Design Review 1 day Wed 6/5/02 Thu 6/6/02 CON_PM 

67 1.3.7 Laboratory Data Exchange 5 days Thu 6/6/02 Thu 6/13/02 

68 1.3.7.1 Prepare Lab Data Mapping Matrices 5 days Thu 6/6/02 Thu 6/13/02 CON_TR 

69 1.3.8 Integration Test Plan (draft) 6 days Thu 6/13/02 Fri 6/21/02 

70 1.3.8.1 Prepare document 5 days Thu 6/13/02 Thu 6/20/02 CON_TR,DOT_TA,CON_QA 

71 1.3.8.2 Conduct structured walkthrough(s) 1 day Thu 6/20/02 Fri 6/21/02 CON_QA 

72 1.3.9 System Test Plan (draft) 6 days Fri 6/21/02 Mon 7/1/02 

73 1.3.9.1 Prepare document 5 days Fri 6/21/02 Fri 6/28/02 CON_TR,DOT_TA,CON_QA 

74 1.3.9.2 Conduct structured walkthrough(s) 1 day Fri 6/28/02 Mon 7/1/02 CON_QA 

75 1.3.10 Migration Plan 6 days Mon 7/1/02 Tue 7/9/02 

76 1.3.10.1 Prepare document 5 days Mon 7/1/02 Mon 7/8/02 CON_TR,BOH_PM 

77 1.3.10.2 Conduct structured walkthrough(s) 1 day Mon 7/8/02 Tue 7/9/02 CON_TR 

78 1.3.11 System Design Document 12 days Thu 6/6/02 Mon 6/24/02 

79 1.3.11.1 Prepare document 10 days Thu 6/6/02 Thu 6/20/02 CON_TR 

80 1.3.11.2 Conduct structured walkthrough(s) 1 day Thu 6/20/02 Fri 6/21/02 CON_TR 

81 1.3.11.3 Conduct Critical Design Review 1 day Fri 6/21/02 Mon 6/24/02 CON_TR 

82 1.3.12 Review Design with stakeholders 1 day Mon 6/24/02 Tue 6/25/02 CON_TR 

83 1.3.13 Revise Project Plan 1 day Mon 6/24/02 Tue 6/25/02 CON_PM 

84 

85 1.4 BUILD PHASE 120.5 days Tue 2/26/02 Tue 8/13/02 

86 1.4.1 Create Development Environment 3 days Tue 2/26/02 Thu 2/28/02 CON_TR,DOT_TA 

87 1.4.2 Installation Plan (draft) 6 days Tue 2/26/02 Tue 3/5/02 

88 1.4.2.1 Develop document 5 days Tue 2/26/02 Mon 3/4/02 CON_PM 

89 1.4.2.2 Conduct structured walkthrough(s) 1 day Tue 3/5/02 Tue 3/5/02 CON_PM 

90 1.4.3 Integration Test Plan (final) 2 days Tue 6/25/02 Thu 6/27/02 CON_TR 

91 1.4.4 System Test Plan (final) 2 days Thu 6/27/02 Mon 7/1/02 CON_TR 

92 1.4.5 Migration Plan 3 days Mon 7/1/02 Thu 7/4/02 

93 1.4.5.1 Develop document 2 days Mon 7/1/02 Wed 7/3/02 CON_TR 

94 1.4.5.2 Conduct structured walkthrough(s) 1 day Wed 7/3/02 Thu 7/4/02 CON_TR 

95 1.4.6 Support Plan (draft) 6 days Thu 7/4/02 Fri 7/12/02 

96 1.4.6.1 Prepare document 5 days Thu 7/4/02 Thu 7/11/02 CON_PM 















Contractor Technical Resource,DOTS Techni 


Contractor Technical Resource,DOTS Techn 


Contractor Technical Resource,BOH Project Mgr. 





6/24 











Date: Sun 9/30/01 

Task 

Split 

Progress 

Milestone 

Summary 





Deadline 






97 1.4.6.2 Conduct structured walkthrough(s) 1 day Thu 7/11/02 Fri 7/12/02 CON_PM 


98 1.4.7 Documentation Plan (draft) 4 days Fri 7/12/02 Thu 7/18/02 

99 1.4.7.1 Prepare document 3 days Fri 7/12/02 Wed 7/17/02 CON_PM 

100 1.4.7.2 Conduct structured walkthrough(s) 1 day Wed 7/17/02 Thu 7/18/02 CON_PM 

101 1.4.8 Training Plan (draft) 6 days Thu 7/18/02 Fri 7/26/02 

102 1.4.8.1 Prepare document 5 days Thu 7/18/02 Thu 7/25/02 CON_PM 

103 1.4.8.2 Conduct structured walkthrough(s) 1 day Thu 7/25/02 Fri 7/26/02 CON_PM 

104 1.4.9 Operating Documents (draft) 11 days Fri 7/26/02 Mon 8/12/02 

105 1.4.9.1 Prepare documents 10 days Fri 7/26/02 Fri 8/9/02 CON_TR 

106 1.4.9.2 Conduct structured walkthrough(s) 1 day Fri 8/9/02 Mon 8/12/02 CON_TR 

107 1.4.10 NEDSS Base System 23 days Tue 2/26/02 Thu 3/28/02 

108 1.4.10.1 Install / Configure NEDSS Base System Hardware 10 days Tue 2/26/02 Mon 3/11/02 CON_TR 

109 1.4.10.2 Install NEDSS Base System 10 days Tue 3/12/02 Mon 3/25/02 CON_TR 

110 1.4.10.3 Configure NEDSS Base System 3 days Tue 3/26/02 Thu 3/28/02 CON_TR 

111 1.4.11 Laboratory Data Interface 45 days Tue 4/30/02 Tue 7/2/02 

112 1.4.11.1 Create Data Interfaces 30 days Tue 4/30/02 Tue 6/11/02 CON_TR 

113 1.4.11.2 Document Interfaces 5 days Tue 6/11/02 Tue 6/18/02 CON_TR 

114 1.4.11.3 Verify Data Interfaces 10 days Tue 6/18/02 Tue 7/2/02 CON_TR 

115 1.4.12 Revise Project Plan 1 day Mon 8/12/02 Tue 8/13/02 CON_PM 

116 

117 1.5 TEST PHASE 84.5 days Fri 3/29/02 Thu 7/25/02 

118 1.5.1 Create Test Environment 3 days Fri 3/29/02 Tue 4/2/02 CON_QA 

119 1.5.2 NEDSS Base System 31 days Wed 4/3/02 Wed 5/15/02 

120 1.5.2.1 Create Test Dataset 5 days Wed 4/3/02 Tue 4/9/02 CON_QA 

121 1.5.2.2 Conduct Data Load Test 3 days Wed 4/10/02 Fri 4/12/02 CON_QA 

122 1.5.2.3 Conduct User Interface Test 3 days Mon 4/15/02 Wed 4/17/02 CON_QA 

123 1.5.2.4 Conduct NETSS Functionality Test 5 days Thu 4/18/02 Wed 4/24/02 CON_QA 

124 1.5.2.5 Conduct TIMS Functionality Test 5 days Thu 4/25/02 Wed 5/1/02 CON_QA 

125 1.5.2.6 Conduct Web Access Test 2 days Thu 5/2/02 Fri 5/3/02 CON_QA 

126 1.5.2.7 Conduct Report Testing 5 days Mon 5/6/02 Fri 5/10/02 CON_QA 

127 1.5.2.8 Conduct Security Testing 2 days Mon 5/13/02 Tue 5/14/02 CON_QA 

128 1.5.2.9 Track defects 1 day Wed 5/15/02 Wed 5/15/02 CON_QA 

129 1.5.3 Laboratory Data Exchange 16 days Tue 7/2/02 Wed 7/24/02 

130 1.5.3.1 Create Test Dataset 10 days Tue 7/2/02 Tue 7/16/02 CON_QA 

131 1.5.3.2 Conduct Data Exchange Test 5 days Tue 7/16/02 Tue 7/23/02 CON_QA 

132 1.5.3.3 Track defects 1 day Tue 7/23/02 Wed 7/24/02 CON_QA 

133 1.5.4 Review Test Results with stakeholders 1 day Wed 7/24/02 Thu 7/25/02 CON_QA 

134 

135 1.6 IMPLEMENTATION PHASE 128.5 days Wed 3/6/02 Mon 9/2/02 

136 1.6.1 NEDSS Base System 88.5 days Wed 3/6/02 Mon 7/8/02 

137 1.6.1.1 Install / Configure Base System Production Hardware 5 days Wed 3/6/02 Tue 3/12/02 CON_TR,DOT_TA 

138 1.6.1.2 Install NEDSS Base System 10 days Wed 3/13/02 Tue 3/26/02 CON_TR 

139 1.6.1.3 Configure NEDSS Base System 3 days Wed 3/27/02 Fri 3/29/02 CON_TR 

140 1.6.1.4 Test NEDSS Base System 5 days Mon 7/1/02 Mon 7/8/02 CON_QA 

141 1.6.2 Application Data Migration (NETSS and TIMS) 16 days Mon 7/8/02 Tue 7/30/02 

142 1.6.2.1 Document QA data control points 2 days Mon 7/8/02 Wed 7/10/02 CON_QA 

143 1.6.2.2 Extract, Analyze and Clean data 5 days Wed 7/10/02 Wed 7/17/02 CON_TR 

144 1.6.2.3 Load Data 2 days Wed 7/17/02 Fri 7/19/02 CON_TR 




3/26 









6/18 















7/24 









Date: Sun 9/30/01 

Task 

Split 

Progress 

Milestone 

Summary 





Deadline 






145 1.6.2.4 Test against Specs. and Control points 3 days Fri 7/19/02 Wed 7/24/02 CON_QA 


146 1.6.2.5 Test NEDSS Base System Functionality 3 days Wed 7/24/02 Mon 7/29/02 CON_QA 


147 1.6.2.6 Track defects 1 day Mon 7/29/02 Tue 7/30/02 CON_QA 

148 1.6.3 Testing 6 days Tue 7/30/02 Wed 8/7/02 

149 1.6.3.1 Integration Test Reports 3 days Tue 7/30/02 Fri 8/2/02 CON_QA 

150 1.6.3.2 System Test Report 3 days Fri 8/2/02 Wed 8/7/02 CON_QA 

151 1.6.4 Operating Documents (final) 5 days Wed 8/7/02 Wed 8/14/02 CON_TR 

152 1.6.5 Training Plan (final) 3 days Wed 8/14/02 Mon 8/19/02 CON_QA 

153 1.6.6 Installation Plan (final) 3 days Mon 8/19/02 Thu 8/22/02 CON_TR 

154 1.6.7 Acceptance Test Plan (final) 2 days Thu 8/22/02 Mon 8/26/02 CON_QA 

155 1.6.8 Training 23 days Thu 7/25/02 Tue 8/27/02 

156 1.6.8.1 Create User Documentation 5 days Thu 7/25/02 Thu 8/1/02 CON_QA 

157 1.6.8.2 Create Technical Documentation 5 days Thu 8/1/02 Thu 8/8/02 CON_QA 

158 1.6.8.3 Conduct User Training Sessions 10 days Thu 8/8/02 Thu 8/22/02 CON_TR 

159 1.6.8.4 Conduct Technical Training 3 days Thu 8/22/02 Tue 8/27/02 CON_TR 

160 1.6.9 Acceptance 3 days Tue 8/27/02 Fri 8/30/02 

161 1.6.9.1 Acceptance Test Report 3 days Tue 8/27/02 Fri 8/30/02 CON_QA 

162 1.6.10 Operational System 1 day Fri 8/30/02 Mon 9/2/02 CON_PM,BOH_PM 

163 

164 1.7 REVIEW PHASE 33 days Mon 9/2/02 Thu 10/17/02 

165 1.7.1 Create Review Plan / Stakeholders 1 day Mon 9/2/02 Tue 9/3/02 CON_PM,BOH_PM 

166 1.7.2 Schedule Stakeholder Meetings 1 day Tue 9/3/02 Wed 9/4/02 BOH_PM 

167 1.7.3 Track Operational System 30 days Wed 9/4/02 Wed 10/16/02 CON_QA 

168 1.7.4 Review Project Strengths / Weaknesses w/ Stakeholders 1 day Wed 10/16/02 Thu 10/17/02 CON_PM,BOH_PM 











8/8 



8/30 

Contractor Project Mgr.,BOH Proje 



10/16 


Date: Sun 9/30/01 

Task 

Split 

Progress 

Milestone 

Summary 





Deadline 


Phase II, Task #3 Deliverable: 

NEDSS e-Business Plan

NEDSS Phase II, Deliverable 3 


(NEDSS) Plan – Phase II, Task #3 Deliverable 

TABLE OF CONTENTS 

e-Business Plan 

I. Executive Summary ..........................................................................1 

II. Business Requirements.....................................................................1 

III. Costs and Benefits .............................................................................2 

IV. Constraints and Risks .......................................................................3 

V. Interdependencies .............................................................................4 

VI. Organizational Structure..................................................................4 

VII. Leadership and Governance ............................................................4 

VIII. Impact on Constituents....................................................................5 

IX. Creative and Cognitive Design.........................................................5 

X. High Level Architecture ...................................................................5 


PHASE II Task 3 Deliverable 

National Electronic Data Surveillance System (NEDSS) Plan 

Phase II Task 3 

e-Business Plan 

I. Executive Summary 

E-business query and report generation functions are being developed as part of the National 

Electronic Data Surveillance System (NEDSS). Using an on-line web browser, clinical 

laboratories and providers will transmit laboratory results, integrated through NEDSS, to the 

State of Maine Bureau of Health, who then transmits these data to the Centers for Disease 

Control and Prevention (CDC). Out of state reference labs processing Maine specimens will 

transmit results directly to CDC which in turn will transmit results to Maine. These new e- 

business functions will then allow public health agencies, health services agencies, and providers 

across the state to directly access the NEDSS data through the web browser to perform specific 

queries of the data and to create ad hoc reports specifically requested by the user. Selective, 

confidential, querying and messaging functions will be available for authorized users to extend 

the use of NEDSS data, linked to demographic and disease data, to provide integrated reports of 

patient demographics, laboratory results, and disease history and outcomes. Authorized users 

will have access to their own provider-specific data as warranted, as well as to statewide 

aggregated data that has not existed previously. These e-business query and reporting functions 

will allow public health agencies to more closely monitor, report, and manage disease-specific 

prevalence and incidence rates, plus prevention and treatment programs. These e-business 

functions can provide improved quality assurance through early detection, improved agencyfield 

communication; best practices analyses, and cost-effectiveness analyses of clinical 

providers, clinical treatment modalities, and patient and community outcomes. 

II. Business Requirements 

The National Electronic Data Surveillance System (NEDSS) is a cooperative partnership 

between the Centers for Disease Control and Prevention (CDC) and many public health entities 

to integrate previously disparate data collection and reporting systems into a secure, integrated 

environment. The system was developed to improve the efficiency, effectiveness, and timeliness 

of public health-related surveillance, monitoring, analysis, identification, and management 

concerning various diseases detected through a variety of clinical laboratory procedures, as well 

as to serve as a basis for public health policy at multiple levels of government. The system is 

intended to involve the CDC, state and local public health departments, health care provider and 

service organizations, health care product vendors, and health care standards organizations. 

Data are currently provided to the Maine Bureau of Health (BOH) by hospital laboratories, the 

state Public Health Laboratory, and reference laboratories throughout the State of Maine. 

Current data processes include the collection, verification, storage repository, and reporting 

functions as the data are transmitted to the CDC in Atlanta. The required system elements 

involving data collection and security are discussed previously in the National Electronic Data 

Surveillance System (NEDSS) Overview (PHRG, May 18, 2001). The Maine Bureau of Health 

will maintain the integrated data repository, which will communicate through specific software 

with the clinical database, the CDC, the state and other public health agencies, clinical sites 

(providing electronic laboratory messages), Geographic Information System (GIS) and other 

demographic and clinical disease data mapping and statistical reports, and the Health Personnel 

PHRG 1 of 5 

September 28, 2001


Directory. The BOH will design business rules to ensure data confidentiality to permit 

selectively authorized, read-only access to data housed in selected program area modules 

(PAMs) based on specific user’s roles and responsibilities. The data will be accessible to 

specific commercial software (e.g., standards-based statistical packages, GIS packages) to 

support related data analysis and visualization activities, and to support the electronic exchange 

of laboratory, clinical, and epidemiological data between the state, and other providers and 

laboratories (dependent on licensing agreements). 

The currently proposed e-business plan addresses the important and previously unavailable 

attribute of these disparate data systems that will allow web browser-based development of 

clinical and public health management reports for improving case management. Selective, 

confidential, data reporting, querying and messaging functions will be available for authorized 

users to extend the use of NEDSS data, linked to demographic and disease data, to provide 

integrated reports of patient demographics, laboratory results, and disease history. E-business 

would involve periodic reports and case reports available from BOH, or through the query 

feature for user-generated, ad hoc clinical and management reports. Reports will be available for 

local stakeholders, with aggregate reports for data comparisons, and individual case reports 

available for specific data laboratory providers (to safeguard issues of patient confidentiality) as 

well as state and local public health agencies. Out-of-state laboratories would need to access 

specific data through the CDC. 

The capability to query and generate these resultant reports offers value-added identification, 

communication and program response to directly address public health issues of changes in 

disease incidence, severity, treatment, and prevention. Local public health agencies and 

laboratories can be alerted electronically about specific disease states, rates, and data monitoring 

and reporting requirements to improve detection and treatment management. In addition to these 

clinical processes and outcomes, the query and reporting functions allow government and 

clinical laboratories to access aggregated state-wide data that was unavailable previously or 

available only in hard copy reports by county. These data may be used to enhance financial 

projections of provider business costs and/or public health program costs, to compare and 

contrast competitive patterns and projections, and to improve quality assurance through 

management control and management decision-making that affects patients, communities, public 

health agencies, and commercial providers alike. 

III. Costs and Benefits 

E-business costs are anticipated to be negligible. The initial development of NEDSS has already 

contemplated the system architecture, design, linkages, and maintenance requirements for the 

query and reporting functions. The various user communities will need computer equipment and 

maintenance for access to the web browser, but most if not all components should already exist 

to meet the previously mandated data entry requirements for reporting the relevant laboratory 

tests to the BOH data repository. The user communities may need some minor computer 

software training to effectively utilize the software capabilities to query and produce reports, but 

these costs should be very low. And, it is anticipated that instructions on how to access NEDDS 

will be available on-line. 

Conversely, the benefits of NEDDS from an e-business perspective are significant. In addition to 

PHRG 2 of 5 

September 28, 2001


on-line data entry, query and reporting capabilities of their own data, already noted elsewhere, 

agencies and providers alike will have newly developed electronic access to broad-based, 

statewide data, with which they are able to selectively query to ascertain statewide or specific 

provider trends, patterns, and outcomes. Authorized users will have access to their own 

provider-specific data as warranted, as well as to statewide aggregated data that has not existed 

previously. In a manner similar to the current IMMPACT program that tracks immunizations 

statewide, these query and reporting functions through NEDSS can significantly improve pubic 

health functions in the state by reducing time, quality, and communication delays in developing 

and sharing critical public health community alerts and directives. These e-business functions 

will allow public health agencies to more closely monitor, report, and manage disease-specific 

prevalence and incidence rates, plus prevention and treatment programs. These e-business 

functions can improve quality assurance through early detection of trends, improved agency-field 

communication, best practices analyses, and cost-effectiveness analyses of clinical providers, 

clinical treatment modalities, and patient and community outcomes. 

Additionally, the reporting and querying functions of NEDDS will permit physicians, 

researchers, students and the public health community access to reports that are not now 

accessible or that require staff time to complete with special runs of the data. This has significant 

benefit both to the BOH as well as the public sector. Since the NEDSS base system integrated 

data repository will be structured to permit incorporation of many different additional BOH 

databases, the e-business benefits of NEDSS will be enhanced multi-fold. For example, the 

contemplated addition of online collection and reporting of vital statistics data should reduce 

data collection costs and increase access to data that are routinely used by public health agencies, 

planners, policy makers, researchers and students. Providing access to these data through 

NEDDS will highlight the role of BOH and market its importance in the state. Should the BOH 

require modest fees for these reports, a method of generating revenues to help support the system 

is realized. 

IV. Constraints and Risks 

The e-business functions pose few constraints and risks. Access to the e-business query and 

reporting functions will follow the previously developed programs, policies, procedures, and 

restrictions of the Maine Bureau of Health in addressing technology, security, data access, and 

maintenance issues for NEDSS. The largest concern would encompass issues of data 

confidentiality and security, principally to effectively ensure that only authorized users are to 

access NEDSS data, and further to also ensure that authorized users access, report, and transmit 

the data responsibly, with no disclosure or other inappropriate use of patient or provider data. 

While the system is purposely “user-friendly,” providers are restricted to accessing either the 

data they provided on their own patients, or data that are aggregated and cleaned of all patient- or 

provider-designations. Policies will need to be developed to delineate approved and unapproved 

access, transmittal, and use of the information developed through the query and reporting 

functions of NEDSS. 

A second possible constraint with using these e-business functions involves developing accurate 

projections for short-term and long-term use of the query and reporting functions through 

NEDSS. As these e-business functions become more widely publicized, there could be an 

increase in the number of users employing these functions, especially with the planned expansion 

PHRG 3 of 5 

September 28, 2001


of the system to include other BOH databases. If the increase is sufficiently large, it could 

necessitate changes in system architecture to accommodate the increased user demand. While 

system architectural changes and programming could be costly, the alternative of decreased user 

service through increased processing time, an insufficient number of data ports to support user 

access, and/or diminished public health responses resulting from the inefficient and ineffective 

utilization of the query and reporting functions are significantly more unacceptable and must be 

avoided. 

V. Interdependencies 

Through the Maine Bureau of Health, NEDSS data will be linked to other databases and to a 

network of providers and public health agencies. Thus, BOH works with the various provider 

and public health organizations in developing procedures and policies for data collection 

security, and access. These provider and public health entities rely on this web-based access 

(read only format) for accurate and timely data that can be incorporated, through the e-business 

functions, into reports and other information (e.g., Health Advisory Notices) for dissemination to 

these various entities to protect the public health and to effectively manage public health 

programs and provider practices. As such, each government, provider, and public health entity 

shares responsibility for data accuracy, the appropriate and ethical use of the data, and the 

responsible public health, clinical, and managerial application of the resulting data-derived 

information. 

VI. Organizational Structure 

The e-business query and reporting functions are incorporated under NEDSS, and therefore 

housed under the Maine Bureau of Health organizational design. Management authority and 

responsibility for the technical components and data elements will lie with the Division of 

Disease Control (DDC). The DHS Department of Technical Services (DOTS), a key stakeholder, 

will play an advisory role in the development of the system so that it can communicate as 

appropriate with current and planned systems and technology. 

VII. Leadership and Governance 

As noted above, structural and programmatic responsibility for NEDSS resides with the Division 

of Disease Control, Maine Bureau of Health. This arrangement provides for the data 

development and access to the data by the community of users, but it does not address the issues 

surrounding the e-business query and reporting functions for the user community. 

In addition to the monitoring of system usage provided by DDC and BOH, the e-business 

functions require an additional layer of leadership and governance to address management and 

public health issues. To ensure effective, responsible, and equitable use of the data and their 

resultant reports developed by the user community, the Maine BOH should establish an NEDSS 

Advisory Council, comprised of representatives from the various stakeholder and user 

community constituents. Members could include representatives from the Bureau of Health, 

laboratory providers, clinical providers, hospitals, legislators, public citizens, and other 

stakeholders. Terms could be staggered, with a chairperson designated from the members, 

possibly rotating to different member constituents. The Advisory Council could be responsible 

for providing general direction and representation issues, developing data access and 

dissemination policies, reviewing requests for collecting additional data, benchmarking and 

PHRG 4 of 5 

September 28, 2001


implementing software updates, and providing a forum to address internal issues regarding data 

and reports. 

VIII. Impact on Constituents 

The e-business querying and reporting functions should have a highly positive impact on most 

NEDSS constituents. Through improved early detection and management, public health 

programs for the State of Maine could be more effective and efficient in protecting and treating 

the citizens of Maine. Furthermore, in conjunction with the web browser improvements for data 

reporting, the e-business functions can lead to improved management and treatment programs for 

both providers and public health agencies. 

The one constituent group that may experience a modest negative impact could be the Maine 

Bureau of Health, who is responsible for data security, collection, verification, storage, and all 

system maintenance, including the necessary data query and report generator software. These 

are sensitive data, and access and reporting functions will require strict monitoring procedures 

from BOH. Nevertheless, it is anticipated that there would be, at most, only a modest increase in 

BOH workload stemming from these e-business functions. This could be more than offset by the 

human resource savings should other BOH datasets be incorporated into NEDSS for the 

collection, cleaning, storage and/or reporting of data. 

IX. Creative and Cognitive Design 

It is expected that there would be no creative or cognitive design issues regarding the e-business 

functions. The necessary NEDSS architecture will have already been created, and the various 

constituents will create the subsequent reports generated through the e-business functions online. 

The one caveat involves any projected increases in the numbers of users and the volume of 

queries and reports generated, especially with the addition of other public health datasets. 

Should the volume exceed the current system capacity, new system architecture (and 

programming) may need to be configured to meet the demand for the e-business functions. 

X. High Level Architecture 

As noted above, existing system architecture planned for the base system should be sufficient to 

handle short-term projected e-business query and report generating demand. The system 

supports web browser-based data entry and retrieval, as well as the additional query and report 

generating functions, although subsequent user activity could require higher level architecture to 

improve data access, processing speed, and information dissemination. 

PHRG 5 of 5 

September 28, 2001

National Electronic Disease Surveillance System (NEDSS ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?