Академический Документы
Профессиональный Документы
Культура Документы
Section [MCH])
By
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.
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.
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
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
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
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
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.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.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.
Board
Administration
Information Services
Therapeutic Services
Diagnostic Services
Support Services
Admissions Billing, etc. Med. Records Computer Info. Health Ed. Human Resource.
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
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.
20
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
24
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
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
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,
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
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.
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
33
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
35
Logical Design
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.
These relationships are represented in the entity relationship diagram (ERD) in the next section.
39
username password
username
password
*:1
has
*:1 *:*
does
manages Manages
Does
*:* login
*:* login
40
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_registration database
Add_new database
Back up database
LOGIN
Valid login
NO
details YES
IDENTIFY USER TYPE
User type
NO
admin
YES REDIRECT TO ADMIN ACCOUNT
LOGOUT
END
42
NO
Login failure
YES
Deny access
User
Admin
Child_D
Child_DD
Immun
vaccine
District
Body site
User
Add vaccine
Add district
Add user
Delete vaccine
Edit vaccine
Del admn
Delete disease
Edit disease
Del district
Edit district
Del religion
Edit religion
Del user
43
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.
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.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.
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.
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.
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.
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
12
WEEK ACTI Project Proposal Project Planning Project initiation Project research System design System development System Validation Report Writing Project presentation
13
1. EQUIPMENT
2. COMMUNICATION
Airtime 5000 @ week for 32 weeks * 5 developers Internet services 45,000 @month * 8 months Sub-Total
3. TRAVEL
GRAND TOTAL
UGX 3,883,000.00
14
15
CC: Supervisor
16