ICDAI-DMSS: Iligan City Diabetes Association Inc.

Diabetes Monitoring Support System

A Special Project Presented to The Faculty of Department of Information Technology School of Computer Studies Mindanao State University - Iligan Institute of Technology

In Partial Fulfillment of the Requirements for the Degree of Bachelor of Science in Information Technology Major in Management Information System

Michelle O. Cepada Vinaflor N. Viajante

Prof. Romelyn Inocencio- Ungab Adviser March 2011

ii

Abstract

Monitoring diabetes has become the new development in the medical field of the society. It may be done through various approaches like computer-based software, userhardware procedures or through the internet. Accordingly, monitoring patients condition could be inflexible in most times for diabetic measurements needs to be accurate or, by any means, precise. Apparently, monitoring diabetes in Iligan City Diabetes Association, Inc. is done manually, from recording, describing and recounting laboratory test results of each member patient which may consume a lot of time and is subject to errors. The developed diabetes monitoring and support system for the patients condition and medical measurements in ICDAI records the test results of every patient, give recommendations for their health care, generate reports, and give graphical reports or illustration for the physician to observe the patients condition. Thus, time is used more productively and the accuracy of the current system is improved. The results give efficient recommendations using a knowledge-based method. The reports show the list of patients registered, the available laboratory test being administered and the trending of every patients diabetic condition.

Keywords: diabetes, monitoring system, laboratory test, recommendation, graphical reports

iii

Table of Contents
Abstract....................................................................................................................................ii Table of Contents....................................................................................................................iii Chapter 1...................................................................................................................................x Research Description................................................................................................................x Overview of the Current State of Technology....................................................................x Issues and Problems............................................................................................................1 Statement of the Problem....................................................................................................2 Research Objectives............................................................................................................3 1.4.1 General Objective...................................................................................................3 1.4.2 Specific Objectives.................................................................................................3 1.5 Scope and Limitation.....................................................................................................3 1.6 Significance of the Study...............................................................................................4 1.7 Research Methodology..................................................................................................4 1.7.1 Requirement Analysis.............................................................................................4 1.7.2 System Architecture................................................................................................7 1.7.3 System Design.........................................................................................................8 1.7.4 Implementation.....................................................................................................10 1.7.5 Testing and Evaluation.........................................................................................11 Chapter 2.................................................................................................................................12 Review of Related Literature.................................................................................................12 2.1 Review of Related Concepts........................................................................................12

iv 2.1.1 Diabetes Monitoring System................................................................................12 2.1.2 Decision Support System......................................................................................12 2.1.3 Knowledge Based System....................................................................................13 2.2 Diabetes System Approaches and Techniques............................................................14 2.2.1 Case Based Reasoning Approach.........................................................................14 2.2.2 Evidence Based Medicine Approach....................................................................14 2.2.3 Medical Information Desktop Application...........................................................15 2.3 Diabetes Monitoring and Decision Support Related Systems....................................15 2.3.1 DiabetEASE web-based Monitoring System.......................................................15 2.3.2 DiaComp: Computerized Management of Type II Diabetes...............................15 2.3.3 DDS: Initial Experience with the Vermont Diabetes Information System..........16 2.3.4 Outpatient Assessment of Karlsburg Diabetes Management System..................17 2.3.5 CGMS: Continuous Glucose Monitoring System................................................17 2.4. Summary of Review of Related Literature.................................................................20 Chapter 3.................................................................................................................................21 Theoretical Framework..........................................................................................................21 3.1 The Diabetes Mellitus..................................................................................................21 3.2 Monitoring Diabetes.....................................................................................................23 3.3 Decision Support System.............................................................................................24 3.4 Knowledge-based System............................................................................................24

v 3.5 DMSS: A Medical Management Information.............................................................25 Chapter 4.................................................................................................................................27 The ICDAI Diabetes Monitoring Support System................................................................27 4.1 System Requirement Analysis and Specifications......................................................27 4.1.1 Introduction...........................................................................................................27 4.1.2 Overall Description...............................................................................................28 4.1.3 System Features....................................................................................................29 4.1.4 External Interface Requirements..........................................................................29 4.2 Design Models..............................................................................................................30 4.2.1 Context Diagram...................................................................................................30 4.2.2 UML Use Case Model..........................................................................................31 4.2.3 Activity Diagram...................................................................................................39 4.2.4 Sequence Diagram................................................................................................40 4.2.5 Class Diagram.......................................................................................................44 4.2.6 Component Diagram.............................................................................................45 4.2.7 Deployment Diagram............................................................................................46 4.2.8 Database Design Model........................................................................................47 4.3 Structure and Interface.................................................................................................48 4.3.1 Program Structure.................................................................................................48 4.3.2 Graphical User Interface.......................................................................................49

vi 4.4 Physical Environment and Resources..........................................................................57 4.4.1 Developer..............................................................................................................57 4.4.2 Client.....................................................................................................................58 Chapter 5.................................................................................................................................58 Results and Observations.......................................................................................................58 5.1 Information Gathering..................................................................................................59 5.2 Design of the System...................................................................................................59 5.3 System Development...................................................................................................59 5.4 User Testing and Results..............................................................................................60 5.5 Evaluation and Summary.............................................................................................65 5.6 Systems Capabilitites and Limitations.......................................................................66 Chapter 6.................................................................................................................................67 Conclusion and Recommendations........................................................................................67 6.1 Conclusion....................................................................................................................67 6.2 Recommendation..........................................................................................................69 References .............................................................................................................................70 Appendix A. Resources Person..............................................................................................73 Appendix B: Personal Vitae...................................................................................................74 Appendix C: Current Business Flow Diagram of ICDAI......................................................75 Appendix D: Proposed Computer-Based Flow Diagram for ICDAI....................................76 Appendix E: Evaluation Form...............................................................................................77 Appendix F: Schema..............................................................................................................78 USER MANUAL

vii

List of Tables
Table 2.1 Checklist of Related Studies and Systems22 Table 4.1 Developers Minimum Software Requirements59 Table 4.2 Developers Minimum Hardware Requirements...59 Table 4.3 Clients Minimum Software Requirements...60 Table 4.4 Clients Minimum Hardware Requirements..60 Table 5.1 Functionality Table62 Table 5.2 Non-functional Rating for the ICDAI-DMSS...65

viii

List of Figures

Fig. 1.1 ICDAIs Manual System for Monitoring Patients Health Condition..3 Fig. 1.2 Fishbone Diagram..4 Fig. 1.3 Flow of the Research Methodology..8 Fig. 1.4 System Architecture for Diabetes Monitoring System..9 Fig. 3.1 ICDAI-DMSS Structural Flow25 Fig. 3.2 ICDAI-DMSS Theoretical Framework28 Fig. 4.1 Context Diagram for ICDAI-DMSS...32 Fig. 4.2 Use Case Diagram for ICDAI-DMSS.33 Fig. 4.3 ICDAI-DMSS Activity Diagram.41 Fig. 4.4 Add Laboratory Test Sequence Diagram.42 Fig. 4.5 Add Patient Sequence Diagram...43 Fig. 4.6 Update Patient Record Sequence Diagram..44 Fig. 4.7 View Reports Sequence Diagram.45 Fig. 4.8 Class Diagram of ICDAI-DMSS.46 Fig. 4.9 Component Diagram of ICDAI-DMSS...47 Fig. 4.10 Deployment Diagram of ICDAI-DMSS48 Fig. 4.11 ERD for ICDAI-DMSS.49 Fig. 4.12 ICDAI-DMSS Program Structure..50 Fig. 4.13 Log-In Form GUI...51 Fig. 4.14 Main Form GUI..51 Fig. 4.15 Add Laboratory Test GUI..52 Fig. 4.16 Add Laboratory Test Range GUI...52 Fig. 4.17 Add Patient GUI.53 Fig. 4.18 Search Patient GUI.54 Fig. 4.19 Update Patient Laboratory Record GUI.55 Fig .4.20 List of Laboratory Test GUI...56 Fig. 4.21 List of Members GUI.56

ix Fig. 4.22 Graphical Laboratory Records GUI..57 Fig. 4.23 Patient Medical Record GUI.58

Chapter 1 Research Description

Overview of the Current State of Technology Diabetes Mellitus (DM) is a set of related diseases in which the body cannot regulate the amount of sugar, specifically glucose in the blood. Glucose in the blood gives you energy to perform daily activities. It is produced by the liver and is regulated by several hormones, including insulin. Insulin allows glucose to move from the blood into liver, muscle, and fat cells, where it is used for fuel. People with diabetes will either do not produce enough insulin (Type 1 diabetes) or cannot use insulin properly (Type 2 diabetes), or both (which occurs with several forms of diabetes). Over a long period of time, high blood sugar damages the retina of the eye, the kidneys, the nerves, and the blood vessels. Long term effects like blindness, kidney failure, leg amputations, and heart diseases are usually due to a patient letting their glucose levels remain elevated for long periods of time. That is why early detection is important (Pollock, 2006). In the Philippines, doctors use special tests in diagnosing diabetes and also in monitoring blood sugar level control in known diabetics. If the patient is having symptoms but are not known to have diabetes, evaluation should always begin with a thorough medical interview and physical examination. The healthcare provider will about symptoms, risk factors for diabetes, past medical problems, current medications, allergies to medications, family history of diabetes or other medical problems such as high cholesterol or heart disease, and personal habits and lifestyle. A number of laboratory tests are available to confirm the diagnosis of diabetes and these tests will be able to help the medical practitioners in determining the patients diabetes status. Some of these tests are finger stick blood glucose test, fasting plasma glucose test, oral glucose tolerance test, and glycosylated hemoglobin or hemoglobin A1c test. Normal values may vary from laboratory to laboratory, although an effort is under way to standardize how measurements are

xi performed. Moreover, these laboratory tests and examinations have the existing frameworks that could be utilized in developing a monitoring and decision support system that will contribute a lot in the field of healthcare and medicine. Living with diabetes is a matter of taking control over the disease and preventing complications (ezinearticles.com, 2006). That is why there are organizations that are established to make diabetic persons more informed and motivated to stay as healthy as possible. One of these is ICDAI, or Iligan City Diabetic Association Incorporated. It is a private organization composed of diabetic persons within Iligan City whose main goal is to help other diabetic persons become more aware and knowledgeable of their condition. ICDAI membership is open to all interested persons who, at present, are experiencing the symptoms of diabetes. Registered members must attend a once-a-week meeting for them not to lose their membership. At present, ICDAI is using manual method in recording patients valuable information in terms of their diabetic condition. The usual process is when patient will take laboratory tests to determine his blood sugar count, he also look for a physician outside the association to get his blood pressure. The physician then manages the data he gets from the results of the laboratory test and blood pressure. He would look for the patients record in the shelf and update it. If a record is not found, the patient will fill up an information sheet and this sheet will serve as his personal record. In addition, physician will check the patients health status by tracing his previous results to current and updated ones. In this situation, the doctor will be able to forecast the patients health status and help the patient become aware of his health condition by giving him enough recommendations and prescriptions. (See Figure 1.1)

TAKE TEST Patient LABORATORY TESTS MANAGE TEST Medical Practitioner UPDATE PATIENTS INFORMATION PATIENTS LAB TEST RESULT CHECK PATIENTS CONDITION

RECOMMENDATIONS AND PRESCRIPTIONS

MANAGE INTERPRETATION OF RESULTS

Legend:

-Actor

-Process

-Data

-Input

Fig. 1.1 ICDAIs Manual System for Monitoring Patients Health Condition

Issues and Problems ICDAI members have been rapidly and spontaneously increasing and as of the moment, their set of officers is still deciding whether to go on computerization of accounts for fast and accurate retrieval of records and disease monitoring. The nonexistence of mechanized information system possesses several problems. First, the method they are currently using when recording and monitoring patients condition are time consuming and prone to errors.

2 Since ICDAI keep records of their patients, some of it are sometimes misplaced and becomes missing. It would also take a lot of time for them to go over every record if they are to retrieve it. Another problem is information security. Unlike in a computer-based file in which you can put password to ensure protection from troubles and put into folder to have it classify, paper-based file has a higher possibility of loss especially if its not wellorganize and vital documents can be mishandle. Availability, integrity and confidentiality are points that should be considered and emphasized effectively to ensure the safety and privacy of patients information. Lastly, there is less participation of technological assessment. Some of ICDAI members are aware but still unknowledgeable of their condition, which is why physicians should be able to identify patients priorities after monitoring his condition. In this way, a physician can enforce diabetes education while making his recommendations and prescriptions productively. Thus, a computer-based automated monitoring system can add the flexibility and knowledge needed to improve the monitoring and control of diabetes.
Lack of availability, integrity and confidentiality of patients information

No assurance of information security

Difficulty in information retrieval and monitoring patients condition Less technological assessment participation of patients Consumes too much time when it comes to retrieving patients record.

Statement of the Problem Fig. 1.2 Fishbone Diagram In ICDAI, recording patients information and monitoring their condition are time consuming and prone to error, information security is fragile, and the diabetic patients participation still subsist in the overall technological assessment.

3 Research Objectives 1.4.1 General Objective To develop a desktop application for ICDAIs diabetes monitoring support system that will provide assistance to the physician in recording patients information and monitor their diabetic condition. 1.4.2 Specific Objectives 1. To draw a flow diagram in monitoring patients health condition and analyze how the physician will assess the results in making recommendations; 2. To record laboratory test results to be able to display easy-to-read graphs; 3. To recommend guidelines and to-do-list to patients diet and exercise planning; 4. To create reports in order for the physician to assess the patients condition; 5. To develop a desktop application of DMS that would utilize and process the information collected in a user-friendly interface; and 6. To conduct a testing and evaluation from end user to determine the effectiveness of the system. 1.5 Scope and Limitation Since the arrival of personal computers and the rapid increase in their use have brought about a potential means of providing fast and accurate information, a computer-based monitoring support system can be created to aid the physician in helping his patient to maintain control of diabetes. For a patient, it will enable data collection, promote trend analysis through easy-to-read-graphs, provide significant guidance to support diet and exercise planning, and maintain a comprehensive personal history. For a physician, it can provide a record-keeping mechanism for patient histories, facilitate the analysis of trends and provide recommendations and prescriptions if necessary. In terms of accessibility, it is only the physician who is allowed to access the system. And since ICDAI has a regular meeting, all of the members who will attend will undergo

4 consultation after they have given the results of their laboratory tests to the physician. It is not under the control of the system if the patient will be absent and no data will be inputted in his account. It is only the entered data which are recorded and monitored by the physician. 1.6 Significance of the Study The implementation of the system will aid the physician in the process of recording patients information and retrieving it the fastest way possible, assessing some complications in the disease since it is being monitored well, recommending certain medications to the patients in order to have a positive outlook in their diabetic life. Furthermore, system reliability is present since human errors are reduced. 1.7 Research Methodology The proponents gathered facts in actualizing the ICDAI Diabetes Monitoring Support System through interviews and comprehensive research. 1.7.1 Requirement Analysis This phase appraises the needed requirements for the Diabetes Monitoring System. For a systematic way of evaluating the requirements several processes were involved. The first step involved in analyzing the requirements of the system is recognizing the nature of system. For a reliable investigation, possible transactions and processes are formulated to better understand the Diabetes Monitoring System. 1.7.1.1 Interview An interview is done to obtain knowledge about the operating environment of our client. An endocrinologist or a Diabetes specialist/medical practitioner was interviewed on how the assessments are done in monitoring diabetes conditions inside Iligan City Diabetes Association. Questions regarding the monitoring process were raised. Along with the interview process, the medical practitioners concerns were voiced out and recorded. The

5 researchers obtained a copy of the monitoring flow process, samples of vital documents in evaluating diabetes conditions, and their standard rules and regulations. The unnecessary data was eliminated and required data was organized for the documentation. The system works in parallel with the present business rule in diabetes monitoring used in ICDAI through the gathered data. These requirements serve as resources in making a dynamic system capable of enhancing the present operations of the existing monitoring system. 1.7.1.2 Literature Review There have been studies made and systems developed to monitor the conditions of a Diabetes patient. Members of the team researched and studied more about the development of these projects, learned from the strategies of these studies and their drawbacks, and furthermore implemented the techniques and approaches that will be helpful for the study.

1.7.1.3 Data Analysis The team had brainstorming activity regarding the adequate information acquired from the interview and the examination on related literatures of the study. The researchers also studied on how these data can be configured in the proposed system with respect to the organizations business rules. Accordingly, the team was prepared on how to approach the main problem in monitoring diabetes along with the supervision of an adviser.
Data Analysis
Brainstorming Record evaluation

Data Gathering
Interview Literature review

Database Construction

Graphical User Interface Design Testing and Evaluation System Implementation

Pre-testing System Alterations Final testing

Fig. 1.3 Flow of the Research Methodology

1.7.2 System Architecture In this phase, the researchers assembled the overall architectural design of the system. With ardent understanding on the structure of the system, it is essential to have concrete reviews on the different architectures that may apply to the proposed system. It is significant to select the appropriate architecture to use in the system so a dynamic and reliable monitoring system will be obtained. To be able to attain this, the proponents designed Unified Modeling Language (UML) diagrams which will show control structures, activities and event flows of the proposed system. The terms of how the system shall be developed as well as the database structure and software that will be used is decided upon by the proponents. Figure 1.4 shows the architectural design of the proposed system. The design shall pattern the proposed systems inputs and outputs, and functionality needed to fit its objectives. Interaction from users shall be handled by the Graphical User Interface (GUI). Inputs and outputs shall be validated by systems control structure. Validated data shall be stored to the database.
DATA MODEL

Systems Control

Database Schema

ICDAI Diabetes Monitoring Support System

Fig. 1.4 System Architecture for Diabetes Monitoring System

8 1.7.3 System Design After the data gathering and analysis, the researchers are ready to come up with an appropriate and efficient design for the ICDAI Diabetes Monitoring Support System. Design models will be made as guides on the basic flow of the system for the implementation stage of the system. The diagrams and flow of activities of the systems is illustrated using the Unified Modeling Language (UML), a graphical language for visualizing, specifying, constructing and documenting the sources of an object-oriented software system. UML diagrams are designed to let developers and customers view an apparent and viable perspective of the complications of the system. These are the diagrams which are used in our proposed system: Use Case Diagram illustrates the relationship between a set of use cases and the actors. Activity Diagram which shows the whole picture of behavior. Its a special state diagram where most of the states are action states and most transitions are prompted by completion of the actions in the source states. Sequence Diagram emphasizes the time sequences of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (objects involved). Class Diagram provides a conceptual model of the system; it shows the concepts, association between the concepts, attributes and methods. It displays relationships such as containment, inheritance and others. Deployment Diagram displays the configuration of a run-time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units. 1.7.3.1 Database The researchers constructs a database design that is normalized and well structured that will facilitate the data input and retrieval of the monitoring system.

9 The reviewed business rule of ICDAI is a vital initial component in creating the database design since data will be from their records. Another model used in designing the system is the Entity-Relationship Diagram (ERD) which shows the interrelations between entities in a database. The classes, entities, attributes, and functions specified in the documents pertained with the business rule shall be used in the program codes of the software to achieve consistency in the project. Patients basic information such as name, age, address, etc. will be organized through this database. Moreover, the diabetes patents records regarding their health statistics and improvements like blood sugar counts, daily insulin, etc. is significantly engaged in the database of the system since the overall activity of the project in the first place, is to monitor patients conditions.

1.7.3.2 Graphical User Interface The graphical user interface is necessary for the users to interact with the system. The system is a desktop application to be used by an assigned individual in diabetes monitoring. It is necessary to consider the flexibility and user-friendliness of the systems interface.

10

1.7.4 Implementation This phase covers the different issues regarding the construction of the project. The team is adapting the integrated software development approach. This methodology refers to a deliverable based software development framework utilizing the three primary IT (project management, software development, software testing) life-cycles that can be leverage using multitude (iterative, waterfall, spiral, agile) software development approaches, where requirements and solutions evolve through collaboration between self-organizing crossfunctional teams. In constructing the different UML diagrams which serve as a stable guide in implementing the system, the proponents use the software DeZign, this is also use in constructing the Entity Relationship Diagram (ERD) and in generating the database schema. In developing the proposed system for the ICDAI, the proponents use C# language for the proposed systems interface design and structure. For the back end, the proponents use the PostgreSQL - a database engine. In this phase, ICDAI is checked to determine if there exist proper and important hardware and software components. It is essential for the efficiency of the system that ICDAI will have the necessary factors for the application to take effect.

11

1.7.5 Testing and Evaluation Testing and evaluation will be done to ensure accomplishment of the projects objectives and to test for the systems integrity in handling the monitoring process. The processed involved in the Diabetes Monitoring System is to be tested to ensure that all the requirements are being met, to display the flaws and possible errors in the system, and that the defined input will produce the desired output. In order to test its efficiency and accuracy, the researcher will have a testing activity to the ICDAIs assigned diabetes specialist. A dummy data will be provided to be fed into the system. The validity of the data output especially in generating medical prescriptions will be evaluated through manual enactment to ensure effectiveness. Furthermore, to achieve a better evaluation, we will have a parallel testing. Parallel testing will be done by comparing two different results from two different systems. The areas to be considered during the testing and evaluation also include user-friendliness and functionality. Actual results should agree with the required results. If the desired results are being met, then the testing and evaluation are successful.

12

Chapter 2 Review of Related Literature

This chapter is consists of various related literatures as regards to diabetes and medical research, write-ups about existing online testing systems and online surveys which have frameworks that could be used as basis in implementing the ICDAI Diabetes Monitoring Support System. In this review, the systems, its approaches and strategies are being mentioned and some systems are fully operational presently. 2.1 Review of Related Concepts 2.1.1 Diabetes Monitoring System In order to provide an improved monitoring technique that allows a more effective analysis of monitored data, a medical monitoring method is provided for diabetes, the method comprising the steps of acquiring medical data of a patient, analyzing the medical data with respect to a number of event parameters, whereas a number of user-definable trigger conditions are assigned to each of the event parameters, and in case a number of said trigger conditions are detected providing medical context information and activating an event notification (diabetes.webmd.com, 2010). In other words, not only is medical information provided, additionally an event notification is activated, if a number of trigger conditions are detected. The additional real-time event notification enables the clinical staff to respond immediately to a critical situation of the patient or the like. Furthermore the provided medical context information relating to the event can be reviewed directly. This enables the clinical staff to initiate treatment at a very early point of time. 2.1.2 Decision Support System DSS is a class of information systems (including but not limited to computerized systems) that support business and organizational decision-making activities.

13 A properly designed DSS is an interactive software-based system intended to help decision makers compile useful information from a combination of raw data, documents, personal knowledge, or business models to identify and solve problems and make decisions. It serves the management, operations, and planning levels of an organization and help to make decisions, which may be rapidly changing and not easily specified in advance (Siebel, 2010). Diabetes is the ninth leading cause of death in the Philippines, according to the health indicator statistics of the Department of Health. An estimated four million Filipinos are now afflicted with the disease. Studies show that diabetics worldwide have increased more than twice in the last few decades. This trend is expected to further increase to 380 million by 2025. There is also an increasing incidence of diabetes development especially among children in the past 10 years. About 500 new Filipino diabetic patients are identified per day. Determining those who are predisposed to have the disease due to family history, poor diet and sedentary lifestyle is a serious problem. The low-level awareness of diabetes is a threatening state that may leave Filipino patients suffering from its serious complications, if the disease is not managed properly (diabetesresearchclinicalpractice.com, 2009). 2.1.3 Knowledge Based System Knowledge based systems are artificial intelligent tools working in a narrow domain to provide intelligent decisions with justification. Knowledge is acquired and represented using various knowledge representation techniques rules, frames and scripts. The basic advantages offered by such system are documentation of knowledge, intelligent decision support, self learning, reasoning and explanation. Knowledge-Based Systems focuses on systems that use knowledge-based techniques to support human decisionmaking, learning and action. Such systems are capable of cooperating with human users (elsevier.com, 2010).

14 2.2 Diabetes System Approaches and Techniques 2.2.1 Case Based Reasoning Approach Case-based reasoning (CBR) is the process of solving new problems based on the solutions of similar past problems. Case-based reasoning is a prominent kind of analogy making. The introduction of hospital information systems into the clinical practice has led to the memorization of large amounts of data; such information may be stored in databases and in documents. When dealing with chronic diseases management like Diabetes, one of the most effective is Case Based Reasoning (CBR). In such a context, the data collected from patients' follow up (stored in the case library or the patients database) embody an important knowledge source, to be integrated with the available declarative knowledge. Case based reasoning had been selected for Diabetes Management. CBR was selected for this application because: (a) existing guidelines for managing diabetes are general and must be tailored to individual patient needs; (b) physical and lifestyle factors combine to influence blood glucose levels; and (c) CBR has been successfully applied to the management of other long-term medical conditions (Marling, et al, 2007). Since 1980s, case-based reasoning (CBR) methodology has been proposed as a possible means for supporting decision making and complex management in medical domain. 2.2.2 Evidence Based Medicine Approach Evidence-based medicine (EBM) methodology aims to apply the best available evidence gained from the scientific method to medical decision making. It seeks to assess the strength of evidence of the risks and benefits of treatments (including lack of treatment) and diagnostic tests. EBM seeks to clarify those parts of medical practice that are in principle subject to scientific methods and to apply these methods to ensure the best prediction of outcomes in medical treatment as in Diabetes decision support systems. The strength of evidence based medicine is that it moves clinical practice from anecdotal experience and expert opinion to a strong scientific foundation. It integrates clinical medicine with basic and clinical research and thus enhances the effectiveness and safety of diagnostic, preventive, and therapeutic measures (Herman, 2002).

15 In general, evidence-based medicine advocates that experimental methods that is, randomized, controlled clinical trials provides the gold standard for evaluation and the basis for clinical practice. Conducting systematic reviews of the literature and developing hierarchies for grading evidence have been necessary components of evidence-based medicine. The latter have often assessed both the strength of the effect and the quality of the evidence. Using these systems, evidence-based guidelines have evolved and proliferated. Evidence based medicine has the potential to decrease practice variation and to improve the effectiveness and efficiency of care. 2.2.3 Medical Information Desktop Application Medical desktop applications are software program that provides an easy, intuitive interface designed specifically for doctors and health professionals. It formats reports automatically while storing patient demographics for easy retrieval (mendosa.com, 2010). 2.3 Diabetes Monitoring and Decision Support Related Systems 2.3.1 DiabetEASE web-based Monitoring System DiabetEASE is an advanced web-based diabetic health monitoring system which is designed specifically to track and trend the daily insulin requirements. With the click of a button one can upload information from his blood glucose meter to the extremely userfriendly site. Data is displayed in easy-to-read graphs that can be customized to show the blood glucose levels according to day, week, month, or by events such as exercise or meals. With DiabetEASE, readings are available from anywhere in the world. Whether traveling extensively for work or play, data is at your fingertips wherever there is an internet ready computer (diabetease.com, 2008). 2.3.2 DiaComp: Computerized Management of Type II Diabetes The DIACOMP computer system provides a method of assisting Type II diabetic patients with the day-today management of their insulin administration. The patient is provided with a small, portable computer terminal/modem and is instructed on how to

16 connect with the main DIACoMP computer over existing telephone lines. The patient calls the DIACOMP system daily to report blood glucose levels, amounts of insulin administered, and other pertinent information. The DIACOMP system then evaluates the data, determines if "stat" intervention is required and then makes suggestions for insulin use for the following day. Emergency, or "stat," intervention has a separate routine which overrides the "usual" interaction. The routine is capable of adjusting dose, insulin type (regular, intermediate acting, etc.) and regimen (AM, split, mixed, etc.). The dosage suggestion is based on 6 weeks of glucose and insulin data and will take into account both long and short term trends, thereby providing a personalized insulin regimen. Additionally, the DIACOMP system has separate modes which provide detailed reports for clinicians, a research database, and education for the patient about diabetes. The system is predicted to reduce health care costs for its users by decreasing the number of direct patient clinician interactions and by providing better day-to-day care for the patient. Further, the early detection of infection and of other events with significant physiologic impact is expected to decrease the number of hospitalizations (Faith, et al, 1990). 2.3.3 DDS: Initial Experience with the Vermont Diabetes Information System The VDIS is a decision support system designed to help primary care providers and their diabetes patients achieve guideline-based treatment targets. It has 5 defining characteristics: (1) use of the Chronic Care Model as an organizing framework, (2) daily data feeds from otherwise independent laboratories, (3) automatic test interpretation with algorithms on the basis of consensus guidelines, (4) use of fax and mail to report to providers and patients not easily reached by electronic networks, and (5) report formats that are accessible and useful to patients and providers. The primary function of the system is to collect pertinent clinical information and then provide accurate and timely flow sheets, reminders, alerts, and population reports for providers and their diabetes patients (MacLean, 2006).

17 2.3.4 Outpatient Assessment of Karlsburg Diabetes Management System Karlsburg Diabetes Management System (KADIS) is an interactive model-based system focused on interactive simulation of insulin/glucose profile. KADIS is based on a mathematical model that describes the glucose/insulin metabolism in type 1 diabetes in the form of a coupled differential equation system. It is expanded for application in type 2 diabetes by including an insulin controller describing basal and glucose-stimulated insulin secretion and the therapy with oral anti-diabetic drugs. The study was performed as a randomized, multi-centric, prospective, and open-label trial in a case control design. KADIS has the feature to identify the individual glycemic status of patients and is a patient-centered therapy simulator with the potential to assist physicians in improving diabetes control of insulin-treated diabetic outpatients. Patient-centered KADIS decision support was generated in six steps: 1) input of CGMS (continuous glucose monitoring system) profile and self-control data (time and amount of food intake and insulin therapy), 2) identification of patient specific model parameters and analysis of actual weak points, 3) simulation of glycemic effects of insulin therapies (dosage, type, and timing) according to the International Diabetes Foundation global, 4) generation of KADIS-based recommendations, 5) presentation of the results in a KADIS report visualizing weak points of glycemic control and detailing carbohydrates (amount and time of intake) and insulin (dosage, time, and type) required in silico to optimize the blood glucose curve of the patient, and 6) application for therapeutic decisions by the physician (Petra, et al, 2007). 2.3.5 CGMS: Continuous Glucose Monitoring System A continuous glucose monitoring system (CGMS) is an FDA-approved device that records blood sugar levels throughout the day and night. Results of at least four finger stick blood sugar readings taken with a standard glucose meter and taken at different times each day are entered into the monitor for calibration. Any insulin taken, exercise engaged in, and meals or snacks consumed are both entered into a paper-based "diary" and recorded into the monitor (by pushing a button to mark the time of the meals, medication, exercise, and other special event you wish to

18 record). The information will be presented as graphs or charts that can help reveal patterns of glucose fluctuations (Seibel, 2009). The continuous glucose monitor is not intended for day-to-day monitoring or long-term self-care and it is not a replacement for standard blood sugar monitoring. It is only intended for use to discover trends in blood sugar levels. This helps your health care team make the most appropriate decisions regarding your treatment plan.

19

Currently, Iligan City Diabetes Association Inc. provides essential medical services to each patient in achieving a healthier routine. Patients are assessed by standardized procedures through medical examinations and even using the shared care approach in helping patients lessen and eventually managed to be fully free from diabetes. Medical records of each patient are interpreted every after assessments to provide proper medical measurements for the patient. However, the medical practitioner interpretations are done over and over for every patient who has the same conditions making this a tedious activity for the specialist. Records are still kept manually, producing difficulties in keeping tracks with a certain patients condition. Taken as a whole, the present state of ICDAI is a universal manner for checking and prescribing diabetes condition which generally is a time-consuming and a prone to human errors practice. With the proposed system, a desktop application will be of great help to hasten the process in monitoring diabetic conditions for patients. Guided with the present approaches and methods used for developing and enhancing medical monitoring system, the researcher will use a little concept of the case-based reasoning approach which capitalizes on experience with past problems and solutions to determine solutions for current problems.. Case base reasoning is a good approach for diabetic monitoring because it can integrate numeric data, such as blood glucose readings, with descriptive and personal preference data, such as work schedules and lifestyle choices for the patients resurgence. Table 2.1 (see next page) shows the checklist of the related systems and studies with their corresponding features and functionalities. Overall, the proposed system manages and trends patients medical records that is tracking patients insulin, trends blood sugar, accurate flow of reports and spreadsheets and alerts for the specialist and patients advantage and the system is also a knowledge-based system integrated with a decision support feature which is to generate basic advisory and first-aid medical prescriptions comparable enough to those of the experienced medical practitioners.

20

2.4. Summary of Review of Related Literature Table 2.1 Checklist of Related Studies and Systems
Functionalities / Features Dated records of patients blood sugar Evaluate and determines reports for interventions Accurate flow sheets, reminders and alerts for the practitioner and for the patients More detailed reports for patients Simple visualization of results Generates prescriptions comparable to experienced clinicians DiabetEASE DiaComp Vermont Diabetes Information System Karlsburg DMS CGMS

21

Chapter 3 Theoretical Framework

3.1 The Diabetes Mellitus Diabetes Also known as Diabetes Mellitus, a disease in which the pancreas produces insufficient amounts of insulin, or in which the bodys cells fail to respond appropriately to insulin. Insulin is a hormone that helps the bodys cells absorbs glucose (sugar) so it can be used as a source of energy. In people with diabetes, glucose levels build up in the blood and urine, causing excessive urination, thirst, hunger, and problems with fat and protein metabolism. Type 1 Diabetes Also known as juvenile diabetes, is a form of diabetes mellitus that results from
autoimmune destruction of insulin-producing beta cells of the pancreas. Insulin is a hormone

that is needed to convert sugar, starches and other food into energy needed for daily life. Only 5-10% of people with diabetes have this form of the disease. Injection is the most common method of administering insulin; insulin pumps and inhaled insulin have been available at various times. Pancreas transplants have been used to treat type 1 diabetes; however, this procedure is currently still at the experimental trial stage. Type 1 Diabetes can lead to serious complications if left untreated or poorly controlled, such as retinopathy, cardiovascular disease, nephropathy, neuropathy, and peripheral vascular disease and premature death.

22

Type 2 Diabetes

Formerly known as non-insulin-dependent diabetes mellitus (NIDDM) or adultonset diabetes is a metabolic disorder that is characterized by high blood glucose in the context of insulin resistance and relative insulin deficiency. Insulin resistance means that body cells do not respond appropriately when insulin is present. Type 2 diabetes is due primarily to lifestyle factors and genetics. It is sometimes easier to treat than Type 1 Diabetes, especially in the early years when insulin is often still being produced internally. Severe complications can result from improperly managed type 2 diabetes, including renal failure, erectile dysfunction, blindness, slow healing wounds including surgical incisions, and arterial disease, including coronary artery disease. Type 2 is initially treated by adjustments in diet and exercise, and by weight loss, most especially in obese patients. Gestational Diabetes Gestational diabetes mellitus is a condition in which women without previously diagnosed diabetes exhibit high blood glucose levels during pregnancy. It generally resolves once the baby is born. Based on different studies, the chances of developing GDM in a second pregnancy are between 30 and 84%, depending on ethnic background. A second pregnancy within 1 year of the previous pregnancy has a high rate of recurrence. There are 2 subtypes of gestational diabetes (diabetes which began during pregnancy): Type A1: abnormal oral glucose tolerance test (OGTT) but normal blood glucose levels during fasting and 2 hours after meals; diet modification is sufficient to control glucose levels Type A2: abnormal OGTT compounded by abnormal glucose levels during fasting and/or after meals; additional therapy with insulin or other medications is required

23 A diagnosis of gestational diabetes doesn't mean that you had diabetes before you conceived, or that you will have diabetes after giving birth. Infants born to mothers with GDM are at risk of being both large for gestational age and small for gestational age. 3.2 Monitoring Diabetes Monitoring diabetes relates to a method and system of present medical invention pertaining to computer programs for controlling a medical monitoring system. In order to realize the need for physicians to assess the results in making recommendations, concepts and approaches used in working existing systems are being manipulated. Fig. 3.1 is a process flow representation that shows procedure of ICDAI Diabetes Monitoring Support System.
External Process Flow Internal Process Flow
Patients current medical statistics (blood sugar, insulin, blood pressure)

Patient Take test from a physician outside ICDAI Physician inputs laboratory results

Record retrieval

Case-based Analogy

Evidence-based Analogy

INPUT
Printed summarized records, data sheets and prescriptions handed to patient if requested Date sheets and graphs viewable through the GUI and printable for physicians long term documentation Data stored

Graphical User Interface

OUTPUT

Fig. 3.1 ICDAI-DMSS Structural Flow

24 Case-based Concept This approach assists the memorization of large amounts of data from the large number of patients in ICDAI. This analogy matches the newly inputted patients medical measurements to the stored diabetic cases. Furthermore, case based reasoning is also a mean for supporting decision making and complex management in medical field. Evidence-based Concept Evidence based medicine seeks to assess the strength of the documentations of diagnosing diabetes. This analogy brings about the coordination of outdated patients measurements stored in the databases and the current status of patients, thus improving the effectiveness and efficiency of care. 3.3 Decision Support System The impression of a decision support system holds up the decision making by assisting the organization about structured issues, in this circumstance is the monitoring the medical illness diabetes. Which, taken as a whole, has a framework comprising elements and relations between them that are unknown, too remedial and maybe misunderstood by patients. For the ICDAI-DMSS to achieve its objectives and accomplish the trending analysis, decision support will be applied. DSS concept increases the effectiveness of decision making effort, like how patients are guided in their diabetic life, how they are suppose to take the good practice in exercising their bodies and medicinal intakes; accordingly medical statistics of each patient are then roughly to its precision. Moreover, assimilating this support concept involves the systems engineering steps of formulation of alternatives, the analysis of their impacts, and interpretation and selection of appropriate options for execution. 3.4 Knowledge-based System This artificial intelligence tool works in a narrow domain to provide intelligent decisions with justification. ICDAI, as a medical organization is a domain that needs the

25 functionalities present in knowledge based system. This system is acquires and depicted using various knowledge representation techniques rules, frames and scripts. To pull off the short-term purposes of ICDAI-DMSS, which are to notify the physician about the patients health status and condition, to provide significant guidance in support to the patients diet and exercise planning, and to maintain a comprehensive personal history, the knowledge based system approach is a vital advancement. 3.5 DMSS: A Medical Management Information Managing patients information and health verifications are extremely vital. A successful system centers on early identification of health risks and preventative education. DMSS is designed as a support tool for managing the patients status concerning their diabetes condition. DMSS assist in measuring health status and patients individual needs. It also validates the practices that lead towards improved quality of patient care. DMSS also asses the individuals specific education and behavioral needs. DMSS provides data for scientific and economic analysis and generally, it identifies patients diabetic needs, outcomes and goals.

26

Lack of availability, integrity and confidentiality of patients information

No assurance of information security

Diabetic patients participatio n still subsist in the overall technologic al assessment

Consumes time when it comes to retrieving patients records

ICDAI- Diabetes Monitoring Support System

Patients Information System

Medical Statistics and Diabetes Monitoring System

Medical Updates and Decision Support System

Medical Aftermath and Knowledge Based Systems

Medical System ICDAI- DMSS Database

Fig. 3.2 ICDAI-DMSS Theoretical Framework

27

Chapter 4 The ICDAI Diabetes Monitoring Support System

The ICDAI Diabetic Monitoring Support System is designed to provide assistance to the physician in recording patients information and monitoring their diabetic condition. This project has the following features and capabilities: Dated records of patients blood sugar, blood pressure and other medical measurements needed in the medication Evaluate and determine the more detailed reports for possible interventions on the patients condition Accurate flow sheets, reminders and alerts for the practitioner and for the patients Generate basic prescriptions comparable enough to experienced clinicians Simple visualization of results

The succeeding discussion states the overall system requirements specifications and functional requirements of the system to be developed. 4.1 System Requirement Analysis and Specifications 4.1.1 Introduction System Scope The ICDAI Diabetic Monitoring Support System is a system intended for recording and monitoring of the diabetic patients health conditions at the ICDAI at which only the physician who is allowed to access into it. The system can aid the physician in helping his patient to maintain control of diabetes since the system will endow with considerable supervision to support diet and exercise planning. The system will enable data collection,

28 will promote trend analysis through producing easy-to-read graphs and will provide recommendations and prescriptions if necessary. It is not under the control of the system if the patient will be absent during regular meetings and no data will be inputted in his account. Moreover, the system will be implemented as a desktop application. 4.1.2 Overall Description System Perspective The ICDAI-DMSS is a new system that will replace the current manual recording and monitoring of the diabetic patients medical measurements or condition. User Classes and Characteristics Physician this user has a global view size of the system participation and user productivity. He organize and update the patients medical records, he can view the flow sheets and detailed reports of each member patient in ICDAI and be able to print the reports. Patient this user receives the printed detailed statements of their diabetic condition. And also be able to obtain the generated basic prescriptions preferable for their current status. Operating Environment OE-1: The ICDAI-DMSS shall operate in a desktop computer which will be restricted for the use of the allowed physician only. OE-2: ICDAI-DMSS shall run on a computer with PostgreSQL object relational database. User Documentation

29 UD: A hardcopy of the user manual will be provided. And it will also be included in the system to serve as a guide for the first time users. 4.1.3 System Features Prints generated reports of patients Stores photo of ICDAI patients (allows Physician to upload images). Uses external sources (third party software) to generate reports. Implemented in a single workstation (serves as the main server and database server). 4.1.4 External Interface Requirements User Interface UI: The systems UI is designed to be spontaneous and user-friendly as possible. An error messages will prompt the user in case of an inaccuracy in input. Notifications through warning messages will serve to keep the user posted. Hardware Interface HI: The system will need the basic computer hardware package with sufficient specifications; enough memory and power supply to fully support the operations of the system and to carry out the functions accordingly without hardware interruptions.

30

4.2 Design Models This section presents the design models of the system that will offer comprehensive information for the full lifecycle of object-oriented software. 4.2.1 Context Diagram This diagram represents the external entities that could interact with ICDAI-DMSS. It shows the system boundaries, external entities that interact with the system, and the relevant information flows between these external entities and the system.

INPUT

OUTPUT

Medical Record Patient Information Patient Table ICDAI-DMSS ICDAI Diabetes Monitoring Support System Lab Test Results Recommendation Patient

Monitor Condition Physician

Reports Physician

Fig. 4.1 Context Diagram for ICDAI-DMSS

31

4.2.2 UML Use Case Model This diagram displays the relationship among actors and use cases. It describes the functional requirements of the system, the manner in which outside things (actors) interacts at the system boundary, and the response of the system. 4.2.2.1 Use Case Diagram

Fig. 4.2 Use Case Diagram for ICDAI-DMSS

32 4.2.2.2 Use Case Specification Actor Specification Actor: Physician Description This is the one who administers the ICDAI Monitoring Support System and the one who can only access the system granted that he or she is the authorized physician/personnel. Actor: Printer Description After the Physician has generated such laboratory reports, this may be able to print these reports for document keeping or when the patients request these reports. Actor: DMSS Description This is the one that does all the monitoring and viewing of all the records after the transactions are being done.

Use Case: Add Laboratory Test

33 This use case allows the Physician to add laboratory test with its normal value ranges into the system. Basic Flow This use case starts when the Physician wishes to add a patient into the system. 1. The actor selects the Home dropdown menu and selects Add Laboratory Test. 2. The system displays the Add Laboratory Test form. 3. The actor fills up the form. 4. The actor clicks the Add button. 5. The system displays the Add Laboratory Test Details form. 6. The actor fills in the form. 7. The actor clicks the Save button. 8. The system saves the added laboratory test details in the database. 9. The system displays a confirmation message. Alternative Flow If the actor wishes not to submit the Patient details, he may Cancel the operation at which point the use case ends. Pre-Conditions The Physician must be authorized to access the system and views the Main Form.

Post-Conditions If the use case is successful, the new laboratory test is added into the system. Otherwise, the system state is unchanged. Use Case: Add Patient This use case allows the Physician to add a patient and his details into the system.

34 Basic Flow This use case starts when the Physician wishes to add a patient into the system. 1. The actor selects the Patient dropdown menu and selects Add Patient. 2. The system displays the Patient Information form. 3. The actor fills up the form. 4. The actor clicks the Save button. 5. The system saves the added patient details in the database. 6. The system displays a confirmation message. Alternative Flow If the actor wishes not to submit the Patient details, he may Cancel the operation at which point the use case ends. Pre-Conditions The Physician must be authorized to access the system and views the Main Form.

Post-Conditions If the use case is successful, the new Patient data is added into the system. Otherwise, the system state is unchanged.

35

Use Case: Generate Reports This use case allows the Physician to generate reports. Basic Flow This use case starts when the Physician wishes to create reports. 1. The actor may request the system to print a report or result. 2. The system displays the print dialog box. 3. The actor sets the printer settings and click OK. 4. The system prints the report. Alternative Flow If the Physician did not wish to print the chosen report, he may choose Cancel at which point the use case ends. Pre-Conditions The Physician must be authorized to access the system and must be in any available reports in the system. Post-Conditions If the use case is successful, the report is being generated and printed. Otherwise, the system state is unchanged.

36

Use Case: Update Patient Record This use case allows the Physician to search existing patient and update his/her record in the system. Basic Flow This use case starts when the Physician wishes to update the laboratory records of the patient in the system. 1. The actor selects the Patient dropdown menu and selects Update. 2. The system displays the Search form. 3. The actor inputs the name of the patient. 4. The system displays a number(s) of patients name with their details. 5. The actor selects the patient name and clicks the Update button. 6. The system displays the Laboratory Records GUI. 7. The actor inputs the blood sugar and blood pressure details. 8. The system enables the Add Test button. 9. The actor includes laboratory test from the Laboratory Tests Available form. 10. The system enables Update Results button. 11. The actor inputs the values for the chosen laboratory test and clicks Recommend button. 12. The system displays the Recommendation GUI. 13. The actor key in notes and clicks the Save button. 14. The system displays a confirmation message. Alternative Flow If the actor wishes not to save the updated patient records, he may Cancel the operation at which point the use case ends.

37

Pre-Conditions The Physician must be authorized to access the system and the use case can also start when the actor adds a new patient through the Add Patient Use Case. Post-Conditions If the use case is successful, the Patient data is updated in the system. Otherwise, the system state is unchanged.

38

Use Case: View Reports This use case allows the Physician to view reports from the system. Basic Flow This use case starts when the Physician wishes to view available reports from the Diabetes Monitoring Support System. 1. The actor selects the View dropdown menu and selects a certain Report. 2. The actor chooses a report to view. 3. The system displays the chosen report. Alternative Flow None.

Pre-Conditions The Physician must be authorized to access the system and views the Main Form.

Post-Conditions If the use case is successful, the report is being viewed. Otherwise, the system is unchanged.

39

4.2.3 Activity Diagram This diagram displays a special state diagram where most of the states are action and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by the internal process.

Fig. 4.3 ICDAI-DMSS Activity Diagram

40 4.2.4 Sequence Diagram This diagram displays the time sequence of the objects participating in the interaction. It is used to depict work flow, message passing and how elements in general cooperate over time to achieve a result.

Fig. 4.4 Add Laboratory Test Sequence Diagram

41

Fig. 4.5 Add Patient Sequence Diagram

42

Fig. 4.6 Update Patient Record Sequence Diagram

43

Fig. 4.7 View Reports Sequence Diagram

44

4.2.5 Class Diagram This diagram models class structure and contents using design elements such as classes, packages and objects.

Fig. 4.8 Class Diagram of ICDAI-DMSS

45

4.2.6 Component Diagram This diagram illustrates the architectures of the system and the structural relationship between its components. It displays the high level packaged structure of the code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some components exist at compile time, at link time, at run time well as at more than one time.

Fig. 4.9 Component Diagram of ICDAI-DMSS

46

4.2.7 Deployment Diagram This diagram shows how ETESIMS will be physically deployed in the hardware environment. It displays the configuration of run-time processing elements and the software components, processes, and objects that live on them. Software components instances represent runtime manifestations of code units.

Fig. 4.10 Deployment Diagram of ICDAI-DMSS

47

4.2.8 Database Design Model This section describes the different parts of the design of an overall database of the system. This shows the tables, relationships, views, procedures, functions, triggers, sequences, and database links used in developing the system. 4.2.8.1 Entity Relationship Diagram

Fig. 4.11 ERD for ICDAI-DMSS

48

4.3 Structure and Interface 4.3.1 Program Structure

ICDAI-DMSS

Home

Patient

View

Help

Laboratory Test

Add Patient

List of Laboratory Tests

Help Contents Contents

About ICDAI

Patient Laborator y Records

List of Members

About DMSS

Exit

Graphical Laboratory Records Patient Medical Record

Fig. 4.12 ICDAI-DMSS Program Structure

49

4.3.2 Graphical User Interface The functionality done by the ICDAI-DMSS is grouped by the following systems menu options: Log In The physician uses the log in form to access the system.

Fig. 4.13 Log-In Form GUI Main Form Having the authority to access the system, the Main Form will be displayed. This user interface shows the main categories of DMSS.

Fig. 4.14 Main Form GUI

50 Home Laboratory Test

This user interface allows the Physician to add laboratory test by filling in the fields indicated and delete existing laboratory test.

Fig. 4.15 Add Laboratory Test GUI

Fig. 4.16 Add Laboratory Test Range GUI About ICDAI

51 This interface displays the mission and vision and a brief description of Iligan City Diabetes Association Incorporated. Patient Add Patient

This user interface allows the Physician to add new diabetic patient by filling in the required fields indicated and saving it.

Fig. 4.17 Add Patient GUI

52

Update Lab Record

This user interface allows the Physician to update the existing laboratory records of a certain patient by filling in the required fields with new laboratory test results and adding of recommendations.

Fig. 4.18 Search Patient GUI

53

Fig. 4.19 Update Patient Laboratory Record GUI View List of Laboratory Test

This interface views the available list of laboratory test stored in the system.

54

Fig. 4.20 List of Laboratory Test GUI

List of Members

This user interface is a report presenting a list of the existing patients in ICDAI.

Fig. 4.21 List of Members GUI Graphical Laboratory Records

55 This user interface displays the graphical representation of laboratory records/results of a certain patient.

Fig. 4.22 Graphical Laboratory Records GUI

Patient Medical Record

This user interface is a report of the medical history of a certain patient.

Fig. 4.23 Patient Medical Record GUI

56 Help Help Contents

This user interface is a compilation of a step by step user to guide users in operating the system. About DMSS

This user interface presents a brief description of the overall functionality of the Diabetic Monitoring Support System.

57

4.4 Physical Environment and Resources The following are the software and hardware requirements that must be taken into consideration in developing and running the system. 4.4.1 Developer This section shows the software and hardware requirements for the developers of the system. These are needed to make the development of the system easier and faster.Tables 4.1 and 4.2 below are the specifications of hardware and software for the developers. Table 4.1 Developers Minimum Software Requirements
Developers Minimum Software Requirements Operating System IDE DBMS Plug-ins Windows XP Mincrosoft Visual C# 2010 PostgreSQL 8.3

Table 4.2 Developers Minimum Hardware Requirements

Developers Minimum Hardware Requirements Processor RAM Size HDD Size Input Devices Output Devices Intel Pentium 4 1Gb DDR 40Gb PS2/USB Mouse and Keyboard Monitor

58

4.4.2 Client This section shows the software and hardware requirements for the clients of the system. These are needed to ensure that the system will run appropriately.Tables 4.3 and 4.4 below are the specifications of hardware and software for the client. Table 4.3 Clients Minimum Software Requirements
Clients Minimum Software Requirements Operating System DBMS Windows XP PostgreSQL 8.3

Table 4.4 Clients Minimum Hardware Requirements

Clients Minimum Hardware Requriements Processor RAM Size HDD Size Input Devices Output Devices Intel Pentium 4 1Gb DDR 40Gb PS2/USB Mouse and Keyboard (Camera) Monitor and Printer

Chapter 5 Results and Observations

This chapter shows the results and testing methods done in evaluating the system to verify that all the requirements are being met and to find possible errors that could transpire with the current version of the ICDAI-DMSS.

59 5.1 Information Gathering The developers were able to acquire vital and sufficient information from the interview with the Iligan City Diabetes Association, Incorporated. 5.2 Design of the System The developers designed the models to provide structural view for the system to achieve the target functionalities, which were presented in the previous chapter. The Graphical User Interface were developed in comparable to the forms and documents used in the operations of ICDAI 5.3 System Development In developing the system, C# 4.0 was used together with PostgreSQL 8.3 for the database.

60

5.4 User Testing and Results Functional Requirement Testing This testing is done by performing all the systems functionalities to verify that the system meets the imperative specifications and functional requirements. It helps uncover possible discrepancies that may exist in the system. We asked our client to perform the testing and were able to get expected results. The table below shows the different functionalities, its test and the results in evaluating the system. Table 5.1 Functionality Table
FUNCTIONALITIES Add Patient TEST Add Patient details and initial medical Update Patient Laboratory Records Add Laboratory Test Update Laboratory Test View Reports Generate Reports record Input new values for every laboratory test taken Add Laboratory Test Info Update Laboratory Test Info View an existing Report Generate a certain Report Success Success Success Success Success Manage Laboratory Test Table Manage Laboratory Test Table Manage Laboratory Test Table Manage Records Manage Records RESULTS Success DESCRIPTION Manage Patient Table

61

Add Patient this function allows the Physician to add a patient into the system. The Physician provides the basic personal information of the patient. Browse for a picture or may take one and store in the database. This test was successfully done provided with a confirmation message that patient has been successfully added into the system.

Update Laboratory Records this function allows the Physician to store new values for each existing laboratory test a certain patient has undergone. The Physician will have to search for the patient and input the new laboratory results. The physician views the recommendation provided in the recommendation tab. This test was successfully done provided with a confirmation message that the updates has been successfully saved.

Add Laboratory Test this functionality allows the Physician to add new laboratory test. The Physician supplies the necessary information and conditional values for the new lab test. This test was successfully done provided with a confirmation message that the new laboratory test has been added into the database of the system.

Update Laboratory Test this functionality allows the Physician to update existing laboratory tests in the system. The Physician supplies the necessary conditional values or ranges for the laboratory test. The test was successfully done provided with a confirmation message that the laboratory test has been updates into the system.

62

View Reports this function allows the Physician to view a certain report in the View tab of the Main Form. The Physician will choose any of the four available reports to be viewed. This test is successfully having a short loading time.

Generate Reports this function allows the Physician to generate a chosen report for the documentation of ICDAI. The physician prints the reports viewed. This test is successful having a printed documentation of any of the available reports

Non-Functional Requirements Testing While the functional requirement carries the performance of the sole functions and operations, the non-functional requirement focuses on how the system must behave. This includes the remaining requirements not covered by the functional ones. This approach specifies criteria to judge the overall operation of the system rather than a specific behavior. In order to assess the systems non- functional requirements, the developers employ the use of a rating form to evaluate the different aspects of the systems non-functional requirements (see Appendix). The non-functional requirements the proponents considered necessary includes performance, usability, layout and design and system response. The developers gave the evaluation sheet to the physician who would be the authorized person to access the DMSS and hence the only respondent in the testing. Testing the systems nonfunctional requirements would also help the developers in determining the users perspective and his/her feedback toward the system.

63 Presented in the next page, Table 5.2 is the result of the user assessment of the system.

64

Table 5.2 Non-functional Rating for the ICDAI-DMSS

Rating (1-Strongly Disagree, 5-Strongly Agree) 1 2 3 4 5

Non-functional Requirements

Response Average 4 3 3

The graphics, media elements, and content are clear and appealing. System is usable without reference manual or user help. User can easily navigate between program screens. Menus and features make the application easy to use. System performs management tasks satisfactorily. Search methods and results are easy to understand Provides appropriate feed back to user responses. Runs smoothly without delay. System would make job faster and effective. Overall Average Response

4 3 3 3 2 4 3.222

After the evaluation, the developers proceeded to the analysis of the result and its implications to the non-functional behavior of the system. The user rate each item on a 1 to 5 response scale where: Strongly Disagree Disagree Neutral Agree Strongly Agree 1 2 3 4 5

65

With the clients respond shown in the figure, the proponents were able to evaluate the system basing from the level of agreement or disagreement of our user respondent. For the first non-functional requirement which is the systems graphics and media elements, the respondent gave a mark of 4. This value means that the user agreed that the contents and graphics or design of the system is appealing and well-organized. The respondent gave a 4 mark on the non-functional requirement that the system is usable without reference or manual help, this means that the overall ease of usability of the system is being achieved. For the systems ease of navigation between program screens, the participant gave the mark of 3 which indicates that they agree that the interface of the system is user-friendly. The capability of the system to perform its tasks satisfactorily and is understandable in the most easy way to handle, availability of feedback and that it effectively lessens if not eliminates transaction delays has an average mark of 3, giving contentment to the overall behavior of the system. The respondent somehow not so agree that the system runs smoothly and in much lesser time giving a 2 mark. Lastly, the ability of the system to make the job faster and effective, the researchers got a mark of 4. This value means that the user of the system agreed to the evaluation compared to their current way of handling transactions. 5.5 Evaluation and Summary To evaluate the overall functionality and reliability of the system, functional and non-functional testing was done. This is also to reassure that the target system performs what is expected of it, and also helps with the identifications of possible bug and error occurrences. In case of invalid or insufficient inputs, appropriate actions like displaying of notification message or showing no results will be taken to handle such inputs. The results shown in the tables in the functional and non-functional tests infer that DMSS is a satisfactory system software that carries out its functions effectively. Also, it is a user-friendly software that can be easily used, understood and navigated by new users in the medical field.

66 5.6 Systems Capabilitites and Limitations Systems availability depends on the existence of the fundamental tools (electricity and/or workable PC). Initially, the system points to a practical function where the user, maily the Physician does not need to be logged-in with the use of valid usernames and passwords. User should only be authorized to gain access to the system. The reports generated by the system are textual in nature which means that all data gathered are presented as it is or just a summary of it. Furthermore, graphical representation of each patients laboratory test results is made.

67

Chapter 6 Conclusion and Recommendations

6.1 Conclusion Having the main purpose of developing this system that is to provide assistance in recording and monitoring the diabetic criticality of each member patient, the overall result points to the idea that the ICDAI- Diabetes Monitoring Support System is feasible, functional and fully usable. Accordingly, ICDAI-DMSS confirmed the following; The data flow diagram developed assisted in the overall monitoring of patients condition. It helped the proponents analyze how the designed system should guide the user in assessing the results in making additional recommendations.

DMSS provides and follows the trend of a computer-based approach, which is an easier way of keeping vital details for recording and updating medical records of every member patient. Each patients laboratory test results were out looked through the displayed graphs in the report functionality of the system.

The use of ICDAI-DMSS lessens the operational time of the authorized physician; it provides a controlled flow of updating laboratory test results to having practical recommendations and guidelines for every diabetic patient.

DMSS presents a systematic and clear representation of the patients individual medical provision through produced graphs and generated reports.

68

The manual operation of the association does not practically provide a statistical perspective in the diabetic medicine. It is just a mere recording of patients condition. Through DMSS as a desktop application, patients information were utilized and processed in a user-friendly interface.

Testing and evaluating the developed system, DMSS, were done that lead to determining the effectiveness of the approaches and methods used by the developers.

The developers were able to achieve the objectives set in the previous chapters. The team has also constructed the significant modeling approaches and structural designs for the organization of the flow of the systems implementation. After DMSS has been tested, the functionalities of the system were performed successfully and provided accurate reports. The user interface was implemented in such a way that the user need not to have advance knowledge in using application systems. The evaluation for non-functional requirements with the criteria we have set has earned superior results. In one way or another, there is always an advantage that may be derived from this implementation and be useful among users who are in need medical application such as ICDAI-DMSS.

69

6.2 Recommendation The system is intended to furnish the clients needs and meet their demands but however, due to time constraints and limited resources, the researchers have these system recommendations. The system could have Log-in and Log-out functionality for the Physician to provide a more secure operational environment. Extend or add the scope of the medical system. The system could provide a scheduler for the patient laboratory test date. Provide a portal through a web server where patients can view his medical record and may record his medical measurements so Physicians will just have to add recommendations and give medicinal accumulations. Improve the interfaces of reports and graphs. Improve the searching algorithm.

70

References DiabetEASE: Monitoring the Future. 2008. [Online]. Available: http://www.diabetease.com. (July 18, 2010) eMedicineHealth. Exams and Heatlh. 2010. [Online]. Available: http://www.emedicinehealth.com/diabetes/page5_em.htm#Exams and Tests. (July 24, 2010) Faith, R., Beneroch, L., Chausmer, A. Department of Computer Science, College of Engineering University of South Florida. 1990. (August 07, 2010) Farcot, R. (2004). White Paper - Digital Dashboard Technology-Visualize the Possibilities [White Paper]. [Online]. Available: http://www.ciphersys.com/Digital%20Dashboard %20Technologies.pdf. (July 17, 2010) Filho, Antonio Ribeiro, MDSS. Medical Diagnosis Support System. Knowledge Engineer SI Intelligent Systems. 2006. (August 08, 2010) Garcia-Olaya, A., Gomez, A.J., et al. Middleware CSCW Architecture for Diabetes Shared Care. 2004. (August 06, 2010) Herman, W. MD, MPH. Evidence-Based Diabetes Care. Clinical Diabetes. Volume 20. Number 1, 2002. (July 18, 2010) Knowledge-based Systems. [Online]. Available: http://www.elsevier.com/wps/find/journaldescription.cws_home/525448/description#descri ption. (August 8, 2010)

71 MacLean, Charles D., MDCM, Littenberg, Benjamin, MD, Gagnon, Michael, MS. American Journal of Public Health. Diabetes Information Support: Initial Experience with the Vermont Diabetes Information System. April 2006, Vol 96, No. 4. (July 23, 2010) Marling, C., Shubrook, J., Schwartz, F. Towards Case-Based Reasoning for Diabetes Management. Ohio University, Athens, Ohio 45701, USA. 2007. (July 17, 2010) On-Line Diabetes Resourses. Updated: February, 2010. [Online]. Available: http://www.mendosa.com/software.htm. (August 08, 2010) Overland, J., Mira, M. Diabetes management: shared care or shared neglect. May 2009. [Online]. Available: http://www.diabetesresearchclinicalpractice.com/article/S01688227%2899%2900016-9/abstract. (July 25, 2010) Petra, A., Vogt, L., Klaus, K. Outpatient Assessment of Karlsburg Diabetes Management SystemBased Decision Support. Diabetes Care, Volume 30. Number 7, July 2007. (August 07, 2010) Pollock, Jeanette. The Effects of Diabetes. February 2006. [Online]. Available: http://ezinearticles.com/?The-Effects-of-Diabetes&id=130351. (August 08, 2010) Santi Wulan Purnami, Jasni Mohamad Zain, A. Embong. Department of Statistics, Institute of Technology Sepuluh Nopember (ITS) Surabaya Keputih, Sukolilo, Surabaya, Indonesia. March 2010. (July 25, 2010) Siebel, John A., MD. Diabetes and Continuous Glucose Monitoring. The Department of Endocrinology at The Cleveland Clinic. Medtronic. January 2010. [Online]. Available: http://diabetes.webmd.com/continuous-glucose-monitoring. (July 23, 2010) S. Smith, G. Bury, M. O'Leary, W. Shannon, et al. The North Dublin randomized controlled trial of structured diabetes shared care. Beaumont Hospital, Dublin, Ireland. 2004. [Online]. Available: http://fampra.oxfordjournals.org/cgi/content/full/21/1/39. (August 07, 2010)

72 S. Smith M.D, S. Nilay PhD, S. Bryant M.S. Mayo Clinic Proceedings. Chronic Care Model and Shared Care in Diabetes: Randomized Trial of an Electronic Decision Support System. [Online]. Available: http://www.mayoclinicproceedings.com/content/83/7/747.full. (July 08, 2010)

73

Appendix A. Resources Person Dr. Gloria P. Valdez Diabetologist Convener/Facilitator Iligan City Diabetes Association, Inc.

Miss Dixie L. Puerin Office Assistant Iligan City Diabetes Association, Inc.

Mrs. Carmen Viajante Member Iligan City Diabetes Association, Inc.

74

Appendix B: Personal Vitae

Name: Ms. Michelle O. Cepada Address: Blk. 10 Lot 34, PCH-II, San Miguel, Manolo Fortich, Bukidnon Birth Date: April 14, 1989 Language Spoken: Cebuano, English, Filipino Major: Management Information Systems Contact No.: +6393516995353/ +639197807222 Email Add: mich.cepada@gmail.com

Name: Ms. Vinaflor Viajante Address: Tambacan, Iligan City Birth Date: July 26, 1990 Language Spoken: Cebuano, English, Filipino Major: Management Information Systems | Business Software Development Contact No.: +639497539671/ +639226352267 Email Add: vnviajante@gmail.com

75

Appendix C: Current Business Flow Diagram of ICDAI

new

Patient

old

Apply for membership Physician Manual retrieval of medical records

Create new patient records

Check patients condition

YES

NO Any Laboratory test needed?

Check medical records

Take specified laboratory test

Examine and interpret laboratory results

Give recommendatio ns

Make individual report

76

Appendix D: Proposed Computer-Based Flow Diagram for ICDAI

new

Patient

old

Physician

Add new patient information

Search Patient name

Add medical records Examine and interpret laboratory results

Update medical records

Add new laboratory test if needed

Give recommendatio ns

Make individual report

77

Appendix E: Evaluation Form

ICDAI Diabetes Management System (DMSS) Evaluation Sheet Evaluators Name: Contact Information: Please encircle the letter of your choice. 1 Strongly Disagree 5 Strongly Agree

A.

Presentation of Content 1. 2. 3. 4. The graphics, media elements, and content are clear and appealing. System is usable without reference manual or user help. User can easily navigate between program screens. Menus and features make the program easy to use. 1 1 1 1 2 2 2 2 3 3 3 3 4 4 4 4 5 5 5 5

B.

User Interaction 5. 6. 7. 8. 9. System performs management tasks satisfactorily. 1 Search methods and results are easy to understand 1 Provides appropriate feed back to user responses. 1 Runs smoothly without delay. 1 System would make job faster and effective. 1 2 3 4 5 2 3 4 5 2 3 4 5 2 3 4 5 2 3 4 5

C.

This system would require which level of computer skill? a. b. c. Basic Intermediate Advance

D.

Your recommendation.

Please encircle the letter of your choice. a. This would be a valuable system purchase. I recommend it to be adopted by the organization it can be use. b. This system needs more improvement. c. This system does not produce any desired results. This should not be adopted.

78

Appendix F: Schema Benchmark CREATE TABLE bench_marks ( bench_mark_id serial NOT NULL, lab_test_id integer NOT NULL, dt_id integer, min_value integer, max_value integer, recommendation character varying(500), date_recommended date, notes character varying(500), CONSTRAINT pk_bench_marks PRIMARY KEY (bench_mark_id, lab_test_id), CONSTRAINT diabetes_type_bench_marks FOREIGN KEY (dt_id) REFERENCES diabetes_type (dt_id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT lab_test_bench_marks FOREIGN KEY (lab_test_id) REFERENCES lab_test (lab_test_id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION)

Diabetes Type CREATE TABLE diabetes_type (dt_id serial NOT NULL, dt_description character varying(200),

79 CONSTRAINT pk_diabetes_type PRIMARY KEY (dt_id))

Family Diseases CREATE TABLE fam_diseases (fam_diseases_id serial NOT NULL, medrec_id integer NOT NULL, patient_id integer NOT NULL, fam_diseases_desc character varying(200), fam_diseases_remarks character varying(500), CONSTRAINT pk_fam_diseases PRIMARY KEY (fam_diseases_id), CONSTRAINT medical_record_fam_diseases FOREIGN KEY (medrec_id, patient_id) REFERENCES medical_record (medrec_id, patient_id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION)

Hospitalizations CREATE TABLE hospitalizations (hosp_id serial NOT NULL, medrec_id integer NOT NULL, patient_id integer NOT NULL, hosp_desc character varying(200), hosp_remarks character varying(500), CONSTRAINT pk_hospitalizations PRIMARY KEY (hosp_id), CONSTRAINT medrec_id_fk FOREIGN KEY (medrec_id) REFERENCES medical_record (medrec_id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION)

80

Laboratory Test CREATE TABLE lab_test (lab_test_id serial NOT NULL, lab_test_desc character varying(200), CONSTRAINT pk_lab_test PRIMARY KEY (lab_test_id))

Medical Record CREATE TABLE medical_record (medrec_id serial NOT NULL, patient_id integer NOT NULL, dt_id integer NOT NULL, date_rec date, CONSTRAINT pk_medical_record PRIMARY KEY (medrec_id, patient_id), CONSTRAINT diabetes_type_medical_record FOREIGN KEY (dt_id) REFERENCES diabetes_type (dt_id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT patient_med_fk FOREIGN KEY (patient_id) REFERENCES patient (patient_id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT uk_med_id UNIQUE (medrec_id)) Patient CREATE TABLE patient (patient_id serial NOT NULL, lastname character varying(200),

81 firstname character varying(200), midname character varying(200), age integer, gender character varying(200), address character varying(200), contact_no integer, image character varying(200), date_mem date, CONSTRAINT patient_id_pk PRIMARY KEY (patient_id))

Patient Laboratory Test CREATE TABLE patient_lab_test (patient_id integer NOT NULL, lab_test_id integer NOT NULL, date_taken date, result integer, CONSTRAINT lab_test_patient_lab_test FOREIGN KEY (lab_test_id) REFERENCES lab_test (lab_test_id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION) Symptoms CREATE TABLE symptoms (symp_id serial NOT NULL, medrec_id integer NOT NULL, patient_id integer NOT NULL, symp_desc character varying(200),

82 symp_desc_remarks character varying(500), CONSTRAINT pk_symptoms PRIMARY KEY (symp_id), CONSTRAINT medical_record_symptoms FOREIGN KEY (medrec_id, patient_id) REFERENCES medical_record (medrec_id, patient_id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION)