Personal Electronic Medical Assistant (PEMA)

Project Final Report

Team Number: May 00-01 Submitted on 4/19/2000

Consultant: Herb Harmison

Faculty Advisors: John Lamont Ralph Patterson

Team Members: Brian Gunst Jeff Lanning Vinay Tauro Brett Utesch

2

Table of Contents List of Figures 3 List of Tables 4 Introductory Materials 5

Executive Summary 5 Acknowledgement 6 Definition of Terms 6

Introduction 8

General Background 8 Technical Problem 8 Operating Environment 9 Intended Users and Uses 9 Assumptions and Limitations 12

Design Requirements 14

Design Objectives 14 Functional Requirements 17 Design Constraints 27 Measurable Milestones 28

End-Product Description 30 Approach and Design 30

Technical Approaches 30 Technical Design 31 Testing Description 35 Risks and Risk Management 36 Recommendation for Additional Work 36

Budgets & Schedule 37

Financial Budget 37 Personnel Budget 37 Project Schedule 37

Closure Materials 39

Evaluation of Project Success 39 Commercialization 39 Recommendations for Additional Work 40 Lessons Learned 40 Project Team Information 42 Summary 42 References 42 Appendices:

Project Schedule Gantt Chart Appendix A Doctor Survey Summary Appendix B Doctor Interview Summary Appendix C Patient Interview Summary Appendix D

3

List of Figures Figure 1. The PEMA System 8 Figure 2. The PEMA Device 14 Figure 3. A Simple AA Battery 15 Figure 4. The Docking Station 16 Figure 5. Main Menu Example 18 Figure 6. Medications Taken Today Screen 19 Figure 7. Prescription Information Screen 20 Figure 8. Schedule by Day 20 Figure 9. Schedule by Medication Screen 21 Figure 10. Device Settings Screen 22 Figure 11. Docking Mode 23 Figure 12. Alert Screen 24 Figure 13. List Screen 25 Figure 14. Shutdown Confirmation 25 Figure 15. The Programmers Schedule 26 Figure 16. The Software Simulation (initial screen) 32 Figure 17. The Prototype Design 34

4

List of Tables Table 1. Intended Users of the PEMAS 12 Table 2. Sample testing form 36 Table 3. Estimated project expenses 37 Table 4. Current and project personal efforts 37 Table 5. Personal Team Information 42

5

Introduction Executive Summary The Need for the Project: Many people have medical conditions that require multiple prescriptions or prolonged usage of medication. Failure to take these medications regularly can have significant health consequences. The intent of this project was to design a small, digital, portable device that would remind people to take their medications. The team also proposed to create scheduling software for this device, so that physicians or their trained staff could program it. The result of the project was the Personal Electronic Medical Assistant System (PEMAS), consisting of both the portable device and the supporting software. Project Overview : The project began by brainstorming ideas for the device: the features it should have, the capabilities it should support, how to make it marketable, etc. The project advisors suggested that the best way to design the right device would be to interview patients (who could be potential users of the device) as well as doctors. So the team designed questionnaires for the doctors and the patients, which were sent out along with the initial ideas. The objective of these surveys was to bring to the teams attention (before the design process) anything that had been overlooked or anything that was redundant. The questionnaires were followed by short interviews. Though the surveys took a little longer than expected, they enabled the team to design a higher-quality device. Furthermore, the surveys gave the team a better idea of the type of person who would ultimately use the device someone who was not necessarily elderly, but who had a fairly dynamic lifestyle and who had to take a lot of medications. People who lead a regimented and routine life, as well as people who are looked after by a nurse or caregiver, have no real need for this device. The first semester of work on the project ended with the completion of the design report. The second semester began with picking out hardware components that would be a part of the device as well as ordering these components. The team also created a software-based proof of concept of the device to model its capabilities and behavior, and this significantly aided the teams efforts. The simulation brought to the forefront some issues that the team had not previously considered. After assembling the various hardware parts and writing the code, all that is left of the project is to compile and download the written code into a working prototype. This will include testing both the hardware setup as well as the functionality of the code itself. Project Results: As a result of the past years work, the May 00-01 Senior Design team expects that users of the PEMA device will be able to freely enjoy living a dynamic and active lifestyle. These users will be able to rely on the device to alert them at the proper times to take their medications instead of always watching the clock and worrying about their medications. Furthermore, the team believes that the use of this system could help defer assisted care.

6

In conclusion, the PEMA design team hopes to have made a difference in the lives of people with substantial health-care needs. Acknowledgments The following people were extremely helpful in offering their insights and recommendations: Doctors Dr. Tom Johnson Dr. Lynn Theesfield Dr. Cosette Scallon Dr. Lowell Bond Dr. Mark Blaedel Dr. Louis Banitt Heartland Senior Services Caroline Hurst (supervisor) Francis Ballard Lavon Quam Lilian Cowhick Diana (last name unknown) Definition of Terms Below is a list of common terms used throughout this report followed by a brief explanation of their meaning: ACK / NACK Positive and negative acknowledgements used in communication to tell

sender if data was received error free. Polynomial CRCs are usually used to check data integrity.

ASIC Application specific integrated circuit GUI Graphical user interface LCD Liquid crystal display Modal Forms Dialog boxes (or screens) that come up during the use of software that

require the user to close it before control is given back to the screen that launched the dialog box.

PEMA The PEMA (personal electronic medical assistant) is the portable

electronic device that users carry with them. PEMA Programmer or Programmer The software used by doctors and their staff to

program the PEMA device. This software will reside on a personal computer in the doctors office.

7

PEMAS The PEMAS (personal electronic medical assistant system) refers to both the PEMA device and the Programmer.

Polynomial CRC Error detection scheme used for communication. Created by running the

data through a polynomial and appended to the end of the data transmission.

Seniors For the sake of convention, seniors will be referred to as any one over the

age of 60 and/or retired. VLSI Very large scale integration

8

Introduction General Background Many people today must take one or more medications regularly sometimes many times a day. Often, remembering to take these medications can be difficult, while failure to take them can cause significant health consequences. Furthermore, most people have no means of remembering to take their medicine other than by their own memory or the help of a spouse, nurse, or caretaker. The teams objective is to create a system, the PEMAS, which will remind people to take their medications at the proper times. The entire PEMAS system (see Fig. 1) consists of two components: 1) the portable device, referred to as the Personal Electronic Medical Assistant (PEMA), and 2) the Programmer (software that resides on the doctors computer).

Figure 1. The PEMA System

The PEMA will be small and durable about the size of a thick wallet. This way it will easily fit in a purse, coat pocket, or snapped to a belt. To effectively remind the user, it will need an audible alarm and vibration. Furthermore, it will require a display screen to provide the user with the information they need upon being alerted. When alerted, the patient simply responds to the alert. The patient cannot, therefore, change a schedule or prescription medication. This device will be brought with the patient during visits to the doctor. The doctors staff, using their PEMA Programmer software, can view and modify the schedule before returning it to the patient. If a new prescription is made, it can easily be added to the schedule. Technical Problem In order to be easily programmed and updated by a physician or nurse, we will include software (the PEMA Programmer) to run on a common PC. The prescriptions and their schedules will be entered into the Programmer and then downloaded to the PEMA.

9

The PEMA will utilize a holographic, backlit LCD display that will provide high contrast and easy readability. This will be a 6-line, 120-character display (6 x 20). The faceplate will consist of a single on/off button, two sets of scroll buttons (one horizontal and one vertical), as well as one enter button. This device will run on a single AA battery that will operate for 3 months or more. A lithium watch battery will act as a backup battery to retain memory if the primary battery is dead or removed. The primary battery will drive the LCD display as well as an audible alarm and a silent vibration alarm. The device logic will initially be programmed in C and then migrated to VLSI logic to produce an ASIC chip. The use of ASIC chips will enable miniaturization of the device, keeping it within acceptable size constraints. The PEMA Programmer will be developed in Java using Metrowerks CodeWarrior IDE. The software will interface with the PEMA through the docking station and provide a graphical user interface, which will facilitate easy programming of the device. The use of Java will also allow deployment of the software across many different platforms and operating systems. Much of the following document describes the commercial version design. However, the team did not create a commercial version, but rather two preliminary steps: 1) A software Proof of Concept designed in Visual Basic, and 2) A hardware Prototype described under the Technical Design section. Several references to these two deliverables will be made throughout the document.

Note: Much of the following document describes the commercial version design. However, the team did not create a commercial version, but rather two preliminary steps: 1) A software Proof of Concept, or Simulation, designed in Visual Basic, and 2) A hardware Prototype described under the Technical Design section. Several references to these two deliverables will be made throughout the document.

Operating Environment Because the PEMA will be mobile and travel with its user, it will be subject to a wide variety of environments. Ideally, it should stand up to any of the rigor that a typical wristwatch or pager goes through. In particular, the device must, at least, endure:

• Temperature ranges from 40° to 110 ° F (limited by LCD properties) • Splashes of water • Dust, lint, dirt, and body oils • Short drops and falls • Jean pocket conditions - leaned against, sat on, etc

Intended Users and Uses Several target groups were considered for this project. In order to narrow down a market niche, two essential questions were asked concerning each group of people:

10

• Would the group use this device? • Would the group be willing to purchase this device?

Based on the surveys and interviews conducted (summarized in Appendix B, C, and D), the following observations were made: People blind and/or deaf: Research was inconclusive about the need that people with disabilities have for this device. However, both the blind and deaf represent a small enough portion of the population that they should not be targeted as the primary user. Later versions may target these groups. Seniors with moderate to high dementia: As Caroline Hurst mentions in Appendix D, most of this group cannot be trusted to operate this device correctly or take their medication when alerted. These patients require one of two types of caretakers to watch over them, either non-resident caretakers or a resident caretaker such as a spouse or close relative. Both of those groups are listed separately below. Non-resident caretakers: Non-resident caretakers are those that just check up on patients instead of actually live with them. Non-resident caretakers should not use this device because they arent with the patient at all times. Furthermore, many of these caretakers may check up on more than one senior, which makes carrying several PEMA devices impractical. People with regimented schedules and relatively static prescriptions: From the surveys mentioned in Appendix D, this group has no need for a better reminder system and isnt interested in it anyway. Of course, there are probably exceptions, but not enough to make this group a primary target. Hospitals and nursing homes: Based on the doctors surveys as well as team agreement, hospitals and nursing homes should not be targeted by this device. First of all, very few (if any) of the patients at these facilities are responsible for giving themselves their own medication. Second, these institutions have been operating for years and already have established methods of medication distribution. Finally, the objective of this project is to help patients remember to take their medication. Therefore, the product should be designed with primarily the patient in mind. Later versions could be designed to benefit doctors and/or nurse, but the primary focus and objective is to help patients. Independent seniors with an active and dynamic lifestyle: This group definitely has a need for this device. As people get older, their medications typically increase, but an active and dynamic lifestyle often makes taking the medications on a regular basis difficult. Because this group doesnt suffer from dementia or substantial memory loss, they can learn to use the PEMA quickly and correctly. Also, this group is likely to be willing to purchase the PEMA because they are much more aware of their health than younger generations.

11

Patients with multiple medications that arent seniors: For the most part, this group is well aware of computers and electronic devices, so they could learn to operate the PEMA with relative ease. However, three observations make this group a secondary target to the active seniors:

• Because they are younger and still working, they may not be as health conscious as the seniors.

• Because they are younger, they may be less likely to admit their need for such a device. Even if they do realize they need it, they may be kept from purchasing it because they dont want others to know about their medications.

• The number of 40 to 60 year olds that have multiple medications is much less than the number of 60+ year olds with multiple medications. That means this target group is probably much smaller than the active seniors.

Caretaker of a spouse, relative, or close friend: This is a unique situation where the actual patient wouldnt be the one carrying the device. Above, non-resident caretakers were ruled out because they arent with the patient at all times, but in the case of a spouse or similar type of caretaker, the caretaker is always near the patient. Although this may be a smaller target group than active seniors, the device would be very helpful in simplifying the caretakers life. Summary: From the above observations, independent seniors with dynamic and active lifestyles are the primary market group targeted by the PEMAS. They seem to be the group that would be mostly likely to both buy AND use the PEMA system. Table 1 below illustrates which groups mentioned above are targeted and which ones are not.

12

Table 1. Intended Users of the PEMAS

Primary Target Secondary Targets Groups not Targeted 1) Independent seniors with

an active and dynamic lifestyle.

1) Patients with multiple medications that arent seniors.

2) A caretaker of a spouse, relative, or close friend.

1) The blind and deaf. 2) Seniors with moderate to

high dementia. 3) Non-resident caretakers. 4) People with regimented

schedules and relatively static prescriptions.

5) Hospitals and nursing homes

Primary Target The PEMAS is being designed specifically with this group of people in mind. This is the group that will benefit most from the PEMAS and is also most willing to purchase it. Secondary Target These groups may not have quite as many people interested in the PEMAS as are in the primary target. However, these groups are still targeted as potential users. Groups not Targeted For various reasons listed in the above observations, these groups are not targeted by the PEMAS. However, people in these groups could find value in using this system. Not targeting them simply means that the device is not designed to specifically meet their needs. Furthermore, some groups that arent targeted now may be targeted by a later version. Assumptions and Limitations Assumptions: • A physicians staff will be willing and able to program this device using the scheduling

software. • Users of this device will feel comfortable using it in public. If they dont, they can keep it

concealed and on vibration mode. • When the user is alerted, the user will take their medicine. In this respect, the reliability of the

device is much like an alarm clock. An alarm clock can wake a person up, but it cant guarantee that they wont turn it off and go back to sleep. In the same way, the PEMA can alert a person that they need to take their medication, but it cant force them to actually take it.

• The users are able to read standard print (i.e. Times New Romans 11). • People care enough about forgetting their medications that they are willing to try this device. • The patient is still ultimately responsible to take their medication. • Patients are willing to disclose to each of their doctors all of their current medications being

taken. • Doctors will still collaborate before modifying one anothers schedule. • The PEMA will be able to sufficiently store all critical information while in standby mode

(e.g. when the battery is being changed). • The patient visits the doctor at least once every 6 months.

13

Limitations: • The PEMA screen contains a maximum of 6 lines with 20 characters per each line. For the

prototype, we are limited to 4 lines. • The device must be less than one pound (ignored for prototype). • The device must be small enough to fit in a purse or coat pocket and can be easily clipped

onto a belt like a pager (ignored for prototype). • The device must be fully functional through the use of 4 navigation buttons, an on/off switch,

and a select button (same for prototype). • The battery must lasts at least 3 months without being replaced or recharged (ignored for

prototype). • A time limitation occurred after the team experienced several hardware difficulties. Most

notably, finding a real-time counter proved almost impossible. As a result, completing the prototype will be difficult before the Industrial Review Presentation. If it is completed, the testing phase will only consist of what is absolutely necessary to prepare for the presentation.

For a discussion of risks and concerns about the PEMA, see the Risks and Risk Management section under Approach and Design.

14

Design Requirements Design Objectives The design of the PEMA system will consist of two main components the PEMA device (see Figure 2), and the PEMA Programmer. To download information from the Programmer, the PEMA will be inserted into a docking station (see below). The PEMA device has been further broken down into physical and behavioral specifications. The Programmer has been broken down into areas of major functionality.

(RED LED)

(←←←← LEFT) (↓↓↓↓ DOWN) (↑↑↑↑ UP) (→→→→ RIGHT) (•••• SELECT) ( POWER) Figure 2. The PEMA Device

PEMA Device (Physical Specs): Case: • Dimensions will be 3.0 x 2.0 x 0.75 or smaller. • Silver, injection molded, hard plastic will be used (other colors may be desired like red, teal,

blue, etc). • Product and company name will be printed in white above and below the LCD display • Case molding will accommodate the LCD, on/off button, 4 navigation buttons, a select

button, battery door, and proprietary serial connection pins. • One hole will be made to allow sounds to pass out of the case from the speaker. LCD Display: • 6-line, 120-character LCD display • Holographic back surface for high contrast in low light conditions • Backlit for viewing in environments with little or no light

15

Buttons: • On/off and select buttons • Four navigation buttons (up, down, left, and right) • Constructed with same material used for the case • Membrane switches (high-feedback) will be mounted below each button.

Figure 3. A simple AA battery. Batteries: • Primary: One 1.5V AA battery (see Figure 3)

o Exclusive source of power for all device functions o Supports device for 3 months or more @ 5 audio alerts / day

• Secondary: Lithium watch battery o Maintains memory when primary battery is removed or dead

• Battery monitor (see Appendix E): o Indicates when primary battery is getting low and needs to be replaced

Alert Systems: • Audio:

o Piezo buzzer with minimum output 80dB @ 12 in. o Speaker Mounted to underside of the case o Small hole in case will allow sounds to escape

• Vibration: o Motor with offset lead slug will be used to cause vibration o Motor will not produce more then 30 dB @ 12 in

Microcontroller: • ASIC microcontroller from National Semiconductor • VLSI logic ported from assembly (produced by C compiler) • 0.26 micron transistor size • 8 MHz (crystal driven) • Power-saving modes • Integrated internal clock Memory: • 4.0 KB RAM (low power) • Stores up to 30 different medication records

o Name of medicine (25 characters) o Comments (50 characters) o Scheduling information (5 bytes)

• Protected by secondary battery Belt Clip: • Black, injection molded, hard plastic

16

• Holster-style design will be used to hold the PEMA • Tabs on the holster will clasp device and hold it in place Communication Pins: • Small metal pins will be placed on the back of the PEMA • Connects with pins on docking station when placed in cradle • Allows serial transfer of data to and from the PEMA Programmer

Figure 4. The Docking Station Docking Station (Physical Specs)*: *No docking station will be used for the prototype. Base: • Weighted base with rubber feet • The PEMA will be set in a slot built to receive the device. • Metal pads (pins) will be mounted on the back of the device. • Interface pins will be positioned to come in contact with a set on the PEMA once the device

completely inserted. Cord: • 6 feet of insulated cord will be provided between the station and the DB9 adapter Receive Socket: • Standard serial communication protocol (RS-232) will be used between the PC and the

PEMA PC Adapter: • Female DB9 adapter will be used to interface with the male DB9 serial ports found on

standard PCs • Printer port adapters will be used to interface with Apple computers • USB adapters could also be developed as a future upgrade PEMA Programmer Software (Physical Specs)*: *Due to time constraints, only a stripped-down version of the Programmer will be implemented for the prototype. Minimum System Requirements: • 10MB free on hard drive • 2MB RAM (application space)

17

• 60MHz processor (higher preferred) • 2x CD-ROM drive or network access (for software install) • One free serial port (or printer port for Macs) • Mouse and keyboard support Operating Systems: • Windows 95, 98 • Windows NT 4.0 (Service Pack 6) • Windows 2000 (Professional and Server) • UNIX / Linux • MacOS 8, X Functional Requirements This section defines detailed behavioral requirements for the PEMA device as well as the Programmer. In general, the PEMA is an autonomous unit and performs all the required tasks without the help of other devices or systems. The docking station and Programmer are only needed to initialize the device for new users and to modify medication scheduling. PEMA Device (Behavioral Specs): PEMA behavioral specifications can be divided into 3 categories:

1) Device Operation This is simply turning the device on and off. 2) The Main Menu From here you can navigate through all of the PEMAs modes, or

screens. 3) The Alert Screen This screen has special functionality, and will be described last.

All screen shots in this section come from the Simulation.

Device Operation: 1) Press ON to activate the LCD. The LCD will turn on and the device will be ready to use. 2) Press OFF to turn off the LCD. The LCD also turns off if nothing has been pressed for

60 seconds. 3) If the battery needs replacing, the Green LED will flash. If the battery level is critical,

the device will chirp every 60 seconds.

NOTE; The PEMA doesnt actually turn off. When the off button is pressed, only the LCD turns off. When the PEMA is turned back On, it returns to the same screen that was displayed the last time the device was used. This is true even if the device is in the Alert Screen.

18

The Main Menu: The PEMAs Main Menu consists of 7 different screens. For example, the second screen is shown in Figure 5. The screens are listed below:

1. Welcome Screen 2. Medications Taken Today 3. Prescription Information 4. Schedule by Day 5. Schedule by Medication 6. Device Settings 7. Docking Mode

Figure 5. One of the screens in the Main Menu

If one of the above screens is selected, the PEMA jumps into the sub-menu for that particular function (all five sub-menus are described later). Navigation:

• LEFT/RIGHT: scroll through the main menu • UP/DOWN: disabled • SELECT: select a sub-menu

The MAIN MENU level scrolls through the following sub-menus: 1. Welcome Screen

There is nothing here other than a simple welcome and the devices version number. 2. Medications Taken Today

a. This screen lists every medication that has been or will be taken today in the format: x/y medication

i. x = how many already taken ii. y = how many total to be taken

19

b. Navigation i. LEFT/RIGHT: disabled

ii. UP/DOWN: scroll iii. SELECT: return to Main Menu

c. Screen Shot see Figure 6

Figure 6. Medications Taken Today

3. Prescription Information a. This screen lists each prescription that the device monitors with the following

information: i. Amount (in mg) per dosage

ii. Dosages / day iii. Brief doctor notes

NOTE;

If a prescription requires taking different amounts of medication in the same day, then the doctor notes can be used to specify this information (e.g. 10mg-morning, 20mg-night).

b. Navigation

i. LEFT/RIGHT: scroll through medications ii. UP/DOWN: scroll through information for each medication

iii. SELECT: return to Main Menu c. Screen Shot see Figure 7

20

Figure 7. Prescription Information

4. Schedule by Day

a. This option actually consists of 7 menus one for each day of the week. Each days menu contains the following:

i. Time a medication needs to be taken ii. Which medication to take

b. Navigation i. LEFT/RIGHT: scroll through days of the week

ii. UP/DOWN: scroll through information iii. SELECT: return to Main Menu

c. Screen Shot see Figure 8

Figure 8. Schedule by Day

21

5. Schedule by Medication a. This screen lists all of the medications with every time that medication needs to be

taken during the week. b. Navigation

i. LEFT/RIGHT: scroll through medications ii. UP/DOWN: scroll through information

iii. SELECT: return to Main Menu c. Screen Shot see Figure 9

Figure 9. Schedule by Medication

6. Device Settings

a. This screen includes a menu with configurations for the following options: i. Ring Type (silent, ring once, ring, vibrate, or vibrate and ring)

ii. Volume (1 through 9) iii. Timezone (+/- 0 to 12 GMT) iv. Set Date v. Set Time

vi. Snooze Length (15 to 180 minutes; +/- 15 min. intervals) b. Navigation

i. LEFT/RIGHT: scroll through options ii. UP/DOWN: adjust configurations

iii. SELECT: return to Main Menu c. Screen Shot see Figure 10

22

Figure 10. Device Settings

7. Docking Mode

a. Allows the user to download new information from the doctor. The device should be connected to the doctors computer by a serial connection.

b. Navigation i. LEFT: return to Device Settings menu

ii. UP/DOWN: disabled iii. SELECT: Download data. If, after a few seconds, no data

is received, then the PEMA displays an error message and returns to the Docking Modes main screen. If data is received, the screen displays Waiting for connection Receiving data Transfer complete.

c. Screen Shot see Figure 11

23

Figure 11. Docking Mode

The Alert: When a medication needs to be taken, the PEMA alerts the user with an alarm and the Alert Screen. Note the following:

• An alert takes precedence over any other action that is being done. • If the PEMA is in standby mode, then it the LCD will automatically turn on to the Alert

Screen. • The Alert consists of 2 screens: the Alert Screen and the List Screen:

1. The Alert Screen a. This screen alerts the user of medications that need to be taken. Along with the

alarm, a red LED also starts flashing. b. Options

i. RIGHT: Show Me (proceed to the List Screen; see below) ii. UP/DOWN/LEFT: disabled

iii. SELECT: Snooze 1. The LED stops flashing. 2. The PEMA returns to the Main Menu. 3. The alarm goes off again after the user-set snooze time passes. This

cycle can be repeated as long as the medication alert has not surpassed that medications Alert Limit*.

iv. USER DOESNT RESPOND: Wait Mode 1. The LED continues to flash to remind the user that there is

medication that needs to be taken. 2. The LCD times out after 60 seconds (like usual) 3. If the user doesnt respond to the alert before the medications Alert

Limit*, then the LED turns off, the screen returns to the Main Menu, and the device continues as if the user took the medication.

24

*ALERT LIMIT: The device will NEVER snooze or wait for longer than half the time until

the next medication, known as the medications Alert Limit. For example, if a medication is to be taken at 10 AM and 2 PM, then the Alert Limit expires at noon. Once this limit passes, the device returns to the Main Menu and acts as if the medication had been taken.

The Alert Limit will NOT be implemented in the hardware prototype.

c. Screen Shot see Figure 12

Figure 12. Alert Screen

2. The List Screen a. This screen lists the medications that need to be taken. b. Options

i. LEFT: Back to Alert Screen (if the user decides to snooze) ii. RIGHT: disabled

iii. UP/DOWN: scroll through medications iv. SELECT: Taken

1. The PEMA recognizes that the user took the medications listed and returns to the Main Menu.

v. USER DOESNT RESPOND: Wait Mode 1. The List Screen will wait just like the Alert Screen until the

medications Alert Limit passes (i.e. halfway to the next time that medication needs to be taken).

c. Screen Shot see Figure 13

25

Figure 13. List Screen

PEMA Programmer* (Behavioral Specs): *The following description only fits the commercial version and not the prototype. Note: Throughout this section, user refers to staff in the doctors office. Startup: • During program launch, users will be presented with a brief splash/welcome screen.

o Screen will contain, program title, version number, and developer names. o This screen will allow the user to close it or will disappear after 2 seconds.

• After the splash screen has been closed, user will be brought to the Connect to PEMA Screen.

Shutdown: • The option to shutdown will be available from all screens (except modal views). • Users will be prompted to confirm shutdown (see Fig. 14).

o The default option is No.

Figure 14. Shutdown Confirmation • Shutdown frees all resources used during system use.

26

• It thanks user for using the system. • It returns control back to the OS. Connect to PEMA: • The user will select a Connect to PEMA menu option. • Please Wait Connecting will be displayed on the screen. • The selected serial port will be open for communication. • A short ping will be sent to the docking station. • The software will continue to send pings every second for 20 seconds. • After 20 seconds elapse with no reply ping, the connection times out and PEMA could not

be found message is displayed. The user may then retry. • If the ping is returned, the connection is established. • Connected to PEMA - Owned by status of the connection changes. • Menu options (and toolbar options) will change in context to the new connection made. • Pings will be sent to the PEMA every 2 seconds while the serial bus is idle. • If a reply ping is not returned from the PEMA

o Connection is assumed to be lost. o Connection to PEMA Lost message will be sent to user. o The user will be allowed to correct the problem. o If the user decides not to correct the lost connection, the software will reset to an

unconnected state. Download from PEMA Device: • The user will be allowed to download scheduling and medication data once a connection has

been established. • A medication count request will be sent to the PEMA. • Each medication record will be requested in sequence. • The data records will be decoded and stored internally in the program for later use. • Modified select-repeat (stop-and-wait) protocol will be used to ensure reliable data transfer. Upload to PEMA Device: • The user will be able to initiate the upload of a new set of medication schedules from the

Programmer. • A medication count will be sent to the PEMA device. • Each medication record will be sent in sequence to the device. • Modified select-repeat protocol will be used to ensure reliable data transfer.

Figure 15. The Programmers schedule Review Current Schedule: • The user can review the current medication schedule after the data has been downloaded from

the device.

27

• This functionality will help insure correct scheduling and will reduce liability for the PEMA programmer.

• The schedule layout will be determined at a later time. Add Medication: • Adding medications to the current schedule will be permitted at any time provided the

record limit has not been reached. • A small dialog will be displayed, requesting specific information about the new medication:

o Medicine Name o Dosage o Frequency of dosages o Comments/warnings o Times desired to be alerted

• The user will be allowed to exit this dialog by using OK/CANCEL buttons. • Pressing OK will prompt the user to confirm the entered data (the default option will be

CANCEL). • Confirmation causes the record to be added to the internal memory structure. • All views of the schedule data will be updated to reflect the change. • Canceling the prompt brings the user back to their location before the request. Modify Medication/Schedule: • The users will have the ability to make changes to any part of the schedule or medicine data. • A list will be displayed with all medicine names, dosages, and frequencies. • A second (parallel) list will show all currently scheduled medication times. • User will be allowed to highlight the desired list item and select the modify button (or modify

menu item). • A small dialog box will display the collected data for the selected record and the user will be

able to make changes directly to this data. • The user will be prompted to confirm the modification of the data (default option will be

CANCEL). • The users confirmation causes the record to be updated with the information provided in the

dialog. • All views of the schedule data will be updated to reflect the change. • Canceling the prompt brings the user back to their location before the request. Remove Medication: • At any time, the user will be allowed to remove medication records (schedules) from the

inventory. • A summary list will be displayed with medicine name, dosage, and frequency. • The user will be allowed to highlight the desired medication and select the remove button (or

remove menu item). • The user will be prompted to confirm the deletion of the data (default option will be

CANCEL). • If the user confirms the deletion, the record is purged from the memory. • All views of the schedule data will be updated to reflect the change. • Canceling the prompt brings the user back to their location before the deletion request. Design Constraints

28

Below is the list of design constraints that will affect the commercial version design and construction. Each of these constraints accompany a set of trade-offs that will have to be decided once the final product is completed. • Total cost of the PEMA device to consumers will not exceed $100, with a target price of $50.

Functionality may need to be cut to bring the device within this price range. • Print on the display should be large enough to read, but small enough not to impact the

minimum size requirements stated above. • Power requirements will be managed to allow for a minimum of three (3) months useable life

per AA battery (alkaline). • The PEMA will need to be upgradeable to allow user-interface improvements and possible

service patches as they become necessary. • The LCD display will be the limiting factor on the effective temperature range. Measurable Milestones Below is the list of milestones that must be achieved for this project to be considered successful. The milestones have been broken down into two groups: 1) The PEMA device, and 2) the PEMA Programmer Software. PEMA Device: • Communications protocol to the Programmer The protocol to be used to communicate

to the PEMA Programmer will be fully documented. This specification will be compatible with the software protocol and cover data transmission rates, data encoding, data decoding, error correction, acknowledgments, as well as timing information. Completion of this milestone will be determined by verifying all communication events are covered (e.g. faulty data lines).

• Data storage scheme Documented specifications will be developed describing the scheme of data encoding and storage within the RAM of the PEMA. These specifications should allow storage of worst-case data sets within the maximum allowed storage capacity. Verification that the scheme will meet tight storage requirements will finish this milestone.

• Low-fidelity screen shots Screen shots will be produced using marker boards and then captured by hand onto paper. Drawings will include all menus, messages, prompts, labels, lists, etc. that will allow complete operation of all specified functionality. Validation and verification of screens (allowing all desired functionality) will complete this milestone.

• High-fidelity screen shots The low-fidelity screens will be migrated to physical screens on the LCD. This milestone will be complete once the screens had been built and verified for consistency against the low-fis.

• Software communication The communication protocol specifications will be implemented in the device logic. Test harnesses will be used to emulate the Configuration Software during testing. Successful testing of all communication possibilities (including lost packets, dropped connections, faulty transmission lines, etc.) will complete this milestone.

Programmer Software: • Communications protocol with PEMA The protocol to be used to communicate to the

PEMA will be fully documented. This spec will be compatible with device protocol and cover data transmission rates, data encoding, data decoding, error correction,

29

acknowledgments, as well as timing information. Completion of this milestone will be determined by verifying all communication events are covered (e.g lost packets).

• Low-fidelity screen shots Screen shots will be produced using marker boards and then captured by hand onto paper. Drawings will include all buttons, menus, labels, lists, etc. that allow complete operation of all specified functionality. Validation and verification of screens (allowing all desired functionality) will complete this milestone.

• High-fidelity screen shots The low-fidelity screens will be migrated to physical screens on the target platforms. This milestone will be complete once the screens have been built and verified for consistency against the low-fis.

• User interface compliance Each operating system publishes specifications on proper screen layout and design. Verification of screens against the standards for each OS will complete this milestone.

• User Interface Freeze Once all the screen have been constructed and the final touches have been made to the interface, a freeze will mark the end of all work done to the layout and design.

• Successful PEMA communication The communication protocol specifications will be implemented in the PEMA Programmer. Test harnesses will be used to emulate the PEMA device during testing. Successful testing of all communication possibilities (including lost packets, dropped connections, faulty transmission lines, and so on) will complete this milestone.

30

End-Product Description Product Description The Personal Electronic Medical Assistant acts as a portable reminder for people to take their medication. Easily programmed by a doctor or pharmacist, the PEMA can store information for several medications. Over the course of seven-day cycles, the PEMA alerts the user (by an alarm or light) when to take medication as well as specify how much (by a LCD display).

Approach and Design Technical Approaches Below is a list of the major decisions that have been made about the commercial version along with the alternatives considered and reasoning for choosing the listed item: Six Buttons: The underlying comment both doctors and patients had during the interviews was to keep the device simple. In order to deliver on this request, it was decided that no more than 6 buttons (on/off, select, and up/down/left/right navigation buttons) would be used. Even though there is no direct numerical input buttons, this feature could easily be implemented with these six buttons. No vital information: The recoding of vital information was being considered for a very long time during this design phase but, after the surveys and interviews, it appears that it is not a good tradeoff. There seems to be few people that need to record vital information on a regular basis. Of the people that do, there are plenty of good systems already in place to help them with this process. In addition, the increased complexity and additional hardware required to implement this feature would dramatically increase the price and miss the keep it simple and cheap goal. On the other hand, another senior design team will be adding this functionality through a similar project that should be completed by December of 2000. Weekly schedules: Again, during the surveys and interviews, it seems that a large percentage of medications fall into weekly schedules. Medications outside of the weekly scheduling are probably not as important and usually taken on an as needed basis. Discrete schedule times: After many long debates, it was decided that only discrete times (8:00, 3:15p) will be allowed when scheduling medication reminders. The other alternative was to base all medication

31

reminders on the users meal schedule, but this proved to be highly complex and not developed enough to implement in the first version of the PEMA. ASIC Microcontroller: The use of ASIC chips will probably increase the total unit price, but this will allow miniaturization of the PEMA device, which was highly requested during the surveys. Although the May 00-01 team will not implement this miniaturization, it will be recommended for later work. Software in Java: The use of Java will allow development for almost all major platforms, which will make the product available to the largest possible audience. However, for the initial simulation and prototype, only Visual Basic and C were used (VB for the simulation and Programmer Software and C for the PEMA device). Technical Design

This section will outline the differences and purposes of the commercial version, the simulation, and the prototype. The PEMA System Commercial Version: This document so far has been a description of the PEMA Systems commercial version. This product is what will be delivered to the users and consists of 2 components: 1) the PEMA device, and 2) the Programmer Software. However, designing and building this product was always known to be out of the scope of the May 00-01 project. Therefore, the May 00-01 set out to build a prototype of the PEMA which would relax some of the limitations and constraints of the commercial version and instead serve to represent the functionality of the PEMA device. Throughout the course of this project, several brainstorming sessions resulted in numerous ideas for capabilities of the PEMA System. Several of these have since been rejected by the team, but deserve mentioning here

May 00-01 Commercial Version Rejections: Reorder reminder: The surveys determined that this it is not very beneficial. Every time the user takes their medication they can see how many pills they have left. Hence, they know when to reorder. Doctors comments into the device (during patient visits): This function would serve as a sort of scratch pad for doctors to record their thoughts during a particular visit. The doctors survey pointed out that most doctors still prefer writing in a patients file (and its easier, too). Multiple users: Almost all the doctors said that this would not be useful. The device is ineffective if one user has it and the other isnt around.

32

Drug interactions: A few of the doctors pointed out that drug interactions are already listed on the bottle and also on the medication information pamphlet. Pharmacy involvement: The May0001 design group decided that this would not be beneficial since the only involvement the pharmacist has is filling prescriptions. The pharmacist has no vested interest in using this device. In fact, it would only be a hassle and burden for them to have to program it. Finally, to minimize errors, input into the device should come from one source only: the doctors office.

• • • • Even before the prototype could be built, a preliminary step was needed to aid the design process. This step was developing the software simulation described below. The Software Simulation: The primary purpose of creating a software simulation for the PEMA device was to drive the design for the prototype. This allowed the team to make crucial design decisions and immediately see how they would change the end product. The simulation also serves as an easy and portable method of illustrating a virtual commercial version. The simulation is built solely in Visual Basic and designed to run on any Windows PC. Screen shots from the simulation were used repeatedly in the Design Requirements section, but another shot of the opening screen is shown below in Figure 16.

Figure 16. The Software Simulation (Initial Screen)

The software simulation aided design of the PEMA prototype by raising many questions and trade-offs that needed to be resolved. It also stimulated discussion and decisions about output format and requirements. Furthermore, the code written for the simulation used the same logic as the code for the prototype, so most of the coding for the prototype was simply converting Visual Basic to C. Finally, the simulation allowed the team to see firsthand what an alert would look like, how it would be acknowledged, and what options would be given with the alert.

33

The software simulation played a crucial part in the development and design of the PEMA prototype. On the other hand, it wasnt originally anticipated as necessary, and therefore was left out of the Milestones section. Nevertheless, creating and optimizing the PEMA software simulation was one of the major accomplishments of the May 00-01 senior design team. The Prototype: As described in the design report, the main objective of this project is to create a working prototype to illustrate the functionality of the PEMA device. The functionality of this prototype is almost exactly the same as both the commercial version and the simulation. The hardware design, on the other hand, is substantially different. Due to time, money, and knowledge limitations, the components used to build the prototype are not the same components that will be used for the commercial version. Functional Change in the Prototype: The Alert Limit (see Device Operation under Design Requirements) is NOT implemented in the prototype. The prototype exists as a presentation tool and a proof of concept, and in both cases a snooze will never be needed for long enough to reach a medications alert limit. Therefore, the prototype will have no limits on how long the alert screen can remain active or how many times the snooze can be implemented. Physical Changes in the Prototype: The prototype is considerably larger than the anticipated commercial version mostly because ASIC miniaturization is not implemented. Furthermore, to minimize the cost to the team, only surplus parts and readily available parts were used. This, too, increases the size of the prototype. In addition, the prototype is not battery operated. A battery implementation was considered and even tested; however, due to time constraints this implementation was eliminated from the final design. The PEMA Prototype Design: The design of the prototype is illustrated in Figure 17.

34

Figure 17. The Prototype Design.

The hardware consists of the following components: Microcontroller: Adapt-11C75DXE Module Obtained from: Technological Arts Web site: http://www.technological-arts.com Serial LCD Display: LKD204-25 (4 x 20) Note: This includes the input buttons. Obtained from: Matrix Orbital Corporation Web site: http://www.matrix-orbital.com Optocoupler: PS2501-4 Note: This is used for the software controlled hardware switch between the serial line and the

display. Obtained from: Digikey Corp. Web site: http://www.digikey.com Real Time Clock MC68HC68T1 Obtained from: Motorola Web site: http://www.motorola.com Miscellaneous: Resistors Capacitors Crystal Buzzer

• • • • The software for the PEMA was compiled using the following compiler:

35

C Compiler ICC11 v5 Obtained from: ImageCraft Web site: http://www.imagecraft.com The Adapt-11 module is programmed in the C language using the above compiler. This step involved converting all of the Visual Basic simulation software to C and then transforming its functionality to interface with the prototype hardware components. Testing Description A complication occurred in the project when a real time clock could not be found to implement the prototype (see Risks and Risk Management as well as Project Schedule). This delay put the team over a month behind schedule in the second semester. As a result, the prototype will not be completed until after this document is turned in, and testing will be reduced to a minimum. However, two crucial tests were made prior to the hardware prototype being developed. These are listed below: The Software Simulation Test: Purpose and Method: In many ways, creating the software simulation was a test in itself. Before the simulation, the team was unsure about the extent and complexity of programming this device. Also, the simulation allowed the team to test the design and implementation of the device in a simulated environment. Results: The Simulation not only proved that the team could program this device, but it served as the backbone for our future prototype code. Also, coding the simulation raised questions of issues we hadnt thought of yet (e.g. How does the user initiate the download of new information?) as well as issues we hadnt completely resolved yet (e.g. How are we going to fit all of this information on a small, portable screen?). Overall, the simulation test was the most crucial test we could have performed before actually building the device. The C Code Test: Purpose and Method: Having created the Simulation, the code needed to be converted to C. Once converted, however, it couldnt be tested with the prototype because the hardware components werent integrated yet. Therefore, the team implemented a second test using a DOS window on a PC. After compiling the newly converted C code, the team redirected the output and input so that a regular PCs DOS window could act as the PEMA device. Results: Although not that different than the previous software simulation, this simulation verified that the C code was converted properly and worked as planned. Functionality and Reliability Tests: Purpose and Method: Once the prototype is completed, the team will verify that it works properly. First and foremost, this test consists of practicing the demo that will be presented to the Industrial Review Panel. The device needs to operate over a prolonged period of time in a stable

36

condition. It must download prescription information for the Programmer. Finally, it must sufficiently alert the user at the proper time and allow for the user to either turn it off or snooze. Results: The results for these tests are yet to be determined.

Table 2. Sample Testing Form Test Case Person Testing Pass/Fail Fault Description Severity Test 1 Test Case 1 Test Case 2 Test Case 3 Risks and Risk Management The main risks that we anticipated at the beginning of this project are as follows:

1) Loss of team member Redefine scope of project to coincide with new timeline after loss of team member.

2) Failure of technical approaches If time is allowable, change our technical approaches. 3) Failure of tests Redesign device or change product specification. 4) Inadequate funding of project Seek outside sources for funding. 5) Inadequate time management Increase the hours working on the project or push back

the deadline. 6) Schedule conflicts for meetings within group or client/advisor Reevaluate our time

effectiveness for meetings to cut down on meetings. 7) Lack of understanding the employed technology Consult with a specialist or a professor

in required field. One risk that we didnt anticipate was not being able to find a certain hardware component. This is exactly what happened with the real time clock, and as a result, the teams schedule was pushed back by about a month. Recommendations for Additional Work For recommendations for additional work, please see the section under Closure Materials entitled Recommendations for Additional Work.

37

Budgets and Schedule Financial Budget Below is an itemized list of expenses expected and spent during the course of this project.

Table 3. Estimated project expenses

Item Original Estimate Revised Estimate Actual Cost Equipment and Parts $150 $250 $13 Surveying costs $20 $30 $10 Poster $30 $50 $50 Total $330 $330 $78

The poster was done on campus and, along with the glue and backing, cost $50. Originally the team thought that they might need to make some long-distance phone calls with the surveys, but all the surveys were local. The $10 came from stamps, envelopes, and gas (traveling to the locations). Brett already owned most of the hardware equipment the team needed to build the prototype. However, he did spend $13 on the real-time clock. Personnel Budget Table 4 illustrates the original and revised estimates of personal efforts as well as the actual effort spent by each team member.

Table 4. Current and project personal efforts

Personnel Original Estimate Revised Estimate Actual Effort Brian Gunst 125 hrs 159 hrs 140 Jeff Lanning 125 hrs 205 hrs 283 Vinay Tauro 125 hrs 143 hrs 129 Brett Utesch 125 hrs 206 hrs 225 Totals 500 hrs 713 hrs 777 hrs

The revised estimate was made at the end of the first semester. It was calculated by each team member taking their first semester hours (Brian 79; Jeff 95; Vinay 68; Brett 86) and adding on how many hours they thought they would work the second semester. Jeff outworked everyone and completely designed the Software Simulation in Visual Basic. Brett spent a substantial amount of time buying and integrating the hardware components. Vinay and Brian both contributed with the design, but their major work was with preparing the presentation and final report. Project Schedule The teams schedule can be found in Appendix A. Comments for each semester are as follows:

38

First Semester: The May00-01 Design Team spent an unexpectedly large amount of time developing and conducting surveys and interviews for doctors and patients. This caused a shift in the allocation of time and rushed the poster and design report more than was desired. Furthermore, the design at the end of the first semester was much more vague than it should have been. However, the information gathered during the interviews proved to give invaluable insight into the project and helped drive a much higher quality product. Second Semester: The second semester got off to a great start with Jeff creating most of the Software Simulation over Christmas Break. However, it was a few weeks before the team really started meeting consistently, and by that time, the class presentation was around the corner on February 8. It was nice to get the presentation over with early, but by the time it was over a month of the semester was gone and the team hadnt made any progress on our prototype. Around the middle of February, the team finally confirmed all aspects of the prototypes design and functionality. This was something that should have been done the previous semester, but was postponed due to the extra time spent surveying and interviewing. Shortly thereafter, the code was converted to C and things were progressing fine until the team couldnt get a hold of a real time clock. Most of March was spent doing little other than looking for a real time clock. As soon as April hit, the team realized the impending deadlines and started working diligently again. Everything but the clock was assembled on the hardware, and Vinay and Brian started compiling the final report. Hopefully, by the Industrial Review Presentation, the prototype will be functional and ready to demonstrate.

39

Closure Materials Evaluation of Project Success Looking back on the effort of the previous two semesters, it is possible to see how far the teams idea has come. The team set milestones to gauge the success of the project, and based on these milestones, it is possible for this team to now consider the effort a success. From an expense point-of-view, the team set ourselves a budget of $320 and managed to complete the project with only $68 less than a fourth of the original estimate. From a time, or man-hour based perspective, the team did go over the original estimate. The team had estimated that the project would be complete in about 500 man-hours. But, due to unforeseen circumstances, more hours were put into the project. For one, the team did not anticipate that the surveying of potential users and interviewing of doctors would take quite as long as it did. Also, the team had not originally planned to create a software-based proof-of-concept, and a lot of man-hours were devoted to this because of its inherent value. The simulation was able to model the behavior of a device that did not exist, and it helped the team conceptualize what worked and what needed to be changed. A positive way of looking at the project timeline was that the original estimate was conservative enough to still give the team enough time to finish the project despite the setbacks. As far as the physical device goes, the team ordered and assembled the hardware parts, and got the buttons and clock working. A communications protocol was defined that would be the link between the device and the scheduling software. For the scheduling software, the other half of the protocol was defined, and by the time of the Industrial Review, a sufficient user interface should be created. Based on all the above factors, the team considers that the project was a success. Commercialization 1. Cost With an application specific integrated circuit (ASIC), as well as economics of scale

(buying parts at wholesale prices in large quantities), the team foresees that this device could be fully assembled for under $50.

2. Street-price This design team believes that a full-fledged end product could sell in the $50-$100 range, but would probably be closer to the lower end of that range.

3. The following is the potential market for the product.

• Independent seniors with an active and dynamic lifestyle: this group definitely has a need for this device. As people get older, their medications typically increase, but an active and dynamic lifestyle often makes taking the medications on a regular basis difficult. Because this group doesnt suffer from dementia or substantial memory loss, they can learn to use the PEMA quickly and correctly. Also, this group is likely to be willing to purchase the PEMA because they are much more aware of their health than younger generations.

40

• Patients with multiple medications that arent seniors: For the most part, this group is well aware of computers and electronic devices, so they could learn to operate the PEMA with relative ease. However, three observations make this group a secondary target to the active seniors:

o Because they are younger and still working, they may not be as health conscious

as the seniors. o Because they are younger, they may be less likely to admit their need for such a

device. Even if they do realize they need it, they may be kept from purchasing it because they dont want others to know about their medications.

o The number of 40 to 60 year olds that have multiple medications is much less than the number of 60+ year olds with multiple medications. That means this target group is probably much smaller than the active seniors.

• Caretaker of a spouse, relative, or close friend: this is a unique situation where the actual

patient wouldnt be the one carrying the device. Above, non-resident caretakers were ruled out because they arent with the patient at all times, but in the case of a spouse or similar type of caretaker, the caretaker is always near the patient. Although this may be a smaller target group than active seniors, the device would be very helpful in simplifying the caretakers life.

From the above observations, independent seniors with dynamic and active lifestyles are the primary market group targeted by the PEMAS. Recommendations for Additional Work The team has concluded that the following areas provide significant opportunities for future work: 1. Migration of the design to an application specific integrated circuit (ASIC):

The teams effort was aimed primarily at developing a prototype to prove a concept and demonstrate its functionality, and since this has been achieved, the next step towards commercialization would be miniaturization through development of an ASIC version of the device.

2. Data-logging capability: The teams goal was to make a basic and simple prototype that could be used by anyone. However, as users become more familiar with technology, a more complex version supporting the recording of user-entered data could be developed.

3. Speech-capability A final recommendation to make the device even more accessible would be to develop a device that would be fully operational via speech.

Lessons Learned* *Due to the personal nature of this section, it will be written in first person. Over the course of the last two semesters, this design team has had many experiences with both beneficial and unfavorable outcomes. In this section, we will try and summarize some of the experiences, and what we learned from them.

41

What Went Well: One very positive aspect of the project was the fact that we had regular weekly meetings with the clients. This served to help us stay in touch with our clients regarding their ideas and requirements, as well as to keep them up-to-date on the progress of our effort. Another positive aspect was the surveying of possible end-users of the device. At the beginning of the project, the team brainstormed to come up with ideas of what we thought such a device should offer in terms of functionality and ease-of-use. But, once we had surveyed some doctors and potential users of the device, we not only saw that some of our ideas were unnecessary, but also probably not very marketable. This helped us tailor our product to its users needs. What Did Not Go Well: While the survey was invaluable in terms of providing us information, a negative facet was that we spent too much time conducting it. A consequence of this was that we did not define the scope of our project early enough. Therefore, important design decisions were not made as early as they could have been and should have been. Technical Knowledge Gained: Thanks to the senior design course, this team has gained a greater degree of understanding in various aspects of a design process. Our technical writing ability has increased, as has our capability to work in a team environment. Also, we had already learned in previous course labs how to get integrate software and hardware, but never to the extent we did in this project. Above all, this team got a strong impression of how things operate in a real world environment. Non-technical Knowledge Gained: We realized that the only way our project was going to have a chance at success was if we utilized the strengths within our team. We decided that each member should take ownership of a part of the project, and so we divided up into sub-teams one to focus on the software side and the other to tackle the hardware side. In the end, parallel work has made project success possible.

42

Project Team Information

Table 5. Personal Team Information

Brian Gunst Electrical Engineer

219 S. Sherman #7 Ames, IA 50010 (515) 233-8931 bgunst@iastate.edu

Jeff Lanning Computer Engineer

212 Hayward Ave. #303 Ames, IA 50014 (515) 268-0998 lanningj@iastate.edu

Vinay Tauro Computer Engineer

Friley 3443 Spinney Ames, IA 50012 (515) 572-5199 vtauro@iastate.edu

Brett Utesch Computer Engineer

611 Meadow Pl. Ames, IA 50010 (515) 233-9767 brettu@iastate.edu

John Lamont Advisor

1005 Idaho Ave.Ames, IA 50014 (515) 292-5541 jwlamont@iastate.edu

Ralph Patterson Advisor

1807 24th St.Ames, IA 50010 (515) 232-9933 repiii@iastate.edu

Herb Harmison Consultant

2692 Meadow Glen Rd. Ames, IA 50014 (515) 292-7059 herbh@iastate.edu

Summary Many people have medical conditions that require multiple prescriptions or prolonged usage of medication. Failure to take these medications regularly can have significant health consequences. The Personal Electronic Medical Assistant a small, portable, and reliable devicewill free up peoples lives by reminding them to take their medication. Therefore, instead of always watching the clock or worrying about the next medication they need to take, PEMA users can freely enjoy all activities and rely on their PEMA to alert them at the proper times. The May 00-01 team surveyed doctors and health care workers to determine how to best design the PEMA device. After compiling the survey results, the team created a design, and then used that design to make a Software Simulation of the commercial end product. From there the team designed and built a prototype to demonstrate the functionality of the PEMA device as well as its accompanying PEMA Programmer Software.

43

References Below is a list of resources used while constructing this document:

• Motorola Pager (image) • Motorola Pager Docs (LCD images) • Duracell AA Battery (image) • Palm Pilot Cradle (image) • Registration Manager Schedule (image)

44

Appendix A: Project Schedule Gantt Chart

45

Appendix B: Summary of Doctor Surveys

The following is a compilation of several doctor surveys conducted between November 4 and November 15, 1999. All quantitative answers were selected to best represent the doctors as a whole.

Sometimes, only one or two doctors made a statement or point. Those cases are noted to indicate how many doctors mentioned that particular point (e.g. 2 Drs.). If no quantitative answer is given, then the survey data was incomplete or inconclusive.

Furthermore, additional ideas or comments by the doctors are given in regular text. Team input, however, is always given in italics. The doctors included in this survey are the following: Dr. Tom Johnson, Dr. Lynn Theesfield, Dr. Cosette Scallon, Dr. Lowell Bond, Dr. Mark Blaedel, and Dr. Louis Banitt.

1. Estimate the shortest, typical and longest times between which a patient is scheduled to take a

medication. Please specify the unit of time involved (hour, day, etc.) • Shortest: ______1 hour_________ • Typical: ______6 hours_________ • Longest: __Once a week________

2. What is the largest number of different medications that a single patient might be given?

____ 20_________

3. What types of medication schedules should be included?

Schedule Examples Uncommon Very Common Take 2 tablets every 4 hours 1 2 3 4 5 6 Take 2 tablets at specific times

1 2 3 4 5 6

Take 2 tablets at breakfast 1 2 3 4 5 6 Take 2 tablets at bedtime 1 2 3 4 5 6 Other (Please specify): 1

1 2 3 4 5 6

2

1 2 3 4 5 6

3

1 2 3 4 5 6

4. Should the PEMAS be able to store vital information for later retrieval via the personal

computer?

Not Beneficial Very Beneficial 1 2 3 4 5 6

46

5. If so, which of the following would be beneficial?

Vital Information Not Beneficial Very Beneficial Blood pressure 1 2 3 4 5 6 Pulse rate 1 2 3 4 5 6 Temperature 1 2 3 4 5 6 Blood sugar level 1 2 3 4 5 * 6 Other (Please specify): 1. Weight (2 Drs.)

1 2 3 4 5 6

2. Pain or side effects (2 Drs.)

1 2 3 4 5 6

3. Fluids (1 Dr.)

1 2 3 4 5 6

*Blood sugar was considered beneficial, but an existing system is already in place. Patients use a device to both take their blood sugar as well as record the reading. Banitt (verified by patient interviews)

6. Similarly, please provide information regarding the items listed in question 5. Please specify

the unit of time involved (hour, day, week, month, etc.)

Vital Information

How often taken?

Recording period length

Blood pressure __daily____ ___________ Pulse rate ___

daily_____ ___________

Temperature ___________ ___________ Blood sugar level _ 4 xs /

day__ ___________

Other (Please specify): ___________ ___________ 1. Weight

___daily ___ ___________

2

___________ ___________

3

___________ ___________

Note: The responses to this question were inconsistent and vague.

7. Should the PEMAS be able to include special instructions to the patient?

Not Beneficial Very Beneficial 1 2 3 4 5 6

47

8. If so, please indicate which of the following would be beneficial?

Special Instructions Not Beneficial Very Beneficial Food restrictions 1 2 3 4 5 6 Alcohol restrictions 1 2 3 4 5 6 Vehicle operation restrictions 1 2 3 4 5 6 Possible reaction to other drugs

1 2 3 4 5 6

Adverse reaction to medication may occur

1 2 3 4 5 6

The doctors suggested limiting the amount of output to include only the necessities. These

include: 1. When to take the medication (e.g. with food, before a meal, etc.) 2. Extreme precautions that should be noted every time the medication is

taken (e.g. certain medications absolutely cannot be taken with alcohol in the blood stream or the patient will immediately get sick).

9. Should the PEMAS be able to store information concerning if a user took his/her medication

as scheduled?

Not Beneficial Very Beneficial 1 2 3 4 5 6

Notes:

1. Will the patient be honest?

10. If so, please indicate which of the following would be beneficial?

Medication Tracking Not Beneficial Very Beneficial Time since last eaten 1 2 3 4 5 6 Time since last exercised 1 2 3 4 5 6 Adverse reactions to medication

1 2 3 4 5 6

Other (Please specify): 1. Missed dose.

1 2 3 4 5 6

11. Which of the following types of output would be beneficial to the patient?

Output Capabilities Not Beneficial Very Beneficial Audio alarm indicator 1 2 3 4 5 6 Light alarm indicator 1 2 3 4 5 6 Vibration alarm indicator 1 2 3 4 5 6 Visual display of information 1 2 3 4 5 6 Speech instructions 1 2 3 4 5 6 Braille display of information 1 2 3 4 5 6 Other (Please specify):

48

12. Would it be beneficial for the PEMAS to be able to track medication usage and remind the patient to

Capability Not Beneficial Very Beneficial Reorder the prescription from the pharmacy

1 2 3 4 5 6

Contact doctor to renew/extend the prescription

1 2 3 4 5 6

The patients can see when they need to reorder.

13. How beneficial would the PEMAS be for the following uses?

Patient Location Not Beneficial Very Beneficial At home 1 2 3 4 5 6 On vacation 1 2 3 4 5 6 In nursing home 1 2 3 4 5 6 In hospital 1 2 3 4 5 6 Other (Please specify): 1. Assisted Living Facility (1 Dr.)

1 2 3 4 5 6

2. Work (1 Dr.) 1 2 3 4 5 6

14. Should the same PEMAS (handheld device) be able to be used by multiple patients, husband and wife for example? If so, what is the maximum number of patients that should be able to use the PEMAS simultaneously? __ 2, and only if spouse_____ This is a no-brainer. No two people can share this device unless they are always together. Theesfield

15. What is the maximum number of patients that the PEMAS software for the personal computer should be capable of handling? __________

This question got Inconsistent and possibly confused responses. In general, the responses were

as many as possible.

16. If the patient were required to enter data, for example to track vital information, which of the following would be beneficial?

Patient Input Types Not Beneficial Very Beneficial Numbers only (0-9) 1 2 3 4 5 6 Letters only (a-z) 1 2 3 4 5 6 Both numbers and letters 1 2 3 4 5 6 Select from menu 1 2 3 4 5 6

Keep it simple!

The doctors seemed to think that either an alphanumeric pad or a menu-driven approach would be sufficient. The patients, however, may give more insight.

49

17. What are the maximum periods of time to be included?

• Longest schedule to be entered capability: __________ • Longest recording period to be made capability: __________ • Longest storage period capability between visits to doctor 's office: 1 year

Almost every doctor was confused by this question.

18. A medical professional might perform the following functions using the PEMAS software. How beneficial might they be?

Software Functions Not Beneficial Very Beneficial Enter schedule into patient's device

1 2 3 4 5 6

Retrieve information entered by patient

1 2 3 4 5 6

Include a historical record of patient's schedules and patient's entered information

1 2 3 4 5 6

Plot/graph selected patient data

1 2 3 4 5 6

Print the patient's historical record for use during office visit

1 2 3 4 5 6

Be able to remotely access patient's data base via a computer in an examining room

1 2 3 4 5 6

Be able to remotely access patient's data base via a computer from an external location (a hospital room)

1 2 3 4 5 6

Allow the doctor's comments to be added following a patient's visit to the office

1 2 3 4 5 6

Allow the doctor's comments to be added during a patient's visit to the office

1 2 3 4 5 6

Note: Doctors do not want to put comments into this device. In fact, they probably wont interact

with it at all (their staff will; see next section). An issue that several doctors brought up dealing with patients historical records is patient confidentiality. In other words, should a doctor have full access to another doctors information in a patients PEMAS?

50

Appendix C: Doctor Interview Summary Unless otherwise mentioned, all comments below are the teams summary of the doctors responses.

1. For our initial planning, we have assumed that a member of the doctor's staff would be

responsible for entering the schedule in the patient's device via a personal computer software package. Similarly, we have assumed that this same staff member would retrieve any information entered by patient. Would you or your staff be willing to perform this function?

• The doctors staff will program the device.

2. Many patients have more than one doctor. In these cases, should one location be responsible for interfacing with the patient's device to insure that one current schedule is not overwritten by another current schedule? If so, how should the coordination be handled? Should one person be responsible for all schedules entered in a patient's device? • Multiple doctors must be able to use the device without having to

collaborate with other doctors. • This brings up the security issue. Perhaps each doctor should be able to

write to the device but only read their own information.

3. How should possible drug interactions be handled? If they were to be included, would they be the responsibility of the doctor prescribing the medication or some other party such as a pharmacist? How should such information be entered and displayed? • Currently, the doctors perform this role, and the pharmacists act as a

safety net to get anything that slips by the doctor. Therefore, interactions between prescription medications are already taken care of.

• Important interactions with a non-prescription drug could be noted (see #8 of the questionnaire).

• A couple of doctors mentioned the device acting as an interaction database. It would store all known and potentially harmful drug interactions and would then alert the doctor when two drugs are entered that conflict negatively. This is a great function, but it is outside the scope of this projects objective. Furthermore, there are plenty of devices, books, web pages, etc. that already perform this function.

4. What role, if any, should the pharmacist have in the use of this system?

• None

5. Should we limit the patient's input capability in any way? For example, should it be restricted to (a) yes/no button, (b) a numerical keypad (like a telephone), (c) a menu selection process, or (d) a complete keyboard? • Keep it simple yet functional.

6. What types of user's handicaps (blind, deaf, etc.) should we consider when designing this system? Are there handicaps that we should not consider? We are concerned that the device will fail if it tries to be everything to everyone.

51

• Lights are unnecessary (no one will be looking at this device all of the time).

• Focus on the elderly that arent in nursing homes or hospitals (where current systems are already being used to administer medication).

7. Are you aware of any medical regulations or liabilities that we should be aware of in

designing a system of this type? • Keep it simple. • Put a disclaimer on it: "This is only an aid and not a replacement for

personal responsibility."

8. What are the strengths and weaknesses of our proposed system? What do you believe would be required to make such a system a commercial success? • Most doctor input on this question was either redundant or included below

under question #10.

9. Are you aware of any systems similar to the PEMAS? If so, how do they operate and what are their strengths and weaknesses? • No, other than the blood sugar monitor (Banitt).

10. Do you have any other comments or suggestions? More specifically, what haven't we thought of or taken into consideration? • The device should include a recall button. This way, the patient can turn

the alarm off without erasing the alert from memory. Later, when the patient wants to take the medication, he/she can recall which medication it was and record that it is being taken late.

• The device could include some sort of movement or temperature sensor that will allow it to know whether it is being worn or not. If worn, then its default alarm could be a vibration. Otherwise, its default would be an audible alert.

52

Appendix D: Patient Interview Summary

The following is a compilation of several patient surveys conducted on November 22, 1999. The surveys were given to patients at Heartland Senior Services. This facility is only a type of day care for seniors and not a residence for seniors.

Two types of groups are listed below. The first, described as independent seniors with regimented schedules, were represented by four ladies: Francis Ballard, Lavon Quam, Lilian Cowhick, and Diana.

The second groups patients cancelled, but their supervisor, Caroline Hurst, represented them with some helpful information. This group is described as dependent seniors with variable degrees of dementia (including memory loss). Although they dont live in a nursing home, they do require the assistance of a caretaker. Independent Seniors with Regimented Schedules These seniors live independently but spend their days at Heartland Senior Services. Their schedules are static. In other words, they wake up at the same time every day, eat breakfast at the same time every day, etc. Below is a few of the main points they made: 1. They all knew the medical names of each of their medications (ranging from 4 to 14). They

also knew the size, color, and even sometimes the milligrams of each medication. 2. When asked, none of them were personally interested in this device. The following all

seemed to play a factor: a) Because their schedules are regimented, taking their medications quickly becomes a habit and

is easy to remember. They very seldom forget to take a medication. b) They have been taking some of their mediations for several months or even years. c) They already have simple aids like weekly and daily pillboxes as well as lists of all their

medications. These lists, however, arent usually used as reminders because the patients already memorized their medications (but see #6).

d) When asked, none of them have any experience with computers or electronics. Only Diana expressed any interest in trying something new.

3. Most of their medications were related to meals (e.g. before or after breakfast). Only a few were time or interval related (e.g. once every 24 hours).

4. Some medications were over the counter but still recommended or prescribed by the doctor.

5. None of them saw any value in storing vital information. Diana, however, takes her blood sugar several times a day, but she already has a device that records and stores the information. The device has one button besides its on/off switch.

6. The patients carried lists of their medications for emergencies (e.g. an Emergency Medical Team in an ambulance on the way to the hospital). This could add a new component to the device: a quick list function for emergency personnel.

7. They all seemed to be able to read standard print.

53

Depende