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

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

INSTITUTE OF COMPUTER SCIENCE

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.

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

Supervisor

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 Bachelors 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 Acheng Doris Odit (STUDENT)

Date.

SUPERVISORS APPROVAL

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

Signature... Mr. Kimera Richard (SUPERVISOR)

Date....

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 SUPERVISORS 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

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 FAQ GUI HTML ICA ICT IS Lab LAN MCH MIS PHP RAM RM RMS SQL XP

Administrator Frequently Asked Questions Graphical User Interface Hyper Text Markup Language International Council on Archives Information and Communication Technology Information System Laboratory Local Area Network Maternal and Child Issues Management Information System Hypertext Pre-Processor Random Access Memory Records Management Records Management System Structured Query Language 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 hospitals 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 nonclinical 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/ institutions 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 organizations 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 patients 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 individuals 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 cant 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 projects 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 clinics 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 users 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 Services

Therapeutic Services

Diagnostic Services

Support Services

Admissions Billing, etc. Med. Records Computer Info. Health Ed. Human Resource.

PT, OT Speech/Lang. Resp. Therapy Pharmacy Nursing Dietary

Med. Lab Radiology Nuclear Med ER Cardiology Neurology

Central Supply Biomedical Housekeeping Maintenance Dietary 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 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. systems,

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 Hospitals 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 deregistering 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 users 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: Web Browser: Database: Win-XP, Windows Vista, Windows 7 or Higher Internet Explorer 6 or Higher 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 Login_id Passwd Field type INT Length/size 11 Description Unique username Password

VARCHAR 45

37

Table 2 : Child Details Table. Attribute Child_id First name Last name Sex Date_of_birth Mothers name Fathers name District_id Religion_id Field type INT Length/size 11 Description Unique identifier of the child Childs first name Childs last name Sex Childs birth date Childs mothers name Childs father name Identifier of the child home district Identifier of the child religion

VARCHAR 100 VARCHAR 100 VARCHAR 100 DATE VARCHAR 100 VARCHAR 100 INT INT 11 11

Table 3: Child Development Table Attribute Child_id Current height Head circumstance Milestones_reached Language_developement Development status Recommendations Field type INT INT INT VARCHAR VARCHAR VARCHAR VARCHAR Length 11 11 11 100 100 100 100 Description Unique identifier of the child Tallness/shortness of the child Development milestones Normal/abnormal growth of child Recommendations given after treatment

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

11 11

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)

username password

Records Management System 1:*

username

password

user *:* *:*

*:1

has

*:1 *:*

admin *:* *:*

Manages

does

manages Manages

Does

*:* login

*:* Patient records

*:* Patient records *:* User accounts

*:* login

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 systems high-level detail by showing how what laid out the system boundaries.

System start up

User

login
Stores and Retrieves

Administrator

Login_database

Child_ information

Child_registration register

Add_new

Back up

stores and

stores and

stores and

Child_ information database

Child_registration database

Add_new database

Back up database

Figure 7: Data Flow Diagram Manage 41

4.8 System Flow Chart

START

LOGIN

Valid login

NO

details YES
IDENTIFY USER TYPE

User type

NO

admin
YES REDIRECT TO ADMIN ACCOUNT

REDIRECT TO USER 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

Password username correct?

NO

Login failure

YES

Deny access

User

Admin

Child_D

Child_DD

Immun

vaccine

Admin Add admin

Disease Add disease

District

Religion Add religion

Body site

User

Add chil_D Sort child_d Edit chil_d Update child_d

Add child_dd sort Child_dd Edit child_dd Update child_dd

Add imm record

Add vaccine

Add district

Add body site Del body site Edit body site

Add user

sort imm record

Edit imm record Update imm record

Delete vaccine
Edit vaccine

Del admn

Delete disease
Edit disease

Del district
Edit district

Del religion
Edit religion

Del user

43

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

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 shouldnt acess.

4.9.3 Data Entry and Manipulation Forms

Figure 12: Data Entry form for Child Details

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

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.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.

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 projects 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 systems 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.

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 universitys 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 projects 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 hospitals 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 patients 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 1 2 3 Oct 10 1 2 3 Nov10 1 2 3 Dec 10 1 2 3 Jan 11 1 2 4 3 4 Feb 11 1 2 3 March 11 1 2 3 April 11 1 2 3

WEEK ACTI Project Proposal Project Planning Project initiation Project research System design System development System Validation Report Writing Project presentation

13

APPENDIX II- PROJECT BUDGET

Budget Item Details 1 Computer System (Laptop Computer) 5 Rewritable DVDs for Back up @ 3000 2 ream of printing paper 5 pencils and 5 pens 2 GB flash Disk Printing Services 150,000 * 5 developers Sub-Total Amount in UGX 1,500,000.00 15,000.00 11,000.00 2,000.00 45,000.00 750,000.00 2,323,000.00

1. EQUIPMENT

2. COMMUNICATION

Airtime 5000 @ week for 32 weeks * 5 developers Internet services 45,000 @month * 8 months Sub-Total

800,000.00 360,000.00 1,160,000.00

3. TRAVEL

Transport per month @ 20,000 * 5 developers *8 months Sub-Total

800,000.00 800,000.00 200,000.00

4. MISCELLENOUS SUMMARY Equipment Communication Transport Miscellaneous

UGX 2,323,000.00 UGX 1,160,000.00 UGX UGX 200,000.00 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