Chapter Two: Description of the Existing System

---

Chapter Two

Description of the Existing System

2.1 Introduction of the Existing System

The current healthcare system in Ethiopia faces numerous challenges due to its reliance on
traditional, manual methods for disseminating health-related information. Most health
centers and organizations do not utilize digital platforms to provide accessible, centralized,
and real-time information to the public. As a result, patients often struggle to find accurate
information about diseases, hospitals, first aid procedures, and emergency contact details,
leading to delays in receiving proper medical care.

The existing system operates without a standardized platform to integrate all health-related
services. Information is typically passed through word of mouth, printed materials, or
occasional public health announcements. These methods are prone to inaccuracies, delays,
and inefficiencies, especially in emergencies.

2.2 Players in the Existing System

The current system involves several key players:

Healthcare Professionals:

Provide information on diseases, treatments, and hospital services manually.

Respond to patient inquiries through face-to-face interactions, phone calls, or paper-based
reports.

Patients:

Seek medical information and services through direct visits to health centers or through
informal networks.

Face significant challenges in locating specialized health centers or obtaining timely

emergency assistance.

2.3 Major Functions/Activities in the Existing System

The main activities in the current system are:

Inputs:

Patients and community members manually gather information by visiting health centers or
contacting healthcare professionals.

Data related to diseases, first aid, and hospital services are recorded in paper-based
formats.
Processes:

Healthcare professionals manually process and relay information, often with significant
delays.

Public health campaigns attempt to raise awareness but are infrequent and limited in reach.

Outputs:

Patients receive fragmented health-related information, often missing critical details about
hospital locations, disease symptoms, or emergency contacts.

2.4 Bottlenecks of the Existing System

Using the PIECES framework, the bottlenecks of the current system include:

Performance:

Slow response times in providing health information, especially in emergencies.

Lack of real-time updates for hospital services and availability.

Input:

Data collection is often redundant and prone to errors, leading to inconsistencies.

Control:

There is no centralized system to ensure the accuracy and quality of information provided
to the public.

Efficiency:

Resources are wasted on manual processes, and the lack of digital tools increases
inefficiency.

Security:

Sensitive patient and hospital information are stored in unsecured formats, making it
vulnerable to loss or misuse.
2.5 Practices to Be Preserved

While the current system has significant challenges, some practices should be retained in
the new system:

Personal Interaction:

The personal touch of healthcare professionals in addressing patient needs and concerns
should be maintained.

Community-Based Awareness Campaigns:

Existing public health campaigns have successfully raised awareness about specific issues
and should be integrated into the new platform.

2.6 Proposed Solution for the New System

The proposed “Web-Based Ethiopian Health Guidance and Location Service” aims to
address the limitations of the existing system by:

1. Centralizing Information:

Consolidating hospital locations, disease information, and first aid tips into a single, easily
accessible platform.
2. Improving Accessibility:

Providing a user-friendly interface that is accessible through web browsers on computers

and mobile devices.

3. Enhancing Efficiency:

Automating data input, processing, and retrieval to reduce delays and inaccuracies.

4. Ensuring Security:

Implementing robust data protection measures to safeguard sensitive health-related

information.

5. Real-Time Updates:

Allowing administrators to update hospital and health information as changes occur.

2.7 Requirements of the Proposed System

2.7.1 Functional Requirements

The functional requirements define the core features of the new system, including:

1. View Disease Information:

Users can access comprehensive information about diseases, including symptoms, causes,
and preventive measures.

2. Hospital Information and Locations:

Users can search for hospitals based on region, specialization, or name and view their exact
locations on an interactive map.

3. First Aid Guidance:

The system provides step-by-step instructions for handling common emergencies.

4. Emergency Contact Directory:

Displays emergency contacts for hospitals and other health services.

5. Administrative Features:

Administrators can add, update, or delete hospital information, disease data, and first aid
guidelines.

2.7.2 Non-Functional Requirements

The non-functional requirements focus on the system’s quality attributes, including:

1. Performance:

The system must handle multiple user queries simultaneously without significant delays.
2. User Interface:

The interface must be intuitive and compatible with various web browsers and devices.

3. Security and Access Permissions:

Only authorized administrators can modify sensitive data, while users access public
information securely.

4. Backup and Recovery:

The system must include mechanisms to prevent data loss and recover information during
failures.
Chapter Three: System Analysis

Chapter Three

System Analysis

3.1 Introduction

System analysis is a critical phase in the development process, focusing on understanding

the existing problems and designing effective solutions. This chapter provides a
comprehensive analysis of the system requirements, including the functional and non-
functional aspects, to ensure the proposed "Web-Based Ethiopian Health Guidance and
Location Service" meets its objectives.

3.2 System Requirement Specifications (SRS)

System Requirement Specifications outline the detailed requirements of the system. They
are divided into functional and non-functional specifications to ensure clarity and
completeness.

3.2.1 Use Case Diagrams

Use case diagrams visually represent the interactions between users (actors) and the
system. The primary actors include:

Users: Access health-related information, hospital locations, and first aid guides.

Administrators: Manage data by adding, updating, or deleting information.

![Placeholder for Use Case Diagram]

3.2.2 Use Case Documentation

Each use case describes specific functionalities of the system, detailing the interactions
between actors and system components.

3.2.3 Sequence Diagram

Sequence diagrams illustrate the flow of interactions within the system for specific use
cases.

1. Viewing Disease Information:

User selects a disease from a list.

System fetches and displays relevant details.

2. Admin Login and Data Update:

Admin logs in with valid credentials.

System verifies credentials and grants access.

Admin updates data, and the system saves changes.

![Placeholder for Sequence Diagram]

3.2.4 Activity Diagrams

Activity diagrams model the workflow for key processes within the system.

1. User Accessing Hospital Info:

User selects a region.

System retrieves and displays hospital details.

User selects a hospital to view its location on a map.

2. Admin Managing Data:

Admin logs in.

System displays options for adding, updating, or deleting data.

Admin performs the action, and the system processes the request.

![Placeholder for Activity Diagram]

3.2.5 Analysis-Level Class Diagram

The class diagram defines the structural design of the system, showing classes, their
attributes, methods, and relationships.

3.2.6 User Interface Prototyping

Prototyping visualizes the system's interface to ensure usability and accessibility.

1. User Home Page: Provides options to search for diseases, hospitals, or first aid tips.

2. Admin Dashboard: Includes functionalities to manage system data.

3. Interactive Map: Displays hospital locations with navigation assistance.

3.2.7 Supplementary Specifications

Scalability: The system must accommodate increased user traffic and data volume.

Reliability: Ensure 99% uptime with robust error-handling mechanisms.

Legal Compliance: Adhere to Ethiopian data privacy and security regulations.

---