ICDAI-DMSS: Iligan City Diabetes Association Inc.Diabetes Monitoring Support System

A Special ProjectPresented to

The Faculty of Department of Information TechnologySchool of Computer Studies

Mindanao State University - Iligan Institute of Technology

In Partial Fulfillment of theRequirements for the Degree of

Bachelor of Science in Information TechnologyMajor in Management Information System

Michelle O. CepadaVinaflor N. Viajante

Prof. Romelyn Inocencio- UngabAdviser

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, user-

hardware procedures or through the internet. Accordingly, monitoring patient’s 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 patient’s 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 patient’s 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 patient’s diabetic condition.

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

reports

iii

Table of Contents

Abstract i

Chapter 1 1

Research Description 1

1.1 Overview of the Current State of Technology......................................................1

1.2 Issues and Problems..............................................................................................3

1.3 Statement of the Problem......................................................................................5

1.4 Research Objectives..............................................................................................5

1.4.1 General Objective...............................................................................................5

1.4.2 Specific Objectives.............................................................................................5

1.5 Scope and Limitation.................................................................................................5

1.6 Significance of the Study...........................................................................................6

1.7 Research Methodology..............................................................................................6

1.7.1 Requirement Analysis.........................................................................................6

1.7.2 System Architecture............................................................................................9

1.7.3 System Design..................................................................................................10

1.7.4 Implementation.................................................................................................12

1.7.5 Testing and Evaluation.....................................................................................13

Chapter 2 14

Review of Related Literature 14

2.1 Review of Related Concepts....................................................................................14

2.1.1 Diabetes Monitoring System............................................................................14

2.1.2 Decision Support System..................................................................................15

2.1.3 Knowledge Based System................................................................................15

2.2 Diabetes System Approaches and Techniques........................................................16

iv

2.2.1 Case Based Reasoning Approach.....................................................................16

2.2.2 Evidence Based Medicine Approach................................................................16

2.2.3 Medical Information Desktop Application.......................................................17

2.3 Diabetes Monitoring and Decision Support Related Systems.................................17

2.3.1 DiabetEASE web-based Monitoring System....................................................17

2.3.2 DiaComp: Computerized Management of Type II Diabetes............................18

2.3.3 DDS: Initial Experience with the Vermont Diabetes Information System.......19

2.3.4 Outpatient Assessment of Karlsburg Diabetes Management System...............19

2.3.5 CGMS: Continuous Glucose Monitoring System............................................20

2.4. Summary of Review of Related Literature.............................................................22

Chapter 3 23

Theoretical Framework 23

3.1 The Diabetes Mellitus..............................................................................................23

3.2 Monitoring Diabetes................................................................................................25

3.3 Decision Support System.........................................................................................26

3.4 Knowledge-based System........................................................................................27

3.5 DMSS: A Medical Management Information.........................................................27

Chapter 4 29

The ICDAI Diabetes Monitoring Support System 29

4.1 System Requirement Analysis and Specifications..................................................29

4.1.1 Introduction.......................................................................................................29

4.1.2 Overall Description...........................................................................................30

4.1.3 System Features................................................................................................31

4.1.4 External Interface Requirements......................................................................31

4.2 Design Models.........................................................................................................32

4.2.1 Context Diagram...............................................................................................32

4.2.2 UML Use Case Model......................................................................................33

v

4.2.3 Activity Diagram..............................................................................................41

4.2.4 Sequence Diagram............................................................................................42

4.2.5 Class Diagram...................................................................................................46

4.2.6 Component Diagram.........................................................................................47

4.2.7 Deployment Diagram........................................................................................48

4.2.8 Database Design Model....................................................................................49

4.3 Structure and Interface.............................................................................................50

4.3.1 Program Structure.............................................................................................50

4.3.2 Graphical User Interface...................................................................................51

4.4 Physical Environment and Resources......................................................................58

4.4.1 Developer..........................................................................................................58

4.4.2 Client.................................................................................................................59

Chapter 5 60

Results and Observations 60

5.1 Information Gathering.............................................................................................60

5.2 Design of the System...............................................................................................60

5.3 System Development...............................................................................................60

5.4 User Testing and Results.........................................................................................61

5.5 Evaluation and Summary.........................................................................................65

5.6 System’s 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

vi

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 Systems……………………………………22

Table 4.1 Developer’s Minimum Software Requirements………………………………59

Table 4.2 Developer’s Minimum Hardware Requirements……………………………...59

Table 4.3 Client’s Minimum Software Requirements…………………………………...60

Table 4.4 Client’s Minimum Hardware Requirements…………………………………..60

Table 5.1 Functionality Table……………………………………………………………62

Table 5.2 Non-functional Rating for the ICDAI-DMSS………………………………...65

viii

List of Figures

Fig. 1.1 ICDAI’s Manual System for Monitoring Patient’s 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 Flow…………………………………………………25

Fig. 3.2 ICDAI-DMSS Theoretical Framework…………………………………………28

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-DMSS………………………………………48

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

x

Chapter 1

Research Description

1.1 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 patient’s 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

xi

measurements are 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

patient’s 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 patient’s 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 patient’s health status by tracing his previous results to

current and updated ones. In this situation, the doctor will be able to forecast the

patient’s health status and help the patient become aware of his health condition by

giving him enough recommendations and prescriptions. (See Figure 1.1)

1

1.2 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 patient’s condition are

-Input-Data-Process

Patient

Medical Practitioner

MANAGE

TESTMANAGE

TEST

LABORATORY TESTS

PATIENT’S LAB TEST RESULT

UPDATE PATIENT’S INFORMATION

UPDATE PATIENT’S INFORMATION

CHECK PATIENT’S CONDITION

CHECK PATIENT’S CONDITION

MANAGE INTERPRETATION OF

RESULTS

MANAGE INTERPRETATION OF

RESULTS

RECOMMENDATIONS AND PRESCRIPTIONS

-ActorLegend:

Fig. 1.1 ICDAI’s Manual System for Monitoring Patient’s Health

Condition

TAKE TESTTAKE TEST

2

time consuming and prone to errors. 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 it’s not well-organize 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 patient’s 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 patient’s 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.

1.3 Statement of the Problem

In ICDAI, recording patient’s information and monitoring their condition are time

consuming and prone to error, information security is fragile, and the diabetic patient’s

participation still subsist in the overall technological assessment.

Consumes too much time when it comes to retrieving

patient’s record.

Lack of availability, integrity and

confidentiality of patient’s information

Less technological assessment

participation of patients

Difficulty in information retrieval

and monitoring patient’s condition

Fig. 1.2 Fishbone Diagram

No assurance of information

security

3

1.4 Research Objectives

1.4.1 General Objective

To develop a desktop application for ICDAI’s diabetes monitoring support system

that will provide assistance to the physician in recording patient’s information and

monitor their diabetic condition.

1.4.2 Specific Objectives

1. To draw a flow diagram in monitoring patient’s 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 patient’s diet and exercise planning;

4. To create reports in order for the physician to assess the patient’s 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

patient’s 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 practitioner’s concerns were voiced out and

5

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

6

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 organization’s 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 Gathering

Interview

Literature review

Data Analysis

Brainstorming

Record evaluation

Testing and Evaluation

Pre-testing

System Alterations

Final testing

System Implementation

Graphical User Interface Design

Database Construction

Fig. 1.3 Flow of the Research Methodology

7

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 system’s 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 system’s control structure. Validated data shall

be stored to the database.

Fig. 1.4 System Architecture for Diabetes Monitoring System

Database Schema

System’s Control

ICDAI Diabetes Monitoring Support System

DATA MODEL

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. It’s 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. Patient’s basic information such as name,

age, address, etc. will be organized through this database. Moreover, the diabetes patent’s

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 patient’s 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 system’s

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 cross-functional 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 system’s 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 system’s 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 ICDAI’s 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.

13

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

14

making, learning and action. Such systems are capable of cooperating with human users

(elsevier.com, 2010).

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 patient’s

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

15

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

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

user-friendly 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).

16

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

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

17

flow sheets, reminders, alerts, and population reports for providers and their diabetes

patients (MacLean, 2006).

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

18

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 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 patient’s 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 patient’s medical records that is tracking patient’s insulin, trends

blood sugar, accurate flow of reports and spreadsheets and alerts for the specialist and

patient’s 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

DiabetEASE DiaCompVermont Diabetes

Information System

Karlsburg DMS

CGMS

Dated records of patient’s 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

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 body’s cells fail to respond appropriately

to insulin. Insulin is a hormone that helps the body’s 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 adult-

onset 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

Patient

Take test from a physician outside ICDAI

Physician inputs laboratory results

Printed summarized records, data sheets and prescriptions handed to patient if requested

Date sheets and graphs viewable through the GUI and printable for physician’s long term

documentation

INPUT

OUTPUT

Patient’s current medical statistics (blood sugar, insulin, blood pressure)

Record retrieval

Case-based Analogy Evidence-basedAnalogy

Data stored

Graphical User Interface

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 patient’s 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 patient’s

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

patient’s health status and condition, to provide significant guidance in support to the

patient’s 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 patient’s 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 patient’s status

concerning their diabetes condition. DMSS assist in measuring health status and patient’s

individual needs. It also validates the practices that lead towards improved quality of

patient care. DMSS also asses the individual’s specific education and behavioral needs.

DMSS provides data for scientific and economic analysis and generally, it identifies

patient’s diabetic needs, outcomes and goals.

26

Fig. 3.2 ICDAI-DMSS Theoretical Framework

Lack of availability,

integrity and

confiden-tiality of patient’s

information

No assurance

of information

security

Diabetic patient’s

participation still

subsist in the overall technologic

al assessment

Consumes time when it comes to retrieving patient’s records

ICDAI- Diabetes Monitoring Support System

Patient’s Information

System

ICDAI- DMSS DatabaseMedical

System

Medical Statistics and

Diabetes Monitoring

System

Medical Updates and Decision

Support System

Medical Aftermath and

Knowledge Based Systems

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 patient’s information and monitoring their diabetic

condition. This project has the following features and capabilities:

Dated records of patient’s blood sugar, blood pressure and other medical

measurements needed in the medication

Evaluate and determine the more detailed reports for possible

interventions on the patient’s 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 patient’s 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, will promote trend analysis through producing easy-to-read

28

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 patient’s 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 patient’s 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 system’s 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.

Patient Table

INPUT OUTPUT

ICDAI-DMSS

ICDAI – Diabetes

Monitoring Support System

Physician

Patient

Physician

Patient Information

Monitor Condition

Medical Record

Lab Test Results

Recommendation

Reports

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 patient’s 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

About ICDAI

Exit

Add Patient

Patient Laboratory

Records

List of Members

Graphical Laboratory

Records

List of Laboratory Tests

Patient Medical Record

Help Contents Contents

About DMSS

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 system’s

menu options:

Log In

The physician uses the log in form to access the system.

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.13 Log-In Form GUI

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.

About ICDAI

Fig. 4.15 Add Laboratory Test GUI

Fig. 4.16 Add Laboratory Test Range GUI

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

View

List of Laboratory Test

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

Fig. 4.19 Update Patient Laboratory Record GUI

54

List of Members

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

ICDAI.

Graphical Laboratory Records

Fig. 4.21 List of Members GUI

Fig. 4.20 List of Laboratory Test GUI

55

This user interface displays the graphical representation of laboratory

records/results of a certain patient.

Patient Medical Record

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

Fig. 4.22 Graphical Laboratory Records GUI

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 Developer’s Minimum Software Requirements

Developer’s Minimum Software Requirements

Operating System Windows XP

IDE Mincrosoft Visual C# 2010

DBMS PostgreSQL 8.3

Plug-ins

Table 4.2 Developer’s Minimum Hardware Requirements

Developer’s Minimum Hardware Requirements

Processor Intel Pentium 4

RAM Size 1Gb DDR

HDD Size 40Gb

Input Devices PS2/USB Mouse and Keyboard

58

Output Devices Monitor

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 Client’s Minimum Software Requirements

Client’s Minimum Software Requirements

Operating System Windows XP

DBMS PostgreSQL 8.3

Table 4.4 Client’s Minimum Hardware Requirements

Client’s Minimum Hardware Requriements

Processor Intel Pentium 4

RAM Size 1Gb DDR

HDD Size 40Gb

Input Devices PS2/USB Mouse and Keyboard (Camera)

Output Devices Monitor and Printer

59

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.

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 system’s 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 TEST RESULTS DESCRIPTION

Add Patient Add Patient details

and initial medical

record

Success Manage Patient Table

Update Patient Laboratory

Records

Input new values for

every laboratory test

taken

Success Manage Laboratory

Test Table

Add Laboratory Test Add Laboratory Test

Info

Success Manage Laboratory

Test Table

Update Laboratory Test Update Laboratory

Test Info

Success Manage Laboratory

Test Table

View Reports View an existing

Report

Success Manage Records

Generate Reports Generate a certain

Report

Success Manage Records

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.

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.

62

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 system’s non- functional requirements, the developers

employ the use of a rating form to evaluate the different aspects of the system’s non-

functional requirements (see Appendix). The non-functional requirements the proponents

considered necessary includes performance, usability, layout and design and system

response.

The developer’s 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 system’s nonfunctional requirements would also help the developers in

determining the users’ perspective and his/her feedback toward the system.

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

system.

63

Table 5.2 Non-functional Rating for the ICDAI-DMSS

Non-functional RequirementsRating

(1-Strongly Disagree, 5-Strongly Agree)

Response Average

1 2 3 4 5

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 understandProvides appropriate feed back to user responses.Runs smoothly without delay.

System would make job faster and effective.Overall Average Response

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 1

Disagree 2

Neutral 3

Agree 4

Strongly Agree 5

4

3

3

4

3

3

3

2

4

3.222

64

With the client’s 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 system’s 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 system’s 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.

65

5.6 System’s Capabilitites and Limitations

System’s 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 patient’s laboratory test results is made.

66

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 patient’s

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 patient’s 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 patient’s individual

medical provision through produced graphs and generated reports.

The manual operation of the association does not practically provide a statistical

perspective in the diabetic medicine. It is just a mere recording of patient’s

67

condition. Through DMSS as a desktop application, patient’s 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 system’s 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.

68

6.2 Recommendation

The system is intended to furnish the client’s 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.

69

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#description. (August 8, 2010)

70

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/S0168-

8227%2899%2900016-9/abstract. (July 25, 2010)

Petra, A., Vogt, L., Klaus, K. Outpatient Assessment of Karlsburg Diabetes Management

System–Based 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.

71

2004. [Online]. Available: http://fampra.oxfordjournals.org/cgi/content/full/21/1/39.

(August 07, 2010)

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)

72

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.

73

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, FilipinoMajor: 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

74

Appendix C: Current Business Flow Diagram of ICDAI

Apply for membership

new Patient old

Physician

Create new patient records

Manual retrieval of medical

records

Check patient’s condition

Check medical records

Any Laboratory test needed?

Take specified laboratory test

Examine and interpret

laboratory results

Give recommendatio

ns

Make individual report

YES NO

75

Appendix D: Proposed Computer-Based Flow Diagram for ICDAI

new Patient old

Physician

Add new patient information

Search Patient name

Add medical records

Update medical records

Examine and interpret

laboratory results

Add new laboratory test if

needed

Give recommendatio

ns

Make individual report

76

Appendix E: Evaluation Form

ICDAI Diabetes Management System (DMSS) Evaluation Sheet

Evaluator’s Name:

Contact Information:

Please encircle the letter of your choice. 1 – Strongly Disagree 5 – Strongly Agree

A. Presentation of Content

1. The graphics, media elements, and content are clear and appealing. 1 2 3 4 5

2. System is usable without reference manual or user help. 1 2 3 4 5

3. User can easily navigate between program screens. 1 2 3 4 5

4. Menus and features make the program easy to use. 1 2 3 4 5

B. User Interaction

5. System performs management tasks satisfactorily. 1 2 3 4 5

6. Search methods and results are easy to understand 1 2 3 4 5

7. Provides appropriate feed back to user responses.1 2 3 4 5

8. Runs smoothly without delay.1 2 3 4 5

9. System would make job faster and effective.1 2 3 4 5

C. This system would require which level of computer skill?

a. Basicb. Intermediatec. 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.

77

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),

78

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)

79

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),

80

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),

81

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)