DEVELOPMENT OF A SOFTWARE FOR MANAGING AND MAINTAINING OF  BLOOD TRANSFUSION RECORDS AT UGANDA BLOOD TRANSFUSION CENTRE

ABSTRACT

The topic of study was to development of a software for managing and maintaining of blood transfusion records at Uganda blood transfusion center, the study was guided by the following objectives; to determine key technical requirements for designing medical equipment system, to critically perform an analysis of the requirements of the system, to design a medical equipment system that is able to store, plan and generate service prompts and to implement a medical requirement system.

A safe and adequate blood supply cannot be assured without equipment. Maintenance has a very important part to play during the life cycle of a medical equipment or device; it maximizes the performance of the device. Maintenance ensures that an equipment operates regularly and efficiently, by attempting to prevent and minimize the losses incurred by breakdowns or failures. This research was a descriptive cross-sectional study. Observations, document review and Focus Group Discussions (FGDs) were used to collect data from equipment users and engineering unit staff. The study area was Nakasero Regional Blood Bank (UBTS headquarters).

The project also used questionnaire and interviews to get information regarding the interests of the employees of the organization.Using Krejcie and Morgan’s (1970) table for sample size determination approach, a sample size of 35 employees was selected from the total population of 40 employees

The purpose of this project was to collect data on system requirements, analyze and then design and implement a computerized maintenance management system (CMMS). The system serves all regional blood banks across the country. An agile software development approach was used to develop the computerized system. UBTS manual process of equipment maintenance was studied, observed and adopted into the system. The result of this process was a computer system that was developed in C# with a backend that can be deployed in the internet’s cloud.  The client uses a Desktop Application which can be installed on the end-user’s computer to access the online system. This system provides a solution that can efficiently organize, store and analyze the maintenance and repair information for UBTS. Analyzed information is needed to budget, repair and service medical equipment in the shortest time possible.

CHAPTER ONE

  INTRODUCTION

1.1   Background

Uganda Blood Transfusion service (UBTS) is the ministry of health’s semi-autonomous department responsible for making safe and adequate blood available for all hospitals and health centers in Uganda. UBTS has a centrally coordinated blood service with decentralized network of seven regional blood blanks and six collection centers. UBTS heavily relies on medical equipment for analyzing, processing and storing all the blood that is collected. Hence downtime of this equipment must be low or none because a safe and adequate blood supply cannot be assured without equipment. One of the most common causes of medical devices’ breakdown and downtime is poor maintenance (WHO, 2011).

One of the ways to ensure low or none equipment downtime is by purchasing good equipment and doing routine maintenance for installed equipment, It is the responsibility of the biomedical engineer to recommend and test all the new equipment and approve it prior to installation (Weimer,, Tagny, , Tapko, , Ness, & Bloch, 2019). The engineer manages, maintains and repairs the equipment that have already been installed. For equipment that needs specialized maintenance or repair, it is still the biomedical engineer’s responsibility to make sure that the work is performed in a timely manner by a qualified contractor. In other words, the engineer is responsible for planning maintenance, maintaining equipment and taking inventory for all the equipment at UBTS facilities. Currently, the department has only one biomedical engineer who is supposed to carry out all these tasks. On top of being understaffed, the engineer does all the documentation by hand, excel sheets and Microsoft Word. This process is tiring, time consuming and prone to human error.

As medical devices become more sophisticated and play a more crucial role in modern healthcare, maintenance issues demand ever-increasing attention, The most critical problems facing medical equipment is frequent breakdown and downtime e (Campbell, 2016). Computerizing the management of maintenance information can solve this problem for the engineer. Maintenance has a very important part to play during the life cycle of an item or device. It maximizes the performance of the device by ensuring that it operates regularly and efficiently, by attempting to prevent breakdowns or failures, Maintenance also minimizes the losses incurred by breakdowns or failures, Computerized Maintenance Management Systems (CMMS) are software products that help companies run their maintenance operations efficiently (Uyoga, et al., 2021) and with these systems, companies can plan preventive maintenance, manage corrective maintenance, track machine hours, tires and other consumables, monitor warranty periods, track labor and fuel costs and manage inventory

Development of CMMS is essential for managers and engineers, not only to provide quick management solutions, but also to predict future outcomes based on historical device’s performance data Fouad et al., (2012) Computer Maintenance Management System (CMMS): are tools for Planning and scheduling equipment maintenance and asset management to meet the needs of modern plants and facilities (Labib, 2008). CMMS software notifies operations personnel when maintenance or other action is necessary. The literature and systems developed for computerized maintenance management have so far focused on the maintenance procedure for a specific organization or are too sophisticated to be used and maintained at UBTS. To my knowledge, there is no computerized maintenance system that has been designed and developed to support the maintenance management at UBTS. A customized CMMS has thus been designed and developed to adapt well with the equipment maintenance process at all the UBTS facilities. The system has the features for; inventory taking, fault reporting, work order managements, preventive maintenance scheduling and maintenance reporting.

1.2 Problem Statement

UBTS has over 300 medical equipment spread all over the country in the 6 different regional blood banks and eleven collection centers. Medical equipment are very critical in collection, storage, screening, grouping and separation of blood. Proper maintenance of medical equipment is needed in order to meet the increased demand for safe blood transfusion. Poor value management processes and untimely equipment maintenance has caused equipment breakdown by more than 20% and prolonged down time to 6 months (UBTS equipment manual). Untimely equipment maintenance has caused workflow delays, increased equipment maintenance costs and compromised medical equipment quality. There is need for a system to schedule maintenance in order to improve planning and quality of medical equipment. The primary uses of the system will be to store equipment information, plan maintenance by acting as work maintenance planning tool and generate service prompts.

1.3 Objectives

1.3.1 Main Objective

To practically develop a medical equipment maintenance management system.

1.3.2 Specific Objective

1. To determine key technical requirements for designing medical equipment system.
2. To critically perform an analysis of the requirements of the system
3. To design a medical equipment system that is able to store, plan and generate service prompts.
4. To implement a medical requirement system.

1.4 Research Questions

1. To determine key technical requirements for designing medical equipment system.
2. To critically perform an analysis of the requirements of the system
3. To design a medical equipment system that is able to store, plan and generate service prompts.
4. To implement a medical requirement system.

1.5 Justification

Maintenance costs are a major part of operating costs for many industries. Depending on the industry they can be up to 50% of total production costs (Campbell, 2016). Additionally, downtime caused by poor maintenance can cause even bigger cost due to rework, rejected products, fines and damage to company reputation. Especially in capital-intensive businesses, the profitability of the business is tightly related to proper maintenance. For these reasons, it is important for companies to have an optimized maintenance management strategy that is both cost effective and ensures reliable operation of the equipment (Campbell, 2016). Therefore Medical Equipment Maintenance Management System (MEMMS) contributes towards quality of medical equipment in UBTS which also contributes to the achievement of the Sustainable Development Goals 3 and 5 and the Agenda 2063 aspiration of having a prosperous Africa, based on inclusive growth and sustainable development with healthy and well-nourished citizens. The system will have three core functions: medical equipment inventory and maintenance history, scheduling of Planned Maintenance (PM) for medical equipment, generation of management reports. Repair requests will be generated by equipment users and planned preventive maintenance schedule will help to show the equipment that are due for service. The system will help to reduce equipment downtime and ensure timely maintenance of equipment.

1.6 Scope of the Research

UBTS medical equipment are used for collection, screening, storage, grouping and separation of blood. This work will involve studying the existing system in UBTS and proposes a computer based medical equipment maintenance management information system. The proposed system should be able to assist management through keeping an accurate inventory of equipment. The system will have an equipment database, schedule preventive maintenance, and generate prompts for service.  The output of this research is   a functional prototype that can be used to demonstrate and evaluate how such a system can be implemented .Based on the findings, recommendations for future development can then be given. The study will take a period of 6 months.

1.7 Conceptual Framework

The Figure 1 below summarizes the conceptual framework for the proposed computerized management system for UBTS. The framework shows the entities involved in the maintenance management process and the relationships amongst them. The entities are drawn from the research literature in computer maintenance management systems. Seven entities related to maintenance management are summarized in the framework in figure 1: Engineer, Technician, User, Equipment, Spare parts, Fault, Maintenance. These entities originate from the medical equipment maintenance management practices and process as described in the ministry of health’s operation manual for regional medical equipment maintenance workshops and Medical Equipment Maintenance Guidelines (2013). The entities are represented as labeled rectangles. The relationships between entities explain how the entities interact with each other in form of information sharing. These relationships are represented as labeled diamond shapes.

Figure 1: MEMMS entity relationship model conceptual framework.

1.8 structure of research report

The report has abstract then chapter one which first introduces the research topic by giving background information followed by problem statement, objectives, research questions and conceptual framework. Chapter two is composed of literature review of system design methodologies, system requirements gathering and analysis methods, hardware and software specifications, maintenance information systems follow conceptual framework. Chapter three has research methodology, results, discussion of results. References follow methodology and after references, appendices are the final section of the proposal which contains the system user manual.                         

CHAPTER TWO

LITERATURE REVIEW

2.1 Introduction

The literature review presents an evaluation of existing research related to maintenance management systems and describes how the proposed research is related to prior research. It justifies the proposed methodology after reviewing different system life cycle methodologies. It shows the existing research gaps that need to be covered by looking at drawbacks in the current systems.

2.1.1 Overview maintenance management system

Everyone knows that blood is vital for human life. This knowledge goes far back in time recognizing the association between blood loss and severe illness or even death. Blood has also been surrounded by ideas of having magical power, carrying personality traits or being subject for contamination with demons and evil forces. Already during the Roman era blood loss, by opening veins, was used as a way to commit suicide and during the same era people drank blood from dead gladiators with the aim to gain their strength and courage. In the literature, vampires symbolize the importance of blood trying to achieve eternal life by drinking blood from a human being.

The circulation system was described in the 17th century and understanding that the heart was pumping out volumes of blood into the vessels changed the idea of replacing blood by drinking to instead infuse blood directly in the vessels. Initially transfusion was used to treat different states of madness or in order to gain positive properties from the person donating the blood. Not until 1749 was transfusion proposed as a specific treatment for bleeding conditions. Several scientists experimented with transfusions between animals and between animals and humans. Although some of these experiments succeeded, many animals and persons died and adverse reactions like fever, gastrointestinal symptoms and dark urine were described and as a result the maintenance and management of blood transfusion system has evolved in several parts of the world however some other parts have lagged behind (chou, Chen, Shen, Yen, & Kuo, 2019), Examples of techniques widely used to optimize maintenance costs include Reliability Centered Maintenance (RCM), root cause failure analysis and preventive and predictive maintenance (PM) (Bogdan et al., 2018), Understanding of functional failures of equipment and how these present themselves in an operational environment has improved dramatically. Generic preventive maintenance tasks and typical maintenance intervals are used as a main source when developing preventive maintenance programs.

The wide spread usage of Computers and information technology systems have expanded preventive maintenance programs scope of application all over the world, Maintenance is one of the most important functions of the total logistic support.  Information technology (IT) is an important tool for reaching efficiency and effectiveness within maintenance, provided that correct and applied (Kovacic & Bogdan, 2018) Benefits of a computerized maintenance management systems (CMMSs) are: better cost management and audibility, ability to schedule maintenance; and reduction of breakdowns through improved reliability of equipment the application of an effective maintenance programme, Blood and its components are very significant for human life and therefore blood transfusion can be a life-saving intervention. There are multiple factors that contribute to shortfall in provision of blood including deficient donor recruitment, poor stock management and transportation (Selcuk, 2018), the demand for blood surpasses the blood supply in many countries. World Health Organization (WHO) data indicated that 87.5 % of developing countries collect less than half of the blood needed to meet the transfusion requirements of their populations. Studies on developing countries reported that most of the limited blood supplies are used for complications of pregnancy and childbirth, trauma and severe anemia in childhood (Maitland et al., 2019).

Many factors lead to wastage of blood products like broken bag, broken seal, expired units, returned after 30 min, clotted blood or miscellaneous reasons which is most importantly due to lack of proper knowledge and awareness (Bartonjo & Oundo, 2019), According to the “30-minute rule” and guidelines for blood transfusion in the UK recommend that if RBC units are out of controlled temperature storage for more than 30 min, they should not be put back into storage for reissue. The justification for this rule is that once RBC units are out of controlled temperature storage, the component warms up, and the risk of bacterial proliferation increases with time (Ewer, Aley, Angus, Belij-Rammerstorfer, & Hamlyn, 2020.)

Ideally in a proper setting, outdating and wastage of blood and blood products would never occur. Due to the inherent need to have blood stocks at all times and also often unpredictable demands on the inventory, a very limited and inevitable outdating of components in blood bank is accepted. Studies claim that through target interventions and adherence to strict guidelines, a significant reduction in the wastage of blood components could be achieved and maintained (Keleta, et al., 2019) Globally only 106 countries have national guidelines on the appropriate clinical use of blood and blood products.

The efficient coordination of blood transfusion services at national level is a prerequisite for an effective and sustainable national blood screening programme. It is also required for the uniform application of national standards and procedures across an entire country. Coordination is essential to maintain continuity in operations and consistency in performance in all facilities in which screening is performed, including blood centers and hospital-based services. Each screening facility requires a specific and sufficient budget, a suitable infrastructure, with reliable water and power supplies, well-maintained equipment and efficient transportation and telecommunications systems (Maitland, et al., 2019).

Blood transfusion is a lifesaving therapy that is included on the World Health Organization (WHO) list of essential medications. In sub-Saharan Africa (SSA), blood transfusion is critical to the treatment of diverse pathologies including malaria-associated anemia, obstetric hemorrhage, and trauma. However, access to a safe and adequate blood supply remains an enduring public health challenge in much of SSA (Uyoga, et al., 2021).

A WHO strategy of universal safe blood transfusion has focused on five main areas: 1) development of nationally coordinated blood transfusion services, 2) exclusive collection from voluntary no remunerated blood donors (VNRBDs), 3) quality-assured donation testing, 4) reduction of inappropriate clinical use of blood, and 5) implementation of quality systems and standards. Efforts to address these areas of deficiency in the early 2000s were spurred by external funding, much of which was provided through the US President’s Emergency Plan For AIDS Relief (PEPFAR). Given increased exposure and robust external support, the outlook for transfusion safety in SSA from 2000–2010 appeared to be bright. We sought to review subsequent developments and challenges to regional transfusion safety in SSA (Asamoah-Akuoko, 2018).

Greater efficiency and safety can be achieved by bringing together key blood screening activities into a network of strategically located central and/or regional blood Centres with well-trained staff, suitable equipment and efficient procurement and supply systems, by facilitating economies of scale, this enables overall costs to be minimized without compromising quality. Conversely, the screening

It is the responsibility of governments to assure a safe and sufficient supply of blood and blood products for all patients requiring transfusion (1). Each country should formulate a national blood policy and plan, as part of the national health policy, to define how safe blood and blood products will be made available and accessible to address the transfusion needs of its population, including how blood transfusion services will be organized and managed (Appiah, Burdine, Aftab, Anum, & Kretchy, 2018). The provision of safe and efficacious blood and blood components for transfusion or manufacturing use involves a number of processes, from the selection of blood donors and the collection, processing and testing of blood donations to the testing of patient samples, the issue of compatible blood and its administration to the patient. There is a risk of error in each process in this “transfusion chain” and a failure at any of these stages can have serious implications for the recipients of blood and blood products. Thus, while blood transfusion can be life-saving, there are associated risks, particularly the transmission of bloodborne infections (Tsuung, 2016).

Screening for transfusion-transmissible infections (TTIs) to exclude blood donations at risk of transmitting infection from donors to recipients is a critical part of the process of ensuring that transfusion is as safe as possible. Effective screening for evidence of the presence of the most common and dangerous TTIs can reduce the risk of transmission to very low levels, Blood transfusion services should therefore establish efficient systems to ensure that all donated blood is correctly screened for specific TTIs and that only non-reactive blood and blood components are released for clinical and manufacturing use. The adoption of screening strategies appropriate to the needs, infrastructure and resources of each country can contribute significantly to improvements in blood safety and tis is mainly to solve the current challenges that lead to a recent report from the International Surveillance of Transfusion-Associated Reactions and Events database (STARE) has 409 deaths between 2006 and 2013 – an estimated rate of 0.3 per 100,000 components issued (Yooda, et al., 2019).

Nevertheless, a significant proportion of donated blood remains unsafe as it is either not screened for all the major TTIs or is not screened within a quality system. Data on blood safety indicators provided in 2007 by ministries of health to the WHO Global Database on Blood Safety (GDBS) indicate that, of the 155 countries that reported performing 100% screening for HIV, only 71 screen in a quality-assured manner, Concerted efforts are still required by a substantial number of countries to achieve 100% screening of donated blood for TTIs within quality systems, Laboratory screening of donated blood is the step that determines whether or not a donation is non-reactive for specific markers of infection and is therefore safe to release for clinical or manufacturing use. Each country should decide on the TTIs to be screened for as part of the blood screening programme and develop a screening strategy appropriate to its specific situation. This will be influenced by the incidence and prevalence of infection, the capacity and infrastructure of the blood transfusion service (BTS), the costs of screening and the available resources. The critical factor is that whichever strategy is selected, it is implemented effectively, consistently and within a well-managed quality system (Bartonjo & Oundo, 2019)

According to (Bloch, et al., 2012) the demand for blood or its products is largely driven by variety of factors that among these are hemorrhage during child birth, RTAs, Malnutrition, sickle cell anemia and HIV/AIDS among others. Advances in medical techniques have made it possible to treat many serious illness and wounds and this have resulted in a corresponding climb in the demand for blood transfusion in order to support patient’s recovery and to maintain health (WHO, 2010). Management of blood and its products in Uganda is being done by the Blood Transfusion Service (NBTS), which is a non-profit making governmental organization in charge of mobilizing communities to donate blood, blood collection, laboratory processing, testing and it distribution to donors. The main motivation of a Blood Bank Management System is to ensure the availability of the appropriate kind of blood types and its products. When required for transfusion. This can be summarized as follows; to minimize the waste of blood or its products and to enhance the availability of various products (RBC, Plasma and platelets) (Mremi, Yahaya, Nyindo, & mollel, 2021).

2.1.1 Work Order Management

Work orders are used to initiate, track, and record all maintenance related activities. Work orders start as requests, which are then approved, the work is planned and scheduled, performed and finally recorded. Work orders contain detailed data about the maintenance in question and they produce valuable information on maintenance performance, costs and equipment history. Among the information tracked with work orders are: maintenance tasks and their start and completion dates, information about who performed the work ,life cycle information: where the work order originated from, when it was scheduled, approved, performed etc. After the work order has been completed the information can be used to track maintenance costs for the equipment. The two main types of expenses that are tracked are time and material charges. Work order backlog is useful for determining staffing requirements and shutdown periods (Wireman, 2013).

2.1.2 Equipment management

Equipment management contains information about each equipment in the system including subcomponents and even individual parts. The information can include basic information about the equipment such as identifying information, categorization information, and instructions, blueprints and pictures. It is also used to record the maintenance history of the equipment: the preventive and corrective maintenance done to it, what parts were replaced and when and what the downtime of the equipment has been. This enables analysis of equipment performance and maintenance costs  (Werktetter & Korponay-Szabo, 2017).

2.1.3 Preventive maintenance module

The preventive maintenance module is used to create preventive maintenance plans for the equipment. The plans include service tasks to be performed for certain equipment at predetermined intervals of time. These plans are then used by the system to automatically create work orders for equipment. The system can schedule work based on calendar time such as daily, weekly, monthly or yearly or based on a certain meter reading i.e. every 1000h machine hours. To be able to schedule maintenance based on meter readings the system needs to support logging of meter readings. They can be entered into the system manually or they can be uploaded automatically (Wireman, 2013).

2.1.4 Planning and scheduling

One of the most important functions of a CMMS is planning and scheduling maintenance work. Planning of maintenance is strategic and refers to the design of maintenance work over time and how it will be done. Scheduling, on the other hand, is tactical and refers to what work will be done on what day and with what resources. For CMMS, planning refers to determining the maintenance policy for assets, including preventive maintenance pro-grams, tasks, parts, and resources required for maintenance. Scheduling in CMMS refers to developing daily, weekly and monthly schedules, determining priorities for work, assigning maintenance work to technicians and maximizing asset availability (Plant Services, 2010).

2.1.5 CMMS drawbacks

Virtually no CMMS offers decision support. This is a definite problem, because the key to systematic and effective maintenance is managerial decision-making that is appropriate to the particular circumstances of the machine. This decision-making process is made more difficult if the CMMS package can only offer an analysis of recorded data. When a certain preventive maintenance (PM) schedule is input into a CMMS, for example to change the oil filter every month, the system will simply produce a monthly instruction to change the oil filter and is thus no more than a diary (Labib, 2008).

2.2 System Development Life Cycle

System Development Life Cycle (SDLC) has planning, analysis, design, and implementation as the four stages followed when developing an information system (Dennis, 2013). Planning phase is the fundamental process of understanding why an information system should be built and determining how it will be built. The analysis phase answers the questions of who will use the system, what the system will do, and where and when it will be used. The design phase decides how the system will operate in terms of the hardware, software, and network infrastructure;  user interface, forms, and reports that will be used; and the specific programs, databases, and files that will be needed. The final phase in the SDLC is the implementation phase, during which the system is actually built (or purchased, in the case of a packaged software design and installed).

2.3 System Development Methodology (SDM)

SDM refers to the framework that is used to structure, plan, and control the process of developing an information system(Casteren, 2017). The following are the some of the well-known systems development methodology:

2.3.1 System Prototyping

This is a development methodology that implies designing an early version of the system before attempting to build the final system then gradually developing it to meet the user need. This method emphasizes is on getting a working version of the application to the user as fast as possible; the user is involved throughout the process, which increases the chance of the user accepting the final implementation (Casteren, 2017).

Prototyping is defined as the process of developing a working replication of a product or system that has to be engineered. It offers a small scale facsimile of the end product and is used for obtaining customer feedback as described below:

This model is used when the customers do not know the exact project requirements beforehand. In this model, a prototype of the end product is first developed, tested and refined as per customer feedback repeatedly till a final acceptable prototype is achieved which forms the basis for developing the final product. In this process model, the system is partially implemented before or during the analysis phase thereby giving the customers an opportunity to see the product early in the life cycle. The process starts by interviewing the customers and developing the incomplete high-level paper model. This document is used to build the initial prototype supporting only the basic functionality as desired by the customer. Once the customer figures out the problems, the prototype is further refined to eliminate them. The process continues until the user approves the prototype and finds the working model to be satisfactory (Steinke et al., 2018).

2.3.2 Waterfall model

Project is divided into sequential phases, with some overlap and splash back acceptable between phases.  Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time. Tight control is maintained over the life of the project through the use of extensive written documentation, as well as through formal reviews and approval/signoff by the user and information technology management occurring at the end of most phases before beginning the next phase (Singh et al., 2015).

2.3.3 Agile methodology

All Agile Methodologies share common characteristics, a focus on interaction, communication, and the reduction of resource-intensive intermediate artifacts. Agile development also requires close customer partnerships, agile process models stress on agility for software development. Agility means responding to changes quickly and efficiently. Possible changes required in software projects are in requirements, budget, schedule, resources, technology and team. These are ‘‘reacting’’ changes on which agile models stress for a successful software project, Concerning architectural design, not a key value in Agility, flaws or errors that seriously compromise the integrity of the design are more costly to correct when detected late in the development process (Qureshi, 2018).

2.4 Gathering & analysis of system requirements

Requirements gathering in Information Systems allows for a better understanding of the requirements gathering process and its effectiveness .

Requirements gathering can be broken down three categories i.e. business requirement, User requirement and system requirements which can be summarized into functional & non-functional Requirements. Functional Requirements specify which outputs should be produced from the given inputs. They describe the relationship between the input and output of the system. For each functional requirement, a detailed description of all the data input and their source, the units of measure and the range of valid inputs are given (Labib, 2008). Non-functional requirements describe the desired quality features of the system to be developed such as availability ,usability, reliability and system performance among others (Johansson & Lahtinen, 2013).

 2.5 Techniques for Requirement Elicitation

Requirement elicitation techniques can be divided into four categories according to their nature of communication – traditional, contextual, collaborative and cognitive.

2.5.1 Traditional Techniques:

1. a) Interview: Face-to-face interview is a data collection method when the interviewer directly communicates with the respondent in accordance with the prepared questionnaire (Polak & Green, 2015) This method enables to acquire factual information, consumer evaluations, attitudes, preferences and other information coming out during the conversation with the respondent. Thus, face-to-face interview method ensures the quality of the obtained data and increases the response rate. In this is a method of identifying facts and opinions of users and other stakeholders of the system under development by face to face conversation. There are two different kinds of interviews: The closed interview, where the requirements elector has a pre-defined set of questions and is looking for their answers. The open interview, where the requirements engineer and stakeholders discuss in an open-ended way to find out their expectation from a system
2. b) Questionnaire: this is a technique of eliciting requirement from a large number of people in lesser cost and time. A well designed questionnaire can be useful to elicit the actual requirements from the stakeholders. Data gather from existing system is used when we gather data for a system to replace an existing one. It is a useful technique to collect the depth knowledge of the system Questionnaire Survey method was used to obtain the opinion of the respondents regarding the topic under study, according to (Krosnick, 2018) states that questionnaires are important in research because the respondents are given time to think and they don’t feel intimidated.
3. c) Survey: this is a technique of eliciting requirement from a large number of people. It covers the entire region to collect a huge set of requirements. It is generally used for collecting requirement for general purpose software.

2.5.2 Collaborative Techniques:

1. a) Focus Group: It is a technique where a group of four to nine users from different back-grounds, with different skills discuss in a free form, and concerns about features of a system that will be created.
2. b) Brainstorming: It provides an open environment of discussion, where users are free to give their requirement and expectation of the system. The data (ideas) collected after this process is then discussed and analyzed.
3. c) Prototyping: A prototype of a system is an initial buildup of the system which often used to validate system requirement. There are two different types of prototypes: Throw-away pro-to types help to understand difficult requirement. Evolutionary prototypes deliver a working system to the customer and often become a part of the final system. (Abdalhamid & Mishra, 2017).

2.5.3 Cognitive Technique

 Document Analysis: this process analyzes the documents related to the problem domain to gather the information which is flowing in the organization. It is a useful technique to find in-depth knowledge about a particular task, this was used to supplement the data that acquired from the interviews and questionnaires. The researcher analyzed the documents and publications related to the study topic. Documents that are expected to be reviewed include URA reports, Journals, and Newspapers (Tight, 2019)

2.5.4 Observational Technique

It involves an investigation of user’s work and taking notes on the activities that takes place. Observation may be either direct or indirect. Observation allows the observer to view what users actually do in context, overcoming issues with stakeholders, describing idealized or oversimplified work processes (Mackieson, Shlonsky, & Connolly, 2019).

2.6 Requirements Analysis Strategies

There are several strategies that the analyst can employ with the stakeholders to accomplish requirements analysis.

2.6.1 Problem Analysis

The most straightforward (and probably the most commonly used) requirements analysis strategy is problem analysis. Problem analysis means asking the users and managers to identify problems with the as-is system and to describe how to solve them in the to-be system. Improvements from problem analysis tend to be small and incremental, this type of improvement often is very effective at improving a system’s efficiency or ease of use (Levenson, 2018).

2.6.2 Root Cause Analysis

It focuses on problems first rather than solutions. The analyst starts by having the users generate a list of problems with the current system, then prioritizes the problems in order of importance. The key point in root cause analysis is to always challenge the obvious and dig into the problem deeply enough that the true underlying cause(s) is revealed (Levenson, 2018).

2.6.3 Outcome Analysis

Focuses on understanding the fundamental outcomes that provide value to customers. With this approach, the system analysts encourage the managers and project sponsor to pretend that they are customers and to think carefully about what the organization’s products and services enable the customers to do and what they could enable the customer to do (Khandelwal, et al., 2017).

2.7 Hardware and Software Specification

The hardware and software specification is a document that describes what hardware and software are needed to support the application. When a specification document is created, the hardware needed to support the future system is listed and then described in as much detail as possible. Next, the software to run on each hardware component is written down, along with any additional associated costs, such as technical training, maintenance, extended warranties, and licensing agreements (Bartonjo & Oundo, 2019).

2.8 Spiral method

The spiral model is a systems development lifecycle (SDLC) method used for risk management that combines the iterative development process model with elements of the Waterfall model. The spiral model is used by software engineers and is favored for large, expensive and complicated projects. When viewed as a diagram, the spiral model looks like a coil with many loops. The number of loops varies based on each project and is often designated by the project manager. Each loop of the spiral is a phase in the software development process.

Spiral model example

The spiral model enables gradual releases and refinement of a product through each phase of the spiral as well as the ability to build prototypes at each phase. The most important feature of the model is its ability to manage unknown risks after the project has commenced; creating a prototype makes this feasible.

Spiral model phases

When looking at a diagram of a spiral model, the radius of the spiral represents the cost of the project and the angular degree represents the progress made in the current phase. Each phase begins with a goal for the design and ends when the developer or client reviews the progress.

Every phase can be broken into four quadrants: identifying and understanding requirements, performing risk analysis, building the prototype and evaluation of the software’s performance.

Phases begin in the quadrant dedicated to the identification and understanding of requirements. The overall goal of the phase should be determined and all objectives should be elaborated and analyzed. It is important to also identify alternative solutions in case the attempted version fails to perform.

Next, risk analysis was performed on all possible solutions in order to find any faults or vulnerabilities such as running over the budget or areas within the software that could be open to cyber-attacks. Each risk was then resolved using the most efficient strategy.

In the next quadrant, the prototype is built and tested. This step includes: architectural design, design of modules, physical product design and the final design. It takes the proposal that has been created in the first two quadrants and turns it into software that can be utilized.

Finally, in the fourth quadrant, the test results of the newest version are evaluated. This analysis allows programmers to stop and understand what worked and didn’t work before progressing with a new build, At the end of this quadrant, planning for the next phase begins and the cycle repeats. At the end of the whole spiral, the software is finally deployed in its respective market.

Component analysis

The main idea of the component-based approach is building systems from already existing components. This assumption has several consequences for the system lifecycle;

−    Separation    of    development    processes.    The development processes of component-based systems are separated from development processes of the components; the components should already have been developed and possibly have been used in other products when the system development process starts.

−    A new process: Component Assessment. A new, possibly separated process, finding and evaluating the components appears. Component assessment (finding and evaluation) can be a part of the main process, but many advantages are gained if the process is performed separately. The result of the process is a repository of components that includes components’ specifications, descriptions, documented tests, and the executable components themselves.

−    Changes in the activities the development processes. The activities in the component-based development processes are different from the activities in non-component-based approach. For the system-level process, the emphasis will be on finding the proper components and verifying them. For the component-level process, design for reuse will be the main concern.

2.8 Summary of literature

Maintenance cost on a global scale is estimated at 9% of an estimated world Gross Domestic Product (GDP) of 45,000 billion AUD, Virtually no CMMS offers decision support. This is a definite problem, because the key to systematic and effective maintenance is managerial decision-making that is appropriate to the particular circumstances of the machine. This decision-making process is made more difficult if the CMMS package can only offer an analysis of recorded data, Agile System development methodology is best suitable for developing the maintenance management system because other methodologies have limitations; system prototyping is expensive and may not have sufficient checks and balances incorporated because the working version of the application is got to the user as fast and possible. Waterfall is inflexible, slow, costly, cumbersome and difficult to respond to changes, spiral methodology is challenging to determine the exact composition of development methodologies for use for each iteration around the spiral (Syukur, 2015) Requirement elicitation techniques are many but each has advantages and limitations; interview enables researcher to have face to face conversation with participant though consumes a lot of time, questionnaires and Focus Group Discussions (FGDs) are used to collect system user requirements from a large number of people in a lesser time and cost, surveys collect requirements for general purpose software systems, brainstorming provides an open environment for discussion, document analysis is useful in finding in-depth knowledge about a particular task and observation enables investigation of the user’s work and taking notes on the activities taking place. Problem analysis is the best strategy for requirements analysis when developing a system because of its effectiveness at improving a system’s efficiency or ease of use unlike root cause analysis which focuses on problem first rather than solutions, outcome analysis focuses on understanding the fundamental outcomes that provide value to customers and technology analysis only identifies how each and every technology could be applied to the business process and how the business would benefit.

CHAPTER THREE

METHODOLOGY

3.1 Research Approach

The study will analyze the following objectives; to determine the both the user and systems requirement, to analyze the requirements of the system and to design and implement the system.

3.1.1 To determine both the user and systems requirement

To determine the user requirement the researcher will design a set of questions and interviews to the respondents and this will enable them to answer the questions that is in line with their interests and also enable the researcher to design the appropriate system that is in line with the interest of the people.

The questionnaire will be designed using the 5 point Likert scale

A five point Likert ordinal scales ranging from; strongly agree which shall be assigned 5, strongly Agree, 4 agree, Not Sure assigned 3, disagree allocated 2 and strongly disagree allotted 1 to obtain responses on the variables. The Likert ordinal scale has been used by numerous scholars who have conducted similar studies such as (Taherdoost, 2016) The structured questions will be measured using the following variables;

1. Determining the user requirements.

In order to determine the user requirements the questions will be asked to the users as to what they wish to have in the system and this will answered by the respondents therefore the researcher went ahead and implemented this questionnaire responses in the system designed.

The interviews were also held with the respondents who provided needed information for the design of the system.

1. Systems requirement

The system requirements were determined by the scientific knowledge available and the different technologies which has been developed. This was considered when designing the system.

Objective one the second part: The requirements of the system.

In order to determine the requirement of the system there was scientific analysis and experimentation performed by the researcher. The understanding of maintenance management system of the organization was critical to work out this objective.

MEMMS is an information management system that will have data (text format) as input and it was also output data in text format. The system data inputs will be user information, inventory, suppliers and contractors, equipment faults and maintenance reports. The user information shall include users’ login credentials like; username and password and new user registration details. The inventory data shall include the equipment details and their location and the spare parts for the equipment available in stock. The suppliers and contractors’ details will include their addresses and contact information and the equipment supplied and jobs done. Equipment faults shall be reported by the equipment users and the maintenance work that is done on the equipment shall be entered by the technicians in form of maintenance reports.

The input data shall be processed by the system and outputs returned after the processing of the data. There are finite processes that the system shall be carrying out specific to the data input and these processes are system user management, equipment inventory management and work order processing. The system user management shall receive the user information, check if the user is registered and authorize the user to log into the system. It shall also handle new users’ registration. The Equipment inventory management process shall handle registering equipment and their working conditions, and registering of spare parts’ consumption associated with each intervention.  The work ordering process shall schedule maintenances based on the faults and routine maintenance, and notify the technicians responsible for the work to be done.

The system outputs shall also be in form of data (textual output). The system shall output this information after the processes and different processes shall output different data. The system user management shall output user authentication which gives the user what information they can access, the equipment inventory management shall output the spare parts management which shall be based on the spare parts consumed on a specific maintenance job and this will contribute to identify which maintenance policy is more adequate. This process shall also produce an inventory list with all the working conditions of the equipment registered. The work order processing shall produce work orders for which equipment needs maintenance and what needs to be done, a maintenance schedule for the work orders and an equipment performance report which will reflect the maintenance performance based on predefined indicators. The system organisation framework is illustrated in figure 2.

Figure2: MEMMS system organisation framework.

Focus Group Discussions (FGDs)

Process flow chart

The respondents’ information provided during Focus Group Discussions (FGDs) identified gaps in UBTS medical equipment maintenance .For example; it is difficult to know functional and non-functional equipment at any given time or carry out preventive maintenance (PM) of equipment in time throughout the regional blood banks .This is due to inability to closely monitor and follow up equipment schedule and condition in real time. The purposive sampling strategy was used to select the participants for the FGDs to look out for the more knowledgeable and experienced equipment users. The approach used in this project was for developing a software application. Therefore, a software development methodology was used. The methodology chosen was scrum which follows an agile mindset. Agile principles that are centered on continuous improvement of the software product were used to carry out this project. These principles were implemented using the scrum framework that employs the agile methodology. Scrum is based on continuous learning and adjustment to fluctuating factors. This acknowledges that the researcher didn’t know everything at the start of the project and evolved through experience as the project progressed. Figure 3 below shows the process that was followed in developing the software including tasks, stakeholders and artifacts:

Figure 3: The Project’s process flow chart showing activities and people involved at each stage

 Second objective; to analyze the requirements of the system.

In the process of analyzing the requirements of the system, the process includes the following;

3.2.1 Scrum process

The scrum process begun with an inception process where the product owner (UBTS) defined the version of the software. The product ideas suggested by the product owner were then written down as a list of user stories. These stories were recorded in a document (artifact) called product backlog (figure 3.) which guided in keeping track of the software development progress by identifying what was completed and still incomplete. The product backlog was routinely revised, adding new stories, user feedback, errors and updating stories as more insight was garnered. After having an initial product backlog in place, a selection was made of a few user stories which would take utmost 4 weeks to implement. The user stories with a high priority from the backlog were preferred to begin with. After completing the development of these user stories into a working software, the system was presented them to the product owner for approval. When the owner was satisfied, the next user stories to be worked on were discussed and planned. This process was called a sprint in scrum terminology as shown in Figure 4 below.

Figure 4: A diagram showing the activities that were involved in one sprint

The project underwent a number of sprint iterations until the final version with each iteration delivering the software with an increment to its features. Each sprint outcome added value to the user. When new requirements, enhancements, features, and fixes were got based on user feedback and more insight into the equipment maintenance process, they were added to the product backlog. And when a user story implementation was completed, it was marked “Done” or “Completed”. The product backlog was the document that helped keeping track of the product progress. Figure 5 below shows an example of the of the product backlog.

Figure 5: The product backlog stores as an excel sheet where all the user stories, estimates and priorities are recorded to guide the scrum team and product manager to track the progress of the product

3.1.3 Objective three: design and implement the system

Agile System Development Life Cycle

The section below presents the activities that were carried out in the research process. The agile software development life cycle (Agile SDLC) was followed to achieve the objectives of the study. The study population mainly focused on the laboratory technicians, biomedical engineers and technicians. A total of 5 laboratory technicians, 1 biomedical engineer and 2 technicians were randomly sampled to provide the relevant information to identify requirements. Data was collected through interviews, observations, literature review and questionnaires. The questionnaires were distributed amongst the 8 sampled stakeholders to determine the users’ capability to use the system. Interviews were conducted with the biomedical engineer and the laboratory technicians to identify system requirements. Observation methods helped to make informed decisions on system design, layout, adjustments and allowances based on what had been studied. The process of how equipment maintenance was being done was studied and the documentation involved was reviewed. Analysis of the collected data was done using Microsoft Excel because it has the features for calculation, drawing and manipulating graphs, pivot tables among others.

A system analysis determined the viability of the system by performing a feasibility study that evaluated the technical, operational and economic feasibility of the system. A Data flow Diagram (DFD) was used for the system design. Implementation was done using Microsoft Visual Studio (as the IDE (Integrated Development Environment)) and programming tools and techniques including C Sharp (C#), Structured Query Language (SQL), Windows Presentation Foundation (WPF), and .NET Core 2.0. WPF is a rich presentation system used for building Windows Desktop Application with complex business requirements. WPF was used because it is free and has the capability of designing intuitive user interfaces and integrates well with .NET Core. .NET Core is a general-purpose software development framework that allows developers to build software including web, desktop, cloud etc. It was used to develop the system’s business functionality which persists data to a SQL Server database. SQL Server is database management system that stores and manages data. C# is a simple, modern, object-oriented programming language developed by Microsoft that runs on the .NET platform. It was used to develop the desktop application and the web application.

The .Net is a platform that supports applications (web, desktop, mobile etc.) to run on any operating system. This platform was used because it supports using the same programming language (i.e., C#) for development of the Desktop application and the RESTful Web API. This platform was used to develop the XAML (Extensible Application Markup Language) files which are used for creating the desktop application’s user interface. All the C# classes and objects of the system were built on the .NET Core which runs on the .NET platform. Testing was necessary to ensure that the system functions correctly and verified that the system components worked together as expected by confirming the desktop application accessed the Web API and correctly authenticated and authorized the user. The system behavior was checked to identify errors through verification and the use of iterative prototyping. System validation involved users interacting with the system to check if it meets their requirements both functional and non-functional. The system was documented in a user-manual to guide users on how to use the system.

3.2 Research Design

The study used both Experimental and descriptive research design, this is because some of the objective involved understanding the Reponses of the respondents. Descriptive was used in particular because they provide an in depth study of a particular situation. The study also adopted the use of qualitative and quantitative methodologies for data analysis. Quantitative research consists of those studies in which the data concerned can be analyzed in terms of numbers while qualitative describes events, persons and so forth scientifically without the use of numerical data. Quantitative research is based more directly on its original plans and its results are more readily analyzed and interpreted. Qualitative research is more open and responsive to its subject.

3.3 Population

Population in the study is the entire group of people, events or things that a researcher wishes to investigate (Depoy & Gitlin, 2019) . The entity comprises of 40 employees, 1executive director, 2 management staff, 7 technical staff and 30 staff members.

3.4 Sampling Method

According to, (Omona, 2013) argue that it is impossible to study the whole targeted population and therefore the researcher shall took a sample of the population. A sample is a subset of the population that comprises members selected from the population. Using Krejcie and Morgan’s (1970) table for sample size determination approach, a sample size of 35 employees was selected from the total population of 40 employees.

Table 1: Population, Sample size, sampling method

Source: UBTS Employee List, (2020)

3.5 Sample Size Determination

In determining the sample size the researcher used krecie and mrgan 1970 table ofsample size determination. Where as sampling selection the research used both purposive and random sampling method.

Purposive sampling, also known as judgmental, selective or subjective sampling, is a type of non-probability sampling technique where the researcher chooses a sample based on what they think in other words they use their personal judgement (Palys, 2008). The study used Purposive sampling technique because it saves time and also enabled the researcher to get information from the right people who had knowledge and skills regarding the subject topic. This technique was used in selecting, executive director and managers, the researcher used this technique because these respondents held enough knowledge and skills regarding the study topic.

The researcher used simple random sampling technique, According to Amin, (2010) a simple random sample is a subset of individuals chosen from a larger set (a population). Each individual was chosen randomly and entirely by chance, such that each individual had the same probability of being chosen at any stage during the sampling process, and each subset of individuals had the same probability of being chosen for the sample. The technique was used to select from the technical staff and staff members.

3.6 Data Collection Method

The section presents data collection methods which include questionnaire survey and interview.

3.6.1Questionnaire Survey

Questionnaire Survey method was used to obtain the opinion of the respondents regarding the topic under study, according to (Onen & onen, 2013) states that questionnaires are important in research because the respondents are given time to think and they don’t feel intimidated. Questionnaire gives the respondents ample time to respond to the questions when ready and they can be kept for future references. This method was deployed to capture information from Staff Members and technical staff.

3.6.2    Interview

Face-to-face interview is a data collection method when the interviewer directly communicates with the respondent in accordance with the prepared questionnaire (Polak  & Green, 2015).

This method enables to acquire factual information, consumer evaluations, attitudes, preferences and other information coming out during the conversation with the respondent. Thus, face-to-face interview method ensures the quality of the obtained data and increases the response rate.

Interviews were used because they fetched a variety of ideas needed for the study and gave a deeper understanding of the topic. The method was used to generate information from Managers and the Executive Director.

3.7 Data Quality Control

The data collection tools was pre-tested on a smaller number of respondents from each category of the population to ensure that the questions are accurate.

3.8.1 Validity

Validity is defined as the extent to which results can be accurately interpreted and generalized to other populations (Oso & Onen, 2008). While Borg & Gall, 1989 as cited in Onyinkwa, (2013) validity is defined as the degree to which results obtained by the research instrument correctly represented to the phenomenon understudy and Mugenda & Mugenda, (1999) as the accuracy and meaningfulness of inferences which are based on the research results.

Amin, (2005) recommended minimum CVI of 0.7 to be used. Validity was tested using content validity index which involves judges scoring the relevancy of the questions in the instruments in relation to the study variables.

The formula for Content Validity Index was;

CVI =

Where CVI = content validity

n= number of items indicated relevant.

N = total no. of items in the instrument

In this study, validity was achieved by establishing content validity. The researcher achieved content validity by using the experts to assess the validity of the research instrument. The experts especially research supervisors and consultants from MUK were given data collection tools to assess whether the items in the instruments were valid in relation to research topic, objectives, and questions. From the instruments they declared some items valid and others invalid. Those declared invalid were dropped, others adjusted, while the valid ones were maintained.  Then content validity index (CVI) was computed by dividing the number of items declared valid by total number of items/questions in the data collection instrument.

CVI was 0.82 (82%), and this was very good.  According to Waner (2005), as cited in Barifaijo, Basheka and Oonyu (2010), if the CVI is greater than 0.7, then the instrument is said to have a high content validity. The researcher analyzed the data collected and where need arose, the instruments were re-adjusted and re-designed to improve reliability and validity. To improve face validity a pilot study was carried out at UBTS.

3.8.2 Reliability

According to Mugenda and Mugenda, (2003) reliability is the measure of the extent to which research instruments are able to provide the same results upon being tested repeatedly. Crobach’s coefficient alpha (a) as recommended by Amin, (2005, P.302) will be used to test the reliability of the research instrument. The instrument is deemed reliable if reliable of 0.7 and above is obtained and therefore, it was adopted for use in the data collection.

Formula for reliability is

=       ( )

Where  = alpha reliability co efficiency.

K=Number of items included4 in the questionnaire

= sum of variance of individual items

= variance of all items in the instrument.

To ensure credibility and trust worthiness of qualitative data the researcher will ensure that only the officials who are employees of UBTS were interviewed.

The coefficient ranges between a=0.00 for no reliability, a =1.00 for perfect reliability. The closer alpha gets to 1.0 the better. If the study findings result to Cronbanch’s Alpha of 0.7 and above, this signified that research instrument is good enough for the study. According to Amin (2005), all the measurements in the instrument that show adequate levels of internal consistency of cronbach’s alpha of 0.77 and above are accepted as reliable.

3.8 Data Analysis Method

3.8.1    Quantitative Data Analysis

Data processing was done by entering the data into a statistics package for social sciences (SPSS) version 24.0 in line with the research questions. Data analysis was done by also using this statistics package for social sciences (SPSS) to formulate frequency tables where the percentages, frequency, mean, variance and standard deviation were obtained.

Under quantitative analysis, process included editing, classification, coding and presentation. Data was summarized in frequency tables, percentage; data was analysed with the use of statistical package for social scientist (SPSS). Quantitative data was collected through structured questionnaires and it was cantered into a computer, tabulated and analysed.

3.8.2 Qualitative Analysis

Qualitative data was analysed using content analysis.it involved gathering and analysing data based on the content, where by the raw data collected from the field was read through to enable the researcher to get familiar with the data. At this process the study used noted cards to organise the available data to accelerate further analysis. Data was then evaluated and analysed to determine its accuracy, credibility, usefulness and consistency which aided acceptance or rejection of the research hypothesis.

3.9 Summary of the Chapter

CHAPTER FOUR

RESULTS AND DISCUSSIONS

4.0 Results

This section discusses results based on the specific objectives (i.e., to design and develop a computerized maintenance management system, and to test and validate the system), and also discusses the representations of the system user interfaces that provide a view of how the user interacts with the system. The result of the design and development objective is a computerized maintenance management system that has a Web API as a backend deployed remotely and a client desktop application which is an installable application on the user’s computer. The system was developed with C Sharp on the .NET Core platform for the Web API and Windows Presentation Foundation (WPF) for the Desktop Application. The C Sharp on the Desktop application has classes that support the connection of the Desktop application to the Web API through the URI endpoints.

The classes are also responsible for handling the data that is received and sent between the Desktop app and the Web API. The Desktop app also has XAML files that are responsible for the way the user interface looks as shown in the sub sections below. The C Sharp classes on the Web API define URI (Uniform Resource Identifier) endpoints for accessing the system’s services which include to create, retrieve, update and delete equipment information in the database. The classes also handle user authorization and authentication. The functionalities of the system include accepts user to register equipment, register spare parts, report equipment faults, record equipment repair report, schedule equipment maintenance and update equipment working condition status. The system also notifies when an equipment is due maintenance. The Web API is installed on a server in the cloud and can be accessed by the Desktop Application which is installed on the users’ desktop or laptop with windows operating system (OS).

1. How the user logs in the system

The user can only login using their username and password which can only be obtained when the system administrator is registering the user. The functionality of registering a user is only accessible by the system administrator for security purposes.

1. How the user schedules a maintenance

When the user selects the option of scheduling a maintenance from the system menu, the system lists all the active equipment inventory registered and the user can select from the list the equipment to schedule. The system pop ups a dialog from where the user can set the date for when this equipment can be worked on and details about the maintenance to be done.

• How the system notifies about a due maintenance

The system always checks the current date and compares it against all the scheduled maintenance dates. If it is one day to the scheduled date, the system notifies the user that a maintenance is due. If the scheduled date is two or more days in the future the system does not notify the about the maintenance and if the scheduled date is in the past, and the maintenance was not done, the system notifies the maintenance as an overdue maintenance.

1. Starting interface

The interface displays when the user double clicks on the desktops .exe application. During testing it took 5 seconds on first loading and 2 seconds on subsequent loading. Figure 6 below shows the starting interface page of the system.

Figure 6: starting interface page of the system.

After successful login, the application has on the left side a navigation menu allowing you to jump between different pages. On the right side, the user will see the selected screen and in fig. xx it is showing the Home screen.

1. Registering an equipment

The interface enables the user to register a new equipment to the inventory as shown in figure 7 below.

Figure 7: interface to register a new equipment.

1. Report an equipment fault

The interface enables the user to report an equipment fault and details about the fault to the engineer as shown in figure 8 below.

Figure 8: interface to report equipment fault

1. Record a maintenance report

The interface enables the user to save a report of what has been done to repair a fault as shown in figure 9 below.

Figure 9: interface to save report of repair work done.

1. Schedule equipment maintenance

The interface enables the user to schedule an equipment maintenance by setting a date of maintenance and some notes about the maintenance required. This is clearly shown in figure 10 below.

Figure 10: interface for scheduling equipment maintenance.

1. Update the equipment working status

During the validation process, the users installed the desktop application on their desktops and interacted with the system to determine whether it fully met their requirements. Questionnaires were handed out to 8 system users and the results were analyzed using MS Excel. The responses from the system testing and validation questionnaires are summarized in Table 1 below;

Table 1: Results from system testing and validation questionnaires.

The result of the research project was a working computerized maintenance management information system that has a desktop installation and a backend information management service that is hosted on a server. The backend stores the information in a relational database designed with Microsoft SQL server. Figure 11 below shows a high level architectural diagram of the system components.

Figure 11: The high level architectural diagram showing the components involved in the setup and installation of the system

The desktop installation is an executable file that is installed on the end user’s computer or laptop. This is the software that the user interacts with. The software has a user interface with various features below:

• Authentication and authorization
• Equipment registration
• UBTS facility Locations registration
• Inventory registration
• System user registration and management
• Equipment faults reporting
• Faults management
• Maintenance schedules recording

Figure 12 below shows the user interface with a menu of all the system features for an authorized user logged in. For the detailed descriptions of the features and their screen shots, check in the appendix A.

Figure 12: The home page of the system after login showing a menu of all the functionalities of the system on the left panel and the equipment which the user has subscribed to for any instant updates

CHAPTER FIVE

5.0 Discussion, recommendation and conclusion.

The data collected from this study through Focus Group discussions, user interaction, document revision and observation suggests that the users want a system that can manage equipment information, track maintenance schedules and manage maintenance reports. One reason for this finding is that UBTS equipment maintenance process is still manual. It uses different documents for different steps of the process. Information is scattered so it’s hard to consolidate and analyze this information for better maintenance planning. The user requirements also gathered showed that the users wanted a system that centralizes the maintenance information. Role based features’ access was also emphasized since not all information was necessary to certain groups of people and other features like scheduling maintenances was a mandate for only the engineer. The study however is hampered by a small number of participants. All the participants were UBTS staff at only one facility (Nakasero office) and this might have biased the features of the resulting system. Additional research may find out if the users in other UBTS facilities have the same requirement needs. A research can also be done to develop a simpler version for a mobile application that utilizes these same services. This research did not include connecting equipment to the system to do automatic monitoring and report an equipment anomaly. Therefore, a research to carry out a system integration of the equipment to the MEMMS system would also be a recommended area of study.

There were no main challenges that were faced during the development of the equipment maintenance management system that directly affected the process. The validation and test results show that the system is easy to use , very good for managing equipment information, effectively reports faults to the biomedical engineer, gives inventory reports for better monitoring of equipment and is fast, reliable and available; these are all important attributes of the system which make it to be easily accepted compared to the manual equipment maintenance system using paper work which easily gets lost and destroyed by natural calamities like fire and floods.

The limitations of the system include the following:

1. The system requires participation from all the users (i.e., lab technicians, engineers and technicians) for it to be effective and yet some of the users are reluctant to use it.
2. The system’s web API is hosted on the cloud hence the user needs internet connection to use the system which implies a financial cost.

• The system does not integrate or communicate with the equipment or other systems such as the finance systems and yet sometimes the maintenance delay is caused by late communication to the finance department.

5.1. Recommendation

The administration of UBTS should roll out the equipment maintenance management system as the authorities’ officially recognized CMMS, sensitize and train its employees about the system such that users at all the branches can participate in the system flow with confidence.

Information mismanagement is not the only cause of poor equipment maintenance so the engineers need to take measures on solving other factors that cause poor equipment maintenance at UBTS. Further research should be carried out to find out the causes of continuous equipment failure, misuse and underutilization of some equipment. Innovative and appropriate systems should be developed for those causes.

UBTS should ensure that the technical requirements of the systems are always well provided so as there is no breakdown of the system.

5.2. Conclusion

With the above recommendations considered and implementation of the system, I believe that the problem of poor equipment maintenance at UBTS will reduce to some extent thereby increasing the uptime and lifespan of medical equipment. This is true because;

1. Users do not have an official communication channel for reporting their equipment faults and the system is designed to act as one which will be available all the time.
2. The Engineer always requires an up-to-date inventory list of the equipment to do regular follow ups and the system makes this list available

• Users need to work collaboratively to achieve high efficiency at UBTS and the system works as a tool that enables them to communicate issues regarding equipment maintenance.

Therefore, if other causes of poor equipment maintenance are eliminated or reduced, and the designed system is used to manage the equipment maintenance information, the problem of poor value management processes and untimely equipment maintenance which has caused equipment breakdown and prolonged down time will reduce to some extent.

REFERENCES

12 principles behind the Agile Manifesto . (n.d.). (Agile Alliance) Retrieved November 30, 2020, from https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/

Appiah, B., Burdine, J., Aftab, A., Anum, D., & Kretchy, I. (2018). Determinants of intention to use mobile phone caller tunes to promote voluntary blood donation:. JMIR m Health and u Health, 6(5) e9752.

Bartonjo, G., & Oundo, J. (2019). Risk factors associated with blood transfusion; The pan african medical journal, 34.

Bartonjo, G., & Oundo, J. (2019). Prevalence and associated risk factors of transfusion transmissible infections among blood donors at Regional Blood Transfusion Center Nakuru and Tenwek Mission Hospital, Kenya. The Pan African Medical Journal,, 34.

chou, S., Chen, y., Shen, Y., Yen, H., & Kuo, S. (2019). Implementation and Effectiveness of a Bar Code–Based Transfusion Management System for Transfusion Safety in a Tertiary Hospital: . Retrospective Quality Improvement Study. JMIR medical, 7(3) 14192.

compu. (n.d.).

Computerized maintenance management system- Wikipedia. (2020, October 16). (Wikipedia) Retrieved Novemeber 30, 2020, from  https://en.wikipedia.org/wiki/Computerized_maintenance_management_system

Depoy, E., & Gitlin, L. (2019). Introduction to research E-book: understanding and applying multiple strategies. Elsevier Health scienes.

Ewer, K., Aley, P., Angus, B., Belij-Rammerstorfer, S., & Hamlyn, J. (2020.). Safety and immunogenicity of the ChAdOx1 nCoV-19 vaccine against SARS-CoV-2: a preliminary report of a phase 1/2, single-blind, randomised. The lancet, 467-478.

Keleta, Y., Achila, O., Haile, A., Gerbrecherkos, B., Tesfaldet, D., Teklu, K., & Ghedel, S. (2019). Seroprevalence of transfusion transmitted infections among blood donors in Gash Barka Zonal Blood Transfusion Center. BMC hematology, 19(1), 1-9.

Khandelwal, M., Hill, J., Greenoungh, P., Quill, M., Linderman, M., & Udaykumar, H. (2017). Why have improved cook-stove initiatives. World Development, 92, 13-27.

Kovacic, Z., & Bogdan, S. (2018). Fuzzy controller design: theory and applications. . CRC press.

Krosnick, J. (2018). Questionnaire design. In the palgrave handbook of survey research.

Levenson, A. (2018). Using workforce analytics to improve strategy execution. Human Resource Management, 685-700.

Mackieson, P., Shlonsky, A., & Connolly, M. (2019). Increasing rigor and reducing bias in qualitative research. Qualitative social work, 965-980.

Maitland, K., Kiguli, S., Engoru, C., Mallewa, M., Saramago, G., & Walker, A. (2019). Immediate transfusion in African children with uncomplicated severe anemia. New England Journal of medicine, 407-419.

Mremi, A., Yahaya, J., Nyindo, M., & mollel, E. (2021). Transfusion-Transmitted Infections and associated risk factors. Dar es salaam: plosone.

Nielsen, J. (1994). 10 Usability Heuristics for User Interface Design. Retrieved April 2020, from Nielsen Norman Group logoNielsen Norman Group: https://www.nngroup.com/articles/ten-usability-heuristics/

Omona, J. (2013). Sampling in qualitative research: Improving the quality of research outcomes in higher education. Makerere Journal of Higher Education, 169-185.

Polak, L., & Green, J. (2015). Using quantitative risk information in decisions about statins. British Journal of General practice, 264-269.

Price, D. (2016, February 15). EDGE, 3G, H+, Etc: What Are All These Mobile Networks? Retrieved April 2020, from MakeUseOf: https://www.makeuseof.com/tag/edge-3g-h-etc-mobile-networks/

Selcuk, S. (2018). Predictive maintenance, its implementation and latest trends. Proceedings of the Institution of Mechanical Engineers,. Part B: Journal of Engineering Manufacture,, 231(9), 1670-1679.

Syukur, I. (2015). Refining the SDLC Method, Improving the Quality and Accelerating the Software Development at BR.

Taherdoost, H. (2016). Validity and reliability of the research instrument. How t test the validation of a questionnaire/survey in research.

The product backlog: your ultimate to-do list. (n.d.). (Atlassian agile coach) Retrieved November 30, 2020, from https://www.atlassian.com/agile/scrum/backlogs

Tight, M. (2019). Documentary research in the social sciences. SAGE.

UBTS. (2020). Where to donate. Retrieved April 2020, from https://www.ubts.go.ug/: https://www.ubts.go.ug/where-to-donate.php

Uyoga, S., Adetifa, I., Karanja, H., Nyagwange, J., Tuju, J., Wanjiku, P., & Warimwe, G. (2021). Seroprevalence of anti–SARS-CoV-2 IgG antibodies in Kenyan blood donors. Science, 371(6524), 79-82.

Weimer,, A., Tagny, , C., Tapko, , A., Ness, P., & Bloch, E. (2019). Blood transfusion safety in sub‐Saharan Africa: a literature review of changes and challenges in the 21st century. Transfusion, 59(1), 412-427.

Werktetter, K., & Korponay-Szabo, R. (2017). Accuracy in diagnosis of celiac disease without biopsies in clinical practice. Gastroerology, 924-935.

What is Agile Software Development? | Agile Alliance. (2020). (Agile Alliance) Retrieved Noveember 30, 2020, from https://www.agilealliance.org/agile101/

What is Scrum? (n.d.). (Scrum.org) Retrieved November 30, 2020, from https://www.scrum.org/resources/what-is-scrum

Yooda, A., Soubeiga, S., Obiri-Yeboah, D., Nebie, K., Outtara, A., & Simpore, J. (2019). Residual risk of HIV, HCV, and HBV transmission by blood transfusion between 2015 and 2017. Journal of blood medicine, 10, 53.

7.0 Appendix

7.1 Appendix A

MEMMS System User Manual

1. The Login Page

The first screen that appears whenever the application is launched is the login page. The system can only be accessed by authenticated users and on this screen is where a registered user enters his/her username and password given to them by the system administrator.

Figure 1: The Login Page

2. Landing Page

When an authenticated use successfully logs in, the system displays a dashboard that has a list of equipment’s statuses of which the user is interested to know about. The dashboard shows critical information such as if the equipment has a fault, if it is scheduled for maintenance and when it was last repaired. A user can add and remove an equipment from his/her dashboard.

Figure 2: Landing Page

The user can always navigate back to the dashboard whenever he/she wants to by clicking on the dotted vertical line next to the user name located at the right of the top application bar and selecting the Dashboard option from the popup menu

Figure 3: Popup Menu with link to navigate back to the Dashboard

The landing page(Dashboard) has an Add Equipment button which the user can click and access a form which has a list all of the equipment that the user doesn’t follow. From this list the user can choose an equipment which he/she would like to follow and be notified of any important information about the equipment

Figure 4: The Add Equipment Button for adding an Equipment to follow

Figure 5: The Popup form that has a list of all the equipment not followed by the user. A new equipment can be selected to add to the form

3. Equipment Page

The equipment page shown in figure 12 below has a list of all the types of medical equipment that are available at the facility. The list also has the total number of equipment installed in the facility. The page also has a form from which a new equipment type can be added.

Figure 6: The Equipment page with a list of equipment type and the quantity installed and a Form for adding a new Equipment type

4. Blood banks Locations Page

The page shown in figure 13 below enables a user to register locations of available blood banks or centers where equipment is installed. The Page displays a list of all the registered centers in a table format with the location name and the district where it is found.

Figure 7: The page that shows all the blood bank centers and the districts where they are found

5. Inventory Page

The page lists all the equipment that is registered in a facility with their serial numbers. It also has a form where information about a new equipment can be added as shown in Figure 14. Below.

Figure 8: The Inventory page that has a form where newly purchased equipment can be added and an inventory list that displays all the installed equipment registered

6. Equipment list

The figure 15 shown below is the equipment list which is clickable hence when a user clicks on an equipment in the list, the system displays the details of that equipment. The details are information that was captured when the item was being registered.

Figure 8: Inventory Item details that the system displays when an item in the list is clicked

7. User Management Page

This page is used for registering users and assigning roles to registered users. The page has a list showing all the users registered in the system and a form where a new user can be registered. The user is assigned a location i.e. the blood bank center where the user works at the time of registration. Figure 16 below shows the user management page.

Figure 9: The user management page that has a list of all the registered users and a registration form for a new user

8. User details form

When the user clicks on a row in the users list, a user details form appears on the right of the users’ table where the selected user can be edited as shown in figure 17 below. A role can be added or removed from this user.

Figure 10: The user details form where the user roles can be edited. A role can be added or removed from the selected user.

9. Equipment Faults Page

This is the page where an equipment user can report faults about an installed equipment. The user selects the faulty equipment from a list as shown in Figure 18 below.

Figure 11: A List of all the installed equipment

The other details about the fault as shown in the figure 19. The page also has a list that shows all the reported faults that have been reported but have not yet been worked on. Once the fault is worked on, it disappears from the list.

Figure 12: The equipment faults page showing the equipment faults reported by the equipment users and a form where a new fault can be reported

10. Fault Management Page

The page is used by the engineer, lab manager or technician and it shows all the faults that have been reported by the equipment user. Upon finishing the repair, the technician/engineer/manager can click on a fault and fill in a summary of the work done in the form as shown in Figure 20 below. When the form is saved, the fault will disappear from the list.

  Figure 13: Fault management page that shows all the faults reported by the equipment user and also has a repair form filled in by the technician or engineer or lab manager after finishing the repair.

11. Maintenance Schedules Page

This page is accessed by users with the role of biomedical engineer or lab manager. On this page is where the user can schedule maintenance dates for when preventive or routine maintenance can be done. The system will alert how many days are left or past a schedule date. The list of all set schedules is displayed in a table with clickable rows. When the user clicks on a row, the maintenance schedule form appears on the right as shown in Figure 21 below.

Figure 14: The maintenance schedule form with the list of maintenances scheduled and a maintenance form to fill in the maintenance work information for a clicked row

The engineer can fill in the information of a completed maintenance work in the maintenance Form. Once saved, the schedule will disappear from the list. The user can also add to the schedule by clicking on the Add Schedule button (Figure 22) and a form for adding a schedule will popup (as shown Figure 23 below). The form has a list of equipment from which the user can select and schedule a date for that equipment.

Figure 15: The button that is clicked to add schedule of a new maintenance work

Figure 16: The form for scheduling a new maintenance for an equipment

12. Logout

To logout from the application, the user clicks on the dotted line net to the username on the top bar at the right end. When the line is clicked a popup menu will appear and the user can click on logout to logout from the application and redirects the user to the login page. When the user clicks on the “Exit Application” button, the system will automatically logout the user and close the application.    Figure 24 below shows the logout page.

Figure 17: The popup menu where the user can logout from

APPENDIX II: QUESTIONAIRE

Section a:  Background information of the respondents

 Please tick the most appropriate answer in the corresponding box

User Requirements of the system

APPENDIX II

INTERVIEW GUIDE FOR RESPONDENTS

1. What are some of the challenges with the current system here?
2. What specific designs do users expect in the new system?
3. What are some of the key features that that the new system must have?
4. What solutions must the new system solve?

Thank you for your time