DIABETES AID: A SYSTEM FOR THE DIAGNOSIS AND MANAGEMENT OFDIABETES USING A PALM PILOT

By

GARY LLOYD UNDERWOOD

A THESIS PRESENTED TO THE GRADUATE SCHOOLOF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT

OF THE REQUIREMENTS FOR THE DEGREE OFMASTER OF SCIENCE

UNIVERSITY OF FLORIDA

2001

Copyright 2001

by

Gary Lloyd Underwood

This thesis is dedicated to my family who has supported me in all my endeavors.

iv

ACKNOWLEDGMENTS

I would like to express my thanks to Dr. Douglas Dankel for being my teacher,

my advisor, and my friend. His help was instrumental in the completion of this thesis.

I would also like to thank Dr. Joseph Wilson and Dr. Douglas Benn for serving on

my supervisory committee. Also, I would like to thank Dr. Josef Vesely for his medical

contributions both on the interface and the diagnosis parts of this project.

I would like to thank all my friends here at the University of Florida and abroad

who have helped me in so many ways. Finally, I would like to thank my family, who

supported me throughout my life in everything I have done.

v

TABLE OF CONTENTS

page

ACKNOWLEDGMENTS...................................................................................................iv

LIST OF FIGURES............................................................................................................vii

ABSTRACT......................................................................................................................viii

CHAPTERS

1 INTRODUCTION ............................................................................................................1

Problem Area Overview.................................................................................................. 1Diabetes Aid .................................................................................................................... 2Structure of this Thesis.................................................................................................... 3

2 LITERATURE SURVEY.................................................................................................5

Mycin............................................................................................................................... 5Palm Pilot ........................................................................................................................ 7ePocrates, Inc. ................................................................................................................. 8Other Palm Diabetes Systems ....................................................................................... 10Graphical User Interfaces.............................................................................................. 10Summary....................................................................................................................... 13

3 USING DIABETES AID................................................................................................14

New Patient ................................................................................................................... 14Diagnose Figures........................................................................................................... 18

Which Information.................................................................................................... 19Summary................................................................................................................... 19Labs and Vitals .......................................................................................................... 20History, Allergies, Rx (Medications) ........................................................................ 21Dyslipidemia ............................................................................................................. 21Nephropathy.............................................................................................................. 22Wrap Up .................................................................................................................... 23

Summary....................................................................................................................... 24

vi

4 IMPLEMENTATION DETAILS ...................................................................................25

Palm Programming........................................................................................................ 25General...................................................................................................................... 25Forms......................................................................................................................... 26Static Form Elements................................................................................................ 27Dynamic Form Elements........................................................................................... 28Palm’s Database ........................................................................................................ 28

Examples ....................................................................................................................... 30Main .......................................................................................................................... 30Vitals ......................................................................................................................... 31History....................................................................................................................... 33Allergies.................................................................................................................... 37Patient List................................................................................................................. 40Dyslipidemia ............................................................................................................. 41Wrapup...................................................................................................................... 44

Summary....................................................................................................................... 45

5 SUMMARY AND EXTENSIONS.................................................................................46

Summary....................................................................................................................... 46Extensions ..................................................................................................................... 46

Connectivity.............................................................................................................. 47Internal....................................................................................................................... 48Hardware ................................................................................................................... 49

Conclusion..................................................................................................................... 49

LIST OF REFERENCES ...................................................................................................50

BIOGRAPHICAL SKETCH..............................................................................................52

vii

LIST OF FIGURES

Figure Page

1. qRx drug interaction and selection by class.....................................................................8

2. Basic Screen.....................................................................................................................14

3. Navigation Screen............................................................................................................15

4. Patient History Screen......................................................................................................15

5. Allergies Screen...............................................................................................................16

6. Add Allergies Screen.......................................................................................................17

7. Edit Allergy Screen..........................................................................................................17

8. Which Information Screen...............................................................................................19

9. Summary Screen..............................................................................................................20

10. Lab Reports Screen..........................................................................................................20

11. Vitals Screen....................................................................................................................21

12. Dyslipidemia Screen........................................................................................................21

13. Nephropathy Screen.........................................................................................................22

14. Wrap Up Screen...............................................................................................................23

15. Wrap Up Next Screen......................................................................................................23

16. Patient List........................................................................................................................41

viii

Abstract of Thesis Presented to the Graduate Schoolof the University of Florida in Partial Fulfillment of the

Requirements for the Degree of Master of Science

DIABETES AID: A SYSTEM FOR THE DIAGNOSIS AND MANAGEMENT OFDIABETES USING A PALM PILOT

By

Gary Lloyd Underwood

December 2001

Chairman: Douglas D. Dankel IIMajor Department: Computer and Information Science and Engineering

Advances in medical research have led to the collection of significant quantities

of patient and medical data presenting doctors with a complex data management problem.

Doctors need a simple and effective interface to quickly and easily review and diagnose

their patients. A system that could remind them of certain guidelines in patient care

would also prove helpful.

This thesis examines Diabetes Aid, a Palm Pilot hand-held device to record data

on patients with diabetes.

This Palm Pilot-based program is responsible for tracking a patient’s data and

assisting the doctor with his/her diagnosis of the patient. It provides the doctor with the

relevant information needed when talking with a patient and allows the doctor to make

notes, changes, and recommendations. Diabetes Aid makes recommendations based on

its knowledge base, which models the American Diabetes Association’s (ADA)

guidelines. Ideally, this system would connect to a global database of patient records so

ix

updates to a patient’s records would be available to all doctors who are managing this

patient.

1

CHAPTER 1INTRODUCTION

Problem Area Overview

The increase in patient data in recent years has created an immense amount of

paper work that must be managed. Typically, a patient’s folder contains the patient’s lab

reports, past history, current medications, past diagnoses, etc. Much of this data exists

only in paper form requiring a significant amount of money, space, and time maintaining

the patient’s folder. A considerable amount of work also is involved in obtaining data

from other doctors, pharmacies, laboratories, etc. One goal of this thesis is to provide a

method by which the doctor can easily track all of a patient’s data electronically. While

the potential cost savings are enormous, the real benefit is a potential increase in the

quality of care provided for the patient.

This thesis describes the creation of Diabetes Aid, an expert system for

diagnosing diabetes. An expert system, which may also be called a decision support

system, is a program whose goal is to provide expert knowledge and advice. The system

is provided with knowledge gleaned from an expert. This knowledge includes facts about

the application domain as well as rules of inference for making deductions based on a

specific case’s data. These rules are often in the form of IF-THEN rules. For example:

IF (statement 1 AND statement 2) THEN statement 3

identifies that if the first two statements are true, then the third is as well. Sometimes this

knowledge is represented as a decision tree where each branch in the tree represents some

2

question. The answers to the questions determine which branch of the tree is to be taken.

The final answer results from following the path described by the case’s data.

Diabetes Aid

This thesis involves the development of Diabetes Aid, an expert system to assist

doctors in treating and managing diabetes patients. Diabetes Aid consists of two main

modules: “New Patient” and “Diagnose.” The first module obtains new patient screening

information from the patient. Doctors use the latter module in diagnosing and treating

patients.

Diabetes Aid is to replace the paper folders commonly used by doctors. It allows

doctors quickly and easily to see information needed in the diagnosis of a patient. Its

small size and weight make it ideal for a doctor as he/she moves from patient to patient.

No additional materials are needed drastically reducing the administrative cost of patient

care. This also makes it easier for doctors as they need only to carry one item with them

throughout the day after downloading patient records for the patients they are to see that

day.

To aid ease of use, data entry has been streamlined as much as possible. Textual

data entry has been avoided due to its difficulty on a Palm Pilot. Instead, checkboxes,

buttons, and selection lists have been used wherever possible. This allows those without

Palm Pilot experience to be able to easily use Diabetes Aid without extensive training.

Doctors should not have difficulty migrating from paper-based forms to this system. In

addition, many medical teaching institutions have begun issuing medical interns with

Palm Pilots or other hand-held devices resulting in greater acceptance of such devices in

medicine.

3

In addition to data presentation, Diabetes Aid can also make suggestions of

possible treatments to the doctor. This includes suggesting medicines, brands, and dates

for the next visit. It also tracks the ages of various laboratory tests and uses a visible

marker to indicate to doctors when a test needs to be performed again. At the end of a

visit, the system presents a list of all tests that are outdated or will be before the next visit.

This way, the doctor has a concise list of tests that the patient must perform before the

next visit. As it is very common for patients, or doctors, to forget tests this can greatly

improve patient care and costs by reducing repeat visits due to missing test results.

Diabetes Aid provides reminders to the doctor for such areas as retinopathy and

foot care, both of which are often forgotten by doctors who do not deal regularly with

diabetic patients. This can result in better care for a patient with no additional cost. Also,

this results in more consistent care.

CodeWarrior 6 for the Palm Pilot and the C language was chosen for the

development of the code for Diabetes Aid. This combination provided the best

environment and ease of learning for the project. Diabetes Aid is intended to run on any

device compatible with Palm Operating System (Palm OS 2001) version 2.0 or later.

Expert medical information was assimilated from Dr. Josef Vesely and the

American Diabetes Association’s guidelines for the treatment of diabetes. By using the

American Diabetes Association’s guidelines, a doctor can feel confident that the medical

advice given by Diabetes Aid is sound.

Structure of this Thesis

The following is a brief description of the remainder of this thesis. Chapter 2

provides a summary of the field of medical decision support systems. This includes a

4

literature survey of present and recent publications regarding medical decision support

systems, Palm Pilots, and graphical user interfaces. In Chapter 3, the operation of

Diabetes Aid is discussed. This chapter is a user’s manual on the use of the Diabetes Aid

system. Chapter 4 provides implementation details on the system. It describes some of

the underlying algorithms and the use of medical knowledge in the program as well as

details regarding the coding of Palm Pilot applications. Finally, Chapter 5 provides a

summary of the thesis, some possible extensions, and improvements that can be made to

Diabetes Aid.

5

CHAPTER 2LITERATURE SURVEY

This chapter provides background related to this thesis including medical

informatics, Palm Pilots, and graphical user interfaces. Mycin is given as an example of

a previous medical decision support system and two of ePocrates products are discussed

as examples of currently available medical support programs for a Palm Pilot.

Mycin

One of the first and most influential expert systems in the field of medicine was

Mycin (Cawsey 1994). Edward Shortliffe developed this system at Stanford University

in the 1970’s. The domain of Mycin was the prescribing of antibiotics for the treatment

of various blood disorders, and it was designed for use by a clinician in the diagnosis of a

patient. A full diagnosis of the patient involved growing cultures, which could take days.

Since some of the disorders could result in death in less time than that, it is necessary for

the doctor to make educated guesses about the patient’s infection and its treatment.

Mycin was developed to aid this process by determining a treatment for a patient who has

incomplete medical data, which is a common problem in the medical field. One of

Mycin’s goals was to study how doctors derived their decisions with incomplete data.

Mycin’s intelligence was contained in a collection of rules of an IF (…) THEN

(…) style. For example:

IF the infection is primary-bacteremiaAND the site of the culture is one of the sterile sites

6

AND the suspected portal of entry is the gastrointestinal tractTHEN there is suggestive evidence (0.7) that infection is bacteroid (Cawsey 1994)

This rule has three conditions: the infection is primary-bacteremia, the site of the

culture is one of the sterile sites, and the suspected portal of entry is the gastrointestinal

tract. If all three are found then there is suggestive evidence (0.7) that the infection is

bacteroid. The conclusions of each rule contained a confidence factor representing the

certainty of the conclusion. In this example the confidence factor is 0.7 identifying that if

the three clauses are met with perfect certainty (1.0) then there is a 0.7 certainty

associated with the conclusion. If the clauses forming the IF of a rule have associated

certainty factors, these factors would adjust the conclusion’s certainty factor. Certainty

factors ranged from -1, representing total denial of a fact, to 1, representing a definite

fact.

Mycin worked on the principle of backward reasoning in a depth first manner. It

started with a hypothesis and collected all rules containing that hypothesis in their

conclusions (the THEN parts). It attempted to prove that the hypothesis was true by

determining whether the IF parts of these rules were true using other rules to derive a

value or data gathered from the physician. In the case where one of the antecedents in the

IF clause was false or had a certainty factor less than 0.2, the rule would be pruned and

Mycin would continue its search examining the rest of the rules. Mycin would query the

physician as needed throughout the process to gather data for use in the proving or

disproving of a clause. This avoided unnecessary questioning of the doctor.

One of the keys to Mycin was its ability to answer questions posed by the doctor.

If Mycin asked a doctor a question, the doctor could ask the system why it needed that

data. The system would then display an explanation of its chain of reasoning and what

7

rule it was trying to prove. This idea was taken a step further in NEOMYCIN (Clancey,

W. J. and R. Letsinger 1984), where the system was used to train future doctors and to

explain their errors.

Physicians never actively used Mycin other than a test to shot the efficacy of its

knowledge. Its importance is mainly derived from its contributions to the field, which

included the development of certainty factors and the separation of the knowledge base

and the inference engine. Many other systems have also been derived from Mycin

(Clancey, W. J. and R. Letsinger 1984).

Palm Pilot

The Palm Pilot (often referred to simply as a Palm) is a specific brand of Personal

Data Assistant, or PDA. It is an extremely miniature version of a computer with limited

functionality. The original Palm Pilot, the Pilot 1000, was introduced in May of 1996. It

gained popularity for its usability (PC Computing’s Most Valuable Player award of

“Usability Achievement of the Year” Award for the Pilot 1000). As an indication of its

acceptance in the field, by March of 1997 there were over 2000 developers working on

hardware and software products for use with the Pilot series and by January 2001, there

were 140,000 developers. Through the years PDAs have gained more support and have

improved the hardware’s speed and screen quality. They have also increased the

functionality with support for color, wireless Internet access, and 3rd party peripheral

support. The Palm Pilot line of PDAs is by far the dominant leader in the market with a

75 percent share in June 2000 (International Data Corp., June 2000) in 35 countries

(3Com Historical 2001). In addition to the hardware dominance, many other companies

are making products based on the operating system of the Palm Pilot line, Palm OS. A

8

large part of their success is due to ease of use and the consistency of the applications that

run on them.

The Palm Pilot architecture was chosen for this thesis for several reasons. First,

the Palm Pilot series of handheld devices is widely accepted and established. This

increases the system’s lifetime. Next, these machines have the capabilities needed for

this research. Since the Palm Pilot is the current standard in hand-helds, there are many

vendors developing additional hardware and software for the Palm Pilots that may be of

use in the future, including voice capture. Specifically, the program is designed to run

under the Palm OS system software. It is not directly tied to the Palm Pilot hardware.

ePocrates, Inc.

ePocrates, Inc. makes two products for use on Palm compatible hand-helds, both

specifically targeting doctors. qRx is a clinical drug database. It contains listings for

approximately 1,600 different drugs and gives information regarding their side effects,

drug interactions (Figure 1), dosage, cost, and other implications of prescribing a given

drug. Drugs can be selected from lists that are organized alphabetically, by class (Figure

2), or by a number of other characteristics.

Figure 1: qRx drug interaction and selection by class

9

Doctors use it as a reference when a patient is taking a drug with which they are

unfamiliar. ePocrates designed the program with a narrow focus of providing only drug

information and doing so in the simplest and most easy to use format they could design

(Gottlieb 2000). The system is free for download, with more advanced services available

for a fee. The zero cost has helped this product reach over 94,000 physicians as of

January 2001 (Freudenheim 2001). Given that many new doctors are using hand-held

devices in school, this number should increase (Freudenheim 2001).

qRx helps doctors to avoid an average of one adverse drug reaction per week

according to study at Harvard Medical School (Leff 2001). According to the Medical

Informatics Association in November 2000, qRx could assist doctors avoid over two

million adverse drug reactions per year. The system has also been shown to save time

and improve the doctor-patient relationship (Green 2001). Since the FDA has approved

drugs at a faster rate in recent years, there are many new drugs being introduced to the

market. The increase in the number of drugs is making it difficult for doctors to keep up

with all the changes and qRx provides them a tool with an up-to-date and current listing

of all available drugs.

ePocrates’ other product is qID which is designed to identify infectious diseases.

It allows physicians to search by disease type, drug, or location (of the infection). It is

also integrated with qRx to allow a doctor to quickly retrieve specific information

regarding recommended drugs (ePocrates 2001).

The Institute of Medicine has recommended that the healthcare industry reduce

the amount of paperwork involved in patient care to reduce medical errors. Part of that

solution is to have point of care tools for physicians to use. This includes drug reference

10

tools like qRx as well as diagnosis programs like qID. Having the information in an

easily used and readily available form when the doctor is seeing the patient is critical

(Shalo 2001).

Other Palm Diabetes Systems

There are currently very few diabetes related systems available for the Palm Pilot

platform. One system available is GlucoPilot. This system is for a patient to use to track

their blood sugar levels. It is not a diagnostic tool and offers no drug related information

(Healthetech 2001). There are several programs, such as Cook'n™ for Diabetics (DVO

2001), available that deal with dieting, cooking and other lifestyle related issues. They

are not for use by doctors and they do not provide medical advice. Medical reference

material is also available on the Palm. For example, Mark Goodarzi has put together a

series of documents to be downloaded to a Palm (Goodarzi 2001). However, these are

simply reference material. This is not a program that will track patient data or make

suggestions for treatment based on specific data for a patient.

Graphical User Interfaces

A graphical user interface (GUI) is a method of using a computer system through

the use of graphics, specifically icons, rather than text. In a graphical environment, a user

selects icons (i.e., small pictures) using a pointing device (e.g., mouse or stylus) as

opposed to typing commands. These icons represent the task the user would like the

machine to perform. For instance, selecting an icon that looks like a small printer may

print the current document. Graphical interfaces have been an integral part of desktop

systems for a number of years.

11

User interface design has been studied for a number of years. However, due to

the Palm’s unique features, some of the practical techniques do not conform well to the

Palm platform. For example, the Palm interface is not a windowed environment with

several programs open simultaneously in their own windows. Though popup forms that

appear on top of the main screen are available, they are not commonly used. This is

partially due to user interface confusion (Rhodes, Neil and Julie McKeehan 1999) and

partially due to the technical implementation details for popup forms that cause them to

ignore certain system alarms. Another example is color, development was done on a

gray-scale Palm, and therefore using color was not possible. There are also design

elements, such as “folder tabs” that are not available on the Palm.

There are many general, or more theoretical, techniques of interface design that

do still apply. For example, using flow charts to visualize the interface design (Ambler

2001). This allows the designer to more easily recognize potential problems in the

interface such as not being able to reach a particular screen from a related screen.

Another common idea in interface design is that the system should behave how the

intended user thinks it should (Spolsky 2001). An important note about this statement is

that it is the intended user, not the programmer, which determines what should happen.

Often, interface design is done according to what those doing the design would want,

regardless of the true users’ desires.

The screen size on a Palm is significantly smaller than on a desktop or even a

notebook machine requiring that information be packaged into logically related, smaller

sections (Rhodes, Neil and Julie McKeehan 1999). This is actually the most critical

difference in designing an application for the Palm versus one for a desktop machine—

12

“the screen size drives the design—not the other way around” (Rhodes, Neil and Julie

McKeehan 1999).

Palm Pilots do not come with a keyboard. Therefore, data entry is much more

convenient through selection elements, like checkboxes and lists, than from free response

text fields that require character input. Interfaces that rely on character input will not be

easy to use and will most likely result in the application not being successful.

Memory and processing power is very limited on a Palm relative to a desktop

machine. Though this is not directly an interface concern, users expect fast responses

from their applications. This is especially critical on a Palm since a Palm application is

likely to be used 15-40 times per day for short periods each time (Rhodes, Neil and Julie

McKeehan 1999). Applications must load and react quickly or the user will become

frustrated. It also affects the scope of an application making a fast, simple program better

than a slow, feature-rich one (Rhodes, Neil and Julie McKeehan 1999). Note that what

the users want is responsiveness, not necessarily speed. If the program appears to work

quickly then the user is satisfied, even if it is actually taking a longer period of time. For

example, it is better to draw screen elements as they become available, then to wait until

every element is ready to be drawn (Johnson 2000).

A user interface should be designed such that the most frequently used functions

are available with the fewest pen taps. This allows users to retrieve the information they

need most often in the shortest amount of time (3Com Palm 1999). As a result, a

streamlined interface design is critical. Commonly used features need to be easy to use

and understand, even if the underlying process is complex (Johnson 2000).

13

It is important that a program fulfill the users’ relevant needs, no more and no

less. If the program has too many features then the complexity level will increase the

users having difficulty learning the software. However, if the program cannot fulfill the

users’ requirements then the product is not going to be used (Johnson 2000).

Even in a graphical user interface, there may still be a large amount of text on the screen.

It is important that the language used on these screens conforms to the users’ vocabulary.

Using the specialized language of the application domain is good, while using specialized

language from other fields (e.g., computers) will confuse most users. Consistency is also

an important factor in the use of text. Terms must refer to the same concepts each time

they are used. The language used to describe a particular form element on one screen

should be consistent with how another screen describes a similar form element (Johnson

2000).

Summary

This chapter provided a literature survey of background information relating to

medical informatics, Palm Pilots, and graphical user interfaces. It discussed Mycin as an

example of a decision support system in the field of medicine. Two of ePocrates’

products were used as examples of medical programs currently available on Palm Pilots.

The next chapter discusses how to use Diabetes Aid.

14

CHAPTER 3USING DIABETES AID

Diabetes Aid, involving the treatment and tracking of diabetes, contains two

modules. A new patient uses the first, called “New Patient, ” on their first visit to the

doctor. The doctor uses the other module, “Diagnose,” during each patient visit.

New Patient

The New Patient module is used for gathering screening information regarding

diabetes rather than tracking demographic data. Because the Palm’s data entry for new

users favors selection style questions rather than text entry, a patient on their first visit to

a diabetes specialist is handed a Palm that has this module already opened with the

patient’s name and ID number prerecorded in its database. The patient answers the

questions and returns the Palm so the information can be uploaded from the Palm to the

doctor’s main database. The patient’s data is then removed from the Palm so it to be used

by another patient. This prevents someone from having unauthorized access to a

patient’s data since the Palm contains only the current patient’s data.

The first screen (Figure 2) displays the patient’s name and ID number.

Figure 2: Basic Screen

15

Though it is editable, the primary reason for displaying this information is for

patient confidence and identification. The Exit1 button leaves Diabetes Aid while Next

proceeds to the main navigation screen. The implementation details of this and

subsequent screens (or pages) are discussed in Chapter 4.

The next screen is the Navigation screen (Figure 3) containing buttons to navigate

to each of the other eight screens comprising this module.

Figure 3: Navigation Screen

It also includes instructions to the patient on how to use Diabetes Aid. Lastly, it

asks the patient to select their gender. This introduces the patient to using checkboxes

through a simple case.

By tapping the Page 1 button the patient moves to the next screen (Figure 4).

Figure 4: Patient History Screen

1 Boldface indicates the name of a button.

16

This screen requests basic patient history, including the date of first diagnosis of

diabetes, how often and when the patient checks their blood sugar, and if they have

problems with low blood sugars. To avoid requiring the patient to write out information,

all input is made by either button choices or lists improving the usability and processing

speed. This screen and subsequent ones have three navigation buttons along the bottom

of the form — Prev takes the patient to the previous page, Beginning takes them back to

the initial screen, and Next takes them to the next page. In addition, each screen’s title

bar has the patient’s name and current page number (e.g., John Smith Page 1). By

tapping Next, the patient progresses to Page 2.

Page 2’s form (Figure 5) collects information on the patient’s allergies.

Figure 5: Allergies Screen

This information can affect the prescribed medicines. To add an allergy to the list

the patent taps the Add button. This displays the Add Allergy sub-screen (Figure 6).

From here, the patient either selects an allergy from the list of common allergies or

“other” if their allergy is not listed. In this latter case, the doctor or other staff member

will enter in the allergy name for the patient using the Edit button.

17

Figure 6: Add Allergies Screen

This method avoids the patient entering text, unless the patient is comfortable with

Palm’s Graffiti (Palm’s handwriting recognition) system. The patient then selects a

severity level from the list and taps the Add this allergy button.

The patient continues to enter additional allergies, tapping the Done button when

all allergies have been entered. This returns the patient to the allergy list where the

patient can edit already entered allergies by selecting the allergy. Tapping the Edit

button displays the Edit Allergy sub form (Figure 7), which allows the user to edit the

allergy or severity level.

Figure 7: Edit Allergy Screen

The user can also remove an entry from the list from tapping the Delete button on

this screen. The OK button saves the changes made by the user while Cancel discards

the changes, retaining the original data. This is the standard wording on most modern

18

computer systems, so most patients will understand what is happening. Tapping any of

these three buttons returns the patient to the allergy list.

Page 3 is the medicine list, which functions identical to the allergy list except that

a dosage must be entered instead of severity level. Page 4 asks questions concerning the

patient’s eye history related to diabetes.

Pages 5-8 contain the rest of the basic screening questions for new patients.

These consist of either answering Yes/No questions using checkboxes (where the patient

either checks the “Yes” box or the “No” box) or selecting an answer from a popup list.

Page 8’s question regarding erection problems is only asked if the patient is male. Each

of the screens has the Prev, Beginning, and Next (except for the last page) buttons for

navigation.

Diagnose Figures

The doctor and nurses use the Diagnose module. It should not be seen by the

patient, since it has no security features to prevent unauthorized access. It is assumed to

be as secure as the folder of patient information a doctor carries. The starting screen for

this module presents a list of patients who are currently stored on the Palm. Since the

storage space required for each patient record is very small (around 1 kilobyte) relative to

the amount of storage available on a Palm (8 megabyte on current models), the Palm

should easily be able to store every patient the doctor sees in a single day. The doctor

chooses a patient by selecting that patient from the list, which results in the display of the

main navigation screen, “Which Information” (Figure 8).

19

Which Information

The Which Information screen (Figure 8) provides access to nearly all other

screens of the diagnose module.

Figure 8: Which Information Screen

It has navigation buttons for the doctor to review various parts of the patient

record and perform the diagnosis of the patient. The buttons are: Summary, History,

Vitals, Labs , Screening Questions, Rx, Allergies, Dyslipidemia, Neuropathy,

Retinopathy, Foot Care , and Wrap Up. Each of these buttons leads to a different

screen and each of these screens returns to this main form.

Summary

The Summary screen (Figure 9) contains most of the information that doctors are

required to check according to the American Diabetes Association guidelines (American

Diabetes Association 1999). This screen serves as a checklist for the doctor to use. This

is especially useful to doctors who may not deal with diabetes patients regularly by listing

things that they must check.

20

Figure 9: Summary Screen

This includes blood proteins, 24-hour urine count, LDL, HDL, triglycerides, total

cholesterol, CPK, AST, ALT, and Hemoglobin A1C. In addition to the results of these

tests, it displays the date of the most recent test and the last dates that the patient saw a

specialist regarding eye and foot care. The screen also places an “*” adjacent to dates

determined to be too old or will be too old by the time of the next appointment (using

ADA guidelines). This can save the doctor (and patient) significant time and expense

since it is common for patients to not have the necessary tests completed in time

requiring additional visits.

Labs and Vitals

The Labs and Vitals (Figures 10 and 11) screens show the most recent results of

various tests.

Figure 10: Lab Reports Screen

21

Figure 11: Vitals Screen

Vitals include tests performed at the time of the visit such as blood pressure,

temperature, and weight, which would be entered by a nurse or other assistant. The

laboratory reports include cholesterol values, protein levels, and other numbers resulting

from a laboratory test. The form also lists the most recent date of these tests.

History, Allergies, Rx (Medications)

The “History” page is identical to the New Patient’s Page 1 (Figure 15). It is

included for reference by the doctor since its data could change over time. The allergy

and the Rx (medications) lists are also identical to those in the New Patient module.

Dyslipidemia

The Dyslipidemia screen (Figure 12) lists the triglycerides: LDL, and HDL

numbers.

Figure 12: Dyslipidemia Screen

22

It computes a risk factor based on the HDL and a recommended medicine and

dosage based on these numbers and other information. The medicine can be changed

using the popup list. When a medicine is chosen, a popup list of brands is available, a

button marked Side Effects appears, and a popup list of dosages is available. Side

Effects leads to a screen with a list of side effects for the chosen medicine. If two

medicines are recommended or the doctor prescribes a second medicine, then appropriate

popup lists for the dosages and brands of the second medicine appears and the Side

Effects button leads to two screens, one for each medicine’s side effects.

Nephropathy

The Nephropathy screen (Figure 13) displays the last urine test type, its date, and

whether protein was found in the urine.

Figure 13: Nephropathy Screen

It has medicine, dosage, and brands popup lists as well as a Side Effects button

similar to the Dyslipidemia screen. The screen contains an Exit button to return to the

Which Information screen. It also has a text field that lists any recommendations. The

Albumin Results button leads to a sub form concerned with albuminuria, a part of

nephropathy. This screen has a text field that lists recommendations. Tapping the Exit

button returns to the main Nephropathy screen.

23

Wrap Up

After all information as been recorded and the treatment has been determined, the

doctor goes to the “Wrap Up” screen (Figure 14).

Figure 14: Wrap Up Screen

This screen reminds the doctor to impress upon the patient the importance of

aggressive blood glucose control through diet and exercise. The screen contains an entry

for the next visit as well as a button (Suggest Next Visit) allowing Diabetes Aid to

recommend for the time of the next visit (Wrap Up Next figure). The Wrap Up Next

screen (Figure 15), giving the suggested time for the next appointment, has an optional

button (Use this Suggestion) to set the values on the Wrap Up screen to the

recommended values.

Figure 15: Wrap Up Next Screen

24

This method allows the physician to obtain advice only if they need or want it

without forcing them to follow instructions from a machine. The form also lists any

laboratory tests that need to be performed by the patient before the next visit.

Summary

This chapter provided information on how to use Diabetes Aid. Several screens

were presented to demonstrate the interface of the system. The next chapter goes into the

implementation details of the system. It also discusses some general concepts related to

programming Palm Pilots.

25

CHAPTER 4IMPLEMENTATION DETAILS

This chapter discusses details on how Palm systems work in general and in

particular how the New Patient and Diagnose modules function. Topics include Palm

programming, forms, static form elements, dynamic form elements, and the Palm’s

database. The chapter concludes with a section describing the implementation of some of

the screens in New Patient and Diagnose.

Palm Programming

General

A Palm program consists of two parts: resource and source code. Resource code

consists of the user interface elements: the forms, buttons, labels, lists, and other

graphical items appearing on the screen. Forms are often called screens because most

forms occupy the entire space of the screen when they are active. The source is the code

typically written in C or C++ that gives functionality to the resource elements. For this

thesis, Metrowerks’ Constructor for Palm OS was used to create the resources and

CodeWarrior IDE for Palm OS Revision 6 was used for the source coding. The

programming language used in the coding was C.

The Palm Operating System (Palm OS) is an event driven system, meaning that it

waits for something, like a key press or a pen tap, to happen and then responds to this

event. For this reason, the basic starting structure of a Palm program is an event loop.

This loop receives an event from the system (using GetEvent), sends it to an appropriate

26

subsystem for processing, and then waits for the next event. The loop exits when a

“stopEvent” is received. Many low-level events such as the pen hitting the screen are

automatically combined and converted to high-level events such as a specific button

being tapped by the pen. Common high-level events in Palm OS include a form opening,

a button being pressed, a form closing, an item in a list being selected, a menu popping

up, and a trigger being activated.

A typical framework used in a Palm program is to have a different function

handle the relevant events for each form. Another function in the main loop is

responsible for setting which function handles incoming events for a specific form or

menu.

Forms

Forms are the basic building blocks of Palm resources. All other elements are

placed on forms, and changing forms performs navigation. The Palm OS handles the

drawing of the forms and the elements within them. It also assumes responsibility for the

intrinsic properties of various elements. For example, if a checkbox is tapped then the

Palm OS handles the toggling of the graphical checkmark.

The Palm OS handles many of the low-level events and converts them to more

useful, high-level events. For example, if the user taps a button on the screen with the

pen several events are sent to the system. A pen down event occurs when the pen touches

the screen and a pen up event occurs when the pen is lifted. Other events can occur

depending on how long the pen is down and whether it moved on the screen before

lifting. The Palm OS converts these events into a single ctlSelectEvent indicating that a

control, in this case a button, was selected. This allows the programmer to ignore low-

level events if their system does not need to process them.

27

When a form is drawn, all the “usable” elements are drawn on the screen and

become active as appropriate. Non-usable elements are drawn only upon activation from

within the source code. This is discussed further in the section on Dynamic Form

Elements.

Static Form Elements

Nearly all Palm elements can be both static and dynamic, with the default being

static. This section discusses the elements commonly used in a static context. In this

section, static refers to elements always on the form whose labels or values do not

change. This definition is not meant to be fully unambiguous. There are many elements

available for use on Palm forms. Labels are simply text boxes placed on a form, which

do not react to the pen in any way.

Buttons are elements that have a label and are capable of sending events to the

system if the pen enters, leaves, or taps them. Tapping a button is the equivalent of

clicking a button in Windows or Macintosh environments. Situations involving a button

tapped many times or the pen held on the button require the use of Repeating Buttons.

These cause the system to send continuous events, instead of a single one, and are often

used to increment or decrement counters.

Menus are similar to those available on desktop applications. However, an

individual unfamiliar with a Palm may have difficulty finding the menus. For this reason,

menus are used primarily when required to be consistent with the standard Palm interface

(3Com Companion 1999).

Static elements are typically always displayed, but their label or value changes in

a predefined way. For example, a checkbox has a label to the side and a box that is either

“on” (meaning it is checked) or “off.” A list consists of a number of lines containing

28

text. The text can either be static or dynamic. A specific line can be selected using the

pen, which sends an event to the Palm OS. A field is an area where information can be

entered or displayed by the system. Fields are editable and send events to the Palm OS

when they change. Push Buttons can be on or off and contain their label. This label is

often used dynamically as a number. Form Bitmaps are pictures to be displayed on the

Palm screen.

Dynamic Form Elements

Dynamic elements are not always displayed, change value, are not always preset,

and often affect other elements (e.g., cause sub-forms to appear). A Popup Trigger is a

button that creates (i.e., “pops up”) a specific list. When an item in that list is selected, its

text becomes the label of the popup trigger. These are some times referred to as drop

down lists since they have an arrow pointing down as part of their label. Selector

Triggers look more like a field with text inside them; however, when tapped, they react

based on their defined code. Typically, they are used to create a special purpose form

like selecting a date from a calendar. Tables are similar to multicolumn lists but have

more capabilities. Nearly all parts of a table, including how it is drawn and what type of

data can reside in each cell, are determined by code. Scrollbars are use to scroll other

elements such as fields, lists, and tables. Lastly, gadgets are completely dynamic, being

able to do nearly anything and have little default functionality. They may be pictures or

text and react to the pen or their associated code.

Palm’s Database

Palm Pilots do not have a hard drive or other disk drives. This means that a

typical storage system based on files is not appropriate. In fact, early versions of the

Palm Pilot had no files at all. In most computer systems, data are read from a file into

29

memory, manipulated in memory, and then saved back to a file on a disk. Palm Pilots

use a database instead of a disk drive. Data are stored in records in this database rather

than in files. Since all memory on the Palm is the same speed (rather than having a

slower secondary storage device such as a hard drive on a computer) there is no need to

copy data from the database into memory to manipulate it.

Each application stores its data in its own unique database. Databases are

identified by author and application names that are registered with Palm.com to prevent

duplication. The format of a record is completely determined by the author. The

database is a very simple flat file database consisting of records viewed as arrays of

characters (bytes).

A common practice in Palm programming is to have a series of #define lines in

the source code that identify positions in the database. For example:

#define DB_ID_START 0

identifies that something the programmer refers to as “ID” starts at byte position

0. A chain of these definitions defines the start of each item as the sum of the start

position and size of the previous item. For example:

#define DB_ID_START 0

#define DB_ID_SIZE 15

#define DB_FNAME_START (DB_ID_START + DB_ID_SIZE)

defines two positions, ID which is at position 0 and FNAME which is at position

15 (0 + 15). Also, note that multiple applications can share the same database. From the

coding perspective, all that needs to be shared is this collection of #define lines allowing

both applications to use the same location for the same data.

30

To use a record, a database is first opened, and a specific record in the database is

queried, using an index to the database. That record is locked to prevent the operating

system from moving it or another application changing it. The record is then read and

unlocked. When the system finishes with the record it is locked, changed, unlocked, and

released.

Examples

Main

The main event loop for the Diagnose module (New Patient’s is similar) is

contained in the function PilotMain.1 First, this function determines if the application is

running on Palm OS 2.0 or higher, since many of the system calls made by the program

do not work on older versions. It then determines the launch mode of the application.

For a normal launch, the program does not need to do anything special. If it is “find”

mode, which is used by the Palm OS to search through all applications and their

databases, then Diabetes Aid performs a search of the patient database. For “go to”

mode, utilized when a user selects an item from the find list, Diabetes Aid goes directly

to the specified record. This mode is only used when the application needs to open the

record of a specific patient selected from the output list of the “Find” command. The

“Find” function of a Palm searches all databases currently on the machine for a given

search string. Conventions in Palm programming dictate that the system should have the

ability to go to that record directly, bypassing the usual start up and patient selection

screen.

1 Names in italics are the names of functions.

31

After determining the mode, Diabetes Aid opens the database and creates some of

the initial, global values. The function then calls the Palm OS function FrmGotoForm to

start the initial form of the system, which is, typically, the form containing the list of

patients. Finally, the main event loop is started which receives and passes events for

processing. This loop ends when an appStopEvent occurs, causing the function to close

all open forms and the database.

The only event type handled directly by the main event loop is frmLoadEvent,

which occur when a new form is to be loaded. For this event, PilotMain determines

which function will handle events for that form. Each form has its own ...EventHandler

function. For example, the “Allergy” form’s event handler is allergiesHandleEvent.

When an event occurs, PilotMain first gives the operating system (Palm OS) the

chance to handle it. If SysHandleEvent does not handle this event, then it is sent to the

menu handler. Similarly, if MenuHandleEvent does not handle the event, then it is sent

to the individual ...EventHandler function.

Vitals

A few representative screens are discussed in detail here to show how all of the

different types of elements are used. The “Vitals” screen (Figure 18) is a relatively

simple form. This screen is for the recording of information by a nurse, when the patient

arrives. As with all forms, this form has its own event handler function,

vitalsHandleEvent, consisting primarily of a switch statement, which divides its cases

based on what type of event it receives. The four event types handled by the form are

frmOpenEvent, frmCloseEvent, ctlSelectEvent, and menuEvent. A frmOpenEvent

occurs when the form is initialized and ready to be drawn. Two events must happen

when a form is opened: first, it needs to be drawn on the screen (FrmDrawForm) and it

32

needs to read data from the database. The reading of the database is done by

setFieldsVitals.

setFieldsVitals reads the database values by first locking the database record. It

then calls setText for each field in the form, which takes the character string from the

database record and copies it to the field. Finally, setText draws the field. After all the

fields have been drawn, setFieldsVitals releases the database record. Each form that

requires data from the database has a similar setFields function. This convention is used

in both the Diabetes and New Patient modules.

For a frmCloseEvent, the only action needing to be performed is to save data from

the form to the database. This is only done if data in the form may have changed as

determined by the isDirty flag, which is set by the changed function. If data may have

been changed then getFieldsVitals is called.

The getFieldsVitals function is opposite to setFieldsVitals. It reads the data in the

form elements and writes them to the database record. It first locks the record. Next, it

calls getText for each field, which obtains the character string and writes it to the

database. Finally, getFieldsVitals clears the isDirty flag. As with setFields, each form

with data to save to the database has a getFields function.

The Palm OS handles any events related to the user entering data into fields

except for one special case. If the special Grafitti characters nextFieldChr or

prevFieldChr are entered, the form places the cursor into the next or previous field

respectively. This allows users who are familiar with Palm Pilots to navigate the form

quicker. The only other events to be handled by vitalsHandleEvent are the tapping of the

33

Exit2 button and menu events. When a button is pressed the Palm OS sends a

ctlSelectEvent. vitalsHandleEvent processes this by calling FrmGotoForm to switch

back to the WhichInfo Form. Events related to the menu fall into the menuEvent

category. These are all sent to the menuEventHandler for processing. All forms in both

New Patient and Diagnose that have a menu have the same menu and call

menuEventHandler to process the event. This event is generated if the user opens the

menu with the Palm menu button or if they select an entry on one of the menus.

There are two menus. The first has the standard Palm Edit menu consisting of

Undo, Cut, Copy, Paste, Select All, Keyboard, and Graffiti Help. The second is the

Options menu that has a single choice: about diabetes. The edit menu choices revolve

around editing a field while the about diabetes choice displays a screen containing

copyright information.

History

This form is more complicated because it is used in both the New Patient and the

Diagnose modules. First, recall the History form (Figure 15) is Page 1 in New Patient

and History in the Diagnose module. Several static variables track the values in the form.

The variables are static (i.e., to retain their values) since this function is exited and

reentered several times while the form is on the screen. The event handler function for

this form is page1HandleEvent, which contains the typical switch statement

differentiating on the type of event.

The first event coded is also the first event that occurs: the event indicating that

the form is being opened or activated. The code calls a system function to draw the form

2 Boldface indicates the name of a button.

34

elements using FrmDrawForm. Next,3 the label on the Exit button is changed and two

other buttons are displayed. Lastly setFieldsPage1 is called.

setFieldsPage1 is passed the addresses to the static variables in

page1HandleEvent so that they can be set from the database. It first locks the database

record (hrecord) using MemHandleLock. To keep the memory from becoming

fragmented, the Palm OS moves memory chunks around as programs are running. To

write to this movable memory it is necessary to first tell the OS not to move the chunk to

avoid corruption problems when directly editing the memory. The record was already

queried and the handle to the record is only changed when Diabetes Aid deals with a

different patient.

Next, setDate is called. This function reads the year, month, and day from the

database corresponding to the date of the first diagnosis of diabetes in the patient.

setDate then calls setDateTrigger, which converts the date to a character string using the

current date format style. For example, the default type would convert August 15, 2001

to 8/15/01. If no date has yet been set, it uses the words “No Date” as the label of the

selector trigger for the date. The value of the push button representing how often the

patient checks their blood sugar is read from the database and set, then the values of the

two lists are read and the lists and their associated popup trigger labels are set. This is

done by setList, which sets the label of the popup trigger to the text of the current

selection from the list.

3The notes are relative to the form being used in New Patient as opposed to being in theDiagnose module. The differences are determined at compile time using C’spreprocessor directive #ifdef. This way the run time size and speed of the module is notaffected and the code can easily be reused by both forms thus improving coding time,efficiency, and consistency between the modules.

35

setCheckbox examines the value of the given checkbox (used to identify whether

the patient has had problems with low blood sugar). The forms were created so that the

“No” checkboxes’ ID numbers are 50 more than the corresponding “Yes” checkboxes’.

For setCheckbox , it reads a single byte representing if neither box was checked (0), the

yes box was checked (1), or the no box was checked (2). It then checks the appropriate

boxes on the form.

The title of the form is set to “patients first name last name Page 1.”4 The

setTitleName function concatenates the patient’s name with Page 1 and FrmSetTitle sets

and draws the title on the form. Lastly, the record is unlocked (using

MemHandleUnlock) so that the Palm OS can move it as needed. In general, a record

should be locked for a minimum amount of time to give the OS the most flexibility

possible in memory management.

The next event type handled is the last that occurs, the closing of the form. This event

checks the Boolean flag isDirty to see if any of the elements on this form were potentially

changed and, if so, saves the changes to the database. The isDirty flag is set by the

function changed, which checks if a given event could have changed data. The

getFieldsPage1 function clears the flag.

getFieldsPage1 is responsible for saving the form data to the database. First, it

locks the handle to the patient record (hrecord) using MemHandleLock. getDate uses the

DmWrite function to write the year, month, and day values of the date from the Palm OS

DateTimeType structure. Next, the values of the static variables of page1HandleEvent

are written to the database. These are the current value of the Times push button that

4For the Diagnose module, the title is set to “History.”

36

stores how often the patient checks their blood sugar, the selection in the TimesPer list,

and the selection in the TimeOfDay list. getCheckbox examines the given checkbox ID

and its companion and saves the appropriate value: 0, 1, or 2. Finally, the isDirty flag is

cleared and the record is unlocked.

The next event is the popSelectEvent. This event occurs when the user selects an

item from a pop up list. The Palm OS automatically handles the display of the list when

the user taps on a popup trigger. There are two popup triggers on the History form. The

first one is related to how often the patient checks their blood sugar. This popup list has

choices of day, week, or month. The other trigger is for the time of day that the patient

checks their blood sugar: AM, PM, or bedtime. The page1HandleEvent function must

store choice made by the user.

The last two events, ctlRepeatEvent and ctlSelectEvent, are handled by the same

code since they both relate to a button or repeating button being tapped. This is because

the first time a repeating button is tapped, it sends a regular ctlSelectEvent like a regular

button, but after that, it sends a ctlRepeatEvent. The code uses another switch statement,

which differentiates which button was tapped by looking at the controlID of the event.

ID numbers are integers assigned by Constructor to each element and form a unique

identifier to all elements.

The first two types of events handled are generated by the up and down repeating

buttons for the number of times the patient checks their blood sugar. page1HandleEvent

calls the repeater function that increments or decrements the value appropriately and

keeps it within the bounds of 0 to 10. It also sets the label of the associated push button.

37

The Prev and Next buttons are set to go to the Navigation page (page 0) and

allergies (page 3) forms, respectively. Also, Exit leads back to the Navigation page.5

The last type of ctlSelectEvent is if the selector trigger for the first diagnosis page

is tapped. If so, dateTrigger is called. This function displays the built-in date selection

form of the Palm OS. The starting date is the date that is already stored in the database

for the first diagnosis or the current day’s date if no date has yet been chosen. It uses

setDateTrigger to set the label of the selector trigger to the date in the current date

format.

Allergies

This form (Figure 5) also has a function to handle its events,

allergiesHandleEvent. The frmCloseEvent is not handled because no action is required

for that event as the data has already been stored in the database. The frmOpenEvent

draws the form and calls the appropriate setFields function, in this case

setFieldsAllergies.

setFieldsAllergies first performs some conditional actions depending on whether

the form is being used from New Patient or Diagnose. For the New Patient module, the

title is set to “patient’s first name last name Page 2,” the Exit button is changed to say

Next, and the Prev button is activated and displayed while Diagnose requires the title be

set to “Allergies.” The database is then read to obtain the current number of allergies

(allergCount) and medicines (medCount). These numbers are required due to the resizing

of the patient’s record based on the number of allergies and medicines appended to the

end of their record. Next, a line is drawn to separate the text labels at the top from the

5 In the Diabetes module, exit take the user back to the Which Information screen.

38

table of allergies to make the form more readable. Lastly, drawTable is called to draw

the allergy table.

For efficiency and consistency, both the allergy and medicines tables use the

drawTable function. First the allergy table is initialized and reset. If there are fewer

allergies than rows in the table, then the extra rows are ignored. If there are more

allergies than rows, then the scrollbar is initialized and displayed. The scrollbar needs to

know which allergy is on top (i.e., the 5th one or the 12th one), how many to scroll by, and

whether it is at the top, bottom, or in the middle of the list.

Like drawTable, drawCol is used for both allergies and medicines. After the

database record is locked, the function determines where in the patient record to read.

The exact location of the allergies in the record is not static because the number of

allergies and medicines varies. Both allergies and medicines are appended to the end of

the record. Therefore, the offset in the database is the end of the static section of the

record (DB_RECORD_SIZE) plus a factor based on the size that each allergy occupies

(DB_ALLERGENTRYSIZE) to skip to the correct allergy (like the 5th one). The correct

characters to display are stored in the variable “string” and the record is unlocked. Next

some drawing modes are set and the string is truncated if necessary to fit in the cell.

Then the old value is erased and a new string is drawn.

A tblSelectEvent occurs when the user taps (selects) a row in the table. The row

number selected is stored in allergRow based on the allergTop and which row in the table

is selected. The sclRepeatEvent is generated when the scrollbar is used to scroll the

table. The new top row of the table is stored in allergTop and the table is redrawn.

39

The keyDownEvent is a special event occurring when the user presses one of the

physical buttons (i.e., the page up and page down buttons) on the Palm Pilot itself. These

buttons scroll the table up or down respectively by one row less than the number of rows

that can be displayed in the table. This is done for usability reasons. It is less confusing

to the user if after hitting page down, that the last row of the previous page is still visible.

For example, if rows 1-10 are being displayed and the user hits page down, then rows 10-

19 are shown.

Next, as in the historyHandlerEvent function, a switch statement handles the

buttons at the bottom of the screen. For the New Patient module, the Prev button takes

the user back to Page 1, the Exit button (relabeled as Next) takes the user to the

medications form, otherwise there is no Prev button and Exit returns the user to the

Which Information screen. The Add button takes the user to the add allergies form. The

Edit button first checks that a row has been selected and if so brings that row up in the

allergies edit form; otherwise, it sounds an error.

The allergies add form allows the user to add additional allergies to the list. Its

event handler is allergAddEventHandler. There are only two buttons on this form, Add

and Done . When the user taps Done Diabetes Aid returns to the allergy table. The Add

button does most of the work.

When the user taps Add, Diabetes Aid first checks that an allergy name was

entered or selected from the list and that a severity level was chosen. If not, an error

message is generated and the program waits for the next event. If both selections have

been made, allergCount is incremented to count the new allergy and the database record

is resized to hold the new allergy. Since medicines are stored after allergies, if there are

40

any medicines in the record, they need to be pushed further down the record to make

space for the new allergy. Because of this, adding an allergy can take some time if

medicines must be transferred. This is why allergies are examined before medicines.

Also, as allergies do not tend to change as frequently as medicines, the placing of

medicines last, reduces the time required for the more common processes. Next, the

function stores the new value of allergCount, the new allergy, and the new severity level

in the database. The record is released and the form is reset so that another allergy can be

added.

The last button on the allergy form is the Edit button. This is used to change an

already entered item or to delete an item from the list. The setFieldsAllergEdit function

reads the database and sets the field to the allergy name and the list to the item selected.

Tapping the Cancel button returns the user to the allergy form with no changes made.

Tapping the OK button checks the isDirty flag (i.e., has anything changed) and saves the

changes using getFieldsAllergEdit if needed. It then returns to the allergy, redrawing it

using the new values.

The Delete button is more complicated. It first decrements allergCount and

writes the new value to the database record. It moves any following allergies and all of

the medicines. It scrolls the table as needed and then shrinks the database record by

resizing it.

Patient List

The Patient List screen (Figure 16) presents a list of patients stored on the Palm

using their last names and identification numbers.

41

Figure 16: Patient List

The frmOpenEvent case includes a call to the buildPatientList function that reads

the database and pulls the patient’s last name and identification numbers from each

record.

When the doctor selects a patient from the list, a lstSelectEvent occurs.

patientListHandleEvent stores which record was accessed in the global variable cursor. It

then runs the function inits to reset all global variables for the new patient.

The Exit button performs its functions by adding an appStopEvent to the event

queue. This type of event is handled in the main loop and causes Diabetes Aid to exit.

Dyslipidemia

The Dyslipidemia screen (Figure 12) is part of the Diagnose module and is

reached by tapping the Dyslipidemia button on the Which Information form. This form

is used to prescribe medications based on the lipid profile results of LDL, HDL, and

triglycerides. The dyslipHandleEvent function has the same basic structure as the

previous event handlers. However, this form is more complicated because it has several

dynamic elements.

If a medicine has been selected either directly by the doctor or suggested by

Diabetes Aid, four new elements are activated on the form by the function dyslipshow.

42

The first is a Side Effects button listing some of the common side effects for the selected

medicine. There is new popup trigger to allow the selection of a second medicine. The

other two elements are popup triggers for selecting the dosage level and the brand of the

selected medicine. The list of brands and dosages for each medicine has been coded into

the Constructor as string lists that are simply a static collection of strings. This makes

them relatively easy to change as each medicine has its own string lists, one for brands,

and one for dosages. dyslipshow uses setStrList to get the resource, read the strings from

it, and set those strings to be the choices in the list. The freehandles function frees the

memory and unlocks the handle to the resource used when reading the strings from the

string list.

If a second medicine is selected, dyslipshow activates a second pair of popup

triggers to select the dosage level and brand of the second medicine. If no medicine was

selected then dysliphide deactivates all of the optional elements.

The events handled by this function are almost the same as those handled in

previously discussed event handlers. The functions setFieldsDyslip and getFieldsDyslip

behave similarly to the previously discussed setFieldsPage1 and getFieldsPage1

functions. The one difference is that setFieldsDyslip calls an additional function

AIdyslip.

AIdyslip is responsible for making the system recommendations associated with

dyslipidemia for medicine, dosage, brand, and next appointment. There are several

intelligent functions like this called by other setFields functions. This function contains

several if-else-if ladders used to make choices. The first ladder examines the LDL value.

If the value is below 100 it is considered a good value and no medicine is prescribed.

43

The patient need not be seen for two years. This suggested next appointment is not

finalized until all areas affected by diabetes have been examined and all lab dates have

been checked. Eventually, the overall suggested next appointment is the minimum of

those suggested by each section.

If the LDL value is between 100 and 130, it is a little high but not extreme, then

Diabetes Aid recommends the drug statin at its base dosage level. If the patient is already

using this medicine, it is suggested that the dosage be increased to the next level. If the

dosage level is already at the maximum, then it is suggested that statin be combined with

another medicine, setting dosages accordingly. It recommends the patient be seen in 3

months.

For LDL values above 130, Diabetes Aid recommends medicines identical to the

middle range. The patient’s next visit, however, is one month to make ensure the LDL is

lowering. If the LDL values stay high and the patient has already been taking high

dosages of both statin and resin then the system alerts the doctor that it is no longer

capable of making recommendations. This is because the patient has gone beyond the

normal range of diabetics and beyond the guidelines for treating diabetes. Diabetes Aid,

therefore, recommends that the patient be referred to a specialist.

For HDL values, a risk factor is displayed. A patient is considered “Low,”

“Medium,” or “High” risk. This risk factor is also dependent on the gender of the patient

since normal HDL levels vary between males and females. This risk factor goes into

overall treatment of diabetes but does not have a direct effect on treatment by itself.

Triglycerides are handled in a similar fashion to LDL values.

44

Next, AIdyslip updates the global variables for the suggested next appointment.

This is stored in two variables: Appointnexttype stores whether the next appointment is

months or years away and Appointnext identifies how many. For example, if Diabetes

Aid suggested three months till the next appointment then Appointnext is set to 3 and

Appointnexttype is set to 2 since it represents choice number two in a list consisting of

NA, years, and months. If the Appointnexttype is 0 then no suggestion has been

calculated. The variables are set so the minimum length of time until the next

appointment is used. If the next appointment time is modified, Appointreason is set to 1,

representing that the reason for the next appointment time was dyslipidemia.

Finally, the global limits array is updated. This array stores in seconds how old a

particular laboratory test is allowed to become before it must be redone. This is used

when checking if laboratory values are too old. The Palm OS does not include any native

functions to compare dates. Instead, it includes functions to convert them to and from

seconds relative to a starting point of January 1, 1904. These numbers can then be

compared as normal unsigned long integer values.

Wrapup

The Wrapup (Figure 14) form is one of the last forms used in the diagnosis of a

patient. It has the standard wrapupHandleEvent, setFieldsWrapup, and getFieldsWrapup

functions. The setFieldsWrapup function also checks a Boolean array called labs to see

which laboratory tests will be needed by the next appointment time. It creates a textual

list of these tests and displays them on the form.

frmOpenEvent contains a function computeOffset. This offset is the number of

seconds from the current time until the next appointment. This is used to determine

which laboratory tests must be redone before the next visit by the patient. The

45

computeOffset function uses three constants defined using #define: MONTH1 equals the

number of seconds in an average month, MONTH12 is the number of seconds in a year,

and MONTHHF is the number of seconds in half of a month. These were predefined

using #define rather than computed on the fly to increase the speed of the program, since

the function converting dates to seconds is not fast.

The form contains repeating buttons for entering values for Appointnext similar to

those on the History form. However, these push buttons increment by 0.5 instead of by

one. Since the Palm does not easily support floating-point numbers, these values are

simulated by incrementing a counter by 5s instead of by ones.

The Suggest button takes the user to a form that displays the suggested next

appointment time using the global Appointnext variables. The user is given a choice of

using the suggested appointment time in which case the elements on the Wrapup form are

updated accordingly.

Summary

This chapter discussed details of programming a Palm and how form elements

and source code interact. Several example screens were discussed in detail to show how

implementation was done for this project. The next chapter includes a summary of this

thesis. It also discusses possible future extensions to Diabetes Aid.

46

CHAPTER 5SUMMARY AND EXTENSIONS

This chapter contains a summary of this thesis and its associated program,

Diabetes Aid. It discusses the system’s feasibility and possible future extensions.

Summary

This thesis examined the development of a Palm Pilot for the treatment and

diagnosis of diabetes. The result, Diabetes Aid, demonstrates the feasibility of such a

system. It also showed limitations in such an undertaking. Some of these limitations are

due to the Palm Pilot’s difficulty in text entry and current lack of voice recognition.

Other limitations are due to a lack of a general consensus within the medical field

regarding how to treat certain instances of diabetes.

Diabetes Aid assists a doctor in the management of diabetes by displaying

relevant information in a concise and easy to use form. Since it runs on a Palm Pilot, the

doctor can use the system at the point of visit regardless of where the patient is. There is

no need to place computers in every examination room or to carry around large and

heavy pieces of equipment from room to room.

Extensions

Several possible areas of extensions exist to this thesis. First is the area of

connectivity: interfacing Diabetes Aid with outside systems. Next are extensions internal

to Diabetes Aid itself and how it manages patients. Last is how new hardware could be

use to extend the capability of Diabetes Aid.

47

Connectivity

A global database shared by all parties involved with a patient would be of

significant value. This would allow all the data in this system to be updated when any

relevant change to a patient’s record occurred. It would also allow for easier

maintenance between doctors, laboratories, pharmacies, etc. as outside information would

all come from a single source. Without this database, Diabetes Aid would need some

way to gather information from these outside sources. Currently, this information is

either scanned or entered as it is received. This could be improved through automatic

updates by faxing or emailing to the database system directly, thereby reducing human

effort in inputting data.

Another area of possible extensions would be integrating the different types of

treatment. For example, when Diabetes Aid suggests that the patient needs to see an

ophthalmologist, it could connect to the patient’s ophthalmologist to create the

appointment before the patient leaves the office. This also applies to prescriptions and

laboratory tests.

Diabetes Aid could be extended to allow prescription authorizing to be performed

directly from the visit. As soon as the doctor has confirmed a new medication for a

patient, the prescription request could be faxed or emailed to a pharmacy. This could

reduce the costs as well as potentially reduce forged prescriptions with the use of an

electronic signature and encryption system.

Using the Palm’s built in “Beam” (transferring data between Palm Pilots using the

built in infrared port) capability, Diabetes Aid can transfer the entire database to another

Palm. However, in consultation situations it would be beneficial to beam only a single

patient’s record. This would allow a consulting doctor to have all the information

48

instantly and in a familiar format. This alleviates the communication problems that can

occur when describing a patient’s condition.

Reference material related to diabetes could be available on the Palm for the

doctor’s use. Information regarding prescriptions, such as side affects, would be a

valuable addition to the doctor. Ideally, this reference material should be directly

accessed from within Diabetes Aid. For example, the Dyslipidemia Side Effects button

could bring up the appropriate information from an outside side-effects database such as

ePocrates’ qRx product discussed in Chapter 2.

Internal

A major area of diabetes diagnosis that Diabetes Aid does not handle is insulin.

Insulin is a commonly used medicine to treat the more serious cases of diabetes. The

main problem with implementing intelligence related to insulin is the lack of accepted

standards for its use. Though general themes exist, such as early onset diabetics use

insulin more frequently, there are no specific standards as to when to start insulin or how

much the dosages should be.

Diabetes Aid currently does not track the patient beyond the current visit. This

idea would be useful to a physician as they could see if the patient is improving in some

specific area such as LDL values. This information could be presented as a line graph of

values versus dates to convey quickly and easily the information to the doctor.

Finally, long-term tracking could be performed on the patient data to see which

treatment plans worked best for certain situations. This would lead to better treatment of

patients by using those treatment plans that have been most successful in the past. This

could also result in better cost efficiency by reducing the amount of extraneous tests and

treatments.

49

Hardware

Another area extension involves the hardware. Clearly, hardware advances will

result in better screens, faster performance, and color. However, other hardware

advancements will do more than merely improving the current situation. For example,

true voice recognition would allow the doctor to dictate notes directly into the system.

This would greatly increase efficiency since there would be no need to re-examine the

patient’s records to dictate notes nor would anyone need to transcribe these notes.

A wireless network would allow the Palm Pilot to update its records throughout

the day. This would free the doctors from needing to go to a desktop computer and

download records. It also would allow the system to update the patient’s record

throughout the day if new information from an outside source, such as a laboratory, came

arrived. As a result, the doctor would always have all the current information available.

Conclusion

This thesis presented Diabetes Aid, a program designed to assist physicians in the

treatment and tracking of patients with diabetes. The thesis discussed the usefulness of

such a system and examined other decision support systems in the medical field. The use

of Diabetes Aid and some of the implementation details were presented. Finally, possible

extensions to this program were discussed.

50

LIST OF REFERENCES

Ambler, Scott W. User Interface Design: Tips and Techniques, 2000.http://www.ambysoft.com/userInterfaceDesign.html, visited October 31, 2001.

American Diabetes Association. Standards of Medical Care. Diabetes Care 1999; Vol.22. Pp. 32 - 41.

Cawsey, Alison. MYCIN: A Quick Case Study. 1994.http://www.cee.hw.ac.uk/~alison/ai3notes/section2_5_5.html, visited August 20,2001.

Clancey, W. J. and R. Letsinger 1984. Stanford University. Historical Projects.http://www-camis.stanford.edu/research/history.html#MYCIN, visited August 28,2001.

DVO Enterprises. Cook'n™ for Diabetics, 2000.http://www.dvo.com/cookndiabetics.html, visited October 31, 2001.

ePocrates. ID Overview, 2001.http://www.epocrates.com/products/epocratesID/overview.cfm, visited September14, 2001.

Freudenheim, Milt. The New York Times, Digital Doctors, January 8, 2001.http://www.nytimes.com/2001/01/08/technology/08HAND.html?pagewanted=all,visited September 14, 2001.

Goodarzi, Mark, MD. Palm Pilot Resources, 2001.http://www.endocrinology.med.ucla.edu/Palm_Pilot_Resources.htm, visitedOctober 31, 2001.

Gottlieb, Scott, MD. American Medical News, Internet Health Care Sites Cast theirLures for Physicians, July 10/17, 2000.

Green, Lydia. Duke University to Provide ePocrates Handheld Medical Software toAffiliated Physicians, 2001http://www.epocrates.com/headlines/story.cfm?story=10063, visited September14, 2001.

51

Healthetech. GlucoPilot, 2001.http://www.healthetech.com/h/products/products_glucopilot.html, visited October31, 2001.

Johnson, Jeff. GUI Bloopers: Don’ts and Do’s for Software Developers and WebDesigners. San Diego: Academic Press, 2000.

Leff, Marni. Seattle Post-Intelligencer, A World of Help in their Palm Handheld Devicesare Perfect Rx for Doctors, January 29, 2001.http://www.epocrates.com/headlines/story.cfm?story=10059, visited September 1,2001.

Mykland, Robert. Palm OS Programming from the Group Up. Chicago:Osborne/McGraw-Hill, 2000.

Palm Inc. Historical Timeline, 2001http://www.palm.com/about/corporate/timeline.html, visited September 14, 2001.

Rhodes, Neil and Julie McKeehan. Palm Programming: The Developer’s Guide.Chicago: O’Reilly & Associates, Inc., 1999.

Shalo, Sibyl. Bugs, Drugs, and the Success of Viral Marketing. PharmaceuticalExecutive. May 2001. Pp. 100 – 102.

Spolsky, Joel. User Interface Design for Programmers, 2001.http://joel.editthispage.com/stories/storyReader$51, visited October 31, 2001.

3Com. Palm OS Programmer’s Companion. Santa Clara: 3Com, 1999.

3Com. Historical Timeline, 2000. http://www.palm.com/about/corporate/timeline.html),visited August 20, 2001.

52

BIOGRAPHICAL SKETCH

Gary Lloyd Underwood was born on August 31, 1976, in Winter Park, FL, USA.

He began his career at the University of Florida (Gainesville) in August of 1994 and

completed his Bachelor of Science degree in mathematics in May 1998. He started work

on a master’s degree in mathematics in August of 1998 before changing to computer

science in January of 1989.

His research interests include artificial intelligence areas such as decision support

systems, game strategy planning, and machine learning. Outside of research, he plays

video games and enjoys playing sports.

He is currently enrolled at the University of California at Los Angeles pursuing a

Doctor of Philosophy degree in computer science. He hopes to later receive a

professorship in computer science.