Advanced Reporting Tools For Personal Medical Devices:

Medical History Vault

 

 

Interface Design Report

November 29th, 2005

 

 

Team PerMed

Andrew Bouis              bouisa*NO_SPAM*@wam.umd.edu

Stanley Lam                 sjlam*NO_SPAM*@umd.edu

Obaid Siddiqui             obaid1982*NO_SPAM*@yahoo.com

Mark Slowikowski       mslowiko*NO_SPAM*@umd.edu



Implemented Interface

http://mhv.daft.cc (Best viewed using FireFox)

 


This Report in Word Document Format

http://mhv.daft.cc/report/final3.doc

 

Classroom Presentation PowerPoint Slides

http://mhv.daft.cc/report/finalPresentation.ppt

 


Table of Contents

 

  1. Abstract
  2. Credits
  3. Background
  4. Existing Systems
  5. Academic Studies
  6. Overview of Approach and Solution
  7. Interface Walkthrough
  8. Low Fidelity Prototype Development
  9. Usability Testing
  10. Test Results
  11. Conclusion
  12. Future Considerations
  13. Acknowledgements
  14. References
  15. Appendix

 

 



Abstract

 

The primary objective of this project is to design a system that will capture, store and report data sent from various personal medical devices onto a central server, in doing so, allowing for more accurate reporting tools to be made available to physicians and doctors. Transmissions from various Bluetooth-enabled personal medical devices (such as blood glucose monitoring devices) will be first captured by a Bluetooth-enabled mobile device (such as a cell phone). This data then gets transmitted to a central server, making it available for analysis by the patient and their physician(s) later.  Interfaces that need to be designed for the full system would be for the cellular part which enables users to register various devices and the website part which allows users and their doctors to view the collected data through various reports.  Only the website interface for the patients was developed in this project.

 

Back to Top

Credits

 

Everyone

  • User needs: Tasks and requirements (deliverable 1)
  • References (deliverable 2)
  • Low fidelity prototypes and descriptions (deliverable 3)
  • Task list and questionnaires (deliverable 4)
  • Usability tests and usability test report (deliverable 5)

 

Andrew Bouis

  • Final Interface Report: report on the development process

 

Stanley Lam

  • Final Interface Report: introduction
  • High-fidelity prototype
  • Editing & Compilation: final interface report, deliverable 4

 

Obaid Siddiqui

  • Final Interface Report: conclusions
  • Classroom Presentation
  • Editing & Compilation: deliverables 2, 4

 

Mark Slowikowski

  • Final Interface Report: presentation of design
  • Logo design
  • Editing & Compilation: deliverables 1, 3, 5

 


Back to Top

Background

 

Patient monitoring devices measure, display and document physiological information collected from a patient’s body using sensors.  Information such as electrocardiogram, invasive and noninvasive blood pressure, pulse rate, pulse oximetry, body temperature, respiration rate, end-tidal CO2 and other specialized parameters can be obtained from these devices.  Due to factors such as an increasing aging population, increased incidence of heart diseases and other conditions requiring close patient monitoring, U.S. and international patient monitoring markets have grown rapidly in recent years.  Despite technological advancements, accurate and consistent data collection cannot be guaranteed if the task is left solely in the hands of the end-user.  A patient who does not have enough data collected may leave their physician or care-provider in the dark about their physiological state.  With enough accurate and consistent data, a patient’s physician or care-provider can analyze the data and take steps to ensure the patient’s well-being.   Steps can be taken to automate this process and eliminate this repetitive and manual task, and the Medical History Vault (MHV) is designed to do just that.

 

To handle data transmissions from patient monitoring devices, the Bluetooth technology was selected over other wireless technologies such as WiFi (802.11), IrDA and ZigBee.  Bluetooth is a short range ad hoc technology that does not require an existing infrastructure or network for it to communicate with other devices.  In comparison to some of the other technologies available, it has low power consumption, is widely supported, is inexpensive to implement and has 128bit data encryption for security.  WiFi, a growing wireless technology, requires an existing network to be in place for the system to be functional.  Even though it has higher data throughput rates, the higher energy consumption makes Bluetooth a better choice[1]. Another reason why Bluetooth is the ideal technology for patient monitoring device to mobile device data transmissions is that no line of sight is required.

 

Existing Systems

 

The Think Positive Diabetes (T+ diabetes) system, a mobile-based diabetes management system, is a commercial system similar to the Medical History Vault system that has already been implemented.  Its scope is much smaller than the MHV system, targeted only to diabetics and limited to only the mobile phone.  The patient collects data using the supplied blood glucose monitoring device, which transmits the data via Bluetooth to the software installed on the patient’s mobile phone.  The software processes and graphs it, allowing for the patient to interpret the data and take any necessary corrective measures.  If the measurements lie outside of the patient’s target range, the patient and his or her health professional is notified[2].  The MHV system takes this one step further, collecting data from many different types of patient monitoring devices and storing them on a secure centralized server.  This extra step allows for the patient to easily share physiological information with relevant health professionals in real-time, without any significant extra work.

 

VICOMTech researched and developed a different mobile-based diabetes management system based on the European standard VITAL, whose main purpose is to the representation and exchange of vital signs[3].  Their system was composed of several parts: a glucometer, GSM/GPRS mobile phone for long range data transmission, a File Transfer Protocol (FTP) server, and a Personal Digital Assistant that stored, formatted and communicated with the mobile phone to transmit the data to this FTP server.   The data available on the FTP server could be accessed by another system, which would properly format and display the data collected to those with the proper permissions and credentials.

 

Academic Studies

 

Bluetooth enabled medical devices are becoming more common.  In the article “Future Applications for Bluetooth Wireless Technology,” Miller Brent discusses three domains where the technology can be used: remote patient monitoring, wireless biometric data and medicine dispensers[4].  Applications such as these were validated by a paper by Yousef J and Lars AN in a paper about the integration of wireless telemedicine systems in clinical practice.  Patients as well as healthcare professionals were highly confident in the system and felt that they had high degrees of mobility and freedom when using the system. [5] 

 

With the noted success and growth of these Bluetooth systems, a paper by T Cooper  MDCIG, R Schrenker discussed the need of a plug-and-play operability in these types of systems.  The main issue that was brought up was the lack of standardization between devices, which limited the ability to develop accurate and complete medical records electronically[6].  For the MHV system to work effectively, a communications protocol for data transmissions between the medical devices and the mobile phone needs to be developed and implemented to ensure that the system is highly compatible and capable of handling many types of different devices from many different manufacturers.  A costly alternative solution would be the continual development of a software gateway that would act as a device driver and handle the system integration of each and every patient monitoring device.

 


Back to Top

Overview of Approach and Solution

 

The interface implemented is a webpage.  It allows access to subscribers from limitless locations.  This is important as it caters to the theme eliminating the hassle of recording and carrying around medical data. The interface is a clean white design with consistent patterns including a logo, table of contents, and link bar.

 

The user must first login to the system.  In doing this, the user is redirected to the Home page.  After that the user is free to navigate through the website using the menu bar located on the left of each page.

 


Figure 1. Transition diagram


Back to Top

Interface Walkthrough

 

Login. The first page the user encounters is a simple login page.  A graphic and text are displayed to introduce the user to the Medical History Vault’s domain.  On the right side of the page is an area for an Account ID and Password.  After entering in the correct information the user clicks the ‘Login’ button to enter their account.  Should users forget their passwords there is a link to assist in password recovery.

 

The sample read only account is ID: abc123  Password: bcd234.  Upon success a brief loading screen is displayed and then the browser is redirected to the home page.  A failed attempt is distinguished with red text prompting the user to try again.

 

Figure 2. Medical History Vault, Login Page

 

 


Home. The home page is made up of two useful parts.  The first section displays the five most recent records for any device apart of the account.  This allows the user to get a quick glance at the latest data collected.  Because this data is likely to be of interest and frequently checked, it can be found on the main user page.  The second helpful part to the home screen is a news feed.  The latest medical news is displayed to help keep the user current on potentially important medical information.

 

Figure 3. Medical History Vault, Home Page

 

 


Search. The search feature is what makes the Medical History Vault such a powerful tool.  The process is relatively intuitive.  With the use of a calendar tool that pops up after clicking the date buttons enter in both the beginning and ending dates (inclusive).  Leaving the ‘From’ or ‘To’ date field blank signifies the minimum or maximum dated possible respectively.  Next, select which device to apply the search.  Finally, choose either to view the data in chart form, as a graph for a visual representation of the data, or export the collection to a file.

 

Conveniently after making a search you can easily switch from chart and graph views with the click of a link at the top and bottom of the page.

 

Figure 4. Medical History Vault, Search Page

 

 

 


Chart Display:  (October 28th to Present)

Figure 5. Medical History Vault, Chart Display

 

 


Graph Display:  (All Glucometer Data)

Figure 6. Medical History Vault, Graph Display

 


Contacts. Here is a list of all the doctors, physicians, and researchers the users have allowed viewing access to their collected data.  When adding a contact, the user may select if identify information should remain anonymous or not.  This could be important when making a researcher a contact.  Also the users have the ability to update the properties of the contact or remove it all together. To change the properties of a contact the users simply click ‘Update’ for the desired contact. 

 

 

This feature is obviously very important to both the patient and the professional.  It facilitates instant and constant communication between both parties.  Doctors can monitor the patient with less frequent visits just by accessing the system.

 

Figure 7. Medical History Vault, Contacts Page

 

 

 

 


On the Update Contact page the user can select which devices are visible to the contact and select whether or not it is an anonymous sharing of data.  The user clicks ‘Save Changes’ to complete the task and send any new changes to the server.

 

Figure 8. Medical History Vault, Update Contacts Page

 


To add a new professional to the contact list the user follows the ‘Add New Contact’ link found on the Contacts page.  The user enters the unique ID number assigned to the doctor or researcher, selects the properties for the contact and clicks ‘Add’.

           

Figure 9. Medical History Vault, Add New Contact Page

 


Personal Info. This page contains basic user information.  Changes are easily accomplished by editing the information in the appropriate text box and clicking the ‘Save Changes’ button.

 

            *the test account is read only and so no changes will be saved*

 

Figure 10. Medical History Vault, Personal Information Page


Back to Top

Low Fidelity Prototype Development

 

Before developing the low-fidelity prototypes, the users and functions of the MHV system were determined.  Users of the system were decided to be:  1. Patients, 2. Doctors, and 3. Researchers.  Patient users actually use the medical devices to input data into the system via a Bluetooth enabled device.  Doctor’s and researchers solely view this data through the MHV web interface.

 

Subsequently, the functions needed to be performed by each type of user were determined.  Patient functions were:

 

  1. Login/Logout
  2. View medical device data
  3. Export medical device data
  4. Add contacts to whom medical device data is sent
  5. Add/edit personal demographic info on website
  6. Access help menu
  7. View relevant health articles

 

Since doctor and researcher tasks were similar to each other, the functions needed by both these user types were the same.  Doctor/Researcher functions were:

 

  1. Login/Logout
  2. View medical device data of single or multiple patients
  3. Export medical device data of single or multiple patients
  4. Search and organize their patient lists
  5. Accept contact requests by patients
  6. Add/edit personal demographic info on website
  7. Access help menu
  8. View relevant health articles

 

After the users and their functions were established, each member of the group developed his own low-fidelity interface prototype.  Prototype 1 (Figure 11) most thoroughly addressed all patient needs and this model largely resembles the final prototype, including an inline frame for news articles, a persistent navigation menu, and table/chart view of device data.  Prototype 2 (Figure 12) focused on doctor/researcher tasks in which the interface allowed easy organization and selection of patient lists and data records.  Prototype 3 (Figure 13) addressed the need for multiple devices and patient demographic info.  Prototype 4 (Figure 14) also addressed both patient and doctor/researcher functions, but most notably raised the question of who has access to the medical records and how to format the incoming medical device data.


Figure 11: Prototype 1

 

 

 


Figure 12: Prototype 2

 

Figure 12a: Login Page

Figure 12b: Individual Information Page

 

Figure 12c: Doctor/Researcher Multi-Patient Page

 

Figure 12d: Aggregate Data Page

 

 


Figure 13: Prototype 3

 

 

 


Figure 14: Prototype 4

 

 

 


Discussion of the low fidelity prototypes led to the decision to limit the scope of the project to the patient interface.  The patient interface was both the most important component of the MHV system and also the most reasonable to complete within the project deadline.  Therefore, Prototype 1 was chosen by vote as the basis for the final prototype because it effectively fulfilled all patient functions.

 

 


Back to Top

Usability Testing

 

The usability study consisted of eight subjects.  The subjects varied in gender and their age ranged from 19 to 28.  The typical subject however, was a 20 year old male.  Each subject was given the same sheet and was asked to read it to begin.  This sheet set up a scenario of a medical patient needing to access the system to complete various tasks.  The users were then given the chance to ask questions and sign the consent form.   Before starting the usability test, the subjects were given a pre-test questionnaire to complete.  After attempting the tasks the users were asked to fill out a post-test questionnaire. See Appendix A for the pre-test questionnaire and Appendix B for post-test questionnaire.

 

Usability Test Scenario:

 

You are a patient that has a medical device such as a blood pressure monitor which automatically reports the readings to a central server.  You want to access the data stored on this central server.  To access the server, you have to go to the website and use your account information to login. 

 

Test website: http://mhv.daft.cc/

Username: abc123

Password: bcd234.

 

Task List:

 

            1. Login to the website using id and password.

            2. View the most recent reading from device Glucometer.

            3. View device Glucometer’s reading for the month of November in a chart format.

            4.  Add Dr. Shelly Shopps so she can see your glucometer device settings.

            5.  Find Dr. Direu Dieo’s phone number and email.

            6.  Unsubscribe Dr. Jones Jimre so he cannot see your glucometer device readings..

            7.  Change your telephone to (555) 344-1234

            8.  Export your glucometer readings from October 2005 to an Excel spreadsheet.

            9.  Logout

 

Back to Top

Test Results

 

User 1: The user logged in without hesitation.  However upon reading the next task it took a few moments before any clicks were made.  The user moved the cursor around in what appeared to be confusion.  After the initial uncertainty, the tasks were accomplished with more ease.  The user said a few times, “I’m guessing” as he clicked a link.   Getting acquainted with the system is probably a large cause of the hesitations.  Another possible factor is terminology.

 

User 2: This user appeared to be trying to move quickly through the tasks.  Only once did he click the wrong link.  While trying to go to the Contacts he clicked Search.  He did not spend much time on this page and went to the Contacts page.  It is likely that he was moving too quickly and made an error and was not lost.  The user seemed unsure of how to remove the glucometer from the doctor.

 

User 3: He took some time finding recent glucometer readings even though it was one of the first things presented to him after logging in.  Terminology or wording caused the user to think about which link to click on in the navigation menu.  The user was able to complete the tasks without any significant problems on the first attempt.

 

User 4: Terminology or wording once caused the user to click on the wrong link in the navigation menu.  This user experienced technical difficulties on his computer when trying to use the calendar button to select dates for a date range search.  The user was still able to complete all the tasks despite the technical difficulties experienced.

 

User 5: This user navigated quickly through the web interface making only one error when she clicked Personal Info to add a doctor rather than Contacts.  There was brief hesitation on the first task to view medical data as the user appeared unsure whether to type in the date or use the pop up calendar button to select dates.

 

User 6: This user completed all tasks without much problem.  He forgot to select a medical device on the task to view device data history.  Instead of an error message, this returned a blank chart which caused momentary confusion to the user.

 

User 7: The user was able to finish her tasks fairly quickly.   However, she was not sure how to export her data at first but after looking at her options, she proceeded in the right direction.

 

User 8: This user was able to finish his tasks very efficiently with minimal hesitation

 

The results from each test were pretty consistent.  High marks (6 or 7) were given for each question.  One case varied, giving only a 3 out of 7 for “How intuitive was the interface in completing each task”?  While watching the tests it was common for the subjects to be unsure at first which link to click on the contents bar to perform the current task.  This is mostly likely caused by two factors.  Systems generally have a small amount of “learning time” where the user discovers what the system is capable of doing and where things are laid out.  The terminology can also affect the user’s ability to know where to go to complete a given task.  In the case where the user felt the system was no very intuitive for completing tasks, he still rated the terminology well, giving it a 6.

 

In almost every case, when attempting to unsubscribe a doctor from the glucose device the user clicked the remove link and not the edit.  While doing essentially accomplished the same task, it did more than just unsubscribe the glucose device.  Likewise in each case the user was unaware that there was a more appropriate option.  One large factor in this problem could be that the study only had one device which left the user lacking an awareness of the full functionality of the contacts page.  Terminology could also play a role.  The word “unsubscribe” and “remove” may seem similar to the average user.


Back to Top

Conclusion

 

Medical History Vault (MHV) website consists of two major interfaces, i.e. patient’s interface and doctor’s interface. In the current version of the project we have only implemented patient’s interface.

 

 

Patient’s Interface

 

Login.  User login with username and password was a vital requirement of our project since we are dealing with sensitive medical data. This requirement has been implemented and the current version of the project checks the username and password before granting access to use the services.

 

View Latest Readings.  One of the requirements of the project was to allow patients to view their latest medical records. This requirement has been implemented. Patient is shown his/her latest readings upon a successful login. The records are sorted in a descending order with the most recent records displayed first.

 

View Records History.  Allowing the patients to see their pervious medical records is the most important feature of MHV. Current version of the project allows patients to select a range of days by either manually typing the date or by using the calendar. In addition to providing a range of days, user also has to select a device for which they want to see the records.

 

Records Format.  MHV allows the users to see their records in chart as well as graph format. In chart format, the most recent records are shown first followed by the older records. The graph format displays the records via a line graph. This is helpful for the patients to determine their progress over a period of time.

 

Patient’s Contacts.  The current version of MHV allows a patient to view their contacts via choosing the “Contacts” option from the menu. 

 

Add/Remove/Update Contacts.  The current version of MHV partially implements addition, removal and editing of patient’s contacts. The link for removing an existing contact as well as forms for adding and editing contacts exist in the interface but are not functional. Using these features gives the user a message indicating that the system is in read-only mode.

 

Editing Personal Information.  Editing the personal information is also partially implemented, i.e. the form to edit the fields exists but the changes do no take effect.

 

Exporting Records.  MHV allows patients to export their records in various formats including Excel, CSV (tab separated) and CSV (comma separated) formats. Exporting records works in a similar fashion as that of viewing record history; user first selects a range of days and the device and then the format in which the records to be exported. Current version of program exports an empty file to the user’s computer.

 

Registration.  Registration process through which users sign up for membership of MHV is not implemented.

 

Help.  Help feature is not implemented in the current version of project.

 

 

Doctor’s Interface

 

Doctor’s interface has not been implemented for the current version of project.

 

 


Back to Top

Future Considerations

 

There are several features of this project which can be implemented by developers who wish to continue building on our code. The most important of these features would be to implement the doctor’s interface. Some of the features that doctors might be interested in using are as follows:

            Viewing a list of all their patients

            View the record history of their patients

            Being able to export patient’s records

            Being able to send messages to patients who are not recording their readings regularly.

The current version of project can also be improved by fully implementing the features which were partially implemented for this semester.

 

Back to Top

Acknowledgements

 

We would like to thank all of the usability testers who spend their time to help us with the evaluation of our website. Also special thanks to professor Ben Shneiderman and George Aptiz who provided us with their useful comments and critique in the development of this project.

 

 


Back to Top

References

 

▪ Chlup, R Payne M, Zapletalova J, Komenda S, Doubravova B, Reznickova M, Chlupova L, Seckar P. “Results of selfmonitoring on glucometer systems Advance and Optium in daily route.” Institute of Physiology, Faculty of Medicine, Palacky University, Olomouc, Czech Republic. 2005.

 

▪Cooper, T, MDCIG, Schrenker R. “Building the Foundation for Medical Device Plug-and-Play Interoperability”, IEEE. <http://www.ieee1073.org/overview/Connectivity_stds%20for%20PNP%20interop_schrenker_cooper.pdf>

 

▪ Coursey, David “Bluetooth vs. WiFi: Why it's NOT a death match.” May 30, 2002

<http://reviews-zdnet.com.com/4520-6033_16-4207317.html>

 

▪ Floerkemeier, C and Siegemund F.  “Improving the Effectiveness of Medical Treatment          with Pervasive Computing Technologies.” Institute for Pervasive Computing           Department of Computer Science ETH Zurich, Switzerland.

 

▪ Jakobsson, M. and Susanne W. “Security Weaknesses in Bluetooth.” Lecture Notes in           Computer Science. 2020 (2001): 176-191.

 

▪ Klein, H.A., Meininger A.R. “Self management of medication and Diabetes: cognitive control”. Systems, Mans and Cybernetics, Part A, IEEE Transactions on. Wright State University, Dayton, OH USA.  2004.

 

Malan, D. et al. “CodeBlue: An Ad Hoc Sensor Network Infrastructure for

            Emergency Medical Care.” Division of Engineering and Applied Sciences School           of Medicine Harvard University Boston University 2005.

 

▪ “Managing Diabetes On Your Mobile.” Sci-Tech Today. Health. 2005 <http://www.sci-tech-today.com/story.xhtml?story_id=38140>

 

▪ McCandless, M. “Staying healthy in a wired world.” Intelligent Systems and Their Applications, IEEE.  MIT, Cambridge, MA, USA.  1998.

 

▪ MI Harris, KM Flegal, CC Cowie, MS Eberhardt, DE Goldstein, RR Little, HM Wiedmeyer, and DD Byrd-Holt. “Prevalence of Diabetes, Impaired Fasting Glucose, and Impaired Glucose Tolerance in U.S. Adults”, Diabetes Care 21: 518-524.

 

▪ Miller, Brent. “Future Applications for Bluetooth Wireless Technology.” Bluetooth Revealed, Second Edition. Nov 30, 2001 <http://www.informit.com/articles/article.asp?p=24243&rl=1>

 

Moor, C, Braecklein M, and Jorns N. “Development of wireless sensors for medical applications.” Biomed Tech, Berl. 2005 Jul-Aug;50(7-8):241-51.

 

▪ Nunnally M, Nemeth C.P., Brunetti V, Cook R.I.  “Lost in menuspace: user interactions with complex medical devices.”  Systems, Mans and Cybernetics, Part A, IEEE Transactions on.  University of Chicago, IL USA.  2004.

 

▪ Susperregui A, Paloc C, Macía I, García I, and Carrasco E. “A Standard-Based Mobile And Wireless Vital Signs Monitoring System”, VICOMTech Association. 

            <http://www.vicomtech.es/publicaciones/ A_STANDARD-BASED_MOBILE_AND_WIRELESS_VITAL_SIGNS_MONITORING_SYSTEM.pdf >

 

▪ Tura, A, M. Badanai, D. Longo, L. Quareni. “A Medical Wearable Device with Wireless Bluetooth-based Data Transmission” MEASUREMENT SCIENCE REVIEW, Volume 3, Section 2, 2003

 

▪ Yousef J and Lars AN. “Validation of a real-time wireless telemedicine system, using bluetooth protocol and a mobile phone, for remote monitoring patient in medical practice.” Eur J Med Res. 2005 Jun 22;10(6):254-62.


Back to Top

Appendix

 

A

 

 

Pre-Test Questionnaire

 

Age  _______           Gender:   i) Male

                                                 ii) Female

 

 

1) On the average, how much time do you spend on internet per week?

     ___  less than 1 hour                        ___  1- 4 hours

     ___  5 -10  hours                            ___  11 or more hours

 

2) Do you have any of the following medical conditions? (Check as many as applicable)

     ___  color blindness             ___  tremor or trembling of arm

     ___  lack of concentration    ___  legally blind

     ___  none

 

3)  What is your highest completed level of education?

    ___  junior high                                 ___ high school

    ___  college                                      ___ post graduate

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

B

 

Post-Test Questionnaire

1) How easy/hard was it to accomplish the task(s) assigned to you (circle one)

           1           2            3             4           5            6             7

      very hard                                                                     very easy

 

2)  Please explain briefly what was the hardest task to accomplish?

 

 

 

 

 

3)  How easy/hard was it to understand the terminology used by the

           1           2            3             4           5            6             7

      very hard                                                                     very easy

 

4)  Did you encounter any problem in the system?

     ___ yes

     ___ no

 

5)  If answer to the above is “yes” please explain briefly

 

 

 

 

 

6)  Rate the consistency of the overall design?

           1           2            3             4           5            6             7

    in-consistent                                                                 consistent

 

7)  How intuitive was the interface in completing each task?

1           2            3             4           5            6             7

     non-intuitive                                                                   intuitive     

 

8)  Rate the presentation of data and records

1           2            3             4           5            6             7

     hard to understand                                                   easy to understand

 

9)  Rate the ease of Search facility

1           2            3             4           5            6             7

     hard to understand                                                   easy to understand

 

10) What was your overall impression of the interface?

1           2            3             4           5            6             7

      terrible                                                                            excellent

 


Back to Top

Footnotes

[1] Coursey, David “Bluetooth vs. WiFi: Why it's NOT a death match.” May 30, 2002

[2] “Managing Diabetes On Your Mobile.” Sci-Tech Today. Health. 2005

[3] Susperregui A, Paloc C, Macía I, García I, and Carrasco E. “A Standard-Based Mobile And Wireless Vital Signs Monitoring System”, VICOMTech Association. 

[4] Miller, Brent. “Future Applications for Bluetooth Wireless Technology.” Bluetooth Revealed, Second Edition. Nov 30, 2001

[5] Yousef J and Lars AN. “Validation of a real-time wireless telemedicine system, using bluetooth protocol and a mobile phone, for remote monitoring patient in medical practice.” Eur J Med Res. 2005 Jun 22;10(6):254-62.

[6] Cooper T, MDCIG, Schrenker R. “Building the Foundation for Medical Device Plug-and-Play Interoperability”, IEEE.