A Web-based blood donor

management
Chapter 1

1.0 INTRODUCTION

1.1 Background to the Study

Blood Donor Recruitment (BDR) is the process of drawing blood from a voluntary Blood
Donor (BD) for future blood transfusion, Wikipedia (2006). In Uganda, blood collection,
safety and management is an activity that is carried out by Uganda Red Cross Society (URCS)
in partnership with Uganda Blood Transfusion (UBTS). Founded in 1939, URCS is part of
the world wide Red Cross Humanitarian Movement whose mission is to mobilize the power
of humanity for improving the lives of the vulnerable in Uganda, Muller (2001). URCS fulfills
this mission while adhering to the principles of impartiality, neutrality, independence, unity,
universality and voluntary service for the Red Cross/Red Crescent Movement. It operates
throughout Uganda with 45 branch offices. Besides providing adequate supply of blood for
transfusion, URCS is involved in the first aid services, road safety, tracing, disaster
mitigation/preparedness, mobilization for routine immunization, HIV homecare, youth
empowerment and Community based HealthCare (CBHC).

URCS had a manual system using paper cards to recruit BDs, collect/keep blood donor
records and disseminate results to BDs who are scattered throughout the country. The paper
card system (PCS) used to specifically capture personal data and medical history of the BDs.
This information would be used in identifying/locating existing BDs, carrying out predonation
counseling and taking blood results. Unauthorized persons however, easily accessed the paper
system and hence making it impossible to keep secrecy and confidentiality expected of medical
records. The security of the medical records was also not inadequate as any person could easily
access them. Lukande (2003), states that such a system is time consuming, prone to errors of
entry and analysis resulting from the fatigue of the users. The PCS at URCS had lead to
accumulation of physical paper cards due to increasing number of blood donors, a situation
that frustrated the system users because of the delays and at times failure to access historical
records.

The safe blood policy was lacking at URCS because the PCS could not cater for the key
attributes of the policy. Gerard (2002), states that the main principles upon which the safe
blood policy is based on are the informed consent, confidentiality and secrecy of the BDs.
The Ethiopian Red Cross Society publication, Development in the 1990 states that
information from blood donors should be completely confidential and if this is not assured,
names of the blood donors should not be recorded at all and/or an alternative record
identification should be used.

Full implementation of the safe blood policy has called the use of information technology (IT)
in providing working solution to the identified challenges. The associated problems with the
PCS included delays in accessing historical records, inconsistencies and errors in data entry
that stem right from acquisition of data from the blood donors because the exercise is of
routine nature and very tedious to the system users. The automation of the system using
modern IT has improved the quality of service. Secondly, with the use of IT, now relevant
and timely blood donor reports can easily be generated and hence facilitating planning and
decision-making.

Scolamiero (2000), recommends blood donor services automated information system as a

solution to routinely collected, accurate and readily available information in blood transfusion
services. It is also important to note that the impact of information technology on
organizations is increasing as new technologies evolve and existing ones expand. According
to Clifton (1995), nearly all business executives say that information technology is vital to their
business and that they use IT extensively. Certainly business executives main concern is
planning, coordination and decision-making, therefore, the role of IT in enhancing
management of blood donor records is of major importance.
In all, the computerization of blood donor PCS at URCS came at the ripe time given the
background to the situation. This is more so because the demand for safe blood in Uganda
has increased due to soaring increase in total population. Therefore, modern means to manage
the PCS using IT had to take route.

1.1.1 Web Based Management Information System

Accessing databases using a web browser as if accessing a normal database application

system can be a very significant advantage. Today’s database systems can be very efficient
in processing large amounts of data by using different type of sources. Any information
that can be defined by a relation can be fed into a database system, however making
information available on the Web requires accessing the database via a special database
algebra called SQL and by converting it to a markup language such as HTML or XML
(Weigang, 1999).

Firstly, to understand this system, it is important to understand the meaning of the Web and
how it can be integrated to a database. The WWW is a software environment based on a
computer network called Internet. It is officially described today as a “wide-area
hypermedia retrieval initiative aiming to give universal access to a large universe of
documents (Orchard, 1995) and has a variety of uses throughout the world. However, in
order to fully take advantage of these uses one must definitely be connected to the Internet
and must use some kind of software package (Web Browser) that understands markup
languages (i.e. hypertext, hypermedia)

An additional requirement of the system is for it to be able to integrate to the Endnote

software. The drawback using this software tool is that it can only be run on a single
computer and therefore users who are not using the computer Endnote is installed on cannot
access its database. Therefore, it is essential to provide a “bridge” between the Web-based
DBMS and the Endnote Software tool database system in order for bibliographical data to
be transferred (import/export) between the above systems when desired. This integration
will not only facilitate the need for continuity, it will certainly also provide a great degree
of standardization to the system and its users.

Many technologies exist (and will be examined in depth) that can be adapted in order to
integrate a web based front end to a database. By analyzing each technology’s strengths
and weaknesses it will be easier for the system to be developed to provide the most optimal
Web-to-database access and Endnote compatibility. Using more automated facilities for
publication purposes will significantly improve the current system by decreasing the
workload of specific members of staff and by increasing their productivity.
1.2 Statement of the Problem

The BDR management system at URCS exhibited a lot of ineffectiveness and inefficiency that
had far fetched impact on the decisions taken by management. The system, which was manual
that is based on paper cards to collect blood donor data, keep records of blood donors and
disseminate results to BDs had weakness that needed IT based solutions. The system was
characterized by delays and sometimes failure to access historical records, errors were
witnessed in entry and manual analysis of results, secrecy and confidentiality of records lacked
because unauthorized persons could easily access the records. Therefore, management
decisions such as blood distribution to hospitals, mobilization/sensitization of blood donors
were not taken basing on real facts. Under such a system, another challenge to management
was quick generation of reports pertaining to blood groups for the big number blood donors
in place. Indeed the application of IT-based solution in improving the system was envisaged.
Therefore, the existing system was reviewed and an effective/robust blood donor management
information system designed to assist management in implementing its strategic plan in order
to achieve the over all mission, goals and objectives.

Douglas (2003), states that the traditional methods of medical data management have resulted
into incomplete and inaccurate data in many cases. Incompleteness has resulted from lack of
printed forms, unwillingness of staff to complete forms and sometimes loss of completed
forms prior to data entry. The scenario explained by Douglas is not far from the PCS that was
at URCS, a situation that rendered decision-making by management challenging and hence
justified for the research of this project.

1.3 General Objective

The main objective of the study was to create electronic blood donor management information
system in order to assist in the management of blood donor records, planning and share
information in a more confidential, convenient and secure way using modern technology.

1.3.1 Specific Objectives

To conduct a study on blood donor management
To design an electronic blood donor management system
To validate the design using a prototype

1.4 Scope
The study geographically limited itself at the URCS blood donation/collection centers. It
focused more on the acquisition, distribution and management of blood units for BDR
activities. The study specially emphasized the creation and implementation of an electronic
management information system that automated blood donor data acquisition and
dissemination of results. This in turn will ease and speeds up the planning, decision-making
process because of the timely, secure, confidential and reliable reports.

1.5 Significance of the Study

This study is important to URCS and the blood donors because it aimed at addressing
problems of security, secrecy and confidentiality of blood donor records. It also strived to
check the delays, errors, inconsistencies in medical records and timely access to historical
records all of which had far fetched impact on planning and decision-making. The study
resulted into the following benefits:

It has eased the control and distribution of blood in various parts of the country basing on the
hospital demands.

URCS can now create market strategies for blood donation, lobbying and sensitization of the
blood donors.

Automated data acquisition and quick access to medical records by the legal users of the system
will be assured.

It has eased the monitoring of the results and performance of the blood donation activity and
hence relevant and measurable objectives of URCS are checked.
It will continue to improve on the planning and decision-making process by providing to
management timely, secure and confidential medical reports related to blood donation.

It will also improve medical service delivery due to timely and easy generation of management
reports by the relevant entities.

The study will benefit the URCS management, who will find it easy to strategically plan,
coordinate and take decisions concerning BDR activities. URCS counsellors on the other hand
will be able to keep confidentiality of the donor’s results and disseminate blood results to
donors with ease. Meanwhile that is the case, the automation of the data collection process
will simplify the work of the data clerks. Equally important, the blood donor mobilizes will be
have strong grounds for laying sensitization strategies between regions that yield more blood
units and those with less. The study also has formed further environment of knowledge for
students who may wish to take research in blood donor management.

Chapter 2

2.0 LITERATURE REVIEW

2.1 Management Information Systems in Medical Records

Overtime, there has been on-going digital revolution of the 21st century especially in the
integration of Information Systems (IS) into the existing various sectors of human
engagement. This revolution has come with a view of enhancing the quality of services
provided, improve data systems and automate all the originally manual operation. Lucey
(1997), defined information systems as formalized IB-based systems used to collect, store,
process and generate reports based on data from various sources to aid management in taking
decisions, coordinating, controlling, analysis and planning for the organization. Information
systems whether automated or manual comprise of people, machines and methods of data
collection, processing, transmission and dissemination. They therefore, play a vital role in
facilitating planning, coordination and decision-making process.

The integration of IT in the medical sector has lead to the increase in the development of
Health Information System (HIS) in the developing world. Ophelia and Chong (2004), defines
HIS as a system that integrates data collection, processing, reporting, and use of information
necessary for improving health service effectiveness and efficiency through better management
at all levels of health services. Procter and Brown (1997), point out that this shift to automation
by the integration of operations using computer technologies in medical records saves time
and improves the reliability of ordering and obtaining results of the tests and therefore a
generic system for Orders, Results and Reporting (ORR) was developed. An example of the
integration talked of is the Hospital Information Support System (HISS). This electronic
transfer system was introduced for hospital wards for purposes of ordering of patients’ tests
and reporting results. Another example of integration of IT in medical sector is the use of
handheld devices to collect data, carry information to patients and used as references. In
Ghana and Kenya, the mobile technology has been used successfully in the routine
immunization campaign to collect data and analyze results and hence providing healthcare
system.

Fadlalla and Wickramasinghe (2004) state that robust healthcare information system (HCIS)
are important in enabling healthcare organizations, address challenges of medical data and that
information captured, generated and disseminated is of possible integrity, quality and
complaint with regular requirements. In one way or another, this is linked to the
computerization of the blood donor records at URCS that is meant to focus on data
acquisition, security, secrecy, consistence, easy access to medical records and generation of
timely reports to facilitate decision-making. All attributes mentioned here were lacking at
URCS and hence the shift from the manual system to IT aided system to enhance the
management of the BDR unit.

Croasdell (2000); Hammoud (2001) note that Information Systems/Information Technology

(IS/IT) have played a central role in enabling organizations across many segments to address
many business challenges and achieve a lot of sustainable comparative advantage. Surely, an
electronic management information system has offered similar benefits to the blood donor
management at URCS. Specifically, it has offered a means to address the challenges that had
crippled the blood donor records management.

2.2 Criteria for Setting up HCIS

Health/medical records must meet a number of criteria. Some of these criteria affect how the
system can be accessed as well as how key players may interact with these systems. Moore and
Welson (2002), point out security requirements, transmission standards, privacy, information
integrity and quality as some of the essential criteria. Essentially security falls into three main
categories namely; administrative, physical and technical. The privacy criterion deals with the
purpose to maintain strong protections for individual identifiable health information/record.

Mandke and Geisler (2003), point out that information flow within the system and between
the key participants in the system must exhibit both the attributes and dimensions of
information integrity as well as satisfy the quality. Specifically, the information should display
the attributes of accuracy, consistency and reliability of content and processes as well as the
dimensions of usefulness, completeness, manipulability and usability.

2.3 Blood Donor Systems: Challenges and Successes

The blood donation service involve a series of interdependent operations such as donor
registration, donor screening/evaluation, blood collection, blood screening, inventory
management and blood dissemination. Most of the popular existing blood information
systems in the western world today are mainly online systems. The systems interfaces do not
meet fully the blood safe policy described in this study and as such not suitable for illiterate
population. Most blood donors in Uganda are rural based where online systems may not be
the best. The level of computer literate among the blood donors in Uganda is growing because
the majority of them are school students. The main challenge remains customizing interfaces
that are suitable for capturing basic donor information. Some of the attributes on the interfaces
used in the western world such as state and province are not applicable in Uganda. Tripura
blood donor information system is a good example of the blood donor system that is not
suitable for Uganda. Also some key attributes such as age and sessions in Uganda are lacking
on most the interfaces viewed. The interfaces also are not user-friendly as there are many links
within the system that can easily confuse the system users and hence leading to data entry
errors and boredom.

At the Macau blood Transfusion Centre, system Integrado de Bancos de Sangue (SIBAS)
works as its solution of computerized blood bank information system. SIBAS complies with
the client/server infrastructure, as does its client, and provides an integrated environment for
those isolated but interdependent operation in the blood center. With the introduction of the
SIBAS the blood service at Macau has been enhance in the following aspect. Operational
efficiency- the processing time has been shortened in that blood donors need not fill in many
regular items. On the other hand, the steps for donor cards are under full control and hence
leading to donor satisfaction and confidence. There is also improved information consistency
and validity.

The Indian case study of Prathma Blood Center, Gupta (2004), promises insights into the
integration of IS/IT in management of blood records. The Prathma Blood Center is a quest
for modernizing blood banking. The entire function from blood donation to its testing and
separation, storage, issue and usage have been integrated through a custom designed enterprise
resource planning (ERP) software that minimizes human intervention and making it less error
prone. The implementation of ERP in blood bank in India has registered many successes in
medical data such as security, confidentiality, secrecy and quick retrieval of historical records
all of which were challenges at URCS blood center. However, full automation of all blood
donation activities like the case cannot be done in Uganda due to limited resources. It requires
transition, as it is resource constraining in terms of IT, other equipments and human resources.

2.4 Mobile Technology and Health Management Information Systems (HMIS)

Ophelia (2004) defines HMIS as an information system designed to assist in the management
and planning of health programmes, as opposed to delivery of care. Mobile technology is a
term used to describe handheld devices such as personal digital assistant (PDA), mobile
phones a few to mention. Advance in mobile technology has changed the devices from
electronic address books to powerful tools with wireless network connectivity. Chiarungi
(2000) found out that mobile technology has the capacity of accessing Internet, sending and
receiving email/text messages and functioning as information repository and this was related
to healthcare industry. The technology in simple terms provides access to a wealth of medical
information. He further states that mobile technology immediate and ubiquitous access to the
patients integrated electronic health record. That such a record can be further enhanced if the
device is also able to display graphical information related to clinical examination records. This
sort of automation talked has eased data acquisition and dissemination of blood results.

In the event of URCS blood donor system, where counselors used to take blood donor results
using sheets of paper that are subject to damage by rainfall, rodents and easily accessed by
unauthorized parties, mobile technology can provide a better alternative. This is because it
provides security, keeps secrecy, confidentiality and consistence as expected of medical
records.

Jeeyapant (2003) emphasize that computer-based interview especially Audio-Computer

Assisted Self_ Interview (ACASI), is feasible and more accurate method for collecting data on
sensitive risk behaviour than the traditional methods such as Face-to-Face Interview (FFI) and
self administered questionnaire (SAQ). However, in the last few years mobile technology such
as Microsoft Windows CE device have become widely popular and provide cheaper, long
lasting battery powered and therefore, mobile technology has proved an alternative to desktop
computers or laptops and more especially in changing and remote locations where power is
not reliable.

The blood donor record management system at URCS shared similar scenario urged by
Jeeyapant. The blood drawn from donors is tested against HIV and other sexually transmitted
diseases hence making it an activity of sensitive risk behaviour. The blood donors are a mobile
population that is scattered in remote areas all over the country; therefore, the routine
collection of data from them necessitates the application of mobile technology.
Biswas (2003) assert that in the 21st century, the potential of mobile technology as a method
to improve healthcare is widely acknowledged in developing countries. The technology has
been applied even in other fields apart from medical sector. For example Zanzueta (2005)
demonstrated the use of mobile technology in agricultural records and programmes. He points
out trends in application of advanced mobile technology. Following the miniaturization of
computer equipment however, the past few years, the capacity of the personal computer (PC)
tended to migrate into handheld technology. The convergence of mobile technology with
wireless networks, better software development tools and broad base of users that are skilled
in using desktop computers and online resources, there is a clear trend towards nomadic
computing. It is urged that early use of handheld technology focused on scheduling, note
taking, email and storage of information such as telephone numbers and addresses but their
maturing reached when they were able to run applications comparable in complexity to those
executed on PC and to substantive amount of information. The costs, mobility, security,
portability, convenience, battery power usage of mobile technology have made it more popular
in rural areas than the traditional PCs.

There are a number of successful projects in the health sector where handheld technology was
used as the main tool to collect, process and manage medical information in a professional
manner. In Tanzania, the food and drug authority used handheld technology in collecting data
on drug usage, track adverse reactions, track stock balances and other pharmaceutical data. In
Bangladesh, hand held technology has been used successfully to collect data related to
programme management at reproductive health. In South Africa, successful a pilot project in
the use of handheld devices in rapid needs assessment of voluntary HIV testing and counseling
has been conducted. Other areas outside the health sector where handheld devices have been
successfully used in Africa include registration in Rwanda with the National Electoral
Commission.

In all areas where handheld technology has been implemented whether medical or otherwise,
their main strengths have been portability, easy access to data, user-friendly, ease of data entry
and sharing while the major weaknesses are limited screen and data power.
The above literature reveal a number of weaknesses existed at URCS blood center and required
IT based solution in order to get better service delivery. Data collection at URCS was a routine
exercise that was boring and frustrating to the system users, therefore, automating it was
necessary. The PCS was time wasting, subject to errors in data capture
Chapter 3

3.0 METHODOLOGY
3.1 Introduction

In this chapter we discuss the approach used to achieve the objectives of the project. The
techniques used to achieve the user requirements and the technologies used in the designing
of the system.

3.2 Fact Finding Techniques

3.2.1 Interviews

The researcher opted for this type of fact finding technique because at first the people in the
blood bank section were not cooperative since blood donation involves knowing peoples HIV
status and these people are compelled to keep confidentiality. Because of this problem, the
needed information could not be got from other methods of fact finding techniques as the
researcher had to first build confidence in the respondents and assuring them that the research
was purely academic. Those interviewed were the managers, blood bank staff and some few
donors. The interview guides and findings are as shown in (Appendix A).

3.2.2 Reading available Literature

The researcher also read the available literature in form of reports and brochures. However
little information was available as regards to information processing. Most of the available
literature was purely demographic.

3.3 Web Application Technologies

A web application is an application that runs on a web server and is accessed by users over the
Internet or a local intranet. Web applications usually consist of static resource files (e.g.
Images), web components, helper classes and libraries. A web browser is commonly used as a
thin client hence all the processing is done on the server. Web applications are usually
organized in a three-tier architecture – a user interface level, a functional process logic level,
and data storage level. A web browser is the user-interface level and dynamic web content
technology such as CGI, ASP or Java Servlets, is used in at the functional (business logic) level.
Data Storage is handled by a database.

Web applications are an extension of a web server (Armstrong et al, 2004). Web applications
are either service oriented or presentation oriented. A presentation oriented web application
produces interactive web pages containing mark up languages like (XML and HTML) and
dynamic content in response to requests. Many of these open source LAMP (Linux, Apache,
MySQL and PHP). A service oriented web application then implements the endpoint of the
web service.

3.3.1 Linux, Apache, MySQL and PHP (LAMP)

Linux, Apache, MySQL, and PHP/Perl/Python (LAMP) are a set of software increasingly
being used to run dynamic web sites. Their popularity arises from the fact that they are basically
free. These open source software can be easily downloaded from the net, or come bundled
with Linux distributions (WWW2).

3.3.2 MySQL

MySQL is a multithreaded, multi-user, SQL relational database server. Programming languages

that can access a MySQL database include C, C++, Java, PHP, and Perl. The MyODBC
interface allows other programming languages which support the ODBC interface to
communicate with MySQL. MySQL runs on many different operating systems including Linux
and Windows. MySQL offers a lot of improvement over previous versions including
transactions (with save points), SSL support, nested SELECTS, ACID compliance and Query
Caching.

3.3.3 PHP

PHP stands for Hypertext Pre-processor. It is mainly used as a general purpose scripting
language used to develop dynamic web content and can be embedded in HTML. PHP can be
used as an alternative to Macromedia ColdFusion, ASP.NET/C#/VB.NET and the JSP/Java
System. PHP is easy to use and is very similar to structured programming languages like Perl.
PHP is more than just a scripting language. It is a full programming language and can be used
from a command line and also be used to develop Graphical User Interface Applications. PHP
runs on many of the major operating systems, including Linux and windows and also supports
many database systems, including MySQL. One feature that leads to the popularity of PHP is
that it is dynamically typed. Variables do not have to be declared and they can hold any type
of object. The arrays in PHP can hold objects of different types, including other arrays. PHP
includes many open-source libraries and includes modules built in for accessing FTP and
database servers.

3.3.4 HTML and CSS

Hypertext Markup Language (HTML) is based on the Standard Generalized Language

(SGML). HTML is a language for describing the structure of a document, not its presentation
(Lemay, 2001). HTML defines a set of common styles for web pages: headings, paragraphs,
lists and tables. HTML provides a means by which a documents main content can be annotated
with various kinds of meta-data and rendering hints. The rendering hints include specifying
scripts, imagemaps and form definitions for web browsers. Macromedia Dreamweaver and
Microsoft Frontpage are the leading software tools for editing HTML. Content and
presentation can be combined using server side scripting languages like PHP and ASP to make
the final HTML.

3.4 Chosen Web Application Technologies

The combination of PHP and MySQL was chosen for this research project because of the
following reasons
i. They are open source which implies that they are cheap to get since one just need to
download them from the net.
ii. PHP is a rapid application development environment and is known for its ease of
use. It enables most developers get involved with dynamic web applications without
having to learn entirely new set of functions because it is very similar to structured
programming languages. iii. MySQL has very fast database management system
and is also easier to use than many other database systems.

3.5 The architecture of WBBDMI -system

A schematic representation of the overall architecture of the system is given in Figure 3.1
below WBBDMI architecture is based on the existence of different independent modules that
are integrated into a communication protocol and operate as a single entity. The modularity
that characterizes the system, gives great flexibility and expansion capabilities without
undesirable side-effects, since all the changes effect only a part of the system.

To be more precise all available information are stored and organised into five distinct database
modules. This distribution depends on the nature of information and it takes place in a way
that the five modules co-operate as a whole, while on the other hand they preserve their
independence. The linking between the database modules is made via some common fields in
a way that the retrieval and manipulation time of data is reduced. Moreover, the remote access
to the system is quite easy, as the distant user doesn't have to manipulate a great deal of useless
information.

The five distinct database modules are the following:-

 DonorDB
 Donation DB
 DiseaseDB
 Transfusion DB
 Statistical DB
 Fig 3.1 : a WBBDMI architecture

Donor Database is the one that manipulates the basic donor's information. This is actually
the kernel of the whole system since every other information is referred to its tuples. Basic
demographic elements and contact information can be stored there. Secondary information
such as the preferable time for transfusion, donation period etc. can also be stored. The
database can handle the case of voluntary donation of individual persons or donations
organized by different groups. Queries like "find the donor with number xxx", or "find all the
donors that can give blood in a given hosipital" can be performed in the Donor DB. Every
person gets a personal unique number as soon as he becomes donor. This number follows a
predefined format that describes his blood type, rhesus and the preferred way for donation
(e.g. with other members of a group, or when a relative needs blood). Using this number the
system can search for every information relative to the donor very quickly. Moreover in case
of power failure or system crash, the personnel of the blood centre can easily find out a few
things about the donor by just looking at his number.

The Donation Database contains information about each person's donations, that is blood
pressure measurements, temperature, hematocrit, etc. The dates of donations can also be
found there. In this database a user can execute queries that present the measurements of a
donor's condition during donations. More time consuming queries can be also performed. For
example a user can ask for a list of all donors with predefined blood type, rhesus and antigens
that should give blood (meaning that the necessary interval from the previous donation has
passed). Another important query, called emergency list, can present the donors that have
more than three months to give blood. This query can help to cover emergency needs for
blood products.

Disease and other laboratory tests are manipulated by the Disease Database. The contents
of this database are actually "sensitive" data and can be retrieved only by authorized personnel.
For this reason, special care is taken to ensure system's security. First of all, every tuple in the
database uses the serial number of the blood bag to identify the input. This guarantees that all
tests are not connected to the donor himself, but to the bag containing the blood. Moreover
every positive test result is stored as negative.

The fourth database, called Transfusion Database, contains information about blood
transfusion. The whole history of a blood bag can be found here. Information for every blood
unit that has been transfused into any patient at the local hospital or at any hospital, results of
compatibility tests and all the possible blood reactions in the transfusion are also stored here.
In case of reactions in blood transfusion all the actions taken are stored here. Quality control
tests for the blood, for all its products and for blood bags can be inserted in the proper tuples
of the database. The contents of the blood refrigerators are organized in the Transfusion DB.
The system will inform the personnel for the items that are near the expiration date every
morning during the boot process.

The last database, the Statistical Database, is a database storing statistical data. More
precisely reports of the way donors are distributed according to their sex, age, job, family state
(married, single, divorced), education, frequency of donation and many other criteria are
provided by the Statistical Database.

3.6 Queries performed by WBBDMI -system

Every user has different privileges on the systems queries, depending on his access level. Low
level users, such as those working at the reception of the blood centre, can execute simple
search queries for information related to a donor. Information about a transfusion, e.g. the
date of a transfusion, contact information, blood pressures etc. are easily executed using hash
procedures with the personal number of the user. These users have the minimum access
privileges in WBBDMI 'S data. Users of the next level, that is doctors, can perform queries
that help them to find transfusion and clinical information about any donor stored in a file in
the centre.

Non available donors and clinical examinations are available to authorized doctor personnel.
The availability of blood type can also be seen from this level. It is actually the level where
strategic decisions can be made, such as when to call donors for donation, how many of them
etc.
Finally there is a great variety of statistical queries that can be performed in printed reports
based on different parameters. Reports can be generated for the way donors are distributed
according to their sex, age, job, education, family condition, frequency of donation and many
other criteria. These queries are a very valuable tool for the social workers of the blood centre.
Chapter 4

4.0 SYSTEMS ANALYSIS AND DESIGN

4.1 Introduction

Following the literature review, background information and correlative knowledge regarding
this research project follows. In the first part of this chapter, the demand and requirements of
the proposed system are discussed and analyzed through dataflow diagrams, the entity relations
model and the data dictionary. According to this analysis, the specification of the system is
defined. This provides the foundation for chapter 5 (Implementation and Testing). This
chapter presents the various design techniques and processes available for building web based
applications. It explains the design technique chosen, showing its advantages and
disadvantages.

4.2 A different approach for designing web based applications

Traditionally, software has been broadly classified into different categories. Some of these
categories include real-time software, personal computer software, artificial intelligence
software and business software. Web-based systems and applications (WebApps) such as web
sites and information processing applications that reside on the Internet or an intranet, require
a somewhat different method of development than these other categories of computer
software (Pressman, 2000) [xx]. This is because web based systems involve a mixture of print
publishing, software development, marketing, computing, internal communications, external
relations, art and technology. WebApps are network intensive, content driven, continuously
evolving applications. They usually have a short development time, need strong security
measures, and have to be aesthetically pleasing. In addition, the population of users is usually
diverse. These factors all make special demands on requirements elicitation and modelling.

4.3 Requirements and Analysis

The requirement analysis stage of a software engineering project involves collecting and
analyzing information about the part of the organization that is supported by the application.
This information is then used to identify the users' requirement of the new system (Conolly et
al, 2002) [xx]. Identifying the required functionality of the system is very important as a system
with incomplete functionality may lead to it being rejected. A description of the aim of the
project is given here along with details of the functional and non-functional requirements for
the system. The test sheets for evaluating the completed system are also presented.
4.3.1 Requirements

The requirements of the Web-based management information system are to develop:

• a web based front end for entering donated blood details including the donor, his/her
blood group, sex, age, and status of the donated blood
• a web based front end for searching the information relating to a given donor or a given
blood group;
• a facility to still enter donor and donated blood information via Endnote and also maintain
the Endnote database using those details entered via the web front end and
• a facility to produce summary information of donor and donated blood particulars and any
other related activities.

4.3.2 Functional Requirements

In this research project we aim at developing a system which should improve on the current
one with a lot of functionalities and therefore the Major target or goal here is to:

• to develop a blood donor database that can support the five above mention
subdatabases that is to say; DonorDB, Donation DB, DiseaseDB, Transfusion DB
and Statistical DB
• to develop a client interface that allows privileged users to carry out tasks such as
inserting or modifying and deleting data in the database;
• to develop a searching functionality in order to allow normal and privileged users to
search the details of a given donor, blood group, stakeholder and if necessary a type
of disease common which causes one to need the donated blood
• to fully integrate the Web-based management information system to the WorldWide-
Web and hence allow access from any Internet networked terminal and Web browser
around the world;
• to develop a facility that can export details entered via the web front end to Endnote
as well as import and confidential detail from the Endnote Database;
• to develop a functionality that produces summary information of required data to
enhance decision making;
• to embed high security features in the Web DBMS to provide privacy, integrity;
• to allow privileged users to maintain the Web-based management information system
by adding/deleting particulars, backing-up or resetting the database and extract online
summary in the form of histograms for each donor and lists of free-format comments.
Thus a graphical reporting tool should be provided for analyzing the data.
• and finally the system should be flexible enough to store data for several years and also
be able provide sufficient User and Administration Guides.

4.3.3 Non-functional Requirements

The system must be developed to suit the particular needs of a user-friendly environment. This
means that the system must accommodate a clearly understandable user interface as well as
clear online help documentation at any stage of the user interaction with the system. A fast
response time in obtaining and providing information to the system may also prove to be a
significant advantage. In addition to these requirements, the system should also embrace the
following requirements:-

Security: Each user is required to log in. The system should log staff that has been assigned
user names and passwords. The system should be designed to make it impossible for anybody
to logon without a valid username and password. Data encryption should be employed to keep
the user login name and password secret.

Reliability: The system would be used by about 50 staff working at the Red Cross head
quarters and also some other many staff in the collaborating clinics and hospitals. The system
should have little or no downtime and be able to handle multiple concurrent users.

Ease of Use: The general and administrative views should be easy to use and intuitive. Online
help and documentation should be provided.

Performance: The system should have a quick response time. For the purpose of this research
project, this would be defined as less than 5 seconds.

System and Browser compatibility Testing: The system should be accessible on the
following browsers - Microsoft Internet Explorer 5.5+, NetScape Navigator 6.0+ and
Mozilla 1. 3+.

System requirements: Red Cross society Uganda has a UNIX server. This system would be
designed to run on a minimum hardware configuration of 500MHz x86 machines.
Considering the vast hardware available at the society , this would not pose any problems.
Server Software:
Operating System: UNIX (Sun Solaris), Windows 2000, or Windows XP
PHP version: PHP 5.0+
Web Server: Apache Web Server. 2.0+
Database: MySQL 4.01+
4.4 Access Level Analysis

In order to take closer look into what the system should do and how, it was necessary to
decompose the system’s functionalities based on the user type and levels of access. The three
main user groups and access levels are:
• Global User Group (normal access level)
• The Red Cross User Group (privileged access level)
• The Administration (privileged access level)

Therefore, the requirements could be efficiently analyzed depending on the user group and the
functionalities they should be allowed to perform.

4.4.1 Main System Page (Index)

It is required for the system to provide a Main Page where any Global user (any user within
and outside the Red Cross Organization) will be able to access. The main functionality of this
page will be to allow any user to search the database by using information such as quantity of
donated blood, available blood and the groups, or any other general information which may
not be considered confidential. The search capabilities of the main page might not be limited
to the exact blood donor, but may for example provide the means for displaying any
information that might be relevant but not confidential. The Main Page should also include a
Login facility for any privileged or normal user to be able to have access to more advanced
functionalities of the System.

4.4.2 The Red Cross User Group

When a Red Cross user has successfully logged into the system via the Main Page Login facility,
it will be necessary for the system to display a specific menu with all available option that can
be carried out. Therefore by taking into account the system requirements, it will be necessary
to include options such as Enter donor details, Search donor, Use Endnote Facilities, Produce
Summary Information as well as an option that will be related to the appropriate User Guide.
A Logout option will also be appropriate for the Red Cross user to be able to logout when
desired.
4.4.3 Entering-Amending Blood donor Details

For a user to be able to amend and enter into the system’s database it will be essential to take
into account that the blood donor system will be integrated to Endnote. Therefore, it will be
essential for the system to provide to the user the exact fields as Endnote does for any
particular type of details. In addition, when a particular of a given donor has successfully been
submitted or amended into the database it will be essential for the system to display the
appropriate message (i.e. Blood donor successfully entered into database).

4.4.4 Searching the Blood Donor Database

The Searching Facility for the Red Cross user should not differ from the facility that will be
provided on the Main Page of the system for all users. Therefore, the Red Cross user will be
able to search any type of information in the database using the same way as specified for the
Global User.

4.4.5 Producing Summary Information

For this requirement it is essential to firstly understand why and when it will be used and to
adjust the functionality to best suit these purposes. In order for the system to efficiently
produce summary information it will have to provide a menu providing options such as
Produce Annual Report, or Produce General Report etc.

4.4.6 Endnote Facilities

In order for the system to be effective, it will be necessary for it to be integrated with the
Endnote software. Therefore, it will be very significant to accommodate two options that will
include Importing blood particulars from Endnote and Exporting blood particulars to
Endnote. How this will be done will mainly rely on taking full advantage of particular Endnote
filters that are provided for these reasons.

4.4.7 Administrator

For maintenance purposes it will be of great significance to include advanced Administrator

functionalities that can only be accessed by this particular user group. The most reasonable
options for an administrator to perform may include tasks such as deleting donors (should not
be provided to the Red Cross user group for security reasons), Backing-up and Restoring the
database, Resetting the blood donors database etc. In addition to these functionalities the
administrator may also be asked to perform tasks related to Red Cross or Global user (i.e.
Entering new donors, Searching for a given donor or available blood group) and therefore any
functionality provided by the system must be included in the administrator capabilities.

4.5 Task Structure Diagrams

For the development of a more consistent and effective system, it was essential to firstly
identify which information should be included accomplish this, it was first of great significance
to group all the relevant tasks (system functionalities) depending on the users.
The way the systems tasks could be efficiently identified was by using a special technique from
the Discovery method called Task Structure Sketching (Simons, 2002).

4.5.1 The Red Cross User

 Red Cross User
Functionalities

Insert New Edit data Search for Produce Use

Data Data summary Endnote

Export d
donations

Search
Import
donors
donations
Insert donor
Edit donors Weekly
-recipients report

Search for a
recipient Produce
Insert annual
Edit diseases
recipients reports
Search for
disease

Edit clinics
Insert new Search for
Update data
disease hospitals

Fig 4.1: The Red Cross User Task Structure Diagram

4.5.2 The Administrator User
 Administrator
Functionalities

Red Cross user Backup data Reset

Delete data
Functionalities database

The administrator can

perform any task that
are performed by the Backup Restore
Red Cross User Delete donor
database Database

Delete
recipient

Delete a phased
out disease

Fig 4.2 The Administrator Task Structure Diagram

4.5.3 The Global User

 Global User
Functionalities

Search database Login

Login as Red Login as

Cross User Administrator

Search by Search by Search y Year Want to donate

donors recipients blood

Fig 4.3 The Global User Task Structure Diagram

4.6 Tests

The requirement analysis stage involves the design of test cases for the completed system. Test
cases are specifications of inputs to the test and the expected output from the system plus a
statement of what is being tested (Sommerville, 2004) [xx].

4.6.1 Designing of test cases

The test cases designed at this stage are for system testing – testing the integrated system with
all the components and functions in place. It is a black-box approach because the tester may
not know how the system works but wants to know if it works.

The approach followed at this stage can be termed as requirements-based testing – test cases
are designed to test the system requirements. For each requirement, test cases were identified
to demonstrate that the system meets the requirement. It is a general principle in software
engineering that requirements should be testable. This requirements testing is a validation test
because it demonstrates that the system has properly implemented the requirements.
4.7 Web Engineering

Web engineering is the process used to create high quality Web-based systems and applications
(WebApps). Web engineering (WebE) exhibits the fundamental concepts and principles of
software engineering by following a disciplined approach to the development of computer-
based systems, emphasizing the same technical and management activities (Pressman, 2000)
[xx].

The design and production of a software product (such as a web application) involves a set of
activities or a software process (Sommerville, 2004) [xx]. A software process model is an
abstract representation of a software process. Three generic process models usually adopted
in projects are

• The waterfall model – This has distinct project phases, which can be easily
monitored. These phases are requirements specification, software design,
implementation and testing.

• Evolutionary development - An initial system is developed quickly from abstract

specifications. This is later refined with the input of the user to produce a system that
meets the users needs. It is an iterative model. Two refinements of this approach are
the incremental and the spiral models. The incremental model of evolutionary
development delivers software in small but usable “increments”, where each increment
builds on those that have already been delivered. The spiral model couples the iterative
nature of prototyping with the controlled and systematic aspects of the waterfall
model.

• Component-based software engineering - This is based on the existence of a large

number of reusable components and is best suited in an object-oriented environment.
A process model helps address the complexity of software, minimize the risk of project
failure, deal with change during the project and help deliver the software quickly. For
this project two process models were considered: 1. Spiral model 2. A waterfall model.

4.8 A WebE Spiral model

The spiral model shown in Fig 4.4 is suggested by Pressman (2000)[xx]. The process consists
of 6 main stages, outlined below:

1. Formulation: This is an activity in which the goals and objectives of the WebApp are
identified and the scope for the first increment in the process is established.

2. Planning: This stage estimates overall project cost, evaluates risks associated with the
development effort, prepares a detailed development schedule for the initial WebApp
increment and defines a more coarsely granulated schedule for subsequent increments.
3. Analysis: This stage is the requirement analysis stage for the WebApp. Technical
requirements and content items to be used are identified. Graphic design requirements
are also identified.

Fig 4.4: The WebE Spiral Model

4. Engineering: Two parallel set of tasks make up the engineering activity. One set
involves content design and production, which is non-technical work. This involves
gathering text, graphics, and other content to be integrated into the WebApp. At the
same time, a set of technical tasks (Architectural design, Navigation design, and
Interface Design) are carried out.

5. Page generation: This is the construction activity that makes use of automated tools
for WebApp creation and the content is joined with the architectural, navigation and
interface designs to produce executable Webpages in HTML.

6. Customer Evaluation: During this stage, each increment of the WebEprocess is

reviewed. Powell (2002) [xx] presents a waterfall model for web engineering (Fig 5.2).
The advantage of this model is that it helps developers plan most of the work up front.

4. 9 Design Phase

The design involves the production of technical and visual prototypes. This stage has some
non-technical aspects such as gathering of web content. Powell (2002)[xx] points out that
content gathering can be one of the biggest problems in web projects. This clearly is not the
case with this survey application as there is very little content required. For the server side
programming and other technical aspects of the design emphasis will be laid on such design
concepts and principles as effective modularity (high cohesion and low coupling), information
hiding and stepwise elaboration. The goal is to make the system easier to adapt, enhance, test
and use (Pressman, 2000) [xx].

4.9.1 Producing HTML

There are basically 4 methods of producing HTML –

1. Coding by hand using a simple text editor

2. Translation in which content produced in a tool such as note pad is saved as a HTML
document.
3. Using a tagging editor that helps fill in the required tags
4. Using a “What you see is what you get editor” (WYSIWYG) such as MS FrontPage or
Macromedia Dreamweaver©.

All these methods have their advantages and disadvantages.

While coding by hand may be slow and error prone, it does provide great control over markup,
as well as help address bugs and new HTML/XHTML elements immediately. At the other
extreme, “What You See Is What You Get” (WYSIWYG) editors provide visual
representation of a page and require no significant knowledge of HTML or CSS. However
they often generate incorrect or less than optimal markup and tend to encourage fixed size
presentations that do not separate the look and the structure (Powell, 2003) [xx]. Putting all
these into consideration, a tagging editor, HTML-kit© was chosen for this work. While tagging
editors can be slow and require intimate knowledge of HTML and CSS, they provide a great
deal of control and are a lot faster than hand editing.

4.10 Architectural Design

WebApps fall into 4 main structures. They can be linear, grid, hierarchical, or networked (fig
4.5). In practice most web sites are a combination of some of these structures.
Fig. 4-5. Navigational Structures of websites/Web Applications ( Lemay, 2000)

Considering the nature of this web application, a combination of both hierarchical and linear
structures will be adopted. The actual survey web pages will have a linear structure while the
Admin pages will have a more hierarchical nature.

4.11 Database Design

Database design involves the production of a model of the data to be stored in the database.
A data model is a diagram of the database design that documents and communicates how the
database is structured. The database design methodology followed in this project is that
suggested by Connolly et al(2002)[xx]. Connolly presents quite a detailed guide to designing
databases, but not all of those steps may apply here, as this project is not too complex.

The design process is divided into three main stages – conceptual, logical and physical database
design. The purpose of the conceptual database design is to decompose the design into more
manageable tasks, by examining user perspectives of the system. That is, local conceptual data
models are created that are a complete and accurate representation of the enterprise as seen
by different users. Each local conceptual data model is made up of entity types, relationship
types, attributes and their domains, primary keys and integrity constraints. For each user view
identified a local conceptual data model would be built. (Connolly et al, 2002) [xx]. In building
the conceptual data model, a data dictionary is built to identify the major entities in the system.
An entity relationship (ER) diagram is used to visualize the system and represent the user’s
requirements. The ER diagram is used to represent entities and how they relate to one another.
The ER diagram also shows the relationships between the entities, their occurrence
(multiplicities) and attributes. Following the view integration approach, a different data model
(ER diagram) is made for each user

Data Dictionary

Entity Name Description

Donors A person who donates blood

Recipients A person who receives blood

Diseases The diseases which are found in the

infected donated blood

Blood group The blood that is donated by the

donors

Hospital/Clinic Hospitals to which donated blood is

distributed

Staff Red Cross staff

District Districts from which donors and

recipients originate from

Table 4.1: Data Dictionary

4.11.1 Conceptual Database Design

In this stage, a local conceptual data model is built for each identified view in the system. A
local conceptual data model comprises of entity types, relationship types, attributes and their
domains, primary and alternate keys, and integrity constraints. The conceptual data model is
supported by documentation such as a data dictionary.

The entity types are the main objects the users are interested in. Entities have an existence in
their own right. Entity types are identified and their names and description are recorded in a
data dictionary. Care is taking to ensure that all relationships in the users requirements
specification are identified.
An Entity-Relationship diagram is used to represent the relationship between entities. The
multiplicity of each relationship is included. This is because a model that includes
multiplicity constraints gives a better representation of the enterprise. Relationship
descriptions and the multiplicity constraints are recorded in the data dictionary. Each model
is validated to ensure it supported the required transactions.

Entity name Attributes Description Data Size Nulls Multi

Type valued

Donors donorId (PK) Donor identification Text 8 No No

number
-dNames Donor’s names Text 30 No No

-sex Donor’s sex Text 6 No No

- dob Date of birth Date 30 No No

- distId (FK) District of origin Int 3 No No

- doreg Date of registration Date 30 No No

Recipients -rId (PK) Recipient’s identification Text 8 No No

number
-rNames Recipients names Text 30 No No

-sex recipient’s sex Text 6 No No

- dob Date of birth Date 30 No No

- distId (FK) District of origin Int 3 No No

- doreg Date of registration Date 30 No No

Diseases -dId (PK) Disease identification Text 8 No No
number
-dNames Disease names Text 30 No No

-drating Disease rating on how text 20 No No

people are infected from
it

Blood bGroup(PK) Blood group Text 2 No No

donorId (FK) Donor identification Text 8 No No

number
rId (FK) recipient identification Text 8 No No
number
status status of the donated text 15 No No
blood whether infected
or not

Hospital/ hId (PK) Hospital identification text 8 No No

Clinic number
hNames Hospital name text 100 No No

distId (FK) District identification int 3 No No

number

Staff staffId (PK) Staff identification text 8 No No

number
staffNames Staff names text 50 No No

sex Sex sex 6 No No

dob Date of birth date 15 No No

department Department to which the text 100 No No

staff belongs

District distId District number int 3 No No

distName District name text 100 No No

Entity name Multiplicity Relationship Entity Name Multiplicity

Donors 1 Donates Blood 1

Recipients 1 Receives Blood 1

0
Diseases 1 Contained in Blood ..*
1
Blood 1 Donated by Donor ..*
1
Hospital/ 1 Receives Blood ..*
Clinic
1
Staff 1 Registers Donors ..*
1
District 1 Has Recipients ..*

Table 4.2: An extract from the data dictionary showing a description of the relationships
between the entities.

4.11.2 Logical Database Design

The process of logical database design constructs a model of the information used in an
enterprise based on a specific data model, such as the relational model, but independent of a
particular DBMS and other physical considerations (Connolly et al, 2002)[xx]. The logical
database design consists of an ER diagram, a relational schema, and any supporting
documentation for them. In the logical data model, all attributes of entities are primitive.

Producing a logical data model involves normalization. The aim of normalization is to eradicate
certain undesirable characteristics from a database design. It removes data redundancy and
thus prevents update anomalies. Normalization helps increase the clarity of the data model.

Integrity constraints are imposed in order to protect the database from becoming inconsistent.
There are five types of integrity constraints – required data, attribute domain constraints, entity
integrity, referential integrity and enterprise constraints. The resulting relations are validated
using normalization. For this project, producing relations in third normal form (3NF) will
suffice. Non-relational features, such as many-to-many relationships and some one-to-one
relationships, are removed from the conceptual data model. The design is also reviewed to
make sure it meets all the transaction requirements.
 Donors Staff

PK donorId PK staffId 1..*

staffNames
dNames sex
sex
dob
dob
department
FK distId
doreg

registers

Recipient
Diseases PK rId
rNames
PK dId sex
dNames dob
drating FK distId
doreg

Hospital Blood

PK hId (PK) PK bGroup

hNames FK donorId

FK distId FK rId

status

District

PK distId
distName

Fig. 4.6: The ER diagram

1..1
 1..*

1..*

1..1 1..1

4.11.3 Physical Database Design

Physical database design translates the logical data model into a set of SQL statements that
define the database for a particular database system. In other words, it is the process of
producing a description of the implementation of the database on secondary storage. It
describes the base relations and the storage structures and access methods used to access the
data effectively, along with associated integrity constraints and security measures. The target
DBMS in this case is MySQL.

The following translations occur:

1. Entities become tables in MySQL.

2. Attributes become columns in the MySQL database.
3. Relationships between entities are modeled as foreign keys.
Chapter 5

5.0 IMPLEMENTATION AND TESTING