Thesis - Diabetes Monitoring Support System
-
Upload
mitol-cepada -
Category
Documents
-
view
2.096 -
download
3
description
Transcript of Thesis - Diabetes Monitoring Support System
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: [email protected]
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: [email protected]
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)