Hospital Records Management System
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Hospital Records Management System

on

  • 18,433 views

 

Statistics

Views

Total Views
18,433
Views on SlideShare
18,433
Embed Views
0

Actions

Likes
4
Downloads
1,460
Comments
3

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Thank you your example helped me a lot to develop my project proposal
    Are you sure you want to
    Your message goes here
    Processing…
  • The example of your project report was a help to mine
    Are you sure you want to
    Your message goes here
    Processing…
  • I appreciate your efforts
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Hospital Records Management System Document Transcript

  • 1. 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 704197062A 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.
  • 2. DECLARATION“I Acheng Doris Odit hereby declare that the information in this dissertation embodies my originalwork done during this project submission in partial fulfillment of a Bachelor’s Degree inInformation Technology at Mbarara University of Science and Technology. This dissertation hasnever been published or submitted to any other institution of higher learning for any academicaward to the best of my knowledge.”Signature……………………… Date…………………………….Acheng Doris Odit(STUDENT)SUPERVISOR‟S APPROVALThis is to certify that Acheng Doris Odit, a third year student of Mbarara University of Science andTechnology pursuing a Bachelor’s degree in Information Technology took part in the project workfor the partial fulfillment of the requirements of this degree under my supervision.Signature……………………... Date……………………..……..Mr. Kimera Richard(SUPERVISOR) i
  • 3. DEDICATIONI wish dedicate this piece of work to my father Francis Joseph Odit, for being my inspiration, to mymother Margaret K. Odit , for being my pillar of strength and to my siblings Dennis Odit, PatrickObong and Salome Akite for their unconditional support. ii
  • 4. AKNOWLEDGEMENTSThis 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 pricelessintellectual 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 parentsFrancis 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
  • 5. TABLE OF CONTENTSDECLARATION ...................................................................................................................... ISUPERVISOR‟S APPROVAL................................................................................................... IDEDICATION........................................................................................................................ IIAKNOWLEDGEMENTS ...................................................................................................... IIITABLE OF FIGURES ........................................................................................................... VILIST OF TABLES................................................................................................................. VIIABBREVIATIONS & ACRONYMS .................................................................................. VIIIABSTRACT ............................................................................................................................ IXCHAPTER 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 ........................................................................................................................................... 17CHAPTER 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 ............................................................................................................................................................................. 22CHAPTER 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 .................................................................................................................... 28CHAPTER FOUR- SYSTEM DESCRIPTION ..................................................................... 29 4.1 SYSTEM OVERVIEW .................................................................................................................................................................. 29 4.1.2 Accessing the System ........................................................................................................................................................ 29 4.1.3. User Privileges ................................................................................................................................................................... 30 iv
  • 6. 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 .................................................................................................................................................. 6CHAPTER 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 ............................................................................................................................................................................. 11REFERENCES & BIBLIOGRAPHY .................................................................................... 12APPENDIX I- PROJECT TIMELINE ................................................................................. 13APPENDIX II- PROJECT BUDGET.................................................................................... 14APPENDIX III- IMPLEMENTATION CODES ................................................................. 15 CONNECTING THE INTERFACE TO THE DATABASE.............................................................................................................. 15 Main Connection Code .............................................................................................................................................................. 15 Interface – to-database connection Code ............................................................................................................................... 15APPENDIX IV- FINAL SUBMISSION LETTER................................................................ 16 v
  • 7. TABLE OF FIGURESFIGURE 1- ORGANISATIONAL STRUCTURE OF MBARARA REGIONAL REFFERAL HOSPITAL ................17FIGURE 2: EXTREME PROGRAMMING LIFECYCLE.......................................................................................24FIGURE 3: SYSTEM ARCHITECTURE ...............................................................................................................34FIGURE 4: HIGH LEVEL ARCHITECTURAL DIAGRAM OF MAIN COMPONENTS .........................................35FIGURE 5 : LOGICAL DESIGN ..........................................................................................................................36FIGURE 6: ENTITY RELATIONSHIP DIAGRAM ..............................................................................................40FIGURE 7: DATA FLOW DIAGRAM .................................................................................................................41FIGURE 8: SYSTEM FLOW CHART ...................................................................................................................43FIGURE 9: HIPPO CHART.................................................................................................................................43FIGURE 10: LOGIN FORM .................................................................................................................................. 1FIGURE 11: USER REGISTRATION FORM.......................................................................................................... 2FIGURE 12: DATA ENTRY FORM FOR CHILD DETAILS ................................................................................. 2FIGURE 13: DATA STORAGE INTERFACE FOR CHILD DETAILS ................................................................... 3FIGURE 14: FPDF REPORT FOR CHILD DETAILS RECORDS............................................................................ 4 vi
  • 8. LIST OF TABLESTABLE 1: LOGIN TABLE ..................................................................................................................................37TABLE 2 : CHILD DETAILS TABLE..................................................................................................................38TABLE 3: CHILD DEVELOPMENT TABLE ......................................................................................................38TABLE 4: IMMUNIZATION TABLE...................................................................................................................38 vii
  • 9. ABBREVIATIONS & ACRONYMSADMIN AdministratorFAQ Frequently Asked QuestionsGUI Graphical User InterfaceHTML Hyper Text Markup LanguageICA International Council on ArchivesICT Information and Communication TechnologyIS Information SystemLab LaboratoryLAN Local Area NetworkMCH Maternal and Child IssuesMIS Management Information SystemPHP Hypertext Pre-ProcessorRAM Random Access MemoryRM Records ManagementRMS Records Management SystemSQL Structured Query LanguageXP Extreme Programming viii
  • 10. ABSTRACT“The purpose and essence of any Records Management system is the right information in the rightplace in the right order, at the right time for the right person at the lowest cost.”- (Baje 1998). Forthis feat to be achieved, an integrated, highly efficient and effective records management system isneeded. With this in mind, a careful analysis of the records management system being utilized by theMbarara Regional Referral Hospital MCH section was conducted. The findings showed that thesystem was highly inefficient- especially as far as retrieval of archival patient information wasconcerned. This analysis established the need for a Records Management System (RMS) that wouldfacilitate effective and reliable records management through automated processes and served as thebasis 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 patientrecords Management and give direct benefit for the MCH section in terms of fast informationretrieval, enhanced decision-making (patient diagnosis) whilst avoiding any confusion that wouldjeopardize the quality of patient care. The RMS was designed as a client/server and web-basedsystem and implemented using open source solutions that include MySQL as the database, andPHP, HTML and JavaScript as the programming languages.The system was developed using Extreme Programming methodology. An extensive evaluation ofthe project determined that the project achieved many of its predefined objectives however, themajor limitation of the project was the scope covered. From a proper analysis and assessment of thedesigned system, it can be concluded that the system developed is an efficient, usable and reliablerecords management system. ix
  • 11. CHAPTER ONE1.1 IntroductionHospitals deal with the life and health of their patients. Good medical care relies on well-traineddoctors and nurses and on high quality facilities and equipment. Good medical care also relies ongood 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, whichcan have serious consequences. Associated records, such as x-rays, specimens, drug records andpatient registers, must also be well cared for if the patient is to be protected. Good records care alsoensures the hospitals administration runs smoothly; unneeded records are transferred or destroyedregularly, keeping storage areas clear and accessible; and key records can be found quickly, savingtime and resources. Records also provide evidence of the hospital’s accountability for its actions andthey form a key source of data for medical research, statistical reports and health informationsystems.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 ensurethat staff have access both to clinical information and to administrative records on a wide range ofissues, 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 basisin accordance with approved policies, procedures and schedules. Records Management as adiscipline defines and applies business rules related to the creation, protection, retrieval anddisposition of an organization as records over time. Retention schedules are the cornerstone of asuccessful Records Management process.Records Management as a discipline involves records keeping. Record keeping is an importantaspect of every organizations/ institution’s day to day operations. There cannot be a records 10
  • 12. management system without records and neither can there be efficient record keeping without agood records management system. Therefore, record keeping is the Systematic procedure by whichthe records of an organization are created, captured, maintained, and disposed of. This system alsoensures 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 toany item or collection of data.A management information system (MIS) is a system or process that provides the informationnecessary to manage an organization effectively. An MIS should be able to influence decisionmaking. A records management system while incorporating aspects of a MIS should be able toinfluence decision making in an institution/ organizationAn information system (IS) is any combination of information technology and peoples activitiesusing that technology to support operations, management, and decision-making. In a very broadsense, 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 theinformation and communication technology (ICT) an organization uses, but also to the way inwhich people interact with this technology in support of business processes and is therefore relevantto the development of a records management system.A management system is a proven framework for managing and continually improving anorganization’s policies, procedures and processes.Therefore a good and efficient records management system should be able to incorporate specificaspects of the systems mentioned above in order to provide and efficient means of records storageand management. 11
  • 13. 1.2 BackgroundMbarara Hospital is a public hospital, funded by the Uganda Ministry of Health which wasestablished in 1940. It is affiliated with the medical school of Mbarara University of Science andTechnology, one of the four medical schools in Uganda. It is the referral hospital for the districts ofMbarara, Bushenyi, Ntungamo, Kiruhura, Ibanda and Isingiro. The hospital also serves as theteaching hospital of Mbarara University. The hospital is staffed by medical students and residents. Itis 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. Thedepartment was started at the inception of the Hospital in 1940. The department however only hasarchives dating back to 1986 owing to the fact that records that preceded that year were destroyedduring 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 andstoring patient’s medical information, another for sundries and drugs and another section isresponsible for Human Resources and financial records. The department however liaises with thedifferent clinics and departments in the hospital which reserve the semi-autonomous responsibilityof maintaining their own patient records. One such department is the Maternal and Child HealthClinic (MCH).The MCH section in relation child immunization provides Immunization services for Children. Theimmunization process under MCH is carried out in phases and is progressive- This requires ameticulous recording system that is able to keep systematic track of each individual’s progress. Inthis Section, various operational functions are done such as; Recording information about thePatients that come, Keeping record of the Immunization provided to children/patients. andKeeping information about various diseases and vaccinations available. Like all other records in thehospital, the records are paper basedIn analyzing the current records management system at the MCU, a lot of the records are stored inpaper files. In the section, Information about Patients is done by just writing the Patients name, ageand gender. Whenever the Patient comes up his information is stored freshly. Immunization recordsof children are maintained in pre-formatted sheets, which are kept in a file. 12
  • 14. All this work is done manually by a few nurses and other operational staff on paper files. This meansthat all this paper files need to be handled and taken care of with utmost care. Unfortunately, this israrely the case. Doctors and nurses have to remember various medicines available for diagnosis andsometimes miss better alternatives as they can’t remember them at that time. As regards recordsstorage, the records are stored in cramped record rooms. This situation is worsened by the massivenumber of children the section receives each day. The current recording system in use is thereforeinefficient and time consuming.1.3 Statement of the ProblemThe system design and development was undertaken in order to eliminate the problem ofredundant, 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 recordingsystem was entered into books and paper files and was later stored in overcrowded storage roomsthat made retrieval of archival records close to impossible.1.4 Objectives1.4.1 General ObjectiveTo design and develop a records management system for Mbarara hospital that would enable fasterand more efficient storage, retrieval and updating of hospital records.1.4.2 Specific ObjectivesThe 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
  • 15. 1.5 SignificanceIn designing and developing the records management system, it was hoped that the project wouldhave the following impact on all stakeholders.The developed records management system was deemed as necessary for the automation andstreamlining 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 thusstreamline operations.It would lead to faster service delivery with faster record insertion and retrieval thus reducing thetime spent by staff filling out forms. This would minimize on the time consumed in the input andretrieval of records, freeing resources for more critical tasks and thus providing an opportunity tothe 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 storingthe paper-based records and this space was saved up by the implementation of the computer-basedrecords 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 recordslife.It would also save the hospital section on badly needed human resources. This is because therecords management system would require less number of Staff to cater more patients in same timeor even less. Therefore, this presents an opportunity for the hospital administration to re-deploy thepersonnel that are currently working in the records desk to other suitable locations- where they areneeded more. The senior Doctors and nurses would also be able to spend their precious time morein clinical activities than to put in clerical activities otherwise.The records management system would also prevent costly paper accumulation with systematicrecord disposal. 14
  • 16. Accounting sometimes becomes needlessly complex. This records management system wouldeliminate any such complexity, since the retrieval of information through its MIS would comevirtually on the tip of the user’s fingers.It would also improve the response time to the demands of patient care because it would automatethe process of collecting, collaborating and retrieving patient information.The records management system would provide the stakeholders the ability to request and receiveany 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 tomanage records in the most cost-effective manner. Serving all of the clinics, wards and offices, thisnew functionality would not only result in cost-savings, time savings and space savings, but alsowould greatly improve on records management at the hospital.The development of the records management system would also lead to better access of tooperational data. This would provide better control over the various processes and also facilitatebetter decision making.The services the system would offer would also; Save the Hospital a lot of space by reducingstorage needs for records; Save hundreds of staff-time hours by providing quick and easy access toimportant information; Save the Hospital resources used in the destruction of unnecessary records 15
  • 17. 1.6 ScopeThe scope provides for the boundary of the research in terms of depth of investigation, content, andmethodology, geographical and theoretical coverage.The system was exclusively designed and developed for the Mbarara Hospital records ManagementDepartment in general and the Maternal and Child Health (MCH) records section in particular. TheMCH records section is solely responsible for keeping medical -immunization and related recordsfor 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 itthrough any web browser programme. This serves as the user interface. The web browser supportedinterface created is dynamic and as a result backed by a database system that enables users to havethe ability to input, access, manipulate and delete data from the databaseHTML (Hyper Text Markup Language) and CSS (Cascading Style Sheets) were used as the languagesof preference for the design of user interfaces. In the interfaces, Java script was used as the clientside validation tool.PHP was used as a scripting language for linking the interfaces to the SQL database(s). PHP is aserver-side scripting language that enables one the ability to insert into a web interface instructionsthat 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 factostandard 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 fordesigning, coding, and developing websites, web pages, and web applications. Dreamweaversupports the creation of dynamic, database-driven web applications using server technologies suchas CFML, ASP.NET, ASP, JSP, and PHP. 16
  • 18. XAMPP an integrated database creation software tool was used as the software for creating theMYSQL database(s)The records management system includes the following elements;A content analysis that describes and categorizes content in the enterprise that can becomerecords, that provides source locations and that describes how the content would move to therecords management application. A method for collecting records that are no longer active fromall record sources and truncating them; A method for auditing records while they are active; Amethod for capturing records metadata and audit histories and for maintaining them; A systemfor 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. TransportationFigure 1- Organisational Structure of Mbarara Regional Refferal Hospital 17
  • 19. CHAPTER TWO- LITERATURE REVIEW1.1 OverviewIn order to understand the concepts associated with records management and or computer basedrecords management systems, it is imperative to examine and analyze published material fromexperts regarding the field. The purpose of this review is to analyze and examine and obtainexperience as regards the creation and archival processing of electronic records. The review is basedon an exhaustive assessment of the literature on computerized electronic management and electronicrecords, and contains an overview of the main concepts associated with the creation of an electronicrecords management system from the perspective of published experts.1.2 RecordsA record is recorded information produced or received in the initiation, conduct or completion ofan institutional or individual activity and that comprises content, context and structure sufficient toprovide evidence of the activity regardless of the form or medium.According to the National Archives and Records Administration (NARA) records include, “… allbooks, papers, maps, photographs, machine-readable materials, or other documentary materials,regardless of physical form or characteristics, made or received ... or in connection with thetransaction of public business and preserved or appropriate for preservation by that agency or itslegitimate 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 datain 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 aninstitutional or individual activity and that comprises content, context and structure sufficient toprovide evidence of the activity." The key word in these definitions is evidence. Put simply, a recordcan be defined as "evidence of an even. 18
  • 20. The “record” is evidence of the occurrence of a particular transaction. With a paper “record” thecontent (i.e. the writing on the page) the media (i.e. the paper) the structure (i.e. how the writing isarranged on the page) and the context (i.e. the interrelationship between the item, the file, and thebusiness in which the transaction is taking place) are all either physically linked or self-evident to thehuman eye.Records consist of content, structure and context. The three qualities must be captured andpreserved together in order to meet the requirements for “recordness”. The content must be puttogether with data about structure and context. We may call these data “metadata” (i.e. data aboutdata). 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 BusinessAcceptable Communications”, David Bearman describes a record as “a metadata encapsulated object”1.3 Electronic RecordsThe distinctive feature of electronic records is that the content is recorded on a medium and insymbols (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 "archivalfunction" which was defined as that group of related activities contributing to, and necessary foraccomplishing the goals of identifying, safeguarding and preserving archival records, and ensuringthat such records are accessible and understandable.1.4 Record FunctionsAs an organizational resource, records serve many functions in the operation of an establishmentsuch 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
  • 21. Records originating from functions or processes have always been kept together in some kind ofsystem, i.e., a “recordkeeping system”. Such systems are functioning, or have once functioned, as atool for those carrying out a process and its transactions.1.5 Records ManagementThe ISO 15489: 2001 standard defines records management as "The field of managementresponsible for the efficient and systematic control of the creation, receipt, maintenance, use anddisposition of records, including the processes for capturing and maintaining evidence of andinformation about business activities and transactions in the form of records".As records management develops, it has also incorporated principles integral to information scienceas "the means of processing information for optimum accessibility and usability, concerned with theorigination, collection, organization, storage, retrieval, interpretation, transmissions, transformationand use of information" (Vakkari and Cronin, 1992). Such principles are adopted by recordsmanagers in seeking to enhance the access and use of records.Stressing the use of technology in records management, McDonald (1995) opines that "indeveloping record keeping solutions, it is necessary to understand the evolution that is taking placein the use of technology." The application of Information and Communication Technology (ICT) tothe management of records therefore, would go a long way in making such records accessible andusable.Luciana Duranti (1996) in an attempt to explain the concept of records management and itsrelationship to record keeping systems, defines records management as the “management over time,from the creators perspective and for its purposes, of the creators records, of the means used tocontrol their creation (e.g. classification, registration, and retrieval instruments), and of the human,technological, and space resources necessary to their handling, maintenance, and preservation.” Inhis definition, Duranti relates records management to Record systems. He alludes to the fact thatRecords Management and Records Management Systems have to co-exist. 20
  • 22. 1.6 Recordkeeping SystemsRecordkeeping systems in the electronic, as well as in the paper, world are designed for the use ofoperational staff in current office operations. In the paper world, it is the archivists role to preservethis tool undisturbed for future users’ organization – (principe de lordre primitif)Luciana Duranti(1996) defines a record keeping system as comprising a set of internally consistentrules that govern the making, receiving, setting aside, and handling of active and semi-active recordsin the usual and ordinary course of the creators affairs, and the tools and mechanisms used toimplement them. According to Duranti “recordkeeping is “keeping record of action”: as such, it isthe presupposition for the existence and the first object of records management.Recordkeeping systems have concrete boundaries and definable properties, and they are critical tothe preservation of the records’ origin and evidential value. In the paper world, recordkeepingsystems 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 rightorder, at the right time for the right person at the lowest cost. For this feat to be achieved, anintegrated records management programme is needed (Baje, 1998).1.7 Databases as Recordkeeping SystemsDatabases are being used as the records management systems of preference because of theirinformational value. Such databases are created for their informational value -- as an informationresource. Statistical databases are good examples of this kind of database. Terry Cook and EldonFrost have described the first generation of databases transferred to the Canadian National Archivesas 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 beinginundated by enormous amounts of paper, but awareness that nothing was left for appraisal, if wedo not formulate fundamental principles, which make us think about a theory to guide everydaydecisions.” 21
  • 23. He continues to say that experience with electronic records sharpens our perception. Thus, the aimof (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 neededby those who create them, not as information collection but as intellectual working tools for thesteering of cooperative decision-making processes. And records are therefore reliable. The betterthey have served their primary purposes of initiating and controlling cooperative, purposeful,intellectual work, the more they are authentic and trustworthy in elucidating those processes forsecondary purposes, be it evidential or informational.According to ARMA International, a not-for-profit professional association and authority onmanaging records and information, records management systems are important because Records areinformation assets and hold value for the organization. Organizations have a duty to all stakeholdersto manage them effectively in order to maximize profit, control cost, and ensure the vitality of theorganization. Effective records management ensures that the information needed is retrievable,authentic, and accurate.1.9 ConclusionIn this “information age”, it is therefore essential that records management be done with the utmostefficiency and accuracy. This is the point at which records management is integrated with computerscience in order to develop a computer based records management system. The conclusion is thatefficient and comprehensive records keeping is as good as guaranteed when the art of recordkeeping is simulated and integrated into a computerized records management system. 22
  • 24. CHAPTER THREE- METHODOLOGY3.1 MethodologyMethodology is a term used to describe a process, technique or manner in which an action isperformed. Under the development a system, a methodology refers to the process that was taken toensure that a system is effectively and efficiently developedIn designing the records management system for Mbarara Hospital, the following systemdevelopment methodology was used.3.2 System Development MethodologyThe 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 managementsystem for Mbarara Hospital.3.2.1 Extreme Programming (XP)Extreme programming is a software development methodology which is intended to improvesoftware quality and responsiveness to changing customer requirements. As a type of agile softwaredevelopment, it advocates frequent "releases" in short development cycles. This is intended toimprove 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 inextremely 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, andcome after coding. Design is done by the same people who do the coding. The incomplete butfunctional system is deployed or demonstrated for the users. At this point, the practitioners startagain on writing tests for the next most important part of the system. 23
  • 25. 3.2.2 Extreme programming FeaturesExtreme 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 ProcessFigure 2: Extreme Programming Lifecycle 24
  • 26. 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 identifiedii. 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
  • 27. 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
  • 28. 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
  • 29. 3.3 Assumptions Made by the ResearcherThe following basic assumptions were made while designing the systemWith 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 architectureWith 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
  • 30. CHAPTER FOUR- SYSTEM DESCRIPTION4.1 System OverviewThe System encompasses all the activities associated with the recording of child immunization anddevelopment 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 recordsAll these features include the ability to create, update (edit), retrieve through search results andtruncate obsolete records. It also contains a report generation system that can be saved in a pdf fileformatThe system works in the following manner,4.1.2 Accessing the SystemA user starts the process by logging into the system by means of a valid username / passwordcombination. 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 theadministrator to access exclusive privileges such as registering new users with either limited (normaluser) or unlimited (administrative) privileges.During the process of user registration, all users are issued with a unique user name and passwordcombination as well as a specific user type (limited or unlimited). This combination is then used bythe registered user to access the system resources that fall under their privilege level. 29
  • 31. A user gains access to the system resources after a username password combination has beenverified as accurate after which they are redirected to the homepage. The system homepage serves asthe gateway to the entire records management system. Therefore, once a user is logged into thesystem 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, theamount of manipulation that a user can perform with regards to the records is dependent on userprivilege levels as explained below4.1.3. User PrivilegesThe system maintains two levels of users:- 1. Administrator Level-Database administrator 2. User Level-Data Entry OperatorAdministrator LevelThe administrator level is reserved for the database administrator. The administrator maintains theexclusive 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
  • 32. User LevelThe user level is reserved for the data entry operator. This user’s privileges are limited to onlyentering in data, specifically, data collected regularly about the children. They have the ability to addand edit data that they have access to but cannot truncate any record.4.1.4 Pseudo CodesLog 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 pageAdd 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 successfulAdding Record Enter Record Details If record exists Return record already exists If not Registration of Record successfull 31
  • 33. 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 editedDeleting 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
  • 34. 4.2. System RequirementsThe system requires a client-server architecture where a server is necessary to host the applicationand the database .The users will access the server to retrieve information from their desktopsthrough their web-based interfaces. For this to work, the following will be required;4.2.1 Non-functional RequirementsNon-functional requirements are described as the constraints on the services the system providesand 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
  • 35. 4.4 Systems ArchitectureThe system is designed in the following manner. The Records Management system has a backendengine that consists of a MYSQL database, PHP as the programming language and Apache as thewebserver and the user interface modules. The system architecture is illustrated in Figure 3 below.4.4.1 Diagram Showing the System ArchitectureFigure 3: System ArchitectureThe details of the user interfaces are displayed in the high level architectural diagram in Figure 4below. After the user login, the appropriate access rights, the user may access the system 34
  • 36. 4.4.2 High-Level Architecture Diagram of the main components Figure 4: High level architectural diagram of main components4.4.3 Logical Database DesignThe logical database design is meant to describe the representation of the database in terms of itsentities in form of tables and the existing relationships. Below is an illustration of the systems logicaldesign as generated by the MYSQL workbench design tool. 35
  • 37. Logical DesignFigure 5 : Logical design 36
  • 38. 4.5 Data RequirementsData is very important to any new system implementation testing. For this project, imaginary datawas used in the testing and demonstration purposes. The sample data was used as a reflection of theactual scenario of real life situation in the MCH section.4.6 Database (Physical Design)4.6.1 Physical Database DesignAs one of the core elements of a records management system, the database had to be designed in ameticulous systematic manner. This process started at the analysis phase of the project. From theanalysis, the researcher was able to identify the necessary tables required for the database and theassociated field names, format and length of each table. After careful analysis of the userrequirements, it was identified that the RMS needed four main tables i.e. child details, childdevelopment, immunization and the login table. However, after the process of normalization a fewsub-tables emerged from the main tables. Below is a list of these tables.4.6.2 Database TablesTable 1: Login TableAttribute Field type Length/size DescriptionLogin_id INT 11 Unique usernamePasswd VARCHAR 45 Password 37
  • 39. Table 2 : Child Details Table.Attribute Field type Length/size DescriptionChild_id INT 11 Unique identifier of the childFirst name VARCHAR 100 Child’s first nameLast name VARCHAR 100 Child’s last nameSex VARCHAR 100 SexDate_of_birth DATE Child’s birth dateMother‟s name VARCHAR 100 Child’s mother’s nameFather‟s name VARCHAR 100 Child’s father’ nameDistrict_id INT 11 Identifier of the child’ home districtReligion_id INT 11 Identifier of the child’ religionTable 3: Child Development TableAttribute Field type Length DescriptionChild_id INT 11 Unique identifier of the childCurrent height INT 11 Tallness/shortness of the childHead circumstance INT 11Milestones_reached VARCHAR 100 Development milestonesLanguage_developement VARCHAR 100Development status VARCHAR 100 Normal/abnormal growth of childRecommendations VARCHAR 100 Recommendations given after treatmentTable 4: Immunization TableAttribute Field type length DescriptionChild_id INT 11 Unique identifier of the childVaccine_id INT 11 Identifier of the vaccineVaccine_date DATE Date when vaccine is givenAge_at_vaccination INT 11 Age at which child is vaccinatedVaccine_mfr_date DATE Date when vaccine was madeVaccine_expiry_date DATE Date when vaccine will expireBody_site_id INT 11 Body site where vaccine administeredAdministrative_method_id INT 11 Method used to vaccine childNext appointment_date DATE Date of Next appointment 38
  • 40. Based on the tables displayed above, the main/core tables are linked together by one Unique keywhich is Child_id. This key serves as the primary key for the whole system implementation and helpsdistinguish information related to each patient/child.4.6.3 Data relationshipsData relationships show how the information or records are related between each other. For thetables to work together, relationships have to be established In the design of the MCH RecordsManagement system, the data relationships were established during the process of the logical datadesign.There are mainly four kinds of relationships  One to One  One to Many  Many to Many  Many to OneThese relationships are represented in the entity relationship diagram (ERD) in the next section. 39
  • 41. 4.7 ER Diagrams and DFDs4.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
  • 42. 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 databaseFigure 7: Data Flow Diagram Manage 41
  • 43. 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
  • 44. 4.9 HIPO-Hierarchical Input Process and OutputThis is a graphical illustration of the flow of events in the system; LOGIN NO Password Login username failure correct? YES Deny access User AdminChild_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
  • 45. 4.9 Data Inputs (System forms).Outputs are selected from the database based on a certain criteria and displayed using forms thatwere 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 keyforms.4.9.1 Login FormThe login form above is the first page a person accessing the system sees. It is used to gain access tothe system resources and determines, based on the user type, which users should acess whichresources Figure 10: Login form 1
  • 46. 4.9.2 User Registration Form Figure 11: User registration formThe form above was specifically desgined for the administrative account. It was designed with a viewto grant the administrator the ability to register new users. The form as displayed above, enables theadministrator to specify the user level or the account type as either user or administrator. Thisinformation is crucial during the process of logging in as it specifies what priviledges the system usershould and shouldn’t acess.4.9.3 Data Entry and Manipulation Forms Figure 12: Data Entry form for Child Details 2
  • 47. Data entry and manipulation forms in the system include the data add, delete and edit forms. Theadd and edit functions are accessible to both the administrator and normal user who is expected tobe the main data entrant. However, access to the delete forms is restricted to a user withadministrative privileges. Figure11 shows a sample of one of the add forms in the system.4.10 Data Outputs4.10.1 Data Storage InterfaceAfter the data in entered into the system, it is stored and can be retrieved at any time using thesearch functionality.Figure 13: Data Storage interface for Child Details 3
  • 48. 4.10.2 Data ReportsThe system was designed with a system of generating pdf reports for the records using the fpdfpackage. 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
  • 49. 4.10 Implementation and Testing4.10.1 ImplementationImplementation is a very important aspect in the development of any computerized system, and thisalso applies to the development of a records management system. Pro-development Implementationusually 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 documentationUnder system construction, the main task is testing. In the next section is a detailed description ofhow 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 environmentwhere the end users can use it. Exhaustive testing is conducted to ensure accuracy and reliabilityand to ensure that bugs are detected as early as possible. In the process of designing the RMS, threelevels of testing were conducted, namely, unit testing, integration testing and system testing.Unit TestUnit test is where the system is tested partially and independently, component by component, toensure that particular portion or module is workable within it. In the development of the recordsmanagement system, each component was tested independently before finally integrating each ofthem into one system. This test was used by the researcher to verify that every input of data wasassigned to the appropriate tables and fieldsMost of the modules were rather similar and therefore required a rather easy reusable testingprocess. However, the user accounts module accessible to the system administrator was one of theunique components that needed to be carefully tested in the RMS. This involved testing each usersaccess rights. This was necessary to ensure that user privileges did not overlap. 5
  • 50. Integration TestIntegration test is where a combination of several portions or components/sub components ofprograms are being tested sequentially and continuously. At this stage, all the system componentswere integrated and a test was based on how they worked together. This involved observing theinteraction of the database and the interfaces. After which the system test followedSystem TestA system normally consists of all components that makeup the total system to function. Its isrequired to ensure the smooth running of the system as a whole, and it should perform as expectedand as required. Here, technical and functional testing was performed. The technical testing involvedthe process of testing the systems compatibility with the hardware, operating system, data integrity inthe database and user authorization access rights. Functional testing was also carried out to establishhow the system would function in its intended working environment.User Acceptance TestDue to a few constraints, this part of testing was not done by the researcher, however, after the oralpresentation of the project work, the system developer intends to review the system with theintended system users so as to analyze acceptability and usability and also to identify areas that mayrequire modification before the system can fully be commissioned for use.4.10.3 System DocumentationsSystem documentation is a crucial aspect of system implementation. It provides a frame of referencewith regards to the implementation process. In designing the RMS for Mbarara Hospital, thedocumentation was done is form an integrated FAQ file that users of the system can refer to if theyhave any challenges as far as using the system is concerned. 6
  • 51. CHAPTER FIVE: EVALUATIONS & CONCLUSIONS5.1 EvaluationsIn the attempt to evaluate the designed system, it is imperative that the researcher look back at thepredefined functionalities, goals and objectives and analyze those in relation to the expectations metby the system. The Records Management System was evaluated based on the set of predefinedobjectives and expected functionalities it was able to fulfill. The Records Management System wasdesigned 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 aconsiderable portion of those expectations.The main objective was to design a system that enables faster and more efficient storage, retrievaland updating of hospital records. As far as this is concerned, the system met this expectation bygiving direct benefit to the clinic such as fast records retrieval. It also included functionalities thatenable all data entrants to access the system online with the assumption that a client-serverarchitecture is in place, retrieve records on demand and execute important reports to support dailymedical tasks.Fundamentally, the effectiveness of this project depended on meeting the project’s specificobjectives which were as follows; To carry out a feasibility study for the possibility of developing arecords management system for the MCH section of Mbarara Hospital; To design and develop arecords management system for the MCH section of Mbarara Hospital; To test and validate therecords management system for the MCH section of Mbarara Hospital and To implement therecords management system for the MCH section of Mbarara Hospital. All the objectives were metby the system, to a certain extent;Analysis was successfully completed. This evaluation is based on the fact that data requirementswere 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 userrequirements defined by the end users. The design objectives of creating an efficient records 7
  • 52. management system was further accomplished with the creation of add, delete, search and editfunctionalities in the system that not only enable computerized but rather efficient, reliable and fastdata entry. All these functionalities possess a relatively high level of accuracy. In evaluating thisobjective in relation to the system’s performance, it would therefore be accurate to state that it wasachieved to a large extent.Still while evaluating the system design and performance, the system enables the synchronization ofrecords through its server-client architecture with a single database. Therefore data entered from onerecording station will be seen on another recording station using the same system.Critical EvaluationFor an evaluation process to be fully comprehensive, it should also include a critical assessment ofthe system. Therefore, despite the fact that the findings obtained after an evaluation showed that thesystem met its expectations to a large extent, it had a few shortcomings. These limitations arediscussed in the next section.5.2 Limitations of the SystemThroughout the development of the Mbarara Hospital Records Management System, a few areaswere overlooked by the researcher. Some of these limitations can be presented as follows;UsabilityWith regard to its use, the system only caters for English speakers. The GUI and associateddocumentation is in English. This may present a problem for non- English speaking usersAccessibilityThe 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 themselvesneeded to access their electronic records via the system. 8
  • 53. SecurityThe system also does not cater for the automatic back up of the data in the database. This maypresent a security problem in the event of data loss.Static FAQ FileThe system currently has a static FAQ file. This is a limitation in the sense that the system does notgenerate the dynamically file based on the frequently asked questions.5.6 Problems EncounteredIn attempting to design the system, the following problems were encountered.Accessing Research MaterialAccessing associated research material was quite a challenge. This was particularly the case becauseof the limited variety of books and journals in relation to the research topic in the local library. Tofurther escalate the challenge, online resources were close to impossible to access due to theuniversity’s slow internet speeds that made it impossible to download books and journals.Wide project scopeDefining the project scope was quite a challenge. This is because the system was meant to bedesigned for the entire hospital including all its departments, however with a view to the limitedamount of time available for the project, the scope had to be narrowed down to one section of thehospital.Understanding Key ConceptsLimitations as far as understanding the key concepts also posed a major challenge. Considering thefact that most of the concepts were new, the researcher had to spend a considerable amount of timelearning the concepts. This took away a lot of valuable time that would otherwise be fully dedicatedto the design of the system.Programming skillsLearning PHP and MySQL requires considerable practice for one to gain the programming skills. 9
  • 54. With limited knowledge and ability, the programming progress was rather slow and this limited thenumber of functionalities that the researcher could implement into the system.Unanticipated ExpenditureAlso 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 tosubscribe for a dial-up internet connection in order to proceed with the project unhindered. Thisexpenditure was however unforeseen and therefore posed a challenge for the researcher.5.7 Recommendations/Future ResearchAs well as addressing the limitations presented in Section 5, there is scope for work to further thefunctionality and usefulness of this project. The researcher therefore made the followingrecommendations for future enhancements to the system.Widening the scopeGiven the limited amount of time given to the developer, the project’s scope was rather limited toonly one clinic in the hospital. The scope can further be widened to include all the other clinics tomake a more integrated comprehensive system that covers the entire hospital’s records managementIncluding additional components and functionalitiesA few other components can be included in the system in future. This may include the ability tocompute calculations especially when determining a patient’s next appointment, this will make thesystem more efficient and drastically minimize the amount of errors. The ability to include an uploadfunctionality for patient images could greatly enhance the usefulness of the system.Increased accessibilityThe system can also be further enhanced so that the patients themselves can be able to access theirinformation online in a secure manner; this will lead to greater doctor-patient transparency. 10
  • 55. 5.8 ConclusionIn Conclusion, from a proper analysis and assessment of the designed system, it can be safelyconcluded that the system is an efficient, usable and reliable records management system. It isworking properly and adequately meets the minimum expectations that were set for it initially. Thenew 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
  • 56. 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 Childrens 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
  • 57. APPENDIX I- PROJECT TIMELINEGANT CHART FOR THE DEVELOPMENT OF A RECORDS MANAGEMENT SYSTEM FOR MBARARA HOSPITALMonth 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 2WEEKACTI 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4Project ProposalProject PlanningProject initiationProject researchSystem designSystemdevelopmentSystem ValidationReport WritingProjectpresentation 13
  • 58. APPENDIX II- PROJECT BUDGET Amount inBudget 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.001. 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.002. COMMUNICATION Internet services 45,000 @month * 8 months 360,000.00 Sub-Total 1,160,000.003. TRAVEL Transport per month @ 20,000 * 5 developers *8 months 800,000.00 Sub-Total 800,000.004. 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
  • 59. APPENDIX III- IMPLEMENTATION CODESConnecting the interface to the databaseMain Connection CodeInterface – to-database connection Code 15
  • 60. APPENDIX IV- FINAL SUBMISSION LETTER FINAL SUBMISSION LETTERDate: 5th April 2011THE RESEARCH COORDINATORICSMUSTThru:The SupervisorMr. Richard KimeraInstitute of Computer ScienceMUSTRE: NOTICE OF SUBMISSION OF PROJECT FOR PRESENTATIONACHENG DORIS ODIT2008/BIT/033/PSBACHELOR OF INFORMATION TECHNOLOGYThis is to submit our Project, “Mbarara Hospital Records Management System- (A Case Studyof 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 OditCC:……………………………………Supervisor 16