JIMMA UNIVERSITY
Jimma Institute of Technology
Faculty of Computing and Informatics
Department of Software Engineering
CBTP-PHASE II: - APPROPRIATE TECHNOLOGY
AND ACTION PLAN DEVELOPMENT
Title: - IMMUNIZATION MONITORING
SYSTEM
For: - CBTB Coordinator
Advisors Sign
Mr. SAMUEL D. _____________
Submission date: -July 5, 2023 G.C
1
Group members
By ;
NAME ID
1. NABON GIRMA RU 0127/14
2. NAOL LEGESSE RU 4750/14
3. SIKAR YOSEF RU 0161/14
4. NATNAEL ZEWDU RU 4687/14
5. SARON WONDWOSSEN RU 0156/14
i
Contents
ACKNOWLEDGMENT ....................................................................................... iii
1. PROJECT OVERVIEW ........................................................................1
Introduction ..................................................................................................................... 1
2. STATEMENT OF PROBLEMS ...........................................................1
3. OBJECTIVE ..........................................................................................3
3.1. General Objective ................................................................................................. 3
3.2. Specific Objective ................................................................................................ 3
3.3. Scope and Limitation ........................................................................................... 3
3.3.1. Scope of the Project ...................................................................................... 3
3.3.2. Limitations .................................................................................................... 3
3.4. Significance of the project.................................................................................... 4
3.5. Methodology ........................................................................................................ 5
3.6. Tools Used............................................................................................................ 5
4. OVER VIEW OF EXISTING SYSTEM ..............................................7
5. PROPOSED SOLUTION......................................................................7
5.1. Participating Actors .............................................................................................. 8
5.2. Functional Requirements...................................................................................... 8
5.3. Nonfunctional requirement .................................................................................. 9
5.4. Proposed Architecture ........................................................................................ 12
5.5. Entity relationship diagram ................................................................................ 12
5.6. Normalization ..................................................................................................... 16
6. ACTION PLAN...................................................................................17
7. FUTURE PHASE ................................................................................19
ii
Table of figures
Fig. 1 system architecture diagram ................................................................................... 12
fig 2 ER diagram ............................................................................................................... 14
fig 3 System database schema.......................................................................................... 15
Tables
Table 1 Action plan ............................................................................................... 18
ACKNOWLEDGMENT
First, we would like to thank JIT Campus especially the Community Based Training
Program (CBTP) coordinators and Faculty of Computing and Informatics for preparing a
chance for us to do this CBTP project which allows us to address the community problem
and solve the problem by applying the knowledge we have in a practical way.
Next, our special thanks go to our project advisor Mr. Samuel D. for his valuable support,
great deal of advice, encouragement and offering us his support on our project. And we
iii
would like to thank all the group members who participated is this challenging project and
put all their effort to do the best of us.
The last but not the least we would like to thank our honorable teachers who give as their
time to support us.
iv
1. PROJECT OVERVIEW
Introduction
Immunization refers to the process of protecting individuals from infectious decease by
stimulating their immune system to produce an immune response. Immunization
system aims to achieve widespread vaccination coverage to protect this individuals and
communities from vaccine preventable diseases.
As we are aware, a significant number of healthcare centers maintain their data records
manually. One of those records is immunization record for pregnant woman and infants.
During this immunization of pregnant woman and infants, a piece of card is used to
record given vaccines and appointment days for future vaccinations that they must take.
This is the same problem we have observed in Jimma Health Center located at Bore
kebele in the first phase of CBTP.
As we know the health sector should give better service for the society mainly for
pregnant mothers and infant because they need special care and treatment. So, we focus
on how we can give better way of data recording for immunization record. Regarding
with this we selected a web-based smartcard system for immunization to both mothers
and infants which can work offline and online. In this phase we will present the design
solution we have proposed for the problems we have found.
2. STATEMENT OF PROBLEMS
In the current system when a pregnant mother comes to follow up pregnancy check they
are given an immunization card to follow up vaccination while they are pregnant and
after giving birth. The pre-birth vaccination is given for the mother and the post birth
vaccination is given for the infants until the infant get to age of 1 year. This
immunization cards are filled manually. These manual card issues many problems due
to different reasons.
Accessibility Problem: -When the mother loses her card and as well as when
changing health center from one to another access for previous data becomes very
difficult.
1
Data Loss: -these manual records could get lost for some reason. For example, because
of natural disaster like earthquake and lightening, and as well as man-made disasters
like fire.
Time consuming: - Data record is manually and it is very time consuming when
wanting to find a specific data. So, giving service in short amount of time will be
difficult.
Wastage of resources: -papers were wasted because of everything were written
manually.
The proposed plan aims to enhance accessibility, prevent data loss, reduce time
consumption, and minimize resource wastage by developing a centralized digital
system for managing immunization records.
2
3. OBJECTIVE
3.1. General Objective
The main objective is to design a web, smart card and database for immunization data
record and management.
3.2. Specific Objective
These are the specific objective identified in order to implement the general objective
• Gathering data from health centers.
• Understanding the existing system.
• Identifying the functional and non-functional requirement of the system.
• Identifying Methodology to be used.
• Identifying the action plan.
3.3. Scope and Limitation
3.3.1. Scope of the Project
The scope of the project includes the development and implementation of a digital
system for managing immunization records for pregnant mothers and infants. The
system aims to provide a more efficient and reliable method of tracking and updating
vaccination data. It includes features such as registration, smart card functionality,
database integration, user authentication, and administration. The project encompasses
the development of both the smart card hardware and the web application.
3.3.2. Limitations
• Hardware Dependency: The system relies on the use of smart cards and smart
card readers. The availability and compatibility of these hardware components
may impose limitations on the system's usage and implementation.
• Internet Connectivity: The web application component requires a stable
internet connection to interact with the central database and provide real-time
3
data updates. The system's functionality may be limited or disrupted in the
absence of a reliable internet connection.
• User Adoption: The successful implementation of the system depends on user
adoption and acceptance. Adequate training and support may be required to
ensure that users, such as registrars, health professionals, and administrators,
are comfortable and proficient in using the system.
• Data Security: While efforts will be made to ensure data security, including
encryption and access controls, the system may still be susceptible to potential
security risks or unauthorized access. Adequate security measures should be
implemented to mitigate these risks.
3.4. Significance of the project
• Improved Accessibility: By transitioning from manual immunization cards to
a digital system, accessibility to immunization records is greatly enhanced.
Mothers and healthcare professionals can easily access and retrieve the
necessary information from anywhere, regardless of geographical location or
health center changes.
• Enhanced Data Security: The digital system ensures robust data security
measures, such as encryption and backups, to protect immunization records
from loss or unauthorized access. This helps in maintaining the confidentiality
and integrity of sensitive healthcare data.
• Efficient Data Management: The digital system enables efficient and
streamlined data management. Health professionals can easily record and
update immunization data in real-time, reducing the risk of errors and ensuring
accurate and up-to-date records. Searching and retrieving specific information
becomes faster and more convenient, saving valuable time for healthcare
providers.
• Disaster Resilience: The digital system mitigates the risk of data loss due to
natural disasters (e.g., earthquakes, fires) or human-made disasters. Electronic
4
backups and remote data storage ensure that immunization records remain safe
and can be easily recovered even in adverse circumstances.
• Resource Optimization: The project aims to reduce resource wastage
associated with manual record-keeping, such as paper consumption. By
transitioning to a digital system, resources can be utilized more efficiently,
contributing to cost savings and environmental sustainability.
• Enhanced Healthcare Planning: The availability of accurate and
comprehensive immunization records allows for better healthcare planning and
decision-making. Health authorities can analyze the data to identify vaccination
trends, monitor immunization coverage rates, and plan targeted interventions to
improve public health outcomes.
• Improved Healthcare Delivery: The digitization of immunization records
enables healthcare professionals to provide more efficient and timely services.
With quick access to complete and reliable information, healthcare providers
can make informed decisions, track vaccination schedules, and ensure timely
administration of vaccines, thereby improving overall healthcare delivery.
3.5. Methodology
Our requirement gathering is mainly focused on observation and asking health
professionals. And we have used object-oriented approach to model the system, because
this approach helps us to know every component needed and simplifies the
implementation process. The object-oriented approach offers advantages such as
modularity, reusability, abstraction, encapsulation, inheritance, polymorphism, code
maintainability, extensibility, collaboration, and real-world modeling. These benefits
make it a widely adopted approach in software development, promoting better code
organization, improved code quality, and enhanced development productivity. Using
this approach, we have identified the class needed and the properties and behavior of
those classes.
3.6. Tools Used
We used different tools during our project
5
➢ StarUml: to model the requirement in drawing the use cases and class
component diagram.
➢ Microsoft word: to write the document.
➢ Internet: to collect information about immunization vaccines.
6
4. OVER VIEW OF EXISTING SYSTEM
The existing system for managing immunization records relies on manual processes
and paper-based immunization cards. Pregnant mothers and infants are provided with
physical immunization cards that track their vaccination history. However, this system
faces several challenges that impact its effectiveness and efficiency. Such as:-
Accessibility Problem, Data Loss, Time Consuming and Resource Wastage:
These challenges highlight the limitations and inefficiencies of the existing system,
which can impact the quality of healthcare services provided to pregnant mothers and
infants.
5. PROPOSED SOLUTION
In this phase, we are going to solve the problems stated above in Jimma Health Center
by designing smart card for infant vaccination. In this system, first the mother and infant
should be registered by registrar filling the registration form online. The data inserted
by the registrar stored in the database by using a unique identification number. A smart
card is given to the mother which contain the data like identification number. The
registrar and doctors can view the detailed information about Mother and Infant using
smart card they retrieving the data from the data base and also contact the admin if
he/she has any queries. In addition to this, it enables health center to request for the
available vaccines. That means it allows online and real-time ordering. Finally, this
system also allows the users to access the system when internet connection lose by
downloading the file and editing the data (store new information to the file) then restore
the data in to database when internet connection available .
Main components of this system are the smart card and the website application. The
smart card is essential part of this system, which hold basic information of the user and
it can read and rewritten. When the mother come to health center the health professional
read the card by using smartcard reader and rewrite the updated information. This part
of the system will work on offline.
The website application will serve as a bridge between the smart card data and the
central database. This part of the system is an online system which has the main tasks
7
such as, it will upload the newly updated information to the central database when there
is internet connection, it also notifies the mother when the vaccination date is coming
closer.
5.1. Participating Actors
1. Mother
2. Registrar
3. Health Professional
4. Admin
5.2. Functional Requirements
Functional requirement is defined as a function of a system or its component.
Mother
✓ The system notifies the mother that her vaccination data.
Registrar
✓ The system allows a Registrar to log in.
✓ The system allows a Registrar to register new mother.
✓ Registrar can read mothers smart card using smart card reader.
Health professional
✓ The system allows health professional to log in.
✓ Health professional can read mothers smart card.
✓ Health professional can update the mothers and infant information on the
smart card and
✓ Health professional can also upload the new updated data to central database
using web.
8
Administrator
✓ The system allows Administrator to log in.
✓ The system allows Administrator to create users.
✓ The system allows Administrator to deactivate.
✓ The system allows Administrator to update user.
✓ The system allows Administrator to generate report.
5.3. Nonfunctional requirement
Non-functional requirements are that detail the constraints and quality standards that
the system building should adhere to. We are finding out what these non-functional
requirements should be by our experience. Also, we can use try and discover what non-
functional requirements should be. Here are some areas that we should have in our non-
functional requirements document:
Usability: - our system is more usable according to different perspectives.
From user perspective: - our system is easily to uses because the smart card can carry
the information needed the user to get the service any health center by using that card
only.
The smart card should have a user-friendly interface and clear instructions for health
professionals to read and update the data efficiently.
From task perspective: - our system operated by simple tasks. According to our system
there is a reader in the health center so the health professional can easily retrieve the
data he/she need by reading the smart card.
From environment perspective: - our system work both offline and online. The card can
be read offline by using reader and updated then by using web the data is uploaded to
the central database which this task performed in online.
From platform perspective: - our system uses simple technology to read the smart card
and to update the data.
9
Accessibility: - our system is easily to access. Because it works both in offline and
online user can access the system functionalities at any time in the presence of the smart
card. So, the user can get service at any health center.
Performance: - In the manual System, the cycle of retrieving and storing data is so
bulky that it needs more time and energy. Our system fixes this problem by storing and
retrieving the data from the smart card faster. It can avoid wastage of energy, time and
resource.
Reliability:
• The system should be highly reliable and available to ensure uninterrupted
access to critical data.
• The smart card should have a robust design to withstand physical wear and tear,
ensuring the data remains intact.
• The website application should have a backup mechanism to prevent data loss
in case of system failures.
Security:
❖ The system should employ strong encryption techniques to protect sensitive data
stored on the smart card and in the database.
❖ Access to the system should require authentication and authorization to ensure
only authorized personnel can view or modify the data.
❖ The website application should have appropriate measures in place to prevent
unauthorized access, such as firewalls, secure protocols, and regular security
updates.
❖ MD5 (Message Digest Algorithm 5) can play a role in ensuring data integrity and
security. Here are a few potential use cases for MD5 in this system:
• Data Verification: MD5 can be used to verify the integrity of the data
stored on the smart card. When the smart card is read by the health
professional, the system can calculate the MD5 hash of the data and
compare it with a previously calculated MD5 hash. If the hashes match, it
indicates that the data on the smart card has not been tampered with.
10
• Authentication: MD5 can be used for user authentication purposes. When
a user logs into the website application, their password can be securely
stored in the database as an MD5 hash. During the authentication process,
the user's inputted password can be hashed using MD5 and compared with
the stored hash to verify the user's identity.
• Data Transfer Integrity: When transferring data between the smart card
and the central database, MD5 can be used to verify that the data was not
corrupted during the transfer. The system can calculate an MD5 hash of
the data before sending it and compare it with the hash received at the
destination to ensure the data integrity.
• Audit Trail: MD5 hashes can be used to create an audit trail for any
changes made to the data. Whenever a health professional updates the
smart card data, the system can generate an MD5 hash of the previous and
updated data. These hashes can be stored in the database, allowing for easy
verification and tracking of any modifications made to the data.
Scalability:
• The system should be able to handle an increasing number of registered mothers
and infants without compromising performance.
• The database should be scalable to accommodate a growing volume of data as
more users are registered in the system.
• The website application should be designed to scale horizontally, allowing for
additional servers or resources to be added as needed.
Offline Capability:
• The system should allow users to access and update data on the smart card even
when there is no internet connection.
• Offline changes made to the smart card data should be synchronized with the
central database once an internet connection is available.
• The system should provide clear indications to the user when the data on the smart
card is not synchronized with the central database.
11
5.4. Proposed Architecture
We selected the three-tier architecture for our system. Which is organized in to three
layers: -
1. Interface layer for users to interact to the system
2. Application layer for smart card reading and connect to database the server for
data exchange.
3. Storage layer for storing data in to smart card and database.
Fig. 1 system architecture diagram
5.5. Entity relationship diagram
The Entity-Relationship (ER) diagram is a visual representation of the entities (objects,
concepts, or things) in a system and the relationships between them. It provides a clear
and concise overview of the data structure and the associations between different
entities.
12
Entities
• Mother: Represents a mother entity with attributes including motherID
(integer), motherName (string), and address (string).
• Registrar (card office): Represents a registrar entity with attributes including
registrarID (integer), registrarName (string), and contactInfo (string).
• HealthProfessional: Represents a health professional entity with attributes
including healthProfessionalID (integer), healthProfessionalName (string), and
specialization (string).
• Admin: Represents an admin entity with attributes including adminID (integer),
adminName (string), and adminRole (string).
• Infant: Represents an infant entity with attributes including infantID (integer),
infantName (string), birthDate (Date), and gender (string).
• Vaccine: Represents a vaccine entity with attributes including vaccineID
(integer), vaccineName (string), dosage (string), and manufacturer (string).
• Vaccination: Represents a vaccination entity with attributes including
vaccinationID (integer), infantID (integer), and dateAdministered (Date).
The relationships depicted in the diagram are as follows:
• Mother has one or more Infants (one-to-many relationship) - represented by the
"has" association.
• Registrar registers one or more Mothers (one-to-many relationship) -
represented by the "registers" association.
• Health Professional interacts with one or more Infants (one-to-many
relationship) - represented by the "interacts" association.
• Admin manages one or more Registrars (one-to-many relationship) -
represented by the "manages" association.
• Infant receives one or more Vaccinations (one-to-many relationship) -
represented by the "receives" association.
• Vaccination uses one Vaccine (one-to-one relationship) - represented by the
"uses" association.
13
fig 2 ER diagram
14
fig 3 System database schema
15
5.6. Normalization
To demonstrate the normalization process, let's consider an example entity called
"Infant" that stores information about individual infants. We'll go through the
normalization steps up to the 3rd Normal Form (3NF).
1. First Normal Form (1NF):
- Ensure that each attribute contains only atomic values.
- Identify a primary key for the entity.
Example:
Infant (InfantID, MotherID, InfantName, BirthDate, Gender, Vaccination)
2. Second Normal Form (2NF):
o Meet the requirements of 1NF.
o Remove partial dependencies by separating attributes into different entities.
Example:
Mother (MotherID, MotherName, Address, PregnancyStatus)
Infant (InfantID, MotherID, InfantName, BirthDate, Gender)
Vaccination (VaccinationID, InfantID, VaccineName, DateAdministered)
3. Third Normal Form (3NF):
o Meet the requirements of 2NF.
o Remove transitive dependencies by creating additional entities.
Example:
Mother (MotherID, MotherName, Address)
Pregnancy (PregnancyID, MotherID, PregnancyStatus)
Infant (InfantID, MotherID, InfantName, BirthDate, Gender)
Vaccination (VaccinationID, InfantID, VaccineID, DateAdministered)
Vaccine (VaccineID, VaccineName)
16
In this example, we've split the original "Infant" entity into separate entities such as
"Mother," "Pregnancy," "Infant," "Vaccination," and "Vaccine." This ensures that each
entity has a primary key and eliminates any partial or transitive dependencies.
6. ACTION PLAN
Action plan is the list of tasks or procedure we used to achieve our objective or goal.
Action plans are useful, because they give us a framework for thinking about how
we’ll complete our project efficiently.
Accordingly, all of our group members used the following throughout our project.
Tasks: -are the actions we performed through our project.
✓ Analyzing the project overview
✓ Prepare objective and scope
✓ Functionalities and non-functionalities of our system
✓ Analyzing the proposed solution
17
✓ Designing our project by using UML diagram
Table 1 Action plan
18
7. FUTURE PHASE
In the phase three, we are aimed to solve the stated problems by implementing the
proposed system by using different concepts of database, programing languages,
HTML and CSS that we designed in the previous chapters of our document.
19
