Appendix 4. Developing an Interactive Response Tool: The HELP Model (continued)

2.0 Interactive Response Tool Planning Document

The Health Emergency Line for the Public (HELP) pilot program in Colorado, established by the Rocky Mountain Regional poison center to provide information during bioterrorism and other public health emergencies, provides a model for disseminating and collecting information in health emergencies in partnership with a State health department. While developing better strategies and means for managing call volume surges without sacrificing customer care, we identified the following capabilities:

• Respond to large influx of call volume during public health events.
• Assist quarantined persons during health emergency events.
• Assist health departments in distributing drugs in emergency events by providing the locations of dispensing centers.
• Have a fixed footprint within our call center preventing the need to expand our physical space in responding to increased call volumes.
• Increase our ability to respond rapidly to customer needs.
• Fit into our operating budget without excessive increases in technology costs prior to and during an emergency or disaster.
• Our key objective was to develop a model that community health call centers could implement to support outpatient health care and monitoring in a major public health event.

Return to Appendix 4 Contents

2.1 System Business Value

Though the applications are intended for use during a disaster, we anticipate there will be ways to use the applications on a day-to-day basis. Any of the anticipated applications (drug identification, quarantine and isolation monitoring, etc.) could be adapted for non-emergency use. Because our center primarily provides services via the telephone, we are always looking for ways to be more efficient. Any way for us to more effectively and judiciously use personnel time, matching the right resource to the right need, is of benefit to our call center. Development of IR applications has the potential for freeing staff from information relating duties that could be automated (such as recordings of locations by entering zip codes) and allowing them to focus on tasks better suited to their training and expertise (such as assisting with clinical decision support of callers with health concerns).

Return to Appendix 4 Contents

2.2 Goals

Our goal was to develop, implement, and test a model to enable call centers (such as poison control centers, nurse advice lines, and other hotlines) to support home management/shelter-in-place approaches in certain mass casualty or health emergency events. We developed strategies, protocols, and algorithms to respond to specific scenarios. We believe that the resulting applications can help us meet the goals of our mission without negatively affecting our customers. In order to both align with the organizational goals and achieve the desired business values, the solution must:

• Address the pertinent issues related to a public health event.
• Handle surges of call volumes without increasing our current physical facilities.
• Assist with delivering services without minimal increases in staffing (especially during a health pandemic event).
• Not adversely affect our customer service.

Return to Appendix 4 Contents

2.3 Roles and Responsibilities

A steering committee must be selected that represents the organization's decision-makers and key stakeholders. This committee ultimately makes the selection decisions and provides oversight for integration of the new technology into the organization. In order to make sure that the needs across our center were being met and that project merged with our existing technology, we chose the following responsibility areas to serve on the steering committee:

Contracts, Finance, Call Center Administrative Director, Research Director, Poison Center Program Manager, HELP Supervisor, Business Technology Manager, Information Systems (IS) Manager, Telecommunications Engineer, and Project Manager.

From this group a project team (below) was selected to manage all aspects of the project through the planning, analysis, design, implementation, and evaluation phases. Additionally, the project team had the following overall responsibilities:

• Understanding the technology being researched and any associated restrictions.
• Understanding the impact of any decisions on other technology within the organization.
• Making decisions for the overall good of the application of the technology.
• Becoming the key resource for the application of the technology once implemented.

Further specific responsibilities for each project team member are:

Research Director

• Principal Investigator—Has overall responsibility for seeing project through completion.

Poison Center Program Manager

• Key stakeholder—Assures project can integrate with established operations and meets business needs.

Business Technology Manager

• Key stakeholder—Coordinates telecommunication/information systems services support and provides input regarding telephone programming, call management, and reporting.

Project Manager

• Assists Principal Investigator with managing all aspects of project, including coordination of pilot tests, documentation, and interface with technical staff.

Telecommunications Engineer

• Coordinates information technology components of project, including vendor evaluation/selection process, ensuring the system conformation to our technology standards, testing and maintaining call routing, voice equipment, and related services.

Information Systems (IS) Manager

• Primary contact for database and reporting support, ensures the system conforms to IS standards, coordinates IS support services.

Outside Technology Vendor

• Understands the needs of the organization, its current infrastructure and resources, and provides a cost-effective technology solution with capability for modifications and refinements.

Return to Appendix 4 Contents

2.4 Objectives

1. Implement IR solution applications within the budget and time table established.
2. Identify and evaluate four important public health event scenarios that will serve as examples for utilization of IR technology applications.
3. Identify the application requirements for each chosen scenario.
4. Identify all processes and procedures necessary to incorporate into applications.
5. Create call flow designs for the applications.
6. Develop the beta versions of the applications.
7. Create an implementation plan and testing strategies for the applications.
8. Pilot test applications in up to two exercises.
9. Review and evaluate testing results and modify applications accordingly.
10. Complete all documentation of application development and testing.
11. Provide health agencies with a tool that describes the process for developing and implementing an IR solution for managing needs of the public during health events, and provide guidance of how to utilize such a tool depending upon their available resources.

Return to Appendix 4 Contents

2.5 Feasibility Analysis

A feasibility analysis guides the selection of the technology/system by determining the opportunities and limitations of the proposed technology, whether its applications will address the identified problems, and if the organization should proceed. The feasibility analysis also identifies the objectives of the system, its costs, benefits and value, and the scope of the project. We used a categorical scale (poor, fair, good, excellent) to judge our Information Technology departments' familiarity with each of these feasibility components, as well as how well the system will ultimately be accepted by its users and incorporated into the ongoing operations of the organization with limited disruption.

Return to Appendix 4 Contents

2.6 Resources and Timeline

Human

• Total project hours include exploring the problem, developing the applications, testing and refining the applications and then developing the tool for others to understand the process. Just application development or adaptation of the developed applications would take significantly less time.

Hardware

• Costs of hardware (for example, an IR system), if any.

Application Development and Administration

• Internal Information Technology (IT) Group—Administer new IR applications.
• External IR Consultant—Develop IR applications and train IT group in their operations.

Timeline for New Applications

The timeframes listed do not necessarily occur in series; many can be done concurrently while other milestones are in progress. There also may be delays between milestones due to other demands on the responsible person(s) and the resources they require to support them. The approximate times required for each of the five project phases are:

• Planning—4 weeks
• Analysis—2 weeks
• Design—4 weeks
• Implementation—34 weeks
• Evaluation (Modification)—16 weeks

Note: In actuality, the evaluation phase including modifications begins during the implementation phase, continues through testing and is ongoing through operations based upon user experiences and feedback.

Return to Report Contents
Proceed to Next Section