PROJECT REPORT

RECORDS MANAGEMENT SYSTEM FOR MBARARA

HOSPITAL
(A Case Study of the Maternal and Child Health Section
[MCH])

By

ACHENG DORIS ODIT

2008/BIT/033/PS

INSTITUTE OF COMPUTER SCIENCE

Email: doradit4t@yahoo.co.uk Tel: +256 773068417 / +256 704197062

A Project Report Submitted to the Institute of Computer Science for the Study Leading to a Project in
Partial Fulfillment of the
Requirements for the Award of the Degree of Bachelor of
Information Techology at Mbarara University of Science and Technology.

Supervisor
Mr. Richard Kimera
Institute of Computer Science, Mbarara University of Science and Technology
Email: rkimera@must.ac.ug Tel +256-774437989.

April, 2011.
DECLARATION

“I Acheng Doris Odit hereby declare that the information in this dissertation embodies my original
work done during this project submission in partial fulfillment of a Bachelor’s Degree in
Information Technology at Mbarara University of Science and Technology. This dissertation has
never been published or submitted to any other institution of higher learning for any academic
award to the best of my knowledge.”

Signature……………………… Date…………………………….

Acheng Doris Odit

(STUDENT)

SUPERVISOR‟S APPROVAL

This is to certify that Acheng Doris Odit, a third year student of Mbarara University of Science and
Technology pursuing a Bachelor’s degree in Information Technology took part in the project work
for the partial fulfillment of the requirements of this degree under my supervision.

Signature……………………... Date……………………..……..

Mr. Kimera Richard

(SUPERVISOR)

i
DEDICATION

I wish dedicate this piece of work to my father Francis Joseph Odit, for being my inspiration, to my
mother Margaret K. Odit , for being my pillar of strength and to my siblings Dennis Odit, Patrick
Obong and Salome Akite for their unconditional support.

ii
AKNOWLEDGEMENTS

This report is greatly indebted to a number of people, without whose ceaseless cooperation,
guidance, and encouragement and all manner of input this would not have been possible.

Sincere gratitude to my project supervisor, Mr. Kimera Richard, for his time, intellectual input,
constructive criticism and suggestions offered while undertaking the project. To my colleagues;
Nahabwe Isaac, Akankwatsa Jenninah, Nahwanja Ritah and Agaba Babra for their priceless
intellectual input.

I also wish to appreciate the efforts of all those without whose limitless and unconditional support,
this undertaking would not have come to be. Sincere Gratitude to Mary Moran, to, my parents
Francis and Margaret Odit for their financial and moral support, and to my siblings, Dennis Odit,
Patrick Obong, and Salome Akite.

Most of all, my deepest and sincerest gratitude goes to the Almighty for bringing me this far.

iii
TABLE OF CONTENTS
DECLARATION ...................................................................................................................... I
SUPERVISOR‟S APPROVAL................................................................................................... I
DEDICATION........................................................................................................................ II
AKNOWLEDGEMENTS ...................................................................................................... III
TABLE OF FIGURES ........................................................................................................... VI
LIST OF TABLES................................................................................................................. VII
ABBREVIATIONS & ACRONYMS .................................................................................. VIII
ABSTRACT ............................................................................................................................ IX
CHAPTER ONE..................................................................................................................... 10
1.1 INTRODUCTION......................................................................................................................................................................... 10
1.2 BACKGROUND ............................................................................................................................................................................ 12
1.3 STATEMENT OF THE PROBLEM ............................................................................................................................................ 13
1.4 OBJECTIVES ................................................................................................................................................................................ 13
1.4.1 General Objective.............................................................................................................................................................. 13
1.4.2 Specific Objectives ............................................................................................................................................................ 13
1.5 SIGNIFICANCE ........................................................................................................................................................................... 14
1.6 SCOPE ........................................................................................................................................................................................... 16
1.7 ORGANIZATIONAL STRUCTURE ........................................................................................................................................... 17
CHAPTER TWO- LITERATURE REVIEW ........................................................................ 18
1.1 OVERVIEW................................................................................................................................................................................... 18
1.2 RECORDS ..................................................................................................................................................................................... 18
1.3 ELECTRONIC RECORDS .......................................................................................................................................................... 19
1.4 RECORD FUNCTIONS............................................................................................................................................................... 19
1.5 RECORDS MANAGEMENT....................................................................................................................................................... 20
1.6 RECORDKEEPING SYSTEMS ................................................................................................................................................... 21
1.7 DATABASES AS RECORDKEEPING SYSTEMS ....................................................................................................................... 21
1.8 RECORD MANAGEMENT SYSTEMS- WHY NEEDED? ...................................................................................................... 21
1.9 CONCLUSION ............................................................................................................................................................................. 22

CHAPTER THREE- METHODOLOGY ............................................................................. 23

3.1 METHODOLOGY........................................................................................................................................................................ 23
3.2 SYSTEM DEVELOPMENT METHODOLOGY........................................................................................................................ 23
3.2.1 Extreme Programming (XP) ........................................................................................................................................... 23
3.2.2 Extreme programming Features ..................................................................................................................................... 24
3.3.3 Illustration of Extreme Programming System Development Process ..................................................................... 24
3.2.4 System Development Lifecycle ....................................................................................................................................... 25
3.2.5 Why Extreme Programming (Advantages) ................................................................................................................... 27
3.3 ASSUMPTIONS MADE BY THE RESEARCHER .................................................................................................................... 28

CHAPTER FOUR- SYSTEM DESCRIPTION ..................................................................... 29

4.1 SYSTEM OVERVIEW .................................................................................................................................................................. 29
4.1.2 Accessing the System ........................................................................................................................................................ 29
4.1.3. User Privileges ................................................................................................................................................................... 30

iv
 4.1.4 Pseudo Codes ..................................................................................................................................................................... 31
4.2. SYSTEM REQUIREMENTS ...................................................................................................................................................... 33
4.2.1 Non-functional Requirements......................................................................................................................................... 33
4.2.2 Hardware Specifications ................................................................................................................................................... 33
4.2.3 Software Specifications ..................................................................................................................................................... 33
4.4 SYSTEMS ARCHITECTURE ...................................................................................................................................................... 34
4.4.1 Diagram Showing the System Architecture .................................................................................................................. 34
4.4.2 High-Level Architecture Diagram of the main components ..................................................................................... 35
4.4.3 Logical Database Design .................................................................................................................................................. 35
4.5 DATA REQUIREMENTS ........................................................................................................................................................... 36
4.6 DATABASE (PHYSICAL DESIGN) ........................................................................................................................................... 37
4.6.1 Physical Database Design ................................................................................................................................................ 37
4.6.2 Database Tables ................................................................................................................................................................. 37
4.6.3 Data relationships .............................................................................................................................................................. 39
4.7 ER DIAGRAMS AND DFDS ....................................................................................................................................................... 40
4.7.1 ERD (Entity Relationship Diagram) .............................................................................................................................. 40
4.7.2 DFD (data flow diagram) ................................................................................................................................................. 41
4.8 SYSTEM FLOW CHART................................................................................................................................................................ 41
4.9 HIPO-HIERARCHICAL INPUT PROCESS AND OUTPUT........................................................................................................ 43
4.9 DATA INPUTS (SYSTEM FORMS). ................................................................................................................................................ 1
4.9.1 Login Form ......................................................................................................................................................................... 1
4.9.2 User Registration Form ...................................................................................................................................................... 2
4.9.3 Data Entry and Manipulation Forms ............................................................................................................................... 2
4.10 DATA OUTPUTS .......................................................................................................................................................................... 3
4.10.1 Data Storage Interface ...................................................................................................................................................... 3
4.10.2 Data Reports ...................................................................................................................................................................... 4
4.10 IMPLEMENTATION AND TESTING ....................................................................................................................................... 5
4.10.1 Implementation ................................................................................................................................................................. 5
4.10.2 Testing: ................................................................................................................................................................................ 5
4.10.3 System Documentations .................................................................................................................................................. 6

CHAPTER FIVE: EVALUATIONS & CONCLUSIONS .......................................................7

5.1 EVALUATIONS .............................................................................................................................................................................. 7
5.2 LIMITATIONS OF THE SYSTEM ............................................................................................................................................... 8
5.6 PROBLEMS ENCOUNTERED .................................................................................................................................................... 9
5.7 RECOMMENDATIONS/FUTURE RESEARCH ..................................................................................................................... 10
5.8 CONCLUSION ............................................................................................................................................................................. 11

REFERENCES & BIBLIOGRAPHY .................................................................................... 12

APPENDIX I- PROJECT TIMELINE ................................................................................. 13
APPENDIX II- PROJECT BUDGET.................................................................................... 14
APPENDIX III- IMPLEMENTATION CODES ................................................................. 15
CONNECTING THE INTERFACE TO THE DATABASE.............................................................................................................. 15
Main Connection Code .............................................................................................................................................................. 15
Interface – to-database connection Code ............................................................................................................................... 15
APPENDIX IV- FINAL SUBMISSION LETTER................................................................ 16

v
TABLE OF FIGURES
FIGURE 1- ORGANISATIONAL STRUCTURE OF MBARARA REGIONAL REFFERAL HOSPITAL ................17
FIGURE 2: EXTREME PROGRAMMING LIFECYCLE.......................................................................................24
FIGURE 3: SYSTEM ARCHITECTURE ...............................................................................................................34
FIGURE 4: HIGH LEVEL ARCHITECTURAL DIAGRAM OF MAIN COMPONENTS .........................................35
FIGURE 5 : LOGICAL DESIGN ..........................................................................................................................36
FIGURE 6: ENTITY RELATIONSHIP DIAGRAM ..............................................................................................40
FIGURE 7: DATA FLOW DIAGRAM .................................................................................................................41
FIGURE 8: SYSTEM FLOW CHART ...................................................................................................................43
FIGURE 9: HIPPO CHART.................................................................................................................................43
FIGURE 10: LOGIN FORM .................................................................................................................................. 1
FIGURE 11: USER REGISTRATION FORM.......................................................................................................... 2
FIGURE 12: DATA ENTRY FORM FOR CHILD DETAILS ................................................................................. 2
FIGURE 13: DATA STORAGE INTERFACE FOR CHILD DETAILS ................................................................... 3
FIGURE 14: FPDF REPORT FOR CHILD DETAILS RECORDS............................................................................ 4

vi
LIST OF TABLES
TABLE 1: LOGIN TABLE ..................................................................................................................................37
TABLE 2 : CHILD DETAILS TABLE..................................................................................................................38
TABLE 3: CHILD DEVELOPMENT TABLE ......................................................................................................38
TABLE 4: IMMUNIZATION TABLE...................................................................................................................38

vii
ABBREVIATIONS & ACRONYMS

ADMIN Administrator
FAQ Frequently Asked Questions
GUI Graphical User Interface
HTML Hyper Text Markup Language
ICA International Council on Archives
ICT Information and Communication Technology
IS Information System
Lab Laboratory
LAN Local Area Network
MCH Maternal and Child Issues
MIS Management Information System
PHP Hypertext Pre-Processor
RAM Random Access Memory
RM Records Management
RMS Records Management System
SQL Structured Query Language
XP Extreme Programming

viii
ABSTRACT

“The purpose and essence of any Records Management system is the right information in the right
place in the right order, at the right time for the right person at the lowest cost.”- (Baje 1998). For
this feat to be achieved, an integrated, highly efficient and effective records management system is
needed. With this in mind, a careful analysis of the records management system being utilized by the
Mbarara Regional Referral Hospital MCH section was conducted. The findings showed that the
system was highly inefficient- especially as far as retrieval of archival patient information was
concerned. This analysis established the need for a Records Management System (RMS) that would
facilitate effective and reliable records management through automated processes and served as the
basis for the research leading to the development of such an RMS.

The Major objective of the project was to design and develop an RMS that would automate patient
records Management and give direct benefit for the MCH section in terms of fast information
retrieval, enhanced decision-making (patient diagnosis) whilst avoiding any confusion that would
jeopardize the quality of patient care. The RMS was designed as a client/server and web-based
system and implemented using open source solutions that include MySQL as the database, and
PHP, HTML and JavaScript as the programming languages.

The system was developed using Extreme Programming methodology. An extensive evaluation of
the project determined that the project achieved many of its predefined objectives however, the
major limitation of the project was the scope covered. From a proper analysis and assessment of the
designed system, it can be concluded that the system developed is an efficient, usable and reliable
records management system.

ix
CHAPTER ONE

1.1 Introduction

Hospitals deal with the life and health of their patients. Good medical care relies on well-trained
doctors and nurses and on high quality facilities and equipment. Good medical care also relies on
good record keeping. Without accurate, comprehensive and up to date and accessible patient notes,
medical personnel may not offer the best treatment or may in fact misdiagnose the condition, which
can have serious consequences. Associated records, such as x-rays, specimens, drug records and
patient registers, must also be well cared for if the patient is to be protected. Good records care also
ensures the hospitals administration runs smoothly; unneeded records are transferred or destroyed
regularly, keeping storage areas clear and accessible; and key records can be found quickly, saving
time and resources. Records also provide evidence of the hospital’s accountability for its actions and
they form a key source of data for medical research, statistical reports and health information
systems.

Managing Hospital Records addresses the specific issues involved in managing clinical and non-
clinical hospital records. A comprehensive records management system in a hospital helps to ensure
that staff have access both to clinical information and to administrative records on a wide range of
issues, including policy, precedents, legal rights and obligations, personnel, finance, buildings,
equipment and resources.

Records Management refers to an on-going process of managing the records in a media neutral basis
in accordance with approved policies, procedures and schedules. Records Management as a
discipline defines and applies business rules related to the creation, protection, retrieval and
disposition of an organization as records over time. Retention schedules are the cornerstone of a
successful Records Management process.

Records Management as a discipline involves records keeping. Record keeping is an important

aspect of every organizations/ institution’s day to day operations. There cannot be a records

10
management system without records and neither can there be efficient record keeping without a
good records management system. Therefore, record keeping is the Systematic procedure by which
the records of an organization are created, captured, maintained, and disposed of. This system also
ensures their preservation for evidential purposes, accurate and efficient updating, timely availability,
and control of access to them only by authorized personnel. The record in question here refers to
any item or collection of data.

A management information system (MIS) is a system or process that provides the information
necessary to manage an organization effectively. An MIS should be able to influence decision
making. A records management system while incorporating aspects of a MIS should be able to
influence decision making in an institution/ organization

An information system (IS) is any combination of information technology and people's activities
using that technology to support operations, management, and decision-making. In a very broad
sense, the term information system is frequently used to refer to the interaction between people,
algorithmic processes, data and technology. In this sense, the term is used to refer not only to the
information and communication technology (ICT) an organization uses, but also to the way in
which people interact with this technology in support of business processes and is therefore relevant
to the development of a records management system.

A management system is a proven framework for managing and continually improving an

organization’s policies, procedures and processes.

Therefore a good and efficient records management system should be able to incorporate specific
aspects of the systems mentioned above in order to provide and efficient means of records storage
and management.

11
1.2 Background
Mbarara Hospital is a public hospital, funded by the Uganda Ministry of Health which was
established in 1940. It is affiliated with the medical school of Mbarara University of Science and
Technology, one of the four medical schools in Uganda. It is the referral hospital for the districts of
Mbarara, Bushenyi, Ntungamo, Kiruhura, Ibanda and Isingiro. The hospital also serves as the
teaching hospital of Mbarara University. The hospital is staffed by medical students and residents. It
is one of the thirteen Regional Referral Hospitals in Uganda. Its bed capacity is 300.

One of the most vital departments in the hospital is the records keeping department. The
department was started at the inception of the Hospital in 1940. The department however only has
archives dating back to 1986 owing to the fact that records that preceded that year were destroyed
during the political instability that Uganda was plunged in at the time.

The department is divided into a number of sections. One section is responsible for collecting and
storing patient’s medical information, another for sundries and drugs and another section is
responsible for Human Resources and financial records. The department however liaises with the
different clinics and departments in the hospital which reserve the semi-autonomous responsibility
of maintaining their own patient records. One such department is the Maternal and Child Health
Clinic (MCH).

The MCH section in relation child immunization provides Immunization services for Children. The
immunization process under MCH is carried out in phases and is progressive- This requires a
meticulous recording system that is able to keep systematic track of each individual’s progress. In
this Section, various operational functions are done such as; Recording information about the
Patients that come, Keeping record of the Immunization provided to children/patients. and
Keeping information about various diseases and vaccinations available. Like all other records in the
hospital, the records are paper based

In analyzing the current records management system at the MCU, a lot of the records are stored in
paper files. In the section, Information about Patients is done by just writing the Patients name, age
and gender. Whenever the Patient comes up his information is stored freshly. Immunization records
of children are maintained in pre-formatted sheets, which are kept in a file.

12
All this work is done manually by a few nurses and other operational staff on paper files. This means
that all this paper files need to be handled and taken care of with utmost care. Unfortunately, this is
rarely the case. Doctors and nurses have to remember various medicines available for diagnosis and
sometimes miss better alternatives as they can’t remember them at that time. As regards records
storage, the records are stored in cramped record rooms. This situation is worsened by the massive
number of children the section receives each day. The current recording system in use is therefore
inefficient and time consuming.

1.3 Statement of the Problem

The system design and development was undertaken in order to eliminate the problem of
redundant, erroneous and incomplete data that was escalating the inefficiencies in data retrieval.
These limitations were mainly caused by the fact that data, under the previous manual recording
system was entered into books and paper files and was later stored in overcrowded storage rooms
that made retrieval of archival records close to impossible.

1.4 Objectives

1.4.1 General Objective

To design and develop a records management system for Mbarara hospital that would enable faster
and more efficient storage, retrieval and updating of hospital records.

1.4.2 Specific Objectives

The project’s specific objectives were;
 To carry out a feasibility study for the possibility of developing a records management
system for the MCH section of Mbarara Hospital
 To design and develop a records management system for the MCH section of Mbarara
Hospital
 To test and validate the records management system for the MCH section of Mbarara
Hospital
 To implement the records management system for the MCH section of Mbarara Hospital

13
1.5 Significance

In designing and developing the records management system, it was hoped that the project would
have the following impact on all stakeholders.

The developed records management system was deemed as necessary for the automation and
streamlining of the clinic’s workflow thus minimizing medical errors. The system, it was hoped,
would enable Hospital administrators to significantly improve the operational control and thus
streamline operations.

It would lead to faster service delivery with faster record insertion and retrieval thus reducing the
time spent by staff filling out forms. This would minimize on the time consumed in the input and
retrieval of records, freeing resources for more critical tasks and thus providing an opportunity to
the MCH section to enhance their patient care.

It would also reclaim office space used for inefficient storage. A lot of space is taken up in storing
the paper-based records and this space was saved up by the implementation of the computer-based
records management system.

It would also secure the vital medical records and information in case of any disruption or disaster.
This is because the system was able to be backed easily and efficiently thus ensuring a longer records
life.

It would also save the hospital section on badly needed human resources. This is because the
records management system would require less number of Staff to cater more patients in same time
or even less. Therefore, this presents an opportunity for the hospital administration to re-deploy the
personnel that are currently working in the records desk to other suitable locations- where they are
needed more. The senior Doctors and nurses would also be able to spend their precious time more
in clinical activities than to put in clerical activities otherwise.

The records management system would also prevent costly paper accumulation with systematic
record disposal.

14
Accounting sometimes becomes needlessly complex. This records management system would
eliminate any such complexity, since the retrieval of information through its MIS would come
virtually on the tip of the user’s fingers.

It would also improve the response time to the demands of patient care because it would automate
the process of collecting, collaborating and retrieving patient information.

The records management system would provide the stakeholders the ability to request and receive
any data in the system in the most efficient manner with confidence of a high level of accuracy.

The development of a database with additional value added functionality would allow the hospital to
manage records in the most cost-effective manner. Serving all of the clinics, wards and offices, this
new functionality would not only result in cost-savings, time savings and space savings, but also
would greatly improve on records management at the hospital.

The development of the records management system would also lead to better access of to
operational data. This would provide better control over the various processes and also facilitate
better decision making.

The services the system would offer would also; Save the Hospital a lot of space by reducing
storage needs for records; Save hundreds of staff-time hours by providing quick and easy access to
important information; Save the Hospital resources used in the destruction of unnecessary records

15
1.6 Scope

The scope provides for the boundary of the research in terms of depth of investigation, content, and
methodology, geographical and theoretical coverage.

The system was exclusively designed and developed for the Mbarara Hospital records Management
Department in general and the Maternal and Child Health (MCH) records section in particular. The
MCH records section is solely responsible for keeping medical -immunization and related records
for both pregnant women and infants under the age of 5 and keeping track of this information.

The records management system was designed in such a way that makes it possible to access it
through any web browser programme. This serves as the user interface. The web browser supported
interface created is dynamic and as a result backed by a database system that enables users to have
the ability to input, access, manipulate and delete data from the database

HTML (Hyper Text Markup Language) and CSS (Cascading Style Sheets) were used as the languages
of preference for the design of user interfaces. In the interfaces, Java script was used as the client
side validation tool.

PHP was used as a scripting language for linking the interfaces to the SQL database(s). PHP is a
server-side scripting language that enables one the ability to insert into a web interface instructions
that web server software would execute before sending a response to the web browser [11]

SQL was used as the programming language for developing the database. SQL is the de facto
standard language used to manipulate and retrieve data from these relational databases.

Macromedia Dream weaver 8 was used as the editing tool for creating interfaces using HTML , CSS,
Javascript and PHP scripts. Macromedia Dreamweaver 8 is a professional HTML editor for
designing, coding, and developing websites, web pages, and web applications. Dreamweaver
supports the creation of dynamic, database-driven web applications using server technologies such
as CFML, ASP.NET, ASP, JSP, and PHP.

16
XAMPP an integrated database creation software tool was used as the software for creating the
MYSQL database(s)

The records management system includes the following elements;

A content analysis that describes and categorizes content in the enterprise that can become
records, that provides source locations and that describes how the content would move to the
records management application. A method for collecting records that are no longer active from
all record sources and truncating them; A method for auditing records while they are active; A
method for capturing records' metadata and audit histories and for maintaining them; A system
for monitoring and reporting on the handling of records to ensure that employees are filing,
accessing, and managing them according to defined policies and processes.

1.7 Organizational Structure

Board

Administration

Information Therapeutic Diagnostic Support

Services Services Services Services

Admissions PT, OT Med. Lab Central Supply

Billing, etc. Med. Speech/Lang. Radiology Biomedical
Records Resp. Therapy Nuclear Med ER Housekeeping
Computer Info. Pharmacy Cardiology Maintenance
Health Ed. Nursing Dietary Neurology Dietary
Human Resource. Transportation

Figure 1- Organisational Structure of Mbarara Regional Refferal Hospital

17
CHAPTER TWO- LITERATURE REVIEW

1.1 Overview

In order to understand the concepts associated with records management and or computer based
records management systems, it is imperative to examine and analyze published material from
experts regarding the field. The purpose of this review is to analyze and examine and obtain
experience as regards the creation and archival processing of electronic records. The review is based
on an exhaustive assessment of the literature on computerized electronic management and electronic
records, and contains an overview of the main concepts associated with the creation of an electronic
records management system from the perspective of published experts.

1.2 Records

A record is recorded information produced or received in the initiation, conduct or completion of

an institutional or individual activity and that comprises content, context and structure sufficient to
provide evidence of the activity regardless of the form or medium.

According to the National Archives and Records Administration (NARA) records include, “… all
books, papers, maps, photographs, machine-readable materials, or other documentary materials,
regardless of physical form or characteristics, made or received ... or in connection with the
transaction of public business and preserved or appropriate for preservation by that agency or its
legitimate successor as evidence of the organization, functions, policies, decisions, procedures,
operations, or other activities of the Government or because of the informational value of the data
in them.”

The International Council on Archives (ICA) Committee on Electronic Records defines a record as
"recorded information produced or received in the initiation, conduct or completion of an
institutional or individual activity and that comprises content, context and structure sufficient to
provide evidence of the activity." The key word in these definitions is evidence. Put simply, a record
can be defined as "evidence of an even.
18
The “record” is evidence of the occurrence of a particular transaction. With a paper “record” the
content (i.e. the writing on the page) the media (i.e. the paper) the structure (i.e. how the writing is
arranged on the page) and the context (i.e. the interrelationship between the item, the file, and the
business in which the transaction is taking place) are all either physically linked or self-evident to the
human eye.

Records consist of content, structure and context. The three qualities must be captured and
preserved together in order to meet the requirements for “recordness”. The content must be put
together with data about structure and context. We may call these data “metadata” (i.e. data about
data). If the metadata are lost the item loses its “recordness” (i.e. evidential value) and becomes
“business un-acceptable” (useless as evidence). In an article “Towards A Reference Model for Business
Acceptable Communications”, David Bearman describes a record as “a metadata encapsulated object”

1.3 Electronic Records

The distinctive feature of electronic records is that the content is recorded on a medium and in
symbols (binary digits) that need a computer or similar technology to read and understand.

The concepts of "record" and "electronic record" are linked to the concept of the "archival
function" which was defined as that group of related activities contributing to, and necessary for
accomplishing the goals of identifying, safeguarding and preserving archival records, and ensuring
that such records are accessible and understandable.

1.4 Record Functions

As an organizational resource, records serve many functions in the operation of an establishment

such as a university library. Records represent all documentary materials such as correspondence,
forms, reports, drawings, maps, photographs, and appear in various physical forms, e.g., paper,
cards, microfilm, tape, CD-ROM, etc., which can be preserved for short or long periods.

19
Records originating from functions or processes have always been kept together in some kind of
system, i.e., a “recordkeeping system”. Such systems are functioning, or have once functioned, as a
tool for those carrying out a process and its transactions.

1.5 Records Management

The ISO 15489: 2001 standard defines records management as "The field of management
responsible for the efficient and systematic control of the creation, receipt, maintenance, use and
disposition of records, including the processes for capturing and maintaining evidence of and
information about business activities and transactions in the form of records".

As records management develops, it has also incorporated principles integral to information science
as "the means of processing information for optimum accessibility and usability, concerned with the
origination, collection, organization, storage, retrieval, interpretation, transmissions, transformation
and use of information" (Vakkari and Cronin, 1992). Such principles are adopted by records
managers in seeking to enhance the access and use of records.

Stressing the use of technology in records management, McDonald (1995) opines that "in
developing record keeping solutions, it is necessary to understand the evolution that is taking place
in the use of technology." The application of Information and Communication Technology (ICT) to
the management of records therefore, would go a long way in making such records accessible and
usable.

Luciana Duranti (1996) in an attempt to explain the concept of records management and its
relationship to record keeping systems, defines records management as the “management over time,
from the creator's perspective and for its purposes, of the creator's records, of the means used to
control their creation (e.g. classification, registration, and retrieval instruments), and of the human,
technological, and space resources necessary to their handling, maintenance, and preservation.” In
his definition, Duranti relates records management to Record systems. He alludes to the fact that
Records Management and Records Management Systems have to co-exist.

20
1.6 Recordkeeping Systems

Recordkeeping systems in the electronic, as well as in the paper, world are designed for the use of
operational staff in current office operations. In the paper world, it is the archivist's role to preserve
this tool undisturbed for future users’ organization – (principe de l'ordre primitif)

Luciana Duranti(1996) defines a record keeping system as comprising a set of internally consistent
rules that govern the making, receiving, setting aside, and handling of active and semi-active records
in the usual and ordinary course of the creator's affairs, and the tools and mechanisms used to
implement them. According to Duranti “recordkeeping is “keeping record of action”: as such, it is
the presupposition for the existence and the first object of records management.

Recordkeeping systems have concrete boundaries and definable properties, and they are critical to
the preservation of the records’ origin and evidential value. In the paper world, recordkeeping
systems range from a simple filing system to a central registry.

The purpose and essence of any record system is the right information in the right place in the right
order, at the right time for the right person at the lowest cost. For this feat to be achieved, an
integrated records management programme is needed (Baje, 1998).

1.7 Databases as Recordkeeping Systems

Databases are being used as the records management systems of preference because of their
informational value. Such databases are created for their informational value -- as an information
resource. Statistical databases are good examples of this kind of database. Terry Cook and Eldon
Frost have described the first generation of databases transferred to the Canadian National Archives
as mainly consisting of statistical and survey files.

1.8 Record Management Systems- Why Needed?

According to Professor Angelika Menne-Haritz, director of the archive school in Marburg,

Germany, electronic office systems enable us to see clearer. “It is no longer the fear of being
inundated by enormous amounts of paper, but awareness that nothing was left for appraisal, if we
do not formulate fundamental principles, which make us think about a theory to guide everyday
decisions.”

21
He continues to say that experience with electronic records sharpens our perception. Thus, the aim
of (records management systems), is to make records eloquent and to facilitate research.

In attempting to define a record Menne-Haritz stated: Records are created because they are needed
by those who create them, not as information collection but as intellectual working tools for the
steering of cooperative decision-making processes. And records are therefore reliable. The better
they have served their primary purposes of initiating and controlling cooperative, purposeful,
intellectual work, the more they are authentic and trustworthy in elucidating those processes for
secondary purposes, be it evidential or informational.

According to ARMA International, a not-for-profit professional association and authority on

managing records and information, records management systems are important because Records are
information assets and hold value for the organization. Organizations have a duty to all stakeholders
to manage them effectively in order to maximize profit, control cost, and ensure the vitality of the
organization. Effective records management ensures that the information needed is retrievable,
authentic, and accurate.

1.9 Conclusion

In this “information age”, it is therefore essential that records management be done with the utmost
efficiency and accuracy. This is the point at which records management is integrated with computer
science in order to develop a computer based records management system. The conclusion is that
efficient and comprehensive records keeping is as good as guaranteed when the art of record
keeping is simulated and integrated into a computerized records management system.

22
CHAPTER THREE- METHODOLOGY

3.1 Methodology

Methodology is a term used to describe a process, technique or manner in which an action is

performed. Under the development a system, a methodology refers to the process that was taken to
ensure that a system is effectively and efficiently developed

In designing the records management system for Mbarara Hospital, the following system
development methodology was used.

3.2 System Development Methodology

The systems development methodology is used to describe the process for building systems,
intended to develop systems in a very deliberate, structured and methodical way.

Extreme programming was used as the methodology of choice in developing a records management
system for Mbarara Hospital.

3.2.1 Extreme Programming (XP)

Extreme programming is a software development methodology which is intended to improve
software quality and responsiveness to changing customer requirements. As a type of agile software
development, it advocates frequent "releases" in short development cycles. This is intended to
improve productivity and introduce checkpoints where new customer requirements can be adopted.
The main goal of XP is to lower the cost of change in software requirements.

Extreme programming is carried out in the following manner; the phases are carried out in
extremely small steps. First, one writes automated tests, to provide concrete goals for development.
Next is coding (by a pair of programmers). Design and architecture emerge out of refactoring, and
come after coding. Design is done by the same people who do the coding. The incomplete but
functional system is deployed or demonstrated for the users. At this point, the practitioners start
again on writing tests for the next most important part of the system.
23
3.2.2 Extreme programming Features

Extreme programming has the following features/ core practices

 Fine scale feedback which involves, Test driven development, Planning game, Whole team
and Pair programming
 Continuous process rather than batch. This also involves, Continuous Integration, Design
Improvement ,and Small Releases
 Shared understanding including Simple design, System metaphor, Collective code ownership
and Coding standards or coding conventions
 And Programmer welfare that involves Sustainable pace that is forty hour week.

3.3.3 Illustration of Extreme Programming System Development Process

Figure 2: Extreme Programming Lifecycle

24
 3.2.4 System Development Lifecycle

In developing the Mbarara Hospital records Management System, the following steps were taken;

i. Planning
A project plan was developed as well as other planning documents. It provided the basis for
acquiring the resources needed to achieve a solution. This phase ensured that the problem
solved was the one that needed to be solved and that the initial description was complete and
consistent.

Under the planning phase of the project, a project timeline, work plan and Budget were
developed. (Please refer to appendices). Under this phase;
 The project team was formed and a project leader appointed
 The system flowcharts were prepared
 The characteristics of the proposed system were defined and identified

ii. Analysis
At this point, the system in place was analyzed to determine where the problem was in an
attempt to fix the system. This step involved breaking down the system in different pieces to
analyze the situation, analyzing project goals, breaking down what needed to be created and
attempting to engage users so that definite requirements could be defined.

Under analysis, Requirement gathering is the most crucial aspect as many times communication
gaps arise in this phase and this leads to validation errors and bugs in the software program.
Therefore, the following techniques were used to gather information

Under analysis , the following data collection techniques were used.

25
a) Semi-structured interviews

Semi-structured interviews are conducted with a fairly open framework which allow for focused,
conversational, two-way communication. They can be used both to give and receive information.
In the process of developing the system, the development team interviewed the data entrants at
MCH inorder to identify the processes, obtain specific quantitative and qualitative information
from the interviewees , obtain general information relevant to data entry , and to Gain a range of
insights on the process of records management.

This tool was used as a data collection methodology of choice because it is; less intrusive to those
being interviewed as the semi-structured interview encourages two-way communication..

b) Direct (Reactive) Observation

Direct Observation is a method in which a researcher observes and records behavior / events /
activities / tasks / duties while something is happening. This was used in correspondence to
interviewing in order to gain a more holistic view of the Hospital’s current records management
system

Direct observation was used as a research methodology of choice in designing the records
management system for Mbarara Hospital because; Observations give additional, more accurate
information on behavior of people than interviews or questionnaires. They can also check on the
information collected through interviews especially on sensitive topics.

c) Using available information

This is a data collection method that involves the process of examining and evaluating already
existent literature material to obtain facts and data regarding a specific subject. Locating these
sources and retrieving the information can help in data collection.

In the development of the records management system, this research methodology was mainly
used in the analysis and design phases of the system development process. This is because it
permitted the researcher(s) to analyze changes in trends.

26
 iii. Design
In systems design the design functions and operations was described in detail, including screen
layouts, business rules, process diagrams and other documentation. The output of this stage
described the new system as a collection of modules or subsystems. The design stage took as its
initial input the requirements identified in the approved requirements document. For each
requirement, a set of one or more design elements was produced as a result of interviews,
workshops, and/or prototype efforts.

Design elements described the desired system features in detail, and generally included functional
hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams,
pseudo code, and a complete entity-relationship diagram with a full data dictionary.

iv. Implementation phase

Here all the iterations were brought together and integrated to make one working system. Modular
and subsystem programming code was accomplished during this stage. Unit testing and module
testing was done in this stage

3.2.5 Why Extreme Programming (Advantages)

Extreme programming was used as the system development methodology of choice in developing a
records management system for Mbarara Hopital because it has various advantages as explained
below;

Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal
partners in a collaborative team. Extreme Programming implements a simple, yet effective
environment enabling teams to become highly productive. The team self-organizes around the
problem to solve it as efficiently as possible.

Extreme Programming improves a software project in five essential ways; communication,

simplicity, feedback, respect, and courage. Extreme Programmers constantly communicate with their
customers and fellow programmers. They keep their design simple and clean. They get feedback by
testing their software starting on day one. They deliver the system to the customers as early as
possible and implement changes as suggested. Every small success deepens their respect for the
unique contributions of each and every team member.

27
3.3 Assumptions Made by the Researcher

The following basic assumptions were made while designing the system

With regards to the operation of the system, it was assumed;

 That the system shall be used ONLY by the MCH staff of Mbarara Hospital.
 That every system user shall have a unique username and password which shall be assigned
by the administrator.
 That the system shall be used to add, update and delete MCH records
 That the normal user shall not have the right to delete information from the system
 That the operating system environment shall have a client-server architecture

With regards to the intended users of the system, the following suppositions were made
 That the end user shall have a basic knowledge of working with computers
 That the end user shall have a basic knowledge of some rudimentary medical terms such as
names of vaccines
 That the end user shall have a basic knowledge of the English language which is used in the
GUI and associated documentation.

28
CHAPTER FOUR- SYSTEM DESCRIPTION

4.1 System Overview

The System encompasses all the activities associated with the recording of child immunization and
development progress all of which are integrated in the Hospital Records Management System.
The main functionalities available in this system are
 Maintaining child details records
 Maintaining patients immunization records
 Maintaining child development records

All these features include the ability to create, update (edit), retrieve through search results and
truncate obsolete records. It also contains a report generation system that can be saved in a pdf file
format

The system works in the following manner,

4.1.2 Accessing the System

A user starts the process by logging into the system by means of a valid username / password
combination. A new user has to first be registered in order to obtain access to the system.

Users with administrative privileges reserve the exclusive authorization to register new system users.
A default administrative account has been provided by the system designers in order to enable the
administrator to access exclusive privileges such as registering new users with either limited (normal
user) or unlimited (administrative) privileges.

During the process of user registration, all users are issued with a unique user name and password
combination as well as a specific user type (limited or unlimited). This combination is then used by
the registered user to access the system resources that fall under their privilege level.

29
A user gains access to the system resources after a username password combination has been
verified as accurate after which they are redirected to the homepage. The system homepage serves as
the gateway to the entire records management system. Therefore, once a user is logged into the
system they can access all system resources available to them based on their privilege level.

Once logged into the system, the user can create, manipulate and truncate records. However, the
amount of manipulation that a user can perform with regards to the records is dependent on user
privilege levels as explained below

4.1.3. User Privileges

The system maintains two levels of users:-

1. Administrator Level-Database administrator
2. User Level-Data Entry Operator

Administrator Level

The administrator level is reserved for the database administrator. The administrator maintains the
exclusive privilege to access ALL system resources and therefore has unlimited access to the system.
In the designed system, the administrator has the following exclusive privileges;
 Granting and revoking access to system resources to users. This involves registering and de-
registering users
 Maintaining all tables with fixed data values for example, table with list of immunisable
diseases which only needs to be updated once in a few years or never at all
 Truncating Obsolete Records

30
User Level

The user level is reserved for the data entry operator. This user’s privileges are limited to only
entering in data, specifically, data collected regularly about the children. They have the ability to add
and edit data that they have access to but cannot truncate any record.

4.1.4 Pseudo Codes

Log in to system
Startup system
Enter login name and password
On clicking the login button
Connect to database
Query database to know whether user credentials are correct
If not
Deny access and return login page with an error message
If correct
Check if credentials are for administrator
If yes
Allow login
Set admin session
Re-direct administrator to admin home page
If no
Allow login
Set user session
Re-direct user to user home page

Add new user

Check if administrator is logged in

If correct
Check if all fields entered are correct
If correct
Check if unique field value entered already exists
If correct
System message: user already exists
If not
Registration of user successful

Adding Record
Enter Record Details
If record exists
Return record already exists
If not
Registration of Record successfull

31
Editing Record

Click on edit button

Query the database to retrieve details
If record exists
Return record details
Check if all fields entered are correct
If not
System message: fields incorrect
If correct
System message: record successfully edited

Deleting a record
Check if administrator is logged in
If not
System message: no sufficient rights to perform this operation
If correct
enter recordID
If record ID exists
Delete record from table
If record ID does not exist
System message: sorry! record does not exist

32
4.2. System Requirements

The system requires a client-server architecture where a server is necessary to host the application
and the database .The users will access the server to retrieve information from their desktops
through their web-based interfaces. For this to work, the following will be required;

4.2.1 Non-functional Requirements

Non-functional requirements are described as the constraints on the services the system provides
and they include;

 Users must login in order to access the system resources.

 All staff who intend to use the system should undergo training.

4.2.2 Hardware Specifications

 Processor Pentium II, Pentium III, Pentium IV or higher

 RAM 64 Mb or Higher

 Disk Space130 Mb

 LAN Ethernet 10/100Mbps card/bus.

4.2.3 Software Specifications

Operating System: Win-XP, Windows Vista, Windows 7 or Higher

Web Browser: Internet Explorer 6 or Higher

Database: Apache 2.0 as web server

MySQL version 5.0.1 or higher as database

33
4.4 Systems Architecture
The system is designed in the following manner. The Records Management system has a backend
engine that consists of a MYSQL database, PHP as the programming language and Apache as the
webserver and the user interface modules. The system architecture is illustrated in Figure 3 below.

4.4.1 Diagram Showing the System Architecture

Figure 3: System Architecture

The details of the user interfaces are displayed in the high level architectural diagram in Figure 4
below. After the user login, the appropriate access rights, the user may access the system

34
4.4.2 High-Level Architecture Diagram of the main components

Figure 4: High level architectural diagram of main components

4.4.3 Logical Database Design

The logical database design is meant to describe the representation of the database in terms of its
entities in form of tables and the existing relationships. Below is an illustration of the systems logical
design as generated by the MYSQL workbench design tool.

35
Logical Design

Figure 5 : Logical design

36
4.5 Data Requirements
Data is very important to any new system implementation testing. For this project, imaginary data
was used in the testing and demonstration purposes. The sample data was used as a reflection of the
actual scenario of real life situation in the MCH section.

4.6 Database (Physical Design)

4.6.1 Physical Database Design

As one of the core elements of a records management system, the database had to be designed in a
meticulous systematic manner. This process started at the analysis phase of the project. From the
analysis, the researcher was able to identify the necessary tables required for the database and the
associated field names, format and length of each table. After careful analysis of the user
requirements, it was identified that the RMS needed four main tables i.e. child details, child
development, immunization and the login table. However, after the process of normalization a few
sub-tables emerged from the main tables. Below is a list of these tables.

4.6.2 Database Tables

Table 1: Login Table

Attribute Field type Length/size Description

Login_id INT 11 Unique username
Passwd VARCHAR 45 Password

37
Table 2 : Child Details Table.
Attribute Field type Length/size Description
Child_id INT 11 Unique identifier of the child
First name VARCHAR 100 Child’s first name
Last name VARCHAR 100 Child’s last name
Sex VARCHAR 100 Sex
Date_of_birth DATE Child’s birth date
Mother‟s name VARCHAR 100 Child’s mother’s name
Father‟s name VARCHAR 100 Child’s father’ name
District_id INT 11 Identifier of the child’ home district

Religion_id INT 11 Identifier of the child’ religion

Table 3: Child Development Table

Attribute Field type Length Description

Child_id INT 11 Unique identifier of the child
Current height INT 11 Tallness/shortness of the child
Head circumstance INT 11
Milestones_reached VARCHAR 100 Development milestones
Language_developement VARCHAR 100
Development status VARCHAR 100 Normal/abnormal growth of child
Recommendations VARCHAR 100 Recommendations given after treatment

Table 4: Immunization Table

Attribute Field type length Description
Child_id INT 11 Unique identifier of the child
Vaccine_id INT 11 Identifier of the vaccine
Vaccine_date DATE Date when vaccine is given
Age_at_vaccination INT 11 Age at which child is vaccinated
Vaccine_mfr_date DATE Date when vaccine was made
Vaccine_expiry_date DATE Date when vaccine will expire
Body_site_id INT 11 Body site where vaccine administered
Administrative_method_id INT 11 Method used to vaccine child
Next appointment_date DATE Date of Next appointment

38
Based on the tables displayed above, the main/core tables are linked together by one Unique key
which is Child_id. This key serves as the primary key for the whole system implementation and helps
distinguish information related to each patient/child.

4.6.3 Data relationships

Data relationships show how the information or records are related between each other. For the
tables to work together, relationships have to be established In the design of the MCH Records
Management system, the data relationships were established during the process of the logical data
design.

There are mainly four kinds of relationships

 One to One
 One to Many
 Many to Many
 Many to One

These relationships are represented in the entity relationship diagram (ERD) in the next section.

39
4.7 ER Diagrams and DFDs
4.7.1 ERD (Entity Relationship Diagram)

Records
Management
username System username
1:*
password
password

user *:1 *:1

has admin
*:* *:* *:* *:*
*:*

Manages
does manages
Manages Does

*:* *:*
*:* *:*
Patient login
Patient records
login records
*:*
User
accounts

Figure 6: Entity Relationship Diagram

40
 4.7.2 DFD (data flow diagram)

A Data flow diagram (DFD) is used to reveal relationships among and between the various
components in a system. It also illustrates the operational context of the system. A data flow
diagram is an important technique for modeling a system’s high-level detail by showing how what
laid out the system boundaries.

System
start up

User login Administrator

Stores and Retrieves

Login_database

Child_registration Add_new Back up

Child_ information

register

stores and stores and stores and

Child_registration
Child_ information database Add_new Back up
database database database

Figure 7: Data Flow Diagram

Manage

41
4.8 System Flow Chart
START

LOGIN

NO
Valid
login
details
YES

IDENTIFY
USER TYPE

NO REDIRECT
User type TO USER
admin ACCOUNT

YES

REDIRECT
TO ADMIN
ACCOUNT

LOGOUT

END

42
4.9 HIPO-Hierarchical Input Process and Output
This is a graphical illustration of the flow of events in the system;
LOGIN

NO
Password Login
username failure
correct?

YES
Deny access

User Admin

Child_D Child_DD Immun vaccine Admin Disease District Religion Body site User

Add Add Add Add Add Add Add Add Add Add
chil_D child_dd imm vaccine admin disease district religion body user
record site
Sort sort Del
sort imm Delete Del Delete Del Del Del
child_d Child_dd religion
record vaccine admn disease district body user
site
Edit Edit
chil_d child_dd Edit imm Edit Edit Edit Edit
record disease district religion Edit
vaccine
body
Update Update site
child_d child_dd Update
imm 43
record
Figure 9: Hippo Chart
4.9 Data Inputs (System forms).

Outputs are selected from the database based on a certain criteria and displayed using forms that
were developed using dream weaver 8. The entire RMS itself contains a number of forms, However,
for the systems main components, there are five main forms, below are some snap shots of the key
forms.

4.9.1 Login Form

The login form above is the first page a person accessing the system sees. It is used to gain access to
the system resources and determines, based on the user type, which users should acess which
resources

Figure 10: Login form

1
4.9.2 User Registration Form

Figure 11: User registration form

The form above was specifically desgined for the administrative account. It was designed with a view
to grant the administrator the ability to register new users. The form as displayed above, enables the
administrator to specify the user level or the account type as either user or administrator. This
information is crucial during the process of logging in as it specifies what priviledges the system user
should and shouldn’t acess.

4.9.3 Data Entry and Manipulation Forms

Figure 12: Data Entry form for Child Details

2
Data entry and manipulation forms in the system include the data add, delete and edit forms. The
add and edit functions are accessible to both the administrator and normal user who is expected to
be the main data entrant. However, access to the delete forms is restricted to a user with
administrative privileges. Figure11 shows a sample of one of the add forms in the system.

4.10 Data Outputs

4.10.1 Data Storage Interface

After the data in entered into the system, it is stored and can be retrieved at any time using the
search functionality.

Figure 13: Data Storage interface for Child Details

3
4.10.2 Data Reports

The system was designed with a system of generating pdf reports for the records using the fpdf
package. This functionality was integrated in order to facilitate printing of the records in the system.
Below is a snapshot of one of the pdf reports.

Figure 14: Fpdf Report for child details records

4
4.10 Implementation and Testing

4.10.1 Implementation

Implementation is a very important aspect in the development of any computerized system, and this
also applies to the development of a records management system. Pro-development Implementation
usually involves two main steps, these are;

 System Construction: The system is built and tested to make sure it performs as designed.

 Installation: Preparation is made to support the installed system. This involves associated
documentation

Under system construction, the main task is testing. In the next section is a detailed description of
how this was carried out in the designed RMS;

4.10.2 Testing:

Testing is critical for a newly developed system as a prerequisite for it being put into an environment
where the end users can use it. Exhaustive testing is conducted to ensure accuracy and reliability
and to ensure that bugs are detected as early as possible. In the process of designing the RMS, three
levels of testing were conducted, namely, unit testing, integration testing and system testing.

Unit Test
Unit test is where the system is tested partially and independently, component by component, to
ensure that particular portion or module is workable within it. In the development of the records
management system, each component was tested independently before finally integrating each of
them into one system. This test was used by the researcher to verify that every input of data was
assigned to the appropriate tables and fields

Most of the modules were rather similar and therefore required a rather easy reusable testing
process. However, the user accounts module accessible to the system administrator was one of the
unique components that needed to be carefully tested in the RMS. This involved testing each users
access rights. This was necessary to ensure that user privileges did not overlap.

5
Integration Test
Integration test is where a combination of several portions or components/sub components of
programs are being tested sequentially and continuously. At this stage, all the system components
were integrated and a test was based on how they worked together. This involved observing the
interaction of the database and the interfaces. After which the system test followed

System Test
A system normally consists of all components that makeup the total system to function. Its is
required to ensure the smooth running of the system as a whole, and it should perform as expected
and as required. Here, technical and functional testing was performed. The technical testing involved
the process of testing the systems compatibility with the hardware, operating system, data integrity in
the database and user authorization access rights. Functional testing was also carried out to establish
how the system would function in its intended working environment.

User Acceptance Test

Due to a few constraints, this part of testing was not done by the researcher, however, after the oral
presentation of the project work, the system developer intends to review the system with the
intended system users so as to analyze acceptability and usability and also to identify areas that may
require modification before the system can fully be commissioned for use.

4.10.3 System Documentations

System documentation is a crucial aspect of system implementation. It provides a frame of reference

with regards to the implementation process. In designing the RMS for Mbarara Hospital, the
documentation was done is form an integrated FAQ file that users of the system can refer to if they
have any challenges as far as using the system is concerned.

6
CHAPTER FIVE: EVALUATIONS & CONCLUSIONS

5.1 Evaluations

In the attempt to evaluate the designed system, it is imperative that the researcher look back at the
predefined functionalities, goals and objectives and analyze those in relation to the expectations met
by the system. The Records Management System was evaluated based on the set of predefined
objectives and expected functionalities it was able to fulfill. The Records Management System was
designed to facilitate efficient records management in Mbarara Hospital by providing an efficient,
reliable computerized records management system and after a careful evaluation process; it met a
considerable portion of those expectations.

The main objective was to design a system that enables faster and more efficient storage, retrieval
and updating of hospital records. As far as this is concerned, the system met this expectation by
giving direct benefit to the clinic such as fast records retrieval. It also included functionalities that
enable all data entrants to access the system online with the assumption that a client-server
architecture is in place, retrieve records on demand and execute important reports to support daily
medical tasks.

Fundamentally, the effectiveness of this project depended on meeting the project’s specific
objectives which were as follows; To carry out a feasibility study for the possibility of developing a
records management system for the MCH section of Mbarara Hospital; To design and develop a
records management system for the MCH section of Mbarara Hospital; To test and validate the
records management system for the MCH section of Mbarara Hospital and To implement the
records management system for the MCH section of Mbarara Hospital. All the objectives were met
by the system, to a certain extent;

Analysis was successfully completed. This evaluation is based on the fact that data requirements
were collected that successfully enabled the design and development of the system.

The system design and development was carried out in a systematic manner and was based on user
requirements defined by the end users. The design objectives of creating an efficient records
7
management system was further accomplished with the creation of add, delete, search and edit
functionalities in the system that not only enable computerized but rather efficient, reliable and fast
data entry. All these functionalities possess a relatively high level of accuracy. In evaluating this
objective in relation to the system’s performance, it would therefore be accurate to state that it was
achieved to a large extent.

Still while evaluating the system design and performance, the system enables the synchronization of
records through its server-client architecture with a single database. Therefore data entered from one
recording station will be seen on another recording station using the same system.

Critical Evaluation
For an evaluation process to be fully comprehensive, it should also include a critical assessment of
the system. Therefore, despite the fact that the findings obtained after an evaluation showed that the
system met its expectations to a large extent, it had a few shortcomings. These limitations are
discussed in the next section.

5.2 Limitations of the System

Throughout the development of the Mbarara Hospital Records Management System, a few areas
were overlooked by the researcher. Some of these limitations can be presented as follows;

Usability
With regard to its use, the system only caters for English speakers. The GUI and associated
documentation is in English. This may present a problem for non- English speaking users

Accessibility
The system has only two user levels which only cater for the administrator and data entrant.
However, there is no facility for a guest. Such a facility would be useful if the patients themselves
needed to access their electronic records via the system.

8
Security
The system also does not cater for the automatic back up of the data in the database. This may
present a security problem in the event of data loss.

Static FAQ File

The system currently has a static FAQ file. This is a limitation in the sense that the system does not
generate the dynamically file based on the frequently asked questions.

5.6 Problems Encountered

In attempting to design the system, the following problems were encountered.

Accessing Research Material

Accessing associated research material was quite a challenge. This was particularly the case because
of the limited variety of books and journals in relation to the research topic in the local library. To
further escalate the challenge, online resources were close to impossible to access due to the
university’s slow internet speeds that made it impossible to download books and journals.

Wide project scope

Defining the project scope was quite a challenge. This is because the system was meant to be
designed for the entire hospital including all its departments, however with a view to the limited
amount of time available for the project, the scope had to be narrowed down to one section of the
hospital.

Understanding Key Concepts

Limitations as far as understanding the key concepts also posed a major challenge. Considering the
fact that most of the concepts were new, the researcher had to spend a considerable amount of time
learning the concepts. This took away a lot of valuable time that would otherwise be fully dedicated
to the design of the system.

Programming skills
Learning PHP and MySQL requires considerable practice for one to gain the programming skills.

9
With limited knowledge and ability, the programming progress was rather slow and this limited the
number of functionalities that the researcher could implement into the system.

Unanticipated Expenditure
Also the researcher was met with a few financial constraints as a result of unanticipated expenditure.
In order to cater for the slow internet speeds in the university computer labs, the researcher had to
subscribe for a dial-up internet connection in order to proceed with the project unhindered. This
expenditure was however unforeseen and therefore posed a challenge for the researcher.

5.7 Recommendations/Future Research

As well as addressing the limitations presented in Section 5, there is scope for work to further the
functionality and usefulness of this project. The researcher therefore made the following
recommendations for future enhancements to the system.

Widening the scope

Given the limited amount of time given to the developer, the project’s scope was rather limited to
only one clinic in the hospital. The scope can further be widened to include all the other clinics to
make a more integrated comprehensive system that covers the entire hospital’s records management

Including additional components and functionalities

A few other components can be included in the system in future. This may include the ability to
compute calculations especially when determining a patient’s next appointment, this will make the
system more efficient and drastically minimize the amount of errors. The ability to include an upload
functionality for patient images could greatly enhance the usefulness of the system.

Increased accessibility
The system can also be further enhanced so that the patients themselves can be able to access their
information online in a secure manner; this will lead to greater doctor-patient transparency.

10
5.8 Conclusion

In Conclusion, from a proper analysis and assessment of the designed system, it can be safely
concluded that the system is an efficient, usable and reliable records management system. It is
working properly and adequately meets the minimum expectations that were set for it initially. The
new system is expected to give benefits to the MCH unit in terms of increased overall productivity,
performance and efficient records management at the MCH section of Mbarara Hospital.

11
REFERENCES & BIBLIOGRAPHY
[1]. Bearman, D. (1992). The American Archivist , No. 55.
[2]. Bearman, D. (1993). Record Keeping Systems. Electronic Evidence, Strategies for Managing Records
in Contemporary Organisations .
[3]. Craig, B. Central Children's Hospital Merger and Archives.
[4]. Iwhiwhu, B. A. The Management of Staff Records at Delta State University Library. Abraka, Nigeria.
[5]. Kalton, M. (1989). Survey Methods in Social Investigation (2nd Edition ed.). Hants, UK: Gower
Publishing Company.
[6]. Kemoni, H. Managing Hospital Reords in Kenya- A Case Study of the Moi National Teaching and
refferal Hospital, Eldoret. Eldoret, Kenya.
[7]. Patton, M. (1990). Qualitative Evaluation and Reserch Methods (2nd Edition ed.). Newbary Park,
NewYork, USA: Sage Publications.
[8]. Roper, M. (2000). Managing Public Sector Records.
[9]. Taylor, J. (2004). Managing Information Technology Projects.

[10]. Wikipedia. (n.d.). Mbarara_Hopital. Retrieved September 27th, 2010, from

http://www.wikipedia.org: http://www.wikipedia.org/wiki/Mbarara_Hopital
[11]. Yank, K. (February 2003). Build Your Own Database Driven Website Using PHP and MYSQL
(Second Edition),. USA: SitePoint.
[12]. Erlandsson A. (April 1996) Electronic Records Management:- A Literature Review

[13]. Luciana Duranti and Heather MacNeil, “The Protection of the Integrity of Electronic
Records: An Overview of the UBC-MAS Research Project”. December 1997).

12
APPENDIX I- PROJECT TIMELINE
GANT CHART FOR THE DEVELOPMENT OF A RECORDS MANAGEMENT SYSTEM FOR MBARARA HOSPITAL
Month Sept „10 Oct „10 Nov‟10 Dec „10 Jan „11 Feb „11 March „11 April „11
1 1 1 1 1 1 1 1
2 2 2 2 2 2 2 2
WEEK
ACTI 3 3 3 3 3 3 3 3
4 4 4 4 4 4 4 4
Project Proposal
Project Planning
Project initiation
Project research
System design
System
development
System Validation
Report Writing
Project
presentation

13
 APPENDIX II- PROJECT BUDGET
Amount in
Budget Item Details UGX

1 Computer System (Laptop Computer) 1,500,000.00

5 Rewritable DVDs for Back up @ 3000 15,000.00
2 ream of printing paper 11,000.00
1. EQUIPMENT
5 pencils and 5 pens 2,000.00
2 GB flash Disk 45,000.00
Printing Services 150,000 * 5 developers 750,000.00
Sub-Total 2,323,000.00

Airtime 5000 @ week for 32 weeks * 5 developers 800,000.00

2. COMMUNICATION
Internet services 45,000 @month * 8 months 360,000.00
Sub-Total 1,160,000.00

3. TRAVEL Transport per month @ 20,000 * 5 developers *8 months 800,000.00

Sub-Total 800,000.00

4. MISCELLENOUS 200,000.00

SUMMARY
Equipment UGX 2,323,000.00
Communication UGX 1,160,000.00
Transport UGX 200,000.00
Miscellaneous UGX 200,000.00
GRAND TOTAL UGX 3,883,000.00

14
 APPENDIX III- IMPLEMENTATION CODES

Connecting the interface to the database

Main Connection Code

Interface – to-database connection Code

15
 APPENDIX IV- FINAL SUBMISSION LETTER

FINAL SUBMISSION LETTER

Date: 5th April 2011

THE RESEARCH COORDINATOR

ICS
MUST

Thru:
The Supervisor
Mr. Richard Kimera
Institute of Computer Science
MUST

RE: NOTICE OF SUBMISSION OF PROJECT FOR PRESENTATION

ACHENG DORIS ODIT
2008/BIT/033/PS
BACHELOR OF INFORMATION TECHNOLOGY

This is to submit our Project, “Mbarara Hospital Records Management System- (A Case Study
of the Maternal and Child Health Section)” for examination/presentation for the Award of
“Bachelor of Information Technology” of Mbarara University of Science and Technology.

The purpose of this letter therefore, is to kindly request you arrange presentation for our group.

Thank You.

Yours Faithfully,

…………………………………..
Acheng Doris Odit

CC:

……………………………………

Supervisor

16