23.4 Case Study: WAP in Telemedicine

23.4 Case Study: WAP in Telemedicine

23.4.1 Objective

As seen in the last section, numerous telemedicine applications are based on the Internet and the mobile phone. Some of the recent examples even reflect the convergence of wireless communications and computer network technologies. ^[44] This trend also is realized with the emergence of new mobile phones, PDAs, cellular modems, wireless infrastructure and networks, and mobile application programming languages and protocols. There are various application protocols, such as Wireless Application Protocol (WAP) and i-mode; application technologies, including Java Version 2 Micro Edition (J2ME™); and operating systems, such as Symbian, Pocket PC 2002, and Palm OS , aimed at supporting various wireless devices.

WAP-enabled devices are now commonly available. As WAP also will be a feature found in various future handheld devices, it is worthwhile to investigate its possible use in telemedicine. This section describes the implementation and experiences with a WAP-based telemedicine system recently developed. ^[45], ^[46] It was tested with an emulator and with a WAP phone using wireless connections provided by a mobile phone service provider in Hong Kong. Store-and-forward monitoring and analysis of wireless ambulatory ECG and other parameters also were demonstrated.

23.4.2 Method

23.4.2.1 System Specification

The WAP programming model is shown in Figure 23.1. A handheld WAP device communicates with a content server, which stores information and responds to the users' requests. A WAP gateway translates and passes information between the device and the server. ^[47] To access an application stored at the content server, the device's WAP browser first initiates a connection with the gateway before requesting for content. The gateway converts these requests into HTTP format for the server. After processing, the server sends the content to the gateway, which then translates it into WAP format for the WAP device. The layers of WAP protocols that govern the communication are shown in Figure 23.2.

Figure 23.1: WAP programming model.

Figure 23.2: WAP architecture.

To determine which telemedicine applications are feasible with WAP, it is important to examine the capabilities of a typical WAP device. Such a device has limited processing power, memory, battery life, display size and resolution, and entry capability. Compared to wired networks, most currently used wireless networks for WAP have low bandwidth, resulting in perceptible delay between request and response at the mobile device. Due to the nature of such a network, requests and responses are required to be concise for minimal latency. This latency depends on the type of bearer used. With a GSM network, some possible bearers are SMS (short message system), CSD (circuit-switched data), and GPRS (General Packet Radio Switching). ^[48] WAP over SMS is the most time consuming of the three. A CSD connection requires several seconds for initial setup before data transfer, and the typical data rate is 9.6 kbps. GPRS, which provides data rates up to 171.2 kbps, is already a commercially available service. It does not need the long connection time as with CSD. When a GPRS phone is switched on, it is always online and is ready to start receiving and sending data in less than one second.

WML (Wireless Markup Language) is designed for creating WAP applications, and is user-interface independent. It supports text, images, user input, variables, navigation mechanisms, multiple languages, and state and management-server requests. WML has been designed for the high latency and narrow band of the wireless network, so connections with the server should be avoided unless necessary. As a result, WAP is mainly intended for displaying text content. Wireless Bitmap Format (WBMP) is a graphics format optimized for efficient transmission over low-bandwidth networks and minimal processing time in WAP devices.

These technical capabilities suggest that use of current WAP devices in telemedicine is feasible in applications operating in a store-and-forward, client/server, and low-bandwidth fashion. The displayed information is limited to text and low-resolution WBMP static images. When displaying graphical information, it is better to first construct the image at the server, thus reducing the usage of memory and processing time at the device.

Based on these requirements, a WAP-based telemedicine system has been developed. Applications include viewing of general patient information, previously captured BP and heart rate readings, and recorded ECG waveforms. Other functions are remote request for doctors' appointments and general inquiries on clinic and hospital information. Targeted users are both doctors and patients. Figure 23.3 shows general features of the system.

Figure 23.3: General features of the WAP-based telemedicine system.

An ECG browsing function is included because of the increasing need for ambulatory ECG monitoring. In 1999, heart disease accounted for 30 percent of all deaths worldwide. ^[49] Monitoring services would allow early detection and diagnosis of pathological symptoms, and thus lead to earlier treatment. A major concern for displaying the ECG is the small screen size and low display resolution of a WAP phone. A group has tried displaying ECG on a 160 144 pixels LCD gray-scale display of a handheld video game platform, and it was shown that some basic features such as R-R intervals were still recognizable with the user's selection of the lead displayed and time scale used. ^[50] Noting that the display resources on a WAP device are similar to those of the game platform, ECG browsing with the WAP-based system should be possible.

23.4.2.2 Overall Architecture

The developed system was set up for testing the feasibility of telemedicine with WAP. Figure 23.4 shows the architecture for the connection between a WAP device and the content server. Applications were stored in the content server. Part of the user interface was written in WML and WMLScript, which executed at the WAP device after being downloaded from the server. The other part of the application, written in Perl, executed within the Linux-based content server. ^[51] It provided the common gateway interface (CGI) for more-complex tasks. Using the GD and CGI modules, the Perl program could dynamically create WBMP graphics and WML decks upon requests from the WAP device. Patient data that the applications accessed and manipulated were stored in a relational database system.

Figure 23.4: Structure of the system.

23.4.2.3 Relational Database

A relational database is made up of tables and columns that relate to one another. MySQL is a relational database management system (DBMS) that can handle multithreaded operations. ^[52] It also has many application programming interfaces (API), including Perl, TCL, Python, C/C⁺⁺, JDBC, and ODBC, thus enabling access to the database by applications written in various languages. MySQL uses the Structured Query Language (SQL) to manipulate, create, and display data within a database.

For the telemedicine system, a MySQL database system consisting of two databases at two different sites was set up to store data, including BP and heart-rate readings, patient records, clinic and hospital information, doctors' appointments with patients, and recorded ECG. One database resided in the content server, and another in a remote PC. During WAP access, data was retrieved by the applications through Perl's Database Interface (DBI), as shown in Figure 23.4. By specifying permissions given by each database, the application could access data not only in the content server, but also data in remote databases. Figure 23.5 shows the entity-relationship (ER) model, which is a high-level conceptual representation of data contained within the database. ^[53]

Figure 23.5: Entity-relationship model of the database.

23.4.2.4 Program for WAP Access

The flow of the program starts when the user accesses the first WML deck at a predefined site. The following WML decks that the user interacts with are then generated by Perl. The user first logs into the WAP site and loads the first card (login.wml), which prompts for username and password. Using CGI with method 'post,' Perl first takes the user inputs. It then accesses the TABLE USER of the database through the DBI. If the user chooses to view patient information, the patient ID must be entered. A menu is then generated if the patient ID is valid and accessible. The user has the choice of viewing general information, a single blood pressure reading, a day log of blood pressures, ECG browsing, and heart-rate reading. The process flow is shown in Figure 23.6.

Figure 23.6: Flow of the WAP application; login, patient information menu, and patient general information.

The menu for single blood pressure reading works in a similar way. After a list of BP recording sessions is displayed, the user chooses the session. Perl then searches through TABLE BP, and charts out the date, time, pulse rate, and the systolic, diastolic, and mean pressure values in WML format. The day log for blood pressure allows the user to view all the pressure values of a day in chart or graphical form. To display BP graphs, the program first searches through TABLE BP and stores the necessary values in a temporary array, which is then used along with the GD module to create a WBMP file called by the WML card. Scrollable graphs are presented by updating the array with a new set of data from the database whenever the user chooses to scroll forward or backward.

When a user browses through the ECG waveform for a specified recording session, the program first searches through TABLE ECG for details, such as sampling rate, recording time, and duration. Recorded ECG data for each session is stored in a separate ECG data table named according to the names in TABLE ECG. To display the ECG, the program traverses through the ECG data table with a pointer, and loads the necessary data points into a temporary array. According to the information in TABLE ECG, it creates a WBMP for each new frame of ECG waveform. The user also can view the waveform with the choice of time-scale, scroll direction, and scroll distance. This flow is summarized in Figure 23.7. Inquiry service for hospital and clinic information also is available by accessing TALBES CLINIC and HOSPITAL.

Figure 23.7: Flow of the WAP application; ECG browsing, heart rate reading, and appointments.

23.4.2.5 ECG Browsing and Feature Extraction

The heart serves as the pump for the circulatory system. The well-coordinated pumping action of its four chambers are a result of a series of electrical depolarizations and repolarizations over different regions of the heart, and these activation sequences establish conduction fields which also extend to the body surface. The heart can be viewed as an electrical equivalent generator, and at each instant of time, the electrical activity of the heart can be represented by a net equivalent current dipole located at a point of the heart. ^[54] The thoracic medium can be considered a resistive load, resulting in attenuation of the field with increasing distance from the source, as well as potential drops measured between two points measured on the body surface. Measurement of the resulting electrical potentials between different sites on the body surface is the ECG, which provides information on the condition of the heart. Its dynamic range is from 10 μV to 5 mV, and its bandwidth is from 0.05 to 1000 Hz; however, 0.05 to 80 Hz is adequate for most monitoring purposes. ^[55]

For initial testing of ECG browsing, a Lead I waveform from a subject was sampled at 250 samples per second by a data acquisition unit, stored as delimited numbers in a file, and loaded into the content server. A Perl program then extracted the sample points from the file and stored them inside an indexed table in the database. Recording sessions were stored in ECG data tables. Because the display size and resolution are limited on a WAP device, performing feature extraction would further enhance the feasibility of using WAP in viewing the acquired data. To demonstrate this, a QRS detection program was written in Perl, providing estimation of QRS occurrence times and R-R intervals in the recorded ECG. The algorithm used was based on amplitude and first derivative. ^[56]

Upon receiving a request for estimating the QRS occurrence times, the program retrieves the ECG data of the specified part of the recording session from the database, and puts it into a one-dimensional array of sample points of the ECG. For example, for 9000 sample points, the array is in the form

X[n] = X[0], X[l], X[2], ... X[8999]

The first derivative, Y[n], is then calculated at each point of X[n]:

Y[n] = X[n + 1] - X[n - 1], 1 < n < 8998

A QRS candidate occurs when three consecutive points in the Y[n] array exceed a predefined positive slope threshold, TH_POS, and are followed within the next 100 ms by two consecutive points which exceed a predefined negative slope threshold, TH_NEG.

Y[i], Y[i + 1], Y[i + 2] > TH_POS

and

Y[j], Y[j+1] < TH_NEG

where (i + 2) < j < (i + 25). The value of 25 is based on the sampling rate of 250 samples per second. Each sample interval is

1/250 = 0.004 s

Therefore, the number of samples that corresponds to 100 ms is

0.1/0.004 = 25

Once such a QRS candidate is detected, all X[n] data points that are between the onset of the rising slope and before the end of the descending slope must exceed the amplitude threshold, TH_AMP, in order to be considered a valid QRS complex.

X[i], X[i + 1], ..., X[j + 1] > TH_AMP

Finally, the occurrence times of the highest points in the QRS complexes are put into an array, which is then used in the dynamic construction of chart or graphical display in WML and WBMP format (see Figure 23.16).

23.4.2.6 Wireless Subsystem

An indoor, wireless subsystem has been built for recording ECG from a mobile subject to demonstrate using WAP in patient monitoring. The data was immediately stored in the PC-based database after each recording session, and was available for viewing and analysis on a remote WAP device. The subsystem, as shown in Figure 23.8, consisted of a patient-worn unit, a receiving unit, and a PC. Photographs of the transmitting and receiving units are shown in Figure 23.9.

Figure 23.8: Block diagram for the wireless ECG connection.

Figure 23.9: (a) Patient-worn unit; (b) receiving unit.

The patient-worn unit, depicted in Figure 23.10, was a portable device consisting of circuits for one-lead ECG acquisition and RF transmission. The biopotential sensed by Ag-AgC1 prejelled electrodes was fed into an instrumentation amplifier with gain of 1000, followed by AC coupling and a Butterworth lowpass filter having cutoff frequency at 150 Hz. After conditioning, the analog signal was input to a two-stage, SAW-controlled, 433 MHz FM transmitter operating on 3V supply voltage with transmitting power of 10 mW. A 24-turn helical antenna was used. Figure 23.11 shows the receiving unit, which consisted of a double conversion FM Superhet receiver operating on a 3V supply voltage, an 8-bit analog-to-digital converter (ADC), an 8-bit microcontroller unit (MCU), and interfacing circuits for connection to a PC via serial port.

Figure 23.10: Patient-worn unit.

Figure 23.11: Receiving unit.

The receiver was connected to a 1/4 wavelength whip antenna, and drew 14 mA when receiving. Output of the receiver was digitized by the ADC at 240 samples per second, fed to the MCU, and pushed into the PC's serial port through an RS232 transceiver at a baud rate of 19,200. The program that resided in the PC was written in Visual Basic 6.0. During each recording session, assigned a unique identifier, the program would read data from the serial port and save it into the PC-based database through ODBC DBI. The program also provided an interface for direct access to the database. The program interfaces are presented in Figure 23.12.

Figure 23.12: Interfaces of ECG recording application.

23.4.3 Results

23.4.3.1 Emulation

All the applications were first tested with an emulation software before using actual WAP phones. The Nokia™ WAP Toolkit was used on a Windows platform to emulate how the applications would appear on a WAP phone. Applications were loaded directly from the server through the Internet. The setup is shown in Figure 23.13. Figures 23.14 to 23.17 are some screenshots of the interface.

Figure 23.13: Setup for accessing WAP applications with emulation software.

23.4.3.2 Experience with WAP Phone

An actual WAP 1.1-compliant phone was used at GSM 1800 MHz through CSD to connect to the same WAP site. The gateway used in the link was provided by a mobile phone service provider in Hong Kong. Figure 23.18 describes the setup, and Figures 23.19 to 23.22 show some screenshots of the interfaces.

Figure 23.14: (a) Login menu; (b) patient data menu.

Figure 23.15: Display of blood pressure readings. (a) readings from a single blood pressure measurement; (b) readings within a day; (c) graphical display of systolic pressures within a day; (d) graphical display of diastolic pressures within six hours.

Figure 23.16: ECG browsing. (a) ECG browsing with a 2-sec window; (b) ECG browsing with a 0.5-sec window; (c) ECG browsing with QRS occurrence times estimation function activated; (d) Chart for estimated QRS occurrence times and R-R intervals.

Figure 23.17: Display of patient general data.

Figure 23.18: Setup for accessing WAP applications with WAP phone.

Figure 23.19: User menus.

The time required for establishing a connection to the site was about 10 to 12 seconds. Starting from the time of request for information at the phone, the time required for database query, dynamic generation of WML and WBMP, and display of new information at the device ranged from 3 to 5 seconds on average.

Figure 23.20: Display of blood pressure readings. (a) readings from a single blood pressure measurement; (b) BP menu; (c) graphical display of systolic pressures within a day; (d) graphical display of diastolic pressures within six hours.

Figure 23.21: ECG browsing. (a) ECG browsing with estimated QRS occurrence times; (b) Chart for estimated QRS occurrence times and R-R intervals.

Figure 23.22: Display of patient general data.

23.4.4 Discussion

Viewing and analyzing patient data have been demonstrated on a WAP phone. This included interactive feature extraction of medical data. Although response time was long, the feasibility of such a system is expected to improve in the future, as newer versions of the WAP specification will be integrated into 3G mobile phones, which operate at a much higher data rate and have more on-board resources.

An issue of concern, as in all telemedicine applications, is security. The security features of a WAP-based system are implemented at several levels. WAP implements most of its security in WTLS (Wireless Transport Layer Security) protocol, which is the wireless equivalent of TLS (Transport Layer Security) protocol. Because data are encrypted between the phone and the gateway (at which point they are decrypted by the gateway before being reencrypted and sent on to the content server over a TLS connection over the Internet), the gateway has access to all of the data in decrypted form. Therefore, using a WAP gateway hosted by a third party is not recommended for telemedicine applications. The solution is to set up a private WAP gateway for the application.

There is still much room for improvement in this system. One area is to utilize the push technology provided by WAP 1.2 and higher. WAP-based push can use SMS or cell-broadcast as the bearer to transmit packets over the wireless network. This messaging service will further enhance the feasibility of using WAP for patient monitoring. When a real-time analysis program detects pathological abnormality in the recorded data, the content server will be able to send a short message to the WAP devices carried by the doctor or the patient.

The wireless subsystem is being upgraded to use Bluetooth™ for transmission. Wireless medical sensors based on conventional infrared or radio frequency transmission have been developed by others. ^[57], ^[58], ^[59] However, the small size and low power consumption of the radio module, use of 2.4 GHz frequency hopping spread spectrum, and the design for short-range transmission makes Bluetooth™ an attractive option in dynamic monitoring of physiological signals for telemedicine. Some parties have already integrated the technology into medical applications. ^[60], ^[61] Further tests on the telemedicine system will be accessing the site with PDAs and PDA-phones, and connecting with GPRS. The system can be expanded also to a network of databases for resource sharing. Currently, another content server that uses Java Servlet and Extensible Markup Language (XML) has been set up.

^[44]Coiera, E., Guide to Medical Informatics, the Internet and Telemedicine, Chapman & Hall, London, 1997.

^[45]Hung, K. and Zhang, Y.T., On the feasibility of the usage of WAP devices in telemedicine, in Proc. 2000 IEEE EMBS Int. Conf. on Information Technology Applications in Biomedicine, Laxminarayan, S., Ed., Arlington, VA, 2000.

^[46]Hung, K., Zhang, Y.T., Web-based telemedicine applications, in Ann. Conf. of Eng. and the Physical Sci. in Med. and Asia Pacific Conf. on Biomed. Eng., Fremantle, 2001.

^[47]Mann, S., Programming applications with the Wireless Application Protocol: the complete developer's guide, John Wiley & Sons, New York, 1999.

^[48]Arehart, C., et al., Professional WAP, Wrox Press, Birmingham, 2000, 34.

^[49]World Health Organization, Death by cause, sex and mortality stratum in WHO Regions, estimates for 1999.

^[50]Rohde, M.M., Bement, S.L. and Lupa, R.S., ECG boy: low-cost medical instrumentation using mass-produced, handheld entertainment computers, Biomed. Inst. Tech., 32 (5), 1998, 497.

^[51]Cozens, S. and Wainwright, P., Beginning Perl, Wrox Press, Birmingham, 2000.

^[52]DuBois, P., MySQL, New Riders, Indianapolis, 2000.

^[53]Elmasri, R. and Navathe, S.B., Fundamentals of Database Systems, Benjamin/Cummings, Redwood City, CA, 1994.

^[54]Webster, J.G., Medical Instrumentation: Application and Design, 3rd ed., John Wiley & Sons, New York, 1998.

^[55]Kenedi, R.M., A Textbook of Biomedical Engineering, Blackie & Son, East Kilbride, 1980.

^[56]Friesen, G.M. et al., A comparison of the noise sensitivity of nine QRS detection algorithms, IEEE Trans. Biomed. Eng., 37 (1), 85, 1990.

^[57]Leung, S.W., Wireless electrode for electrocardiogram (ECG) signal, M.Phil. thesis, The Chinese University of Hong Kong, 1999.

^[58]Santic, A., Theory and application of diffuse infrared biotelemetry, CRC Crit. Rev. Biomed. Eng., 18 (4), 289, 1991.

^[59]Yang, B., Rhee, S., and Asada, H.H, A Twenty-four hour tele-nursing system using a ring sensor, in Proc. 1998 IEEE Int. Conf. Robotics and Automation, Leuven, Belgium, 387, 1988.

^[60]Berggren, M., Wireless communication in telemedicine using Bluetooth and IEEE 802.11b, Master's thesis, Dept. of Computer Systems, Uppsala University, 2001.

^[61]Ortivus, http://www.ortivus.com