National Electronic Disease Surveillance System (NEDSS ...
National Electronic Disease Surveillance System (NEDSS ...
National Electronic Disease Surveillance System (NEDSS ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Phase II Deliverables #1, 2 and 3 for<br />
Encumbrance #1000440, Agreement #2575<br />
<strong>National</strong> <strong>Electronic</strong> <strong>Disease</strong> <strong>Surveillance</strong> <strong>System</strong><br />
(<strong>NEDSS</strong>)<br />
Implementation Project Plan<br />
Submitted to the<br />
State of Maine<br />
Department of Human Services<br />
Bureau of Health<br />
September 28, 2001<br />
Submitted by<br />
PUBLIC HEALTH RESOURCE GROUP<br />
120 Exchange Street<br />
Portland, ME 04101<br />
(207) 761-7093<br />
Vendor # 01-0440183
<strong>National</strong> <strong>Electronic</strong> <strong>Disease</strong><br />
<strong>Surveillance</strong> <strong>System</strong> (<strong>NEDSS</strong>)<br />
Phase II, Task #1 and #2 Deliverables:<br />
Planned IT & Data Management Document<br />
and<br />
Detail Plan Documents
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
<strong>National</strong> <strong>Electronic</strong> <strong>Disease</strong> <strong>Surveillance</strong> <strong>System</strong><br />
(<strong>NEDSS</strong>) Plan – Phase II, Tasks #1 and #2 Deliverables<br />
Table of Contents<br />
Table of Contents .......................................................................................................................... 2<br />
I. Executive Summary ................................................................................................................. 4<br />
<strong>NEDSS</strong> Background................................................................................................................... 4<br />
Purpose....................................................................................................................................... 4<br />
Constraints.................................................................................................................................. 4<br />
II. Project Overview..................................................................................................................... 5<br />
Introduction ................................................................................................................................5<br />
Purpose, Scope and Objectives .................................................................................................. 5<br />
Assumptions............................................................................................................................... 5<br />
Major Project Deliverables......................................................................................................... 6<br />
Schedule Summary..................................................................................................................... 7<br />
Evolution of the Plan.................................................................................................................. 7<br />
References .................................................................................................................................. 7<br />
Definitions and Acronyms ......................................................................................................... 8<br />
III. Project Organization............................................................................................................. 9<br />
External Interfaces...................................................................................................................... 9<br />
Internal Structure...................................................................................................................... 10<br />
Roles and Responsibilities ....................................................................................................... 11<br />
IV. Managerial Process Plans ................................................................................................... 12<br />
Start-up Plan............................................................................................................................. 12<br />
Work Plan................................................................................................................................. 12<br />
Project Tracking Plan............................................................................................................... 12<br />
Risk Management Plan............................................................................................................. 13<br />
V. Technical Process Plans........................................................................................................ 14<br />
Process Model .......................................................................................................................... 14<br />
Methods, Tools and Techniques............................................................................................... 14<br />
Infrastructure ............................................................................................................................ 14<br />
Implementation Acceptance..................................................................................................... 14<br />
PHRG Page 2 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
VI. Supporting Process Plans................................................................................................... 15<br />
Configuration Management...................................................................................................... 15<br />
Verification and Validation...................................................................................................... 15<br />
Documentation ......................................................................................................................... 15<br />
Quality Assurance .................................................................................................................... 15<br />
Reviews and Audits.................................................................................................................. 15<br />
Problem Resolution.................................................................................................................. 15<br />
Subcontractor Management...................................................................................................... 15<br />
Process Improvement ............................................................................................................... 15<br />
VII. Migration and Training Plans ........................................................................................... 16<br />
Migration Plan.......................................................................................................................... 16<br />
Training Plan............................................................................................................................ 16<br />
VIII. Summary ............................................................................................................................ 17<br />
Appendix A – Configuration Management Plan Guideline.................................................... 18<br />
Appendix B – Quality Assurance Plan Guideline .................................................................... 20<br />
Appendix C – Project Management Glossary.......................................................................... 22<br />
Appendix D – Project Plan......................................................................................................... 31<br />
PHRG Page 3 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
I. Executive Summary<br />
<strong>NEDSS</strong> Background<br />
The <strong>National</strong> <strong>Electronic</strong> <strong>Disease</strong> <strong>Surveillance</strong> <strong>System</strong> project is an initiative supported by CDC<br />
through a cooperative partnership with many public health stakeholders to improve the<br />
efficiency, effectiveness and timeliness of public health related surveillance information and<br />
associated activities. The stakeholders include the CDC, state public health departments, health<br />
care service organizations, health care product vendors and health care standards organizations.<br />
Specifically, the <strong>NEDSS</strong> initiative aims to develop standards that will facilitate the collection,<br />
storage, and dissemination of disease related data in real-time, from a variety of sources, to assist<br />
in the monitoring of community health, analysis and detection of emerging public health<br />
problems, and as a basis for public health policy. Some of the distinct opportunities to be gained<br />
through this initiative are:<br />
• Integration of disparate disease reporting systems;<br />
• Ability to identify national public health threats more promptly; and<br />
• More timely and accurate disease reporting.<br />
The standards developed will focus on at least five important areas: data architecture, user<br />
interface, information systems software architecture, tools for analysis, interpretation and<br />
dissemination of data, and secure data transfer. The development of these standards, while<br />
allowing the various State and local health departments enough flexibility to implement systems<br />
that best fit their specific information systems environment and needs, will assure that data (and<br />
software) can be easily and securely shared across health programs.<br />
Purpose<br />
The purpose of this document is to provide BOH professionals with a comprehensive project<br />
plan with which to implement <strong>NEDSS</strong> within the existing information technology infrastructure.<br />
Utilizing the assessment information gathered in Phase I, this document outlines the necessary<br />
phases and tasks to fully implement the <strong>NEDSS</strong> Base system and its functionality, while<br />
maintaining the integrity of the <strong>NEDSS</strong> architecture and existing system data. This includes, but<br />
may not be limited to: data exchange with the State reference laboratory (HETL) along with<br />
other key laboratory stakeholders, functional replacement of both NETSS and TIMS, and some<br />
form of integration with IMMPACT.<br />
Constraints<br />
This document provides high level detailed implementation phase and task descriptions, without<br />
the availability of the final <strong>NEDSS</strong> Base <strong>System</strong> from the CDC (to be released Fall of 2001).<br />
Thus, it is not possible to provide complete detail as to all the data management, functionality<br />
and related tasks. This consequently impacts the completeness of the project plan and should be<br />
taken into account when the final Base <strong>System</strong> does become available to the BOH.<br />
PHRG Page 4 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
II. Project Overview<br />
Introduction<br />
This section of the <strong>NEDSS</strong> Implementation Plan provides an overview of the purpose, scope and<br />
objectives of the project, the project assumptions and constraints, a list of project deliverables, a<br />
summary of the project schedule, and the plan for evolving the Implementation Plan.<br />
Purpose, Scope and Objectives<br />
The purpose of the project is to provide BOH and other key stakeholders with the means to<br />
improve timeliness, completeness and quality of disease reporting. This in turn will allow for the<br />
rapid detection of public health threats, timely public health responses and facilitate accurate and<br />
complete public health decision-making processes.<br />
The core objectives of this project are to:<br />
• Fully implement the <strong>NEDSS</strong> Base system in a production environment;<br />
• Establish reporting and data exchange with the State Health and Environmental Testing<br />
Laboratory;<br />
• Establish reporting and data exchange with a large in-state reference laboratory;<br />
• Establish reporting and data exchange with a hospital laboratory;<br />
• Replace the existing NETSS functionality with the <strong>NEDSS</strong> Base system;<br />
• Replace the existing TIMS functionality with the <strong>NEDSS</strong> Base system;<br />
• Interface with IMMPACT;<br />
• Document the <strong>NEDSS</strong> system; and<br />
• Provide Training to appropriate BOH staff and stakeholders.<br />
This project will be closely tied to the Health Alert Network (HAN) initiative, as both projects<br />
address similar public health issues and objectives and require cooperation from the same<br />
stakeholders. As the HAN project becomes further defined, the <strong>NEDSS</strong> Implementation project<br />
plan will be modified to describe the specific tasks where the two projects dovetail.<br />
Additionally, this project will work closely with the ongoing effort of IMMPACT.<br />
Outside of BOH, this project needs to work in conjunction with ongoing efforts and projects<br />
within the DHS Technology Services (DoTS), such as implementation of Health Insurance<br />
Portability and Accountability Act (HIPAA).<br />
Assumptions<br />
The following assumptions relate to the objectives of the <strong>NEDSS</strong> Implementation project as<br />
stated above:<br />
• The project and other management plans cannot be finalized until the <strong>NEDSS</strong> Base<br />
system is released;<br />
• The final <strong>NEDSS</strong> Base <strong>System</strong> is released by CDC prior to the start of the project<br />
implementation;<br />
• CDC resource is available for technical system training;<br />
PHRG Page 5 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
• Appropriate laboratory resources are available for implementing data exchange<br />
functionality;<br />
• DoTS can assign appropriate resources throughout duration of project; and<br />
• A suitable development / testing environment is available.<br />
Major Project Deliverables<br />
This project will produce the following milestone deliverables:<br />
Deliverable Date Medium<br />
Communication Plan (initial) 1/7/2002 - <strong>Electronic</strong> / hardcopy<br />
Laboratory Assessment Tool 1/15/2002 <strong>Electronic</strong> / hardcopy<br />
Project Plan (initial) 2/7/2002 - <strong>Electronic</strong> / hardcopy<br />
Quality Assurance Plan (initial) 2/14/2002 - <strong>Electronic</strong> / hardcopy<br />
Lab Requirements Document 2/19/2002 <strong>Electronic</strong> / hardcopy<br />
Configuration Management Document 2/14/2002 <strong>Electronic</strong> / hardcopy<br />
Requirements Specification Document 3/1/2002 <strong>Electronic</strong> / hardcopy<br />
Installation Plan Document (initial) 3/4/2002 - <strong>Electronic</strong> / hardcopy<br />
Test Plan Document (initial) 3/14/2002 - <strong>Electronic</strong> / hardcopy<br />
Acceptance Test Plan Document (initial) 3/22/2002 - <strong>Electronic</strong> / hardcopy<br />
Data Migration Plan Document 4/8/2002 <strong>Electronic</strong> / hardcopy<br />
<strong>System</strong> Logical Model Document 5/7/2002 <strong>Electronic</strong> / hardcopy<br />
Data Dictionary (initial) 5/21/2002 - <strong>Electronic</strong> / hardcopy<br />
Requirements Traceability Document 5/28/2002 <strong>Electronic</strong> / hardcopy<br />
<strong>System</strong> Design Document 6/4/2002 <strong>Electronic</strong> / hardcopy<br />
Training Plan Document (initial) 7/25/2002 - <strong>Electronic</strong> / hardcopy<br />
Operations Document 8/9/2002 <strong>Electronic</strong> / hardcopy<br />
Support Plan Document (initial) 7/12/2002 - <strong>Electronic</strong> / hardcopy<br />
Stakeholders trained in system use 8/222002 Training<br />
Technical Stakeholders trained in system maintenance 8/27/2002 Training<br />
Acceptance Test Report 8/30/2002 <strong>Electronic</strong> / hardcopy<br />
<strong>NEDSS</strong> Base <strong>System</strong> in production 9/2/2002 <strong>System</strong><br />
Review Plan and Results Document 10/17/2002 <strong>Electronic</strong> / hardcopy<br />
PHRG Page 6 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Schedule Summary<br />
The following table outlines the project schedule by phase. See appendix for detailed project<br />
plan which includes all tasks.<br />
WBS Phase Duration Begin Date End Date<br />
1 <strong>NEDSS</strong> IMPLEMENTATION 207.5d Tue 1/1/02 Thu 10/17/02<br />
1.1 PLANNING PHASE 34d Tue 1/1/02 Fri 2/15/02<br />
1.2 REQUIREMENTS PHASE 69.5d Fri 1/11/02 Thu 4/18/02<br />
1.3 DESIGN PHASE 60d Tue 4/16/02 Tue 7/9/02<br />
1.4 BUILD PHASE 120.5d Tue 2/26/02 Tue 8/13/02<br />
1.5 TEST PHASE 84.5d Fri 3/29/02 Thu 7/25/02<br />
1.6 IMPLEMENTATION PHASE 128.5d Wed 3/6/02 Mon 9/2/02<br />
1.7 REVIEW PHASE 33d Mon 9/2/02 Thu 10/17/02<br />
Evolution of the Plan<br />
The structure of this project plan is in compliance with the recommendations of IEEE Std. 1058-<br />
1998. The project plan will be maintained in Microsoft Project 2000, and will be disseminated<br />
both electronically and in hardcopy (where needed) by the contracted project manager. The<br />
contractor for this project will manage the project plan in cooperation with the BOH and be<br />
responsible for its configuration management process.<br />
After initial release of the draft plan, the contracted project manager will be responsible for<br />
maintaining the “master” project plan, and all earlier versions will be retained through the<br />
configuration process (check in / check out). A review protocol will be developed in the<br />
communication plan that will outline the process by which the plan is to be modified.<br />
References<br />
This document makes references to the following standards:<br />
IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans<br />
IEEE Std 828-1998, IEEE Standard for Software Configuration Management Plans<br />
IEEE Std 1012-1998, IEEE Standard for Software Verification and Validation<br />
IEEE Std 1012-1998, IEEE Standard for Software Project Management Plans<br />
IEEE Std 1074-1997, IEEE Standard for Developing Software Life Cycle Processes<br />
PHRG Page 7 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Definitions and Acronyms<br />
The following are definitions of all acronyms used in this document:<br />
Acronym<br />
BOH<br />
CDC<br />
DHS<br />
DoTS<br />
HAN<br />
HETL<br />
HIPAA<br />
IEEE<br />
IMMPACT<br />
<strong>NEDSS</strong><br />
NETSS<br />
TIMS<br />
Definition<br />
Bureau of Health<br />
Center for <strong>Disease</strong> Control<br />
Department of Human Services<br />
DHS Technology Services<br />
Health Alert Network<br />
Health and Environmental Testing Laboratory<br />
Health Insurance Portability and Accountability Act<br />
Institute of Electrical and <strong>Electronic</strong>s Engineers<br />
Maine Immunization Information Service<br />
<strong>National</strong> <strong>Electronic</strong> <strong>Disease</strong> <strong>Surveillance</strong> <strong>System</strong><br />
<strong>National</strong> <strong>Electronic</strong> Telecommunications <strong>System</strong> for <strong>Surveillance</strong><br />
Tuberculosis Information Management <strong>System</strong><br />
PHRG Page 8 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
III. Project Organization<br />
External Interfaces<br />
The <strong>NEDSS</strong> Implementation project will have a large number of stakeholders and stakeholder<br />
organizations throughout the life of the project. The following diagram illustrates the<br />
stakeholders and their relative importance (sphere of influence) to the success of the project.<br />
BOH<br />
<strong>Disease</strong><br />
Control<br />
<strong>NEDSS</strong><br />
Contractor<br />
CDC<br />
HETL<br />
State Ref.<br />
Lab / Hospital<br />
Lab<br />
DoTS<br />
Other<br />
Public Health<br />
Organizations<br />
PHRG Page 9 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Internal Structure<br />
The structure of BOH, the primary stakeholder in this project is as follows:<br />
Dora A. Mills, MD, MPH<br />
Director<br />
Bureau of Health<br />
State Health Officer<br />
March 2001<br />
(Draft)<br />
Philip W. Haines<br />
Deputy Director<br />
Bureau of Health<br />
--Environmental<br />
Toxicology<br />
N. Warren Bartlett<br />
Director<br />
Office of<br />
Health Data and<br />
Program Management<br />
--Vital Records<br />
--School Health<br />
Infrastructure<br />
--Survey Operations<br />
--Data and Research<br />
--Office of Primary<br />
Health Care<br />
--Maine Office of<br />
Rural Health<br />
Jack Krueger<br />
Chief, Lab Op.<br />
Health and<br />
Environmental Testing<br />
Laboratory<br />
Clough Toppan<br />
Director<br />
Division of<br />
Health Engineering<br />
Community Health<br />
Programs<br />
Barbara Leonard<br />
Director<br />
Family Health<br />
Programs<br />
Valerie Ricker<br />
Director<br />
Paul Kuehnert<br />
Director<br />
Division of<br />
<strong>Disease</strong> Control<br />
--Chemistry<br />
--Clinical Microbiology<br />
--Environmental<br />
--Clinical Certification<br />
--Organics<br />
--Inorganics, Nutrients,<br />
Microbiology Agents<br />
--Plumbing Control<br />
--Radiological Health<br />
--Eating and Lodging<br />
--Drinking Water<br />
Bureau of Health<br />
Organizational Chart<br />
--Breast and Cervical<br />
Health Program<br />
--Community Health/<br />
Chronic <strong>Disease</strong><br />
Prevention Unit<br />
--Oral Health Program<br />
--Diabetes Control Project<br />
--Teen and Young Adult<br />
Health Program<br />
--Partnership for a<br />
Tobacco-Free Maine<br />
--MCH Medical Director<br />
--Chronic Epidemiology<br />
Capacity Building<br />
--Injury Prevention<br />
and Control Program<br />
--Cancer Registry<br />
--Occupational Health<br />
Program<br />
--Healthy Families Program<br />
--Public Health Nursing<br />
--Women and Children's<br />
Preventive Health<br />
Services Program<br />
--Lead Poisoning<br />
Prevention Program<br />
--Coordinated Care<br />
Services for<br />
Children with Special<br />
Health Needs<br />
--Genetics Program<br />
--WIC Program<br />
--State <strong>System</strong><br />
Development Initiative<br />
--Nutrition Program<br />
--HIV/STD Program<br />
--Tuberculosis Control<br />
Program<br />
--Refugee Health<br />
Assessment Program<br />
--Epidemiology Program<br />
--Immunization Program<br />
--EPSDT<br />
--Immpact<br />
A representative from the Division of <strong>Disease</strong> Control, acting as the project manager from the<br />
State, will provide the direct interface between the key stakeholders (BOH and CDC) and the<br />
implementation contractor. This interaction will typically be on a daily basis and will include<br />
functions such as: resource allocation, plan management, quality assurance, test validation and<br />
general project administration. Other State programs and divisions will also be involved as<br />
needed, and will be directed by the contractor with direction and guidance from the <strong>Disease</strong><br />
Control project manager.<br />
PHRG Page 10 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Roles and Responsibilities<br />
The principle roles in the implementation project plan, as indicated in the project resource plan,<br />
include the following:<br />
Role<br />
<strong>NEDSS</strong> Project Sponsor<br />
Contractor Project Mgr.<br />
Contractor Technical Resource<br />
Contractor Quality Assurance<br />
BOH Project Mgr.<br />
CDC Technical Consultant<br />
DOTS Sponsor<br />
DOTS Technical Advisor<br />
BOH Stakeholder<br />
Lab. Sponsor<br />
Lab. Technical Resource<br />
Abbreviation<br />
BOH_SP<br />
CON_PM<br />
CON_TR<br />
CON_QA<br />
BOH_PM<br />
CDC_TC<br />
DOT_SP<br />
DOT_TA<br />
BOH_SH<br />
LAB_SP<br />
LAB_TR<br />
The roles responsible for the day-to-day management of the implementation project lies with the<br />
BOH Project Manager (<strong>Disease</strong> Control) and the Contractor Project Manager. These two<br />
individuals are responsible for ensuring that the project stays on target as it pertains to<br />
deliverables and budget.<br />
Key individuals from the CDC, DoTS and HETL will provide technical assistance throughout<br />
the project. It will be critical to establish communication with the assigned individuals once<br />
project commences to disseminate the plan objectives and their specific responsibilities. Both<br />
project managers will be responsible for these early stakeholder meetings.<br />
Laboratory (other than HETL) stakeholder meetings will also occur early in the project as to<br />
ascertain the pilot organizations and begin assessment of their environment. This phase depends<br />
heavily on the commitment of the laboratory and knowledge of the assigned resource(s). Both<br />
implementation project managers will also coordinate this section.<br />
PHRG Page 11 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
IV. Managerial Process Plans<br />
Start-up Plan<br />
As control of the budget is not within the scope of this plan, the only portion of the start-up plan<br />
that will be addressed in this document will relate to staffing and resource acquisition.<br />
The required contractor resources allocated during this project will vary from 2 in the initial<br />
phases, to 3 or 4 during the actual testing and implementation phase. These resources will have<br />
both technical and project planning skill sets.<br />
Besides the project manager, which this project will require a significant portion of their time<br />
(+50%), the BOH will need to allocate some nominal time for resources associated with NETSS,<br />
TIMS, IMMPACT, and the data contained within these systems. This should amount to<br />
approximately one person per system for several weeks.<br />
DoTS will provide a key role in this project, and accordingly this project will rely at times quite<br />
heavily on that resource. Concerning the acquisition and allocation of technical resources<br />
(hardware and software), or just familiarizing the project team with the technology standards in<br />
place, this project will require both highly technical and administrative DoTS resources.<br />
One of the primary functions of <strong>NEDSS</strong> is the receipt of laboratory test results. With HETL<br />
acting as the fundamental supplier laboratory data, a successful interface (data exchange)<br />
between the <strong>NEDSS</strong> Base system and the HETL is dependant upon key resources within the<br />
laboratory. This project will require significant time from technical and laboratory processing<br />
staff at HETL. These technical resources will not only need the skill set to understand current<br />
technologies, but have intimate knowledge of the HETL system and all its nuances.<br />
Additional resources will be identified and reported once the project officially begins and the<br />
requirements become established.<br />
Work Plan<br />
See the attached project plan.<br />
Project Tracking Plan<br />
Project tracking will be coordinated between the contractor and BOH project managers. One of<br />
the first stages of the project will be to define how to implement requirements management and<br />
schedule control. Without all the details of the <strong>NEDSS</strong> Base system and consequently the<br />
specifications of the implementation, this section outlines key areas that will need to be<br />
established once the project begins:<br />
• Specify the process for measuring, reporting and controlling changes to the project<br />
requirements.<br />
• Specify the processes to be used in assessing the impact of requirements changes on<br />
product scope and quality, and the impacts of requirements changes on project schedule,<br />
budget, resources and risk factors.<br />
PHRG Page 12 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
• In the configuration management processes, specify change control procedures and the<br />
formation and use of a change control board.<br />
• In the processes for requirements management, include traceability, prototyping and<br />
modeling, impact analysis and reviews.<br />
With project management as it pertains to Quality Control, the following key areas will be<br />
defined:<br />
• Specify the processes to be used to measure and control the quality of the work and the<br />
resulting work products<br />
• Specify the use of quality control processes such as quality assurance of conformance to<br />
work processes, verification and validation, joint reviews, audits and process assessment.<br />
Risk Management Plan<br />
As with Project tracking, Risk Management can only be outlined at a high level until further<br />
details on the <strong>NEDSS</strong> Base <strong>System</strong> arrive. The following topics summarize the steps needed<br />
to create an adequate plan:<br />
• Specify the risk management plan for identifying, analyzing, and prioritizing project risk<br />
factors.<br />
• Specify plans for assessing initial risk factors and for the ongoing identification,<br />
assessment, and mitigation of risk factors throughout the life cycle of the project.<br />
• Describe the following:<br />
o Procedures for contingency planning,<br />
o Procedures for tracking the various risk factors,<br />
o Risk management work activities,<br />
o Procedures and schedules for performing risk management work activities,<br />
o Risk documentation and reporting requirements,<br />
o Organizations and personnel responsible or performing specific risk management<br />
activities, and<br />
o Procedures for communicating risks and risk status among the various customer,<br />
project and subcontractor organizations.<br />
PHRG Page 13 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
V. Technical Process Plans<br />
Process Model<br />
The process model for this project is outlined in the project plan attached (see Appendix).<br />
Though not all phase tasks flow in a sequential format, the overall flow is from top to bottom, or<br />
Planning to Requirements to Design to Build to Test to Implement to Review.<br />
Several of the phases have appropriate review and revision tasks, which allow the appropriate<br />
stakeholders to be updated on the project status and allow for minor project adjustments.<br />
Methods, Tools and Techniques<br />
This project will utilize only established engineering methodologies (e.g. IEEE standards) and<br />
tools. The specific programming tools will be determined when the <strong>NEDSS</strong> Base system is<br />
released. All other standards will be determined at the appropriate time after consultation with<br />
CDC and DoTS technical resources for compatibility within the respective environments.<br />
Infrastructure<br />
The technical infrastructure is dependant on the established standards within BOH, DoTS and<br />
those that are required by <strong>NEDSS</strong>. What will need to be determined during the associated<br />
phases (i.e. Build, Test and Implement) are as follows:<br />
• Hardware, operating system, network and software<br />
• Policies, procedures, standards, and facilities<br />
• Workstations, local area networks, software tools for analysis, design implementations,<br />
testing, and project management,<br />
• Desks, office space, etc.<br />
Implementation Acceptance<br />
Once the final system specifications are determined (Requirements Traceability Matrix), the<br />
criteria for both technical and user (stakeholder) deliverable acceptance is established. The<br />
Traceability Matrix will list every key function point of the system and how it is measured.<br />
Once the project sponsors and key stakeholders have signed off this document, the appropriate<br />
standards are in place to determine (measure) the status of the deliverables.<br />
PHRG Page 14 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
VI. Supporting Process Plans<br />
Configuration Management<br />
See attached Configuration Plan outline (Appendix A)<br />
Verification and Validation<br />
The project will be managed by daily communications between the two project managers, and<br />
weekly status meetings with the active project team members. This weekly status information<br />
will be used to update the project plan with “% complete” and “actual end dates” at the task<br />
level. This updated project plan will then be distributed to the key project stakeholders.<br />
Documentation<br />
The communication plan will outline the documents used throughout the project management<br />
process, such as: project status, project issues/concerns, communication protocols, etc., who is<br />
responsible for each and how they will be distributed.<br />
Quality Assurance<br />
See attached Quality Assurance Plan outline (Appendix B).<br />
Reviews and Audits<br />
Project reviews and audits will be performed on a weekly basis up to the Implementation phase,<br />
where the frequency may change to daily depending on the number of critical activities<br />
scheduled.<br />
Problem Resolution<br />
The problem resolution process and protocol will be outlined in the Communication Plan and be<br />
determined by both project managers.<br />
Subcontractor Management<br />
This plan will be defined by BOH / <strong>Disease</strong> Control Sponsor and Project Manager prior to<br />
project start.<br />
Process Improvement<br />
No activity related to process improvement scheduled at this time.<br />
PHRG Page 15 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
VII. Migration and Training Plans<br />
Migration Plan<br />
The Migration Plan describes the strategies involved in converting data from the existing<br />
systems (NETSS and TIMS) to the <strong>NEDSS</strong> Base system. It is appropriate to reexamine the<br />
original system's functional requirements for the condition of the system before conversion to<br />
determine if the original requirements are still valid. Some of the major tasks in a Migration<br />
Plan are as follows:<br />
• <strong>System</strong> Overview<br />
• <strong>System</strong> Conversion Overview<br />
• Conversion Description<br />
• Type of Conversion<br />
• Conversion Strategy<br />
o Data Conversion Strategy<br />
o Data Conversion Approach<br />
o Interfaces<br />
o Data Quality Assurance and Control<br />
• Conversion Risk Factors<br />
• Conversion Tasks<br />
o Conversion Planning<br />
o Preconversion Tasks<br />
o Major Tasks and Procedures<br />
• Conversion Schedule<br />
Training Plan<br />
The Training Plan outlines the objectives, needs, strategy, and curriculum to be addressed when<br />
training users on the new or enhanced information system. The plan presents the activities<br />
needed to support the development of training materials, coordination of training schedules,<br />
reservation of personnel and facilities, planning for training needs, and other training-related<br />
tasks. An example of a Training Plan is:<br />
• Instructional Analysis<br />
o Issues and Recommendations<br />
o Needs and Skills Analysis<br />
• Instructional Methods<br />
o Training Methodology<br />
o Training Database<br />
• Training Resources<br />
o Resources and Facilities<br />
o Schedules<br />
o Future Training<br />
• Training Curriculum<br />
PHRG Page 16 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
VIII. Summary<br />
Summary<br />
The implementation of the <strong>NEDSS</strong> Base <strong>System</strong> will provide the electronic processes needed for<br />
a superior notifiable disease surveillance and analysis system, replacing the functionality<br />
currently supported by the <strong>National</strong> <strong>Electronic</strong> Telecommunications <strong>System</strong> for <strong>Surveillance</strong><br />
(NETSS) and the Tuberculosis Information Management <strong>System</strong> (TIMS). Additionally, it will<br />
provide an environment for increased data quality, timeliness and reporting of laboratory data.<br />
Though this <strong>NEDSS</strong> Base <strong>System</strong> implementation is not intended to represent the complete<br />
<strong>NEDSS</strong> solution, it will provide the foundation upon which further BOH program needs, data<br />
collection, processing and reporting can be built.<br />
The plan presented in this document proposes several essential components of implementing a<br />
complex disease reporting system—Organization, Managerial Process Plans, Technical Process<br />
Plans, Support Process Plans and Migration and Training Plans and several key appendices.<br />
These documents along with the eBusiness Plan, also attached, were completed with the<br />
understanding that the state will be using, at least in the first phases of implementation, the Base<br />
<strong>System</strong> to be provided by CDC.<br />
The implementation plan presented in this document, and its associated methodology, serve to<br />
provide a structured and proven framework to ensure successful deliverables and to meet<br />
business objectives. More specifically, this plan provides the following benefits:<br />
• Reduced risk of project failure<br />
• Consideration of system and data requirements throughout the entire life of the system<br />
• Early identification of technical and management issues<br />
• Realistic expectations of what the systems will and will not provide<br />
• Information to better balance programmatic, technical, management, and cost aspects of<br />
proposed system development or modification<br />
• Measurements of progress and status to enable effective corrective action<br />
• Information that supports effective resource management and budget planning<br />
• Consideration of meeting current and future business requirements<br />
Once the CDC Base <strong>System</strong> is received it will be necessary to develop a more detailed<br />
implementation plan as part of the implementation process since the parameters of CDC’s Base<br />
<strong>System</strong> and the software that comes are not known at this time. However the planning processes<br />
described in this document will permit the state to move forward with implementation more<br />
swiftly and take a giant leap forward in its ability to access, transmit and report both disease data<br />
for the residents of Maine and soon after that bring many of the related datasets in the BOH into<br />
the system.<br />
PHRG Page 17 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Appendix A – Configuration Management Plan Guideline<br />
Introduction<br />
Provide a brief statement that introduces the Configuration Management (CM) plan and<br />
describes, in general terms, its use in managing the configuration of the specific project,<br />
or system.<br />
Purpose<br />
Describe why this CM plan was created, what it accomplishes, and how it is used.<br />
Scope<br />
Define the scope of CM planning.<br />
<strong>System</strong> Description<br />
Briefly describe the system, its history, and the environment in which the project<br />
operates. Describe the system architecture, operating system, and application languages.<br />
Definitions<br />
Define the terms that appear in the CM plan.<br />
Reference Documents<br />
List the documents that are referenced to support the CM process including any project or<br />
standards documents referenced in the body of the CM plan.<br />
Organization<br />
Identify the organization in which CM resides and all organization units that participate<br />
in the project. Define the functional roles of these organizational units within the project<br />
structure.<br />
CM Activities<br />
Identify all CM functions required to manage the configuration of the system.<br />
CM Responsibilities<br />
List CM responsibilities in supporting this project.<br />
Configuration Identification<br />
Explain that Configuration Identification is the basis on which the configuration items<br />
(CIs) are defined and verified; CIs and documents are labeled; changes are managed; and<br />
accountability is maintained. Define the automated tools that will be used to track and<br />
control the configuration baselines.<br />
Configuration Item Identification<br />
Identify the CIs to be controlled and specify a means of identifying changes to the CIs<br />
and related baselines.<br />
PHRG Page 18 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Identification Conventions<br />
Describe the identification (numbering) criteria for the software and hardware structure,<br />
and for each document or document set.<br />
Naming Conventions<br />
Provide details of the file naming convention to be used on the project and how file<br />
configuration integrity will be maintained.<br />
Configuration Baseline Management<br />
Describe what baselines are to be established. Explain when and how they will be defined<br />
and controlled.<br />
Configuration Control<br />
Explain that configuration change management is a process for managing configuration<br />
changes and variances in configurations.<br />
Change Management<br />
Define the process for controlling changes to the system baselines and for tracking the<br />
implementation of those changes.<br />
Review and Control Board(s)<br />
Describe any Review Groups that will be established for the project. For each group,<br />
discuss the members who will participate and their functional representatives.<br />
Configuration Status Accounting<br />
Explain that Configuration Status Accounting (CSA) is the process of keeping records of<br />
all change actions pertaining to a configuration item to generate reports on all decisions<br />
made and implemented. Also, show that CSA provides a means of storing and crossreferencing<br />
the collected data.<br />
Configuration Audits<br />
Describe how peer review audits and formal audits will be accomplished.<br />
Reviews<br />
Describe how the technical reviews relate to the establishment of baselines and explain<br />
the role of CM in these reviews.<br />
Version Control<br />
Describe the processes in place to control the amount and number of versions<br />
documented by this CM Plan.<br />
Documentation Management<br />
Describe the processes in place for documentation management and who is responsible<br />
for them.<br />
PHRG Page 19 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Appendix B – Quality Assurance Plan Guideline<br />
The purpose of the Quality Assurance (QA) plan is to ensure that delivered products satisfy<br />
contractual agreements, meet or exceed quality standards, and comply with the project<br />
methodology. The delivered QA plan will include a Program Level plan and Project plan. The<br />
Program Level plan describes all potential activities that QA could apply to a projects task and<br />
the Project Level QA plan will describe the actual QA activities that will be integrated with the<br />
project plan and schedule. The level of detail contained in the Project Level QA plan will be<br />
consistent with the complexity, size, intended use, mission criticality, and cost of failure of the<br />
system development effort.<br />
Purpose<br />
Establish the requirements for QA applicable to all portions of the system's development<br />
effort. QA activities require effort, resources, and time just like other project activities.<br />
References<br />
List documents used in QA reviews with complete citations (title; version number, if any;<br />
originating organization; date; etc.). References should include all standards that will<br />
apply to the QA function.<br />
Objective<br />
Outline QA objectives of the program as established by the Project Manager. Describe<br />
the benefits that will be realized by conforming to quality requirements and the<br />
contributions that QA makes to the success of the program.<br />
Organization<br />
Provide an operational organizational chart developed for the program from a QA<br />
perspective. Describe the tasks in terms of QA activities associated with the project.<br />
Identify responsibilities for project tasks.<br />
<strong>System</strong> Development<br />
Describe the objectives of QA in monitoring formal development to ensure that the<br />
concepts and standards applied by QA are implemented at the project and program levels.<br />
Test and Evaluation<br />
Describe the role of QA in ensuring that project requirements are satisfied and that formal<br />
testing is completed in accordance with plans, standards, and procedures. Discuss reviews<br />
of test plans, test specifications, test procedures, and test reports.<br />
Configuration Management<br />
Describe the role of QA in ensuring that CM activities are performed in accordance with<br />
the CM plans, standards, and procedures. Discuss reviews to verify that baseline control,<br />
configuration identification, configuration control, configuration status accounting, and<br />
configuration authentication have been accomplished.<br />
PHRG Page 20 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
QA Roles and Responsibilities<br />
Describe the organizational and functional alignment of the QA staff. Describe the roles<br />
and responsibilities at the management, team leader, and specialist levels.<br />
Processes<br />
Provide an overview of the processes that QA uses to ensure that processes and products<br />
associated with hardware, software, and documentation are monitored, sampled, and<br />
audited to ensure compliance with methodology, policy, and standards.<br />
Peer Review<br />
Commit to QA participation in the peer review process to identify, document, measure,<br />
and eliminate defects in a work product.<br />
Process Review<br />
Describe audit and assessment reviews that ensure that appropriate steps are taken to<br />
carry out activities specified by the project plan. Describe methods by which QA<br />
monitors processes by comparing the actual steps carried out with those in the<br />
documented procedures. Discuss QA's responsibility to provide review data to<br />
management to provide an indication of the quality and status of the project.<br />
Problem Reporting<br />
Describe the role of QA in identifying problems and recommending corrective actions.<br />
Identify the requirement for tasks to include QA in problem reporting and corrective<br />
action functions. Discuss the procedures and formats for the preparation, tracking, and<br />
management involvement in the use of Quality Action Reports (QARs) used in the<br />
program.<br />
QA Escalation Procedure<br />
Describe the QA escalation procedures that bring high-risk or long-standing, unresolved<br />
noncompliance-tracking issues to senior management's attention.<br />
QA Report Formats<br />
Describe the report formats that formally document and transmit information from QA<br />
audits and/or assessment reviews.<br />
Standards<br />
Describe requirement of QA to ensure that standards are identified that establishes the<br />
prescribed methods for development of work products. Also discuss QA's role in<br />
assessing standards for adequacy and applicability.<br />
Tools<br />
Describe the tool sets that QA employs in the conduct of administrative and technical<br />
functions.<br />
PHRG Page 21 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Appendix C – Project Management Glossary<br />
Acceptance Test - Formal testing conducted to determine whether or not a system satisfies its<br />
acceptance criteria and to enable the customer to determine whether or not to accept the system.<br />
See User Acceptance Test.<br />
Activity - A unit of work to be completed in order to achieve the objectives of a work<br />
breakdown structure. See Work Breakdown Structure. In process modeling, an activity requires<br />
inputs and produces outputs. See Input/Output.<br />
Application - A system providing a set of services to solve some specific user problem.<br />
Application Model - A model used to graphically and textually represent the required data and<br />
processes within the scope of the application development project.<br />
Application Software - Software specifically developed to perform a specific type of work; for<br />
example, a word processor. Compare to <strong>System</strong> Software.<br />
Architecture - The structure of a computer system, either a part or the entire system; can be<br />
hardware, software, or both.<br />
Audit - A formal review of a project (or project activity) for the purpose of assessing compliance<br />
with contractual obligations.<br />
Availability - The degree to which a system (or system component) is operational and accessible<br />
when required for use.<br />
Baseline - A work product (such as software or documentation) that has been formally reviewed,<br />
approved, and delivered and can only be changed through formal change control procedures. See<br />
Allocated Baseline, Functional Baseline, Operational Baseline, Product Baseline.<br />
Benchmark - A standard against which measurements or comparisons can be made.<br />
Bottom-up - The process of designing a system by designing the low-level components first;<br />
then integrating them into large subsystems until the complete system is designed; bottom-up<br />
testing tests these low-level components first, using software drivers to simulate the higher level<br />
components. See Top-down.<br />
Build - An operational version of a software product incorporating a specified subset of the<br />
complete system functionality. See Version.<br />
Business Process Reengineering - The redesign of an organization, culture, and business<br />
processes to achieve significant improvements in costs, time, service, and quality.<br />
Capability - A measure of the expected use of a system.<br />
Capacity - A measure of the amount of input a system could process and/or amount of work a<br />
system can perform; for example, number of users, number of reports to be generated.<br />
Certification - Comprehensive analysis of the technical and non-technical security features and<br />
other safeguards of a system to establish the extent to which a particular system meets a set of<br />
specified security requirements.<br />
Change - In Configuration Management, a formally recognized revision to a specified and<br />
documented requirement. See Change Control, Change Directive, Change Impact Assessment,<br />
Change Implementation Notice.<br />
PHRG Page 22 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Change Control - In Configuration Management, the process by which a change is proposed,<br />
evaluated, approved (or disapproved), scheduled, and tracked. See Change, Change Directive,<br />
Change Impact Assessment, Change Implementation Notice.<br />
Change Control Documents - Formal documents used in the configuration management<br />
process to track, control, and manage the change of configuration items over the systems<br />
development or maintenance life cycle. See <strong>System</strong> Change Request, Change Impact<br />
Assessment, Change Directive, and Change Implementation Notice.<br />
Client/Server - A network application in which the end-user interaction with the system (server)<br />
is through a workstation (client) that executes some portion of the application.<br />
Configuration Control - The process of evaluating, approving or (disapproving), and<br />
coordinating changes to hardware/software configuration items.<br />
Configuration Control Board - The formal entity charged with the responsibility of evaluating,<br />
approving (or disapproving), and coordinating changes to hardware/software configuration<br />
items.<br />
Configuration Item - An aggregation of hardware and/or software that satisfy an end-use<br />
function and is designated by the customer for configuration management; treated as a single<br />
entity in the configuration management process. A component of a system requiring control over<br />
its development throughout the life-cycle of the system.<br />
Configuration Management - The discipline of identifying the configuration of a<br />
hardware/software system at each life cycle phase for the purpose of controlling changes to the<br />
configuration and maintaining the integrity and traceability of the configuration through the<br />
entire life cycle.<br />
Configuration Management Plan - A formal document that establishes formal configuration<br />
management practices in a systems development/maintenance project. See Configuration<br />
Management.<br />
Configuration Status Accounting - The recording and reporting of the information that is<br />
needed to effectively manage a configuration; including a listing of the approved configuration<br />
identification, status of proposed changes to the configuration, and the implementation status of<br />
approved changes. See Configuration.<br />
Contingency Plan - A formal document that establishes continuity of operations processes in<br />
case of a disaster. Includes names of responsible parties to be contacted, data to be restored, and<br />
location of such data.<br />
Conversion - The process of converting (or exchanging) data from an existing system to another<br />
hardware or software environment.<br />
Conversion Plan - A formal document that describes the strategies involved in converting data<br />
from an existing system to another hardware or software environment.<br />
Cost Analysis - Presents the costs for design, development, installation, operation and<br />
maintenance, and consumables for the system to be developed.<br />
Cost-Benefit Analysis - The comparison of alternative courses of action, or alternative technical<br />
solutions, for the purpose of determining which alternative would realize the greatest cost<br />
benefit; cost-benefit analysis is also used to determine if the system development or maintenance<br />
costs still yield a benefit or if the effort should stop.<br />
Cost Estimate - the process of determining the total cost associated with a software development<br />
or maintenance project, to include the effort, time, and labor required.<br />
Criteria - A standard on which a decision or judgment may be based; for example, acceptance<br />
criteria to determine whether or not to accept a system.<br />
PHRG Page 23 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Critical Path - Used in project planning; the sequence of activities (or tasks) that must be<br />
completed on time to keep the entire project on schedule; therefore, the time to complete a<br />
project is the sum of the time to complete the activities on the critical path.<br />
Data Dictionary - A repository of information about data, such as its meaning, relationships to<br />
other data, origin, usage and format. A data dictionary manages data categories such as aliases,<br />
data elements, data records, data structure, data store, data models, data flows, data relationships,<br />
processes, functions, dynamics, size, frequency, resource consumption and other user-defined<br />
attributes.<br />
Database - A collection of logically related data stored together in one or more computerized<br />
files; an electronic repository of information accessible via a query language interface.<br />
Database Management <strong>System</strong> - A software system that controls storing, combining, updating,<br />
retrieving, and displaying data records.<br />
Data Store - A repository of data; a file.<br />
Demonstration - A procedure to verify system requirements that cannot be tested otherwise.<br />
Deliverable - A formal product that must be delivered to (and approved by) the customer; called<br />
out in the Task Order.<br />
Design Phase - The period of time in the systems development life cycle during which the<br />
designs for architecture, software components, interfaces, and data are created, documented, and<br />
verified to satisfy system requirements.<br />
Development Phase - The period of time in the systems development life cycle to convert the<br />
deliverables of the Design Phase into a complete system.<br />
Disposition Phase - The time when a system has been declared surplus and/or obsolete and the<br />
task performed is either eliminated or transferred to other systems.<br />
Disposition Plan - A formal plan providing the full set of procedures necessary to end the<br />
operation or the system in a planned, orderly manner and to ensure that system components and<br />
data are properly archived or incorporated into other systems.<br />
Document - Written and/or graphical information describing, defining, specifying, reporting, or<br />
certifying activities, requirements, procedures, reviews, or results. See Product.<br />
Entity - Represents persons, places, events, things, or abstractions that are relevant to the DOJ<br />
and about which data are collected and maintained.<br />
Feasibility - The extent to which the benefits of a new or enhanced system will exceed the total<br />
costs and also satisfies the business requirements.<br />
Feasibility Study - A formal study to determine the feasibility of a proposed system (new or<br />
enhanced) in order to make a recommendation to proceed or to propose alternative solutions.<br />
Functionality - The relative usefulness of a functional requirement as it satisfies a business<br />
need.<br />
Functional Baseline - The approved documentation that describes the functional characteristics<br />
of the system, subsystem, or component. See Baseline.<br />
PHRG Page 24 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Functional Requirement - A requirement that specifies a function (activity or behavior, based<br />
on a business requirement) that the system (or system component) must be capable of<br />
performing.<br />
Functional Requirements Document - A formal document of the business (functional)<br />
requirements of a system; the baseline for system validation.<br />
Functional Test - Testing that ignores the internal mechanism of a system (or system<br />
component) and focuses solely on the outputs generated in response to selected inputs and<br />
execution conditions. Same as black-box testing.<br />
Gantt Chart - A list of activities plotted against time, showing start time, duration, and end<br />
time; also known as a bar chart.<br />
Implementation - Installing and testing the final system, usually at the user (field) site; the<br />
process of installing the system.<br />
Implementation Phase - The period of time in the systems development life cycle when the<br />
system is installed, made operational, and turned over to the user (for the beginning of the<br />
Operations and Maintenance Phase).<br />
Implementation Plan - A formal document that describes how the system will be installed and<br />
made operational.<br />
Integration and Test Phase - Life cycle phase during which subsystem integration, system,<br />
security, and user acceptance testing are conducted; done prior to the Implementation Phase.<br />
Integration Test - Testing in which software components, hardware components, or both are<br />
combined and tested to evaluate the interaction between them.<br />
Integrity - The degree to which a system (or system component) prevents unauthorized access<br />
to, or modification of, computer programs or data.<br />
Interface - To interact or communicate with another system (or system component). An<br />
interface can be software and/or hardware. See User Interface.<br />
Life Cycle - All the steps or phases a project passes through during its system life; from concept<br />
development to disposition. There are nine life cycle phases in the SDLC.<br />
Methodology - A set of methods, procedures, and standards that define the approach for<br />
completing a system development or maintenance project.<br />
Metrics - A quantitative measure of the degree to which a system, component, or process<br />
possesses a given attribute.<br />
Migration - Porting a system, subsystem, or system component to a different hardware platform.<br />
Milestone - In project management, a scheduled event that is used to measure progress against a<br />
project schedule and budget.<br />
Model - A simplified representation or abstraction (for example, of a process, activity, or<br />
system) intended to explain its behavior.<br />
PHRG Page 25 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Operational Baseline - Identifies the system accepted by the users in the operational<br />
environment after a period of onsite test using production data. See Baseline.<br />
Operations Manual - A formal document that provides a detailed operational description of the<br />
system and its interfaces.<br />
Peer Review - A formal review where a product is examined in detail by a person or group other<br />
than the originator. See Inspection, Walk-through.<br />
Phase - A defined stage in the systems development life cycle; there are nine phases in the full,<br />
sequential life cycle.<br />
Pilot - An alternative work pattern to develop a system to demonstrate that the concept is<br />
feasible in an operational environment. Pilots are used to provide feedback to refine the final<br />
version of the product and are fielded for a preset, limited period of time. Compare to a<br />
Prototype.<br />
Planning Phase - The period of time in the systems development life cycle in which a<br />
comprehensive plan for the recommended approach to the systems development or maintenance<br />
project is created. Follows the <strong>System</strong>s Concept Development Phase, in which the recommended<br />
approach is selected.<br />
Post-Implementation Review - A formal review to evaluate the effectiveness of the systems<br />
development effort after the system is operational (usually for at least six months).<br />
Post-Implementation Review Report - A formal document detailing the findings of the Post-<br />
Implementation Review. See Post-Implementation Review.<br />
Post-Termination Review - A formal review to evaluate the effectiveness of a system<br />
disposition.<br />
Post-Termination Review Report - A formal document detailing the findings of the Post-<br />
Termination Review. See Post-Termination Review.<br />
Procedure - A series of steps (or instructions) required to perform an activity. Defines "how" to<br />
perform an activity. Compare to Process.<br />
Process - A finite series of activities as defined by its inputs, outputs, controls (for example,<br />
policy and standards), and resources needed to complete the activity. Defines "what" needs to be<br />
done. Compare to Procedure.<br />
Process Model - A graphical representation of a process.<br />
Process Review - A formal review of the effectiveness of a process.<br />
Production - A fully documented system, built according to the SDLC, fully tested, with full<br />
functionality, accompanied by training and training materials, and with no restrictions on its<br />
distribution or duration of use.<br />
Project - The complete set of activities associated with all life cycle phases needed to complete a<br />
systems development or maintenance effort from start to finish (may include hardware, software,<br />
and other components); the collective name for this set of activities. Typically a project has its<br />
own funding, cost accounting, and delivery schedule.<br />
Project Management - The process of planning, organizing, staffing, directing, and controlling<br />
the development and/or maintenance of a system.<br />
Project Management Plan - A formal document detailing the project scope, activities, schedule,<br />
resources, and security issues. The Project Management Plan is created during the Planning<br />
Phase and updated through the Disposition Phase.<br />
PHRG Page 26 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Project Manger - The person with the overall responsibility and authority for the day-to-day<br />
activities associated with a project.<br />
Quality - The degree to which a system, component, product, or process meets specified<br />
requirements.<br />
Quality Assurance - A discipline used by project management to objectively monitor, control,<br />
and gain visibility into the development or maintenance process.<br />
Quality Assurance Plan - A formal plan to ensure that delivered products satisfy contractual<br />
agreements, meet or exceed quality standards, and comply with approved systems development<br />
or maintenance processes.<br />
Quality Assurance Review - A formal review to ensure that the appropriate Quality Assurance<br />
activities have been successfully completed, held when a system is ready for implementation.<br />
Regression Test - In software maintenance, the rerunning of test cases that previously executed<br />
correctly in order to detect errors introduced by the maintenance activity.<br />
Release - A configuration management activity wherein a specific version of software is made<br />
available for use.<br />
Reliability - The ability of a system (or system component) to perform its required functions<br />
under stated conditions for a specified period of time.<br />
Requirement - A capability needed by a user; a condition or capability that must be met or<br />
possessed by a system (or system component) to satisfy a contract, standard, specification, or<br />
other formally imposed documents.<br />
Requirements Analysis Phase - The period of time in the systems development life cycle<br />
during which the requirements for a software product are formally defined, documented and<br />
analyzed.<br />
Requirements Management - Establishes and controls the scope of system development efforts<br />
and facilitates a common understanding of system capabilities between the <strong>System</strong> Proponent,<br />
developers, and future users.<br />
Requirements Traceability Matrix - Provides a method for tracking the functional<br />
requirements and their implementation through the development process.<br />
Resource - In management, the time, staff, capital and money available to perform a service or<br />
build a product; also, an asset needed by a process step to be performed.<br />
Review - A formal process at which an activity or product (for example, code, document) is<br />
presented for comment and approval; reviews are conducted for different purposes, such as peer<br />
reviews, user reviews, management reviews (usually for approval) or done at a specific<br />
milestone, such as phase reviews (usually to report progress).<br />
Review Report - A formal document that records the results of a review.<br />
Risk - A potential occurrence that would be detrimental to the project; risk is both the likelihood<br />
of the occurrence and the consequence of the occurrence.<br />
Risk Assessment - The process of identifying areas of risk; the probability of the risk occurring,<br />
and the seriousness of its occurrence; also called risk analysis.<br />
Risk Management - The integration of risk assessment and risk reduction in order to optimize<br />
the probability of success (that is, minimize the risk).<br />
PHRG Page 27 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Risk Management Plan - A formal document that identifies project risks and specifies the plans<br />
to reduce these risks.<br />
Role - A defined responsibility (usually task) to be carried out by one or more individuals.<br />
Scope - The established boundary (or extent) of what must be accomplished; during planning,<br />
this defines what the project will consist of (and just as important, what the project will not<br />
consist of).<br />
Security - The establishment and application of safeguards to protect data, software, and<br />
hardware from accidental or malicious modification, destruction, or disclosure.<br />
Security Test - A formal test performed on an operational system, based on the results of the<br />
security risk assessment in order to evaluate compliance with security and data integrity<br />
guidelines, and address security backup, recovery, and audit trails. Also called Security Testing<br />
and Evaluation (ST&E).<br />
Software - Computer programs (code), procedures, documentation, and data pertaining to the<br />
operation of a computer system. Compare to Hardware.<br />
<strong>System</strong> - A collection of components (hardware, software, interfaces) organized to accomplish a<br />
specific function or set of functions; generally considered to be a self-sufficient item in its<br />
intended operational use.<br />
<strong>System</strong> Concept Development Phase - Phase that starts the life cycle; begins when a need to<br />
develop or significantly change a system is identified, then the approaches for meeting this need<br />
are reviewed for feasibility and appropriateness (for example, cost-benefit analysis).<br />
<strong>System</strong> Design Document - A formal document that describes the system architecture, file and<br />
database design, interfaces, and detailed hardware/software design; used as the baseline for<br />
system development.<br />
<strong>System</strong>s Analysis - In systems development, the process of studying and understanding the<br />
requirements (customer needs) for a system in order to develop a feasible design.<br />
<strong>System</strong> Security Plan - A formal document that establishes the processes and procedures for<br />
identifying all areas where security could be compromised within the system (or subsystem).<br />
<strong>System</strong> Software - Software designed to facilitate the operation of a computer system and<br />
associated computer programs (for example, operating systems, code compilers, utilities).<br />
Compare to Application Software.<br />
<strong>System</strong> Test - The process of testing an integrated hardware/software system to verify that the<br />
system meets its documented requirements.<br />
Task - In project management, the smallest unit of work subject to management accountability; a<br />
work assignment for one or more project members fulfilling a role, as defined in a work<br />
breakdown structure.<br />
Test - The process of exercising the product to identify differences between expected and actual<br />
results and performance. Typically testing is bottom-up: unit test, integration test, system test,<br />
and acceptance test.<br />
Test Case - A specific set of test data and associated procedures developed for a particular test.<br />
Test Files/Data - Files/data developed for the purpose of executing a test; becomes part of a test<br />
case. See Test Case.<br />
PHRG Page 28 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Test and Evaluation (T&E) - T&E occurs during all major phases of the development life<br />
cycle, beginning with system planning and continuing through the operations and maintenance<br />
phase, ensures standardized identification, refinement, and traceability of the requirements as<br />
such requirements are allocated to the system components.<br />
Test and Evaluation Master Plan - The formal document that identifies the tasks and activities<br />
so the entire system can be adequately tested to assure a successful implementation.<br />
Test Problem Report - Formal documentation of problems encountered during testing; the form<br />
is attached to the Test Analysis Report. See Test Analysis Report.<br />
Top-down - An approach that takes the highest level of a hierarchy and proceeds through<br />
progressively lower levels; compare to Bottom-up.<br />
Traceability - In requirements management, the identification and documentation of the<br />
derivation path (upward) and allocation path (downward) of requirements in the hierarchy.<br />
Training - The formal process of depicting, simulating, or portraying the operational<br />
characteristics of a system or system component in order to make someone proficient in its use.<br />
Training Plan - A formal document that outlines the objectives, needs, strategy, and curriculum<br />
to be addressed for training users of the new or enhanced system.<br />
Unit Test - In testing, the process of ensuring that the software unit executes as intended; usually<br />
performed by the developer.<br />
User - An individual or organization that operates or interacts directly with the system; one who<br />
uses the services of a system. The user may or may not be the customer. See Customer.<br />
User Acceptance Test - Formal testing conducted to determine whether or not a system satisfies<br />
its acceptance criteria and to enable the user to determine whether or not to accept the system.<br />
See Acceptance Test.<br />
User Interface - The software, input/output (I/O) devices, screens, procedures, and dialogue<br />
between the user of the system (people) and the system (or system component) itself. See<br />
Interface.<br />
User Manual - A formal document that contains all essential information for the user to make<br />
full use of the new or upgraded system.<br />
Validation - The process of determining the correctness of the final product, system, or system<br />
component with respect to the user's requirements. Answers the question, "Am I building the<br />
right product?" Compare to Verification.<br />
Verifiability - A measure of the relative effort to verify a requirement; a requirement is<br />
verifiable only if there is a finite cost-effective process to determine that the software product or<br />
system meets the requirement.<br />
Verification - The process of determining whether the products of a life cycle phase fulfill the<br />
requirements established during the previous phase; answers the question, "Am I building the<br />
product right?" Compare to Validation.<br />
Verification and Validation Plan - A formal document that describes the process to verify and<br />
validate the requirements. Created during the Planning Phase and updated throughout the SDLC.<br />
Version - An initial release or re-release of a computer software configuration item, associated<br />
with a complete compilation or recompilation of the computer software configuration item;<br />
sometimes called a build. See Build.<br />
PHRG Page 29 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Walk-through - A software inspection process, conducted by peers of the software developer, to<br />
evaluate a software component. See Inspection, Peer Review.<br />
Work Breakdown Structure - In project management, a hierarchical representation of the<br />
activities associated with developing a product or executing a process; a list of tasks; often used<br />
to develop a Gantt Chart.<br />
PHRG Page 30 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Appendix D – Project Plan (See following 4 pages)<br />
PHRG Page 31 of 35 September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Appendix D - Project Plan<br />
ID WBS Task Name Duration Start Finish Resource Initials<br />
1 1 <strong>NEDSS</strong> IMPLEMENTATION 207.5 days Tue 1/1/02 Thu 10/17/02<br />
2 1.1 PLANNING PHASE 34 days Tue 1/1/02 Fri 2/15/02<br />
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<br />
4 1.1.2 Get the project team in place 1 day Tue 1/1/02 Tue 1/1/02 BOH_PM,CON_PM<br />
5 1.1.3 Prepare the Requirements Document (RD) 2 days Wed 1/2/02 Thu 1/3/02 CON_PM<br />
6 1.1.4 Conduct project kickoff meeting 1 day Fri 1/4/02 Fri 1/4/02 CON_PM,BOH_PM<br />
7 1.1.5 Create Communications Document (draft) 1 day Mon 1/7/02 Mon 1/7/02 CON_PM<br />
8 1.1.6 Laboratory Stakeholders 3 days Tue 1/8/02 Thu 1/10/02<br />
9 1.1.6.1 Determine Laboratory Stakeholders 1 day Tue 1/8/02 Tue 1/8/02 BOH_PM<br />
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<br />
11 1.1.6.3 Assign Lab Resources 1 day Thu 1/10/02 Thu 1/10/02 BOH_PM,LAB_SP<br />
12 1.1.7 DOTS Stakeholders 7 days Tue 1/8/02 Wed 1/16/02<br />
13 1.1.7.1 Determine DOTS Stakeholders 2 days Tue 1/8/02 Wed 1/9/02 BOH_PM,DOT_SP<br />
14 1.1.7.2 Project Kickoff meeting w/ Stakeholders 1 day Thu 1/10/02 Thu 1/10/02 BOH_PM,CON_PM<br />
15 1.1.7.3 Assign DOTS Resources 1 day Fri 1/11/02 Fri 1/11/02 BOH_PM,CON_PM,DOT_SP<br />
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<br />
17 1.1.8 Project Plan (Draft) 16 days Thu 1/17/02 Thu 2/7/02<br />
18 1.1.8.1 Develop Statement of Scope (SOS) 5 days Thu 1/17/02 Wed 1/23/02 CON_PM<br />
19 1.1.8.2 Conduct work-breakdown structure meeting 1 day Thu 1/24/02 Thu 1/24/02 CON_PM<br />
20 1.1.8.3 Build Work Breakdown Structure (WBS) 3 days Fri 1/25/02 Tue 1/29/02 CON_PM<br />
21 1.1.8.4 Transfer WBS to Microsoft Project 1 day Wed 1/30/02 Wed 1/30/02 CON_PM<br />
22 1.1.8.5 Outline project plan 1 day Thu 1/31/02 Thu 1/31/02 CON_PM<br />
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<br />
24 1.1.8.7 Review with Stakeholders 1 day Wed 2/6/02 Wed 2/6/02 CON_PM<br />
25 1.1.8.8 Publish Project Plan 1 day Thu 2/7/02 Thu 2/7/02 CON_PM<br />
26 1.1.9 Quality Assurance Plan 6 days Fri 2/8/02 Fri 2/15/02<br />
27 1.1.9.1 Develop document 5 days Fri 2/8/02 Thu 2/14/02 CON_QA<br />
28 1.1.9.2 Conduct structured walkthrough(s) 1 day Fri 2/15/02 Fri 2/15/02 CON_QA<br />
29 1.1.10 Revise Communication Plan 1 day Fri 2/8/02 Fri 2/8/02 CON_PM<br />
30<br />
31 1.2 REQUIREMENTS PHASE 69.5 days Fri 1/11/02 Thu 4/18/02<br />
32 1.2.1 <strong>NEDSS</strong> Base <strong>System</strong> Specifications 11 days Mon 2/11/02 Mon 2/25/02<br />
33 1.2.1.1 Acquire <strong>NEDSS</strong> Base <strong>System</strong> 1 day Mon 2/11/02 Mon 2/11/02 CON_PM<br />
34 1.2.1.2 Base <strong>System</strong> Training (w/ CDC Consultant) 10 days Tue 2/12/02 Mon 2/25/02 CON_TR,DOT_TA<br />
35 1.2.2 LAB Assessment 28 days Fri 1/11/02 Tue 2/19/02<br />
36 1.2.2.1 Develop Lab Assessment Tool 3 days Fri 1/11/02 Tue 1/15/02 CON_TR<br />
37 1.2.2.2 Survey Lab Stakeholder Environment 20 days Wed 1/16/02 Tue 2/12/02 CON_TR<br />
38 1.2.2.3 Create Lab Requirements Document 5 days Wed 2/13/02 Tue 2/19/02 CON_TR<br />
39 1.2.3 Configuration Management Plan 6 days Fri 2/8/02 Fri 2/15/02<br />
40 1.2.3.1 Develop document 5 days Fri 2/8/02 Thu 2/14/02 CON_PM<br />
41 1.2.3.2 Conduct structured walkthrough(s) 1 day Fri 2/15/02 Fri 2/15/02 CON_PM<br />
42 1.2.4 Requirements Specification 11 days Mon 2/18/02 Mon 3/4/02<br />
43 1.2.4.1 Develop document 10 days Mon 2/18/02 Fri 3/1/02 CON_PM<br />
44 1.2.4.2 Review Requirements with stakeholders 1 day Mon 3/4/02 Mon 3/4/02 CON_PM<br />
45 1.2.5 Project Test Plan 8.5 days Tue 3/5/02 Fri 3/15/02<br />
46 1.2.5.1 Develop document 7.5 days Tue 3/5/02 Thu 3/14/02 CON_TR,DOT_TA<br />
47 1.2.5.2 Conduct structured walkthrough(s) 1 day Thu 3/14/02 Fri 3/15/02 CON_TR<br />
48 1.2.6 Acceptance Test Plan (draft) 6 days Fri 3/15/02 Mon 3/25/02<br />
r 1st Quarter 2nd Quarter 3rd Quarter 4th Quarter 1st Quarter 2nd Quart<br />
Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May<br />
BOH Project Mgr.,Contractor Project Mgr.<br />
BOH Project Mgr.,Contractor Project Mgr.<br />
Contractor Project Mgr.<br />
1/4<br />
Contractor Project Mgr.<br />
BOH Project Mgr.<br />
BOH Project Mgr.,Contractor Project Mgr.<br />
BOH Project Mgr.,Lab. Sponsor<br />
BOH Project Mgr.,DOTS Sponsor<br />
BOH Project Mgr.,Contractor Project Mgr.<br />
BOH Project Mgr.,Contractor Project Mgr.,DOTS Sponsor<br />
BOH Project Mgr.,Contractor Project Mgr.,DOTS Sponsor<br />
Contractor Project Mgr.<br />
Contractor Project Mgr.<br />
Contractor Project Mgr.<br />
Contractor Project Mgr.<br />
Contractor Project Mgr.<br />
Contractor Project Mgr.,BOH Project Mgr.,DOTS Sponsor<br />
Contractor Project Mgr.<br />
2/7<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Project Mgr.<br />
2/11<br />
Contractor Technical Resource,DOTS Technical Advisor<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Project Mgr.<br />
Contractor Project Mgr.<br />
Contractor Project Mgr.<br />
3/4<br />
Contractor Technical Resource,DOTS Technical Advisor<br />
Contractor Technical Resource<br />
Project: <strong>NEDSS</strong>_Implementation_98_20<br />
Date: Sun 9/30/01<br />
Task<br />
Split<br />
Progress<br />
Milestone<br />
Summary<br />
Project Summary<br />
External Tasks<br />
External Milestone<br />
External Milestone<br />
Deadline<br />
PHRG September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Appendix D - Project Plan<br />
ID WBS Task Name Duration Start Finish Resource Initials<br />
Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May<br />
49 1.2.6.1 Prepare document 5 days Fri 3/15/02 Fri 3/22/02 CON_QA<br />
Contractor Quality Assurance<br />
50 1.2.6.2 Conduct structured walkthrough(s) 1 day Fri 3/22/02 Mon 3/25/02 CON_QA<br />
Contractor Quality Assurance<br />
51 1.2.7 Data Migration Plan 11 days Mon 3/25/02 Tue 4/9/02<br />
52 1.2.7.1 Prepare document 10 days Mon 3/25/02 Mon 4/8/02 CON_TR<br />
53 1.2.7.2 Conduct structured walkthrough(s) 1 day Mon 4/8/02 Tue 4/9/02 CON_TR<br />
54 1.2.8 Data Dictionary Outline 5 days Tue 4/9/02 Tue 4/16/02 CON_TR<br />
55 1.2.9 Revise Project Plan 2 days Tue 4/16/02 Thu 4/18/02 CON_PM<br />
56<br />
57 1.3 DESIGN PHASE 60 days Tue 4/16/02 Tue 7/9/02<br />
58 1.3.1 Create Data Exchange Interface/Mapping Template 10 days Tue 4/16/02 Tue 4/30/02 CON_TR<br />
59 1.3.2 Create Logical Model 5 days Tue 4/30/02 Tue 5/7/02 CON_TR<br />
60 1.3.3 Create Data Flow Diagram (DFD) 5 days Tue 5/7/02 Tue 5/14/02 CON_TR<br />
61 1.3.4 Produce Data Dictionary 5 days Tue 5/14/02 Tue 5/21/02 CON_TR<br />
62 1.3.5 Requirements Traceability Matrix 5 days Tue 5/21/02 Tue 5/28/02 CON_PM<br />
63 1.3.6 Functional Design 7 days Tue 5/28/02 Thu 6/6/02<br />
64 1.3.6.1 Develop document 5 days Tue 5/28/02 Tue 6/4/02 CON_PM<br />
65 1.3.6.2 Conduct structured walkthrough(s) 1 day Tue 6/4/02 Wed 6/5/02 CON_PM<br />
66 1.3.6.3 Conduct Functional Design Review 1 day Wed 6/5/02 Thu 6/6/02 CON_PM<br />
67 1.3.7 Laboratory Data Exchange 5 days Thu 6/6/02 Thu 6/13/02<br />
68 1.3.7.1 Prepare Lab Data Mapping Matrices 5 days Thu 6/6/02 Thu 6/13/02 CON_TR<br />
69 1.3.8 Integration Test Plan (draft) 6 days Thu 6/13/02 Fri 6/21/02<br />
70 1.3.8.1 Prepare document 5 days Thu 6/13/02 Thu 6/20/02 CON_TR,DOT_TA,CON_QA<br />
71 1.3.8.2 Conduct structured walkthrough(s) 1 day Thu 6/20/02 Fri 6/21/02 CON_QA<br />
72 1.3.9 <strong>System</strong> Test Plan (draft) 6 days Fri 6/21/02 Mon 7/1/02<br />
73 1.3.9.1 Prepare document 5 days Fri 6/21/02 Fri 6/28/02 CON_TR,DOT_TA,CON_QA<br />
74 1.3.9.2 Conduct structured walkthrough(s) 1 day Fri 6/28/02 Mon 7/1/02 CON_QA<br />
75 1.3.10 Migration Plan 6 days Mon 7/1/02 Tue 7/9/02<br />
76 1.3.10.1 Prepare document 5 days Mon 7/1/02 Mon 7/8/02 CON_TR,BOH_PM<br />
77 1.3.10.2 Conduct structured walkthrough(s) 1 day Mon 7/8/02 Tue 7/9/02 CON_TR<br />
78 1.3.11 <strong>System</strong> Design Document 12 days Thu 6/6/02 Mon 6/24/02<br />
79 1.3.11.1 Prepare document 10 days Thu 6/6/02 Thu 6/20/02 CON_TR<br />
80 1.3.11.2 Conduct structured walkthrough(s) 1 day Thu 6/20/02 Fri 6/21/02 CON_TR<br />
81 1.3.11.3 Conduct Critical Design Review 1 day Fri 6/21/02 Mon 6/24/02 CON_TR<br />
82 1.3.12 Review Design with stakeholders 1 day Mon 6/24/02 Tue 6/25/02 CON_TR<br />
83 1.3.13 Revise Project Plan 1 day Mon 6/24/02 Tue 6/25/02 CON_PM<br />
84<br />
85 1.4 BUILD PHASE 120.5 days Tue 2/26/02 Tue 8/13/02<br />
86 1.4.1 Create Development Environment 3 days Tue 2/26/02 Thu 2/28/02 CON_TR,DOT_TA<br />
87 1.4.2 Installation Plan (draft) 6 days Tue 2/26/02 Tue 3/5/02<br />
88 1.4.2.1 Develop document 5 days Tue 2/26/02 Mon 3/4/02 CON_PM<br />
89 1.4.2.2 Conduct structured walkthrough(s) 1 day Tue 3/5/02 Tue 3/5/02 CON_PM<br />
90 1.4.3 Integration Test Plan (final) 2 days Tue 6/25/02 Thu 6/27/02 CON_TR<br />
91 1.4.4 <strong>System</strong> Test Plan (final) 2 days Thu 6/27/02 Mon 7/1/02 CON_TR<br />
92 1.4.5 Migration Plan 3 days Mon 7/1/02 Thu 7/4/02<br />
93 1.4.5.1 Develop document 2 days Mon 7/1/02 Wed 7/3/02 CON_TR<br />
94 1.4.5.2 Conduct structured walkthrough(s) 1 day Wed 7/3/02 Thu 7/4/02 CON_TR<br />
95 1.4.6 Support Plan (draft) 6 days Thu 7/4/02 Fri 7/12/02<br />
96 1.4.6.1 Prepare document 5 days Thu 7/4/02 Thu 7/11/02 CON_PM<br />
r 1st Quarter 2nd Quarter 3rd Quarter 4th Quarter 1st Quarter 2nd Quart<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Project Mgr.<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Project Mgr.<br />
Contractor Project Mgr.<br />
Contractor Project Mgr.<br />
Contractor Project Mgr.<br />
Contractor Technical Resource<br />
Contractor Technical Resource,DOTS Techni<br />
Contractor Quality Assurance<br />
Contractor Technical Resource,DOTS Techn<br />
Contractor Quality Assurance<br />
Contractor Technical Resource,BOH Project Mgr.<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
6/24<br />
Contractor Project Mgr.<br />
Contractor Technical Resource,DOTS Technical Advisor<br />
Contractor Project Mgr.<br />
Contractor Project Mgr.<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Project Mgr.<br />
Project: <strong>NEDSS</strong>_Implementation_98_20<br />
Date: Sun 9/30/01<br />
Task<br />
Split<br />
Progress<br />
Milestone<br />
Summary<br />
Project Summary<br />
External Tasks<br />
External Milestone<br />
External Milestone<br />
Deadline<br />
PHRG September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Appendix D - Project Plan<br />
ID WBS Task Name Duration Start Finish Resource Initials<br />
Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May<br />
97 1.4.6.2 Conduct structured walkthrough(s) 1 day Thu 7/11/02 Fri 7/12/02 CON_PM<br />
Contractor Project Mgr.<br />
98 1.4.7 Documentation Plan (draft) 4 days Fri 7/12/02 Thu 7/18/02<br />
99 1.4.7.1 Prepare document 3 days Fri 7/12/02 Wed 7/17/02 CON_PM<br />
100 1.4.7.2 Conduct structured walkthrough(s) 1 day Wed 7/17/02 Thu 7/18/02 CON_PM<br />
101 1.4.8 Training Plan (draft) 6 days Thu 7/18/02 Fri 7/26/02<br />
102 1.4.8.1 Prepare document 5 days Thu 7/18/02 Thu 7/25/02 CON_PM<br />
103 1.4.8.2 Conduct structured walkthrough(s) 1 day Thu 7/25/02 Fri 7/26/02 CON_PM<br />
104 1.4.9 Operating Documents (draft) 11 days Fri 7/26/02 Mon 8/12/02<br />
105 1.4.9.1 Prepare documents 10 days Fri 7/26/02 Fri 8/9/02 CON_TR<br />
106 1.4.9.2 Conduct structured walkthrough(s) 1 day Fri 8/9/02 Mon 8/12/02 CON_TR<br />
107 1.4.10 <strong>NEDSS</strong> Base <strong>System</strong> 23 days Tue 2/26/02 Thu 3/28/02<br />
108 1.4.10.1 Install / Configure <strong>NEDSS</strong> Base <strong>System</strong> Hardware 10 days Tue 2/26/02 Mon 3/11/02 CON_TR<br />
109 1.4.10.2 Install <strong>NEDSS</strong> Base <strong>System</strong> 10 days Tue 3/12/02 Mon 3/25/02 CON_TR<br />
110 1.4.10.3 Configure <strong>NEDSS</strong> Base <strong>System</strong> 3 days Tue 3/26/02 Thu 3/28/02 CON_TR<br />
111 1.4.11 Laboratory Data Interface 45 days Tue 4/30/02 Tue 7/2/02<br />
112 1.4.11.1 Create Data Interfaces 30 days Tue 4/30/02 Tue 6/11/02 CON_TR<br />
113 1.4.11.2 Document Interfaces 5 days Tue 6/11/02 Tue 6/18/02 CON_TR<br />
114 1.4.11.3 Verify Data Interfaces 10 days Tue 6/18/02 Tue 7/2/02 CON_TR<br />
115 1.4.12 Revise Project Plan 1 day Mon 8/12/02 Tue 8/13/02 CON_PM<br />
116<br />
117 1.5 TEST PHASE 84.5 days Fri 3/29/02 Thu 7/25/02<br />
118 1.5.1 Create Test Environment 3 days Fri 3/29/02 Tue 4/2/02 CON_QA<br />
119 1.5.2 <strong>NEDSS</strong> Base <strong>System</strong> 31 days Wed 4/3/02 Wed 5/15/02<br />
120 1.5.2.1 Create Test Dataset 5 days Wed 4/3/02 Tue 4/9/02 CON_QA<br />
121 1.5.2.2 Conduct Data Load Test 3 days Wed 4/10/02 Fri 4/12/02 CON_QA<br />
122 1.5.2.3 Conduct User Interface Test 3 days Mon 4/15/02 Wed 4/17/02 CON_QA<br />
123 1.5.2.4 Conduct NETSS Functionality Test 5 days Thu 4/18/02 Wed 4/24/02 CON_QA<br />
124 1.5.2.5 Conduct TIMS Functionality Test 5 days Thu 4/25/02 Wed 5/1/02 CON_QA<br />
125 1.5.2.6 Conduct Web Access Test 2 days Thu 5/2/02 Fri 5/3/02 CON_QA<br />
126 1.5.2.7 Conduct Report Testing 5 days Mon 5/6/02 Fri 5/10/02 CON_QA<br />
127 1.5.2.8 Conduct Security Testing 2 days Mon 5/13/02 Tue 5/14/02 CON_QA<br />
128 1.5.2.9 Track defects 1 day Wed 5/15/02 Wed 5/15/02 CON_QA<br />
129 1.5.3 Laboratory Data Exchange 16 days Tue 7/2/02 Wed 7/24/02<br />
130 1.5.3.1 Create Test Dataset 10 days Tue 7/2/02 Tue 7/16/02 CON_QA<br />
131 1.5.3.2 Conduct Data Exchange Test 5 days Tue 7/16/02 Tue 7/23/02 CON_QA<br />
132 1.5.3.3 Track defects 1 day Tue 7/23/02 Wed 7/24/02 CON_QA<br />
133 1.5.4 Review Test Results with stakeholders 1 day Wed 7/24/02 Thu 7/25/02 CON_QA<br />
134<br />
135 1.6 IMPLEMENTATION PHASE 128.5 days Wed 3/6/02 Mon 9/2/02<br />
136 1.6.1 <strong>NEDSS</strong> Base <strong>System</strong> 88.5 days Wed 3/6/02 Mon 7/8/02<br />
137 1.6.1.1 Install / Configure Base <strong>System</strong> Production Hardware 5 days Wed 3/6/02 Tue 3/12/02 CON_TR,DOT_TA<br />
138 1.6.1.2 Install <strong>NEDSS</strong> Base <strong>System</strong> 10 days Wed 3/13/02 Tue 3/26/02 CON_TR<br />
139 1.6.1.3 Configure <strong>NEDSS</strong> Base <strong>System</strong> 3 days Wed 3/27/02 Fri 3/29/02 CON_TR<br />
140 1.6.1.4 Test <strong>NEDSS</strong> Base <strong>System</strong> 5 days Mon 7/1/02 Mon 7/8/02 CON_QA<br />
141 1.6.2 Application Data Migration (NETSS and TIMS) 16 days Mon 7/8/02 Tue 7/30/02<br />
142 1.6.2.1 Document QA data control points 2 days Mon 7/8/02 Wed 7/10/02 CON_QA<br />
143 1.6.2.2 Extract, Analyze and Clean data 5 days Wed 7/10/02 Wed 7/17/02 CON_TR<br />
144 1.6.2.3 Load Data 2 days Wed 7/17/02 Fri 7/19/02 CON_TR<br />
r 1st Quarter 2nd Quarter 3rd Quarter 4th Quarter 1st Quarter 2nd Quart<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
3/26<br />
Contractor Project Mgr.<br />
Contractor Project Mgr.<br />
Contractor Project Mgr.<br />
Contractor Project Mgr.<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
6/18<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Project Mgr.<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
7/24<br />
Contractor Technical Resource,DOTS Technical Advisor<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Technical Resource<br />
Contractor Technical Resource<br />
Project: <strong>NEDSS</strong>_Implementation_98_20<br />
Date: Sun 9/30/01<br />
Task<br />
Split<br />
Progress<br />
Milestone<br />
Summary<br />
Project Summary<br />
External Tasks<br />
External Milestone<br />
External Milestone<br />
Deadline<br />
PHRG September 28, 2001
<strong>NEDSS</strong> Phase II, Deliverables 1 and 2<br />
Appendix D - Project Plan<br />
ID WBS Task Name Duration Start Finish Resource Initials<br />
Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May<br />
145 1.6.2.4 Test against Specs. and Control points 3 days Fri 7/19/02 Wed 7/24/02 CON_QA<br />
Contractor Quality Assurance<br />
146 1.6.2.5 Test <strong>NEDSS</strong> Base <strong>System</strong> Functionality 3 days Wed 7/24/02 Mon 7/29/02 CON_QA<br />
Contractor Quality Assurance<br />
147 1.6.2.6 Track defects 1 day Mon 7/29/02 Tue 7/30/02 CON_QA<br />
148 1.6.3 Testing 6 days Tue 7/30/02 Wed 8/7/02<br />
149 1.6.3.1 Integration Test Reports 3 days Tue 7/30/02 Fri 8/2/02 CON_QA<br />
150 1.6.3.2 <strong>System</strong> Test Report 3 days Fri 8/2/02 Wed 8/7/02 CON_QA<br />
151 1.6.4 Operating Documents (final) 5 days Wed 8/7/02 Wed 8/14/02 CON_TR<br />
152 1.6.5 Training Plan (final) 3 days Wed 8/14/02 Mon 8/19/02 CON_QA<br />
153 1.6.6 Installation Plan (final) 3 days Mon 8/19/02 Thu 8/22/02 CON_TR<br />
154 1.6.7 Acceptance Test Plan (final) 2 days Thu 8/22/02 Mon 8/26/02 CON_QA<br />
155 1.6.8 Training 23 days Thu 7/25/02 Tue 8/27/02<br />
156 1.6.8.1 Create User Documentation 5 days Thu 7/25/02 Thu 8/1/02 CON_QA<br />
157 1.6.8.2 Create Technical Documentation 5 days Thu 8/1/02 Thu 8/8/02 CON_QA<br />
158 1.6.8.3 Conduct User Training Sessions 10 days Thu 8/8/02 Thu 8/22/02 CON_TR<br />
159 1.6.8.4 Conduct Technical Training 3 days Thu 8/22/02 Tue 8/27/02 CON_TR<br />
160 1.6.9 Acceptance 3 days Tue 8/27/02 Fri 8/30/02<br />
161 1.6.9.1 Acceptance Test Report 3 days Tue 8/27/02 Fri 8/30/02 CON_QA<br />
162 1.6.10 Operational <strong>System</strong> 1 day Fri 8/30/02 Mon 9/2/02 CON_PM,BOH_PM<br />
163<br />
164 1.7 REVIEW PHASE 33 days Mon 9/2/02 Thu 10/17/02<br />
165 1.7.1 Create Review Plan / Stakeholders 1 day Mon 9/2/02 Tue 9/3/02 CON_PM,BOH_PM<br />
166 1.7.2 Schedule Stakeholder Meetings 1 day Tue 9/3/02 Wed 9/4/02 BOH_PM<br />
167 1.7.3 Track Operational <strong>System</strong> 30 days Wed 9/4/02 Wed 10/16/02 CON_QA<br />
168 1.7.4 Review Project Strengths / Weaknesses w/ Stakeholders 1 day Wed 10/16/02 Thu 10/17/02 CON_PM,BOH_PM<br />
r 1st Quarter 2nd Quarter 3rd Quarter 4th Quarter 1st Quarter 2nd Quart<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Technical Resource<br />
Contractor Quality Assurance<br />
Contractor Technical Resource<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
Contractor Quality Assurance<br />
8/8<br />
Contractor Technical Resource<br />
Contractor Quality Assurance<br />
8/30<br />
Contractor Project Mgr.,BOH Proje<br />
BOH Project Mgr.<br />
Contractor Quality Assurance<br />
10/16<br />
Project: <strong>NEDSS</strong>_Implementation_98_20<br />
Date: Sun 9/30/01<br />
Task<br />
Split<br />
Progress<br />
Milestone<br />
Summary<br />
Project Summary<br />
External Tasks<br />
External Milestone<br />
External Milestone<br />
Deadline<br />
PHRG September 28, 2001
Phase II, Task #3 Deliverable:<br />
<strong>NEDSS</strong> e-Business Plan
<strong>NEDSS</strong> Phase II, Deliverable 3<br />
<strong>National</strong> <strong>Electronic</strong> <strong>Disease</strong> <strong>Surveillance</strong> <strong>System</strong><br />
(<strong>NEDSS</strong>) Plan – Phase II, Task #3 Deliverable<br />
TABLE OF CONTENTS<br />
e-Business Plan<br />
I. Executive Summary ..........................................................................1<br />
II. Business Requirements.....................................................................1<br />
III. Costs and Benefits .............................................................................2<br />
IV. Constraints and Risks .......................................................................3<br />
V. Interdependencies .............................................................................4<br />
VI. Organizational Structure..................................................................4<br />
VII. Leadership and Governance ............................................................4<br />
VIII. Impact on Constituents....................................................................5<br />
IX. Creative and Cognitive Design.........................................................5<br />
X. High Level Architecture ...................................................................5<br />
PHRG September 28, 2001
PHASE II Task 3 Deliverable<br />
<strong>National</strong> <strong>Electronic</strong> Data <strong>Surveillance</strong> <strong>System</strong> (<strong>NEDSS</strong>) Plan<br />
Phase II Task 3<br />
e-Business Plan<br />
I. Executive Summary<br />
E-business query and report generation functions are being developed as part of the <strong>National</strong><br />
<strong>Electronic</strong> Data <strong>Surveillance</strong> <strong>System</strong> (<strong>NEDSS</strong>). Using an on-line web browser, clinical<br />
laboratories and providers will transmit laboratory results, integrated through <strong>NEDSS</strong>, to the<br />
State of Maine Bureau of Health, who then transmits these data to the Centers for <strong>Disease</strong><br />
Control and Prevention (CDC). Out of state reference labs processing Maine specimens will<br />
transmit results directly to CDC which in turn will transmit results to Maine. These new e-<br />
business functions will then allow public health agencies, health services agencies, and providers<br />
across the state to directly access the <strong>NEDSS</strong> data through the web browser to perform specific<br />
queries of the data and to create ad hoc reports specifically requested by the user. Selective,<br />
confidential, querying and messaging functions will be available for authorized users to extend<br />
the use of <strong>NEDSS</strong> data, linked to demographic and disease data, to provide integrated reports of<br />
patient demographics, laboratory results, and disease history and outcomes. Authorized users<br />
will have access to their own provider-specific data as warranted, as well as to statewide<br />
aggregated data that has not existed previously. These e-business query and reporting functions<br />
will allow public health agencies to more closely monitor, report, and manage disease-specific<br />
prevalence and incidence rates, plus prevention and treatment programs. These e-business<br />
functions can provide improved quality assurance through early detection, improved agencyfield<br />
communication; best practices analyses, and cost-effectiveness analyses of clinical<br />
providers, clinical treatment modalities, and patient and community outcomes.<br />
II. Business Requirements<br />
The <strong>National</strong> <strong>Electronic</strong> Data <strong>Surveillance</strong> <strong>System</strong> (<strong>NEDSS</strong>) is a cooperative partnership<br />
between the Centers for <strong>Disease</strong> Control and Prevention (CDC) and many public health entities<br />
to integrate previously disparate data collection and reporting systems into a secure, integrated<br />
environment. The system was developed to improve the efficiency, effectiveness, and timeliness<br />
of public health-related surveillance, monitoring, analysis, identification, and management<br />
concerning various diseases detected through a variety of clinical laboratory procedures, as well<br />
as to serve as a basis for public health policy at multiple levels of government. The system is<br />
intended to involve the CDC, state and local public health departments, health care provider and<br />
service organizations, health care product vendors, and health care standards organizations.<br />
Data are currently provided to the Maine Bureau of Health (BOH) by hospital laboratories, the<br />
state Public Health Laboratory, and reference laboratories throughout the State of Maine.<br />
Current data processes include the collection, verification, storage repository, and reporting<br />
functions as the data are transmitted to the CDC in Atlanta. The required system elements<br />
involving data collection and security are discussed previously in the <strong>National</strong> <strong>Electronic</strong> Data<br />
<strong>Surveillance</strong> <strong>System</strong> (<strong>NEDSS</strong>) Overview (PHRG, May 18, 2001). The Maine Bureau of Health<br />
will maintain the integrated data repository, which will communicate through specific software<br />
with the clinical database, the CDC, the state and other public health agencies, clinical sites<br />
(providing electronic laboratory messages), Geographic Information <strong>System</strong> (GIS) and other<br />
demographic and clinical disease data mapping and statistical reports, and the Health Personnel<br />
PHRG 1 of 5<br />
September 28, 2001
PHASE II Task 3 Deliverable<br />
Directory. The BOH will design business rules to ensure data confidentiality to permit<br />
selectively authorized, read-only access to data housed in selected program area modules<br />
(PAMs) based on specific user’s roles and responsibilities. The data will be accessible to<br />
specific commercial software (e.g., standards-based statistical packages, GIS packages) to<br />
support related data analysis and visualization activities, and to support the electronic exchange<br />
of laboratory, clinical, and epidemiological data between the state, and other providers and<br />
laboratories (dependent on licensing agreements).<br />
The currently proposed e-business plan addresses the important and previously unavailable<br />
attribute of these disparate data systems that will allow web browser-based development of<br />
clinical and public health management reports for improving case management. Selective,<br />
confidential, data reporting, querying and messaging functions will be available for authorized<br />
users to extend the use of <strong>NEDSS</strong> data, linked to demographic and disease data, to provide<br />
integrated reports of patient demographics, laboratory results, and disease history. E-business<br />
would involve periodic reports and case reports available from BOH, or through the query<br />
feature for user-generated, ad hoc clinical and management reports. Reports will be available for<br />
local stakeholders, with aggregate reports for data comparisons, and individual case reports<br />
available for specific data laboratory providers (to safeguard issues of patient confidentiality) as<br />
well as state and local public health agencies. Out-of-state laboratories would need to access<br />
specific data through the CDC.<br />
The capability to query and generate these resultant reports offers value-added identification,<br />
communication and program response to directly address public health issues of changes in<br />
disease incidence, severity, treatment, and prevention. Local public health agencies and<br />
laboratories can be alerted electronically about specific disease states, rates, and data monitoring<br />
and reporting requirements to improve detection and treatment management. In addition to these<br />
clinical processes and outcomes, the query and reporting functions allow government and<br />
clinical laboratories to access aggregated state-wide data that was unavailable previously or<br />
available only in hard copy reports by county. These data may be used to enhance financial<br />
projections of provider business costs and/or public health program costs, to compare and<br />
contrast competitive patterns and projections, and to improve quality assurance through<br />
management control and management decision-making that affects patients, communities, public<br />
health agencies, and commercial providers alike.<br />
III. Costs and Benefits<br />
E-business costs are anticipated to be negligible. The initial development of <strong>NEDSS</strong> has already<br />
contemplated the system architecture, design, linkages, and maintenance requirements for the<br />
query and reporting functions. The various user communities will need computer equipment and<br />
maintenance for access to the web browser, but most if not all components should already exist<br />
to meet the previously mandated data entry requirements for reporting the relevant laboratory<br />
tests to the BOH data repository. The user communities may need some minor computer<br />
software training to effectively utilize the software capabilities to query and produce reports, but<br />
these costs should be very low. And, it is anticipated that instructions on how to access NEDDS<br />
will be available on-line.<br />
Conversely, the benefits of NEDDS from an e-business perspective are significant. In addition to<br />
PHRG 2 of 5<br />
September 28, 2001
PHASE II Task 3 Deliverable<br />
on-line data entry, query and reporting capabilities of their own data, already noted elsewhere,<br />
agencies and providers alike will have newly developed electronic access to broad-based,<br />
statewide data, with which they are able to selectively query to ascertain statewide or specific<br />
provider trends, patterns, and outcomes. Authorized users will have access to their own<br />
provider-specific data as warranted, as well as to statewide aggregated data that has not existed<br />
previously. In a manner similar to the current IMMPACT program that tracks immunizations<br />
statewide, these query and reporting functions through <strong>NEDSS</strong> can significantly improve pubic<br />
health functions in the state by reducing time, quality, and communication delays in developing<br />
and sharing critical public health community alerts and directives. These e-business functions<br />
will allow public health agencies to more closely monitor, report, and manage disease-specific<br />
prevalence and incidence rates, plus prevention and treatment programs. These e-business<br />
functions can improve quality assurance through early detection of trends, improved agency-field<br />
communication, best practices analyses, and cost-effectiveness analyses of clinical providers,<br />
clinical treatment modalities, and patient and community outcomes.<br />
Additionally, the reporting and querying functions of NEDDS will permit physicians,<br />
researchers, students and the public health community access to reports that are not now<br />
accessible or that require staff time to complete with special runs of the data. This has significant<br />
benefit both to the BOH as well as the public sector. Since the <strong>NEDSS</strong> base system integrated<br />
data repository will be structured to permit incorporation of many different additional BOH<br />
databases, the e-business benefits of <strong>NEDSS</strong> will be enhanced multi-fold. For example, the<br />
contemplated addition of online collection and reporting of vital statistics data should reduce<br />
data collection costs and increase access to data that are routinely used by public health agencies,<br />
planners, policy makers, researchers and students. Providing access to these data through<br />
NEDDS will highlight the role of BOH and market its importance in the state. Should the BOH<br />
require modest fees for these reports, a method of generating revenues to help support the system<br />
is realized.<br />
IV. Constraints and Risks<br />
The e-business functions pose few constraints and risks. Access to the e-business query and<br />
reporting functions will follow the previously developed programs, policies, procedures, and<br />
restrictions of the Maine Bureau of Health in addressing technology, security, data access, and<br />
maintenance issues for <strong>NEDSS</strong>. The largest concern would encompass issues of data<br />
confidentiality and security, principally to effectively ensure that only authorized users are to<br />
access <strong>NEDSS</strong> data, and further to also ensure that authorized users access, report, and transmit<br />
the data responsibly, with no disclosure or other inappropriate use of patient or provider data.<br />
While the system is purposely “user-friendly,” providers are restricted to accessing either the<br />
data they provided on their own patients, or data that are aggregated and cleaned of all patient- or<br />
provider-designations. Policies will need to be developed to delineate approved and unapproved<br />
access, transmittal, and use of the information developed through the query and reporting<br />
functions of <strong>NEDSS</strong>.<br />
A second possible constraint with using these e-business functions involves developing accurate<br />
projections for short-term and long-term use of the query and reporting functions through<br />
<strong>NEDSS</strong>. As these e-business functions become more widely publicized, there could be an<br />
increase in the number of users employing these functions, especially with the planned expansion<br />
PHRG 3 of 5<br />
September 28, 2001
PHASE II Task 3 Deliverable<br />
of the system to include other BOH databases. If the increase is sufficiently large, it could<br />
necessitate changes in system architecture to accommodate the increased user demand. While<br />
system architectural changes and programming could be costly, the alternative of decreased user<br />
service through increased processing time, an insufficient number of data ports to support user<br />
access, and/or diminished public health responses resulting from the inefficient and ineffective<br />
utilization of the query and reporting functions are significantly more unacceptable and must be<br />
avoided.<br />
V. Interdependencies<br />
Through the Maine Bureau of Health, <strong>NEDSS</strong> data will be linked to other databases and to a<br />
network of providers and public health agencies. Thus, BOH works with the various provider<br />
and public health organizations in developing procedures and policies for data collection<br />
security, and access. These provider and public health entities rely on this web-based access<br />
(read only format) for accurate and timely data that can be incorporated, through the e-business<br />
functions, into reports and other information (e.g., Health Advisory Notices) for dissemination to<br />
these various entities to protect the public health and to effectively manage public health<br />
programs and provider practices. As such, each government, provider, and public health entity<br />
shares responsibility for data accuracy, the appropriate and ethical use of the data, and the<br />
responsible public health, clinical, and managerial application of the resulting data-derived<br />
information.<br />
VI. Organizational Structure<br />
The e-business query and reporting functions are incorporated under <strong>NEDSS</strong>, and therefore<br />
housed under the Maine Bureau of Health organizational design. Management authority and<br />
responsibility for the technical components and data elements will lie with the Division of<br />
<strong>Disease</strong> Control (DDC). The DHS Department of Technical Services (DOTS), a key stakeholder,<br />
will play an advisory role in the development of the system so that it can communicate as<br />
appropriate with current and planned systems and technology.<br />
VII. Leadership and Governance<br />
As noted above, structural and programmatic responsibility for <strong>NEDSS</strong> resides with the Division<br />
of <strong>Disease</strong> Control, Maine Bureau of Health. This arrangement provides for the data<br />
development and access to the data by the community of users, but it does not address the issues<br />
surrounding the e-business query and reporting functions for the user community.<br />
In addition to the monitoring of system usage provided by DDC and BOH, the e-business<br />
functions require an additional layer of leadership and governance to address management and<br />
public health issues. To ensure effective, responsible, and equitable use of the data and their<br />
resultant reports developed by the user community, the Maine BOH should establish an <strong>NEDSS</strong><br />
Advisory Council, comprised of representatives from the various stakeholder and user<br />
community constituents. Members could include representatives from the Bureau of Health,<br />
laboratory providers, clinical providers, hospitals, legislators, public citizens, and other<br />
stakeholders. Terms could be staggered, with a chairperson designated from the members,<br />
possibly rotating to different member constituents. The Advisory Council could be responsible<br />
for providing general direction and representation issues, developing data access and<br />
dissemination policies, reviewing requests for collecting additional data, benchmarking and<br />
PHRG 4 of 5<br />
September 28, 2001
PHASE II Task 3 Deliverable<br />
implementing software updates, and providing a forum to address internal issues regarding data<br />
and reports.<br />
VIII. Impact on Constituents<br />
The e-business querying and reporting functions should have a highly positive impact on most<br />
<strong>NEDSS</strong> constituents. Through improved early detection and management, public health<br />
programs for the State of Maine could be more effective and efficient in protecting and treating<br />
the citizens of Maine. Furthermore, in conjunction with the web browser improvements for data<br />
reporting, the e-business functions can lead to improved management and treatment programs for<br />
both providers and public health agencies.<br />
The one constituent group that may experience a modest negative impact could be the Maine<br />
Bureau of Health, who is responsible for data security, collection, verification, storage, and all<br />
system maintenance, including the necessary data query and report generator software. These<br />
are sensitive data, and access and reporting functions will require strict monitoring procedures<br />
from BOH. Nevertheless, it is anticipated that there would be, at most, only a modest increase in<br />
BOH workload stemming from these e-business functions. This could be more than offset by the<br />
human resource savings should other BOH datasets be incorporated into <strong>NEDSS</strong> for the<br />
collection, cleaning, storage and/or reporting of data.<br />
IX. Creative and Cognitive Design<br />
It is expected that there would be no creative or cognitive design issues regarding the e-business<br />
functions. The necessary <strong>NEDSS</strong> architecture will have already been created, and the various<br />
constituents will create the subsequent reports generated through the e-business functions online.<br />
The one caveat involves any projected increases in the numbers of users and the volume of<br />
queries and reports generated, especially with the addition of other public health datasets.<br />
Should the volume exceed the current system capacity, new system architecture (and<br />
programming) may need to be configured to meet the demand for the e-business functions.<br />
X. High Level Architecture<br />
As noted above, existing system architecture planned for the base system should be sufficient to<br />
handle short-term projected e-business query and report generating demand. The system<br />
supports web browser-based data entry and retrieval, as well as the additional query and report<br />
generating functions, although subsequent user activity could require higher level architecture to<br />
improve data access, processing speed, and information dissemination.<br />
PHRG 5 of 5<br />
September 28, 2001