Monitoring chronically ill patients using mobile technologies

The treatment of chronic disease, even in the most modern health-care systems, is a compromise. The main challenge in treating chronic disease is to minimize the impact of the treatment on the patient; for acute medical conditions, maintaining a stable state of health is the first priority. Medical science is making continuous progress in discovering and developing more effective and efficient treatment methods and is coming to rely on information technology in general (and networking technology in particular) to assist in those treatments.

If we examine health-care systems around the world, we find that many of them are grappling with issues of financial sustainability. The reasons for this vary and depend on factors such as the local demographics, the political environment within which the health-care system operates, and the level of industrialization. Volz¹ describes the structural and financial constraints of health-care systems in countries such as Germany, in particular the increasing demands being placed on the health-care infrastructure by an aging population (typical for Western Europe and North America), a politically motivated separation between health-care providers and health-care insurers, and a highly industrialized and well-nourished society, where life expectancies are constantly increasing. Every country has similar factors which influence how health care is delivered and what type of health care is provided.

Populations such as Germany's are aging rapidly and will experience a shift in the age structure with a projected peak around 2025.² An aging population means that the prevalence of age-related disease is rapidly increasing. Most countries in Western Europe and North America have experienced financial prosperity (with short interruptions) since the end of World War II. This prosperity has brought with it a change in the types of illnesses that are prevalent.

The best example of this is the incidence of diet-related diabetes, which is high and increasing in prospering countries; the people who live there enjoy a high standard of living, and very few experience malnutrition. The high level of nutrition also brings with it the risk of overeating, with the attendant increase in risk of heart attacks, arteriosclerosis, or problems with the body's sugar-regulating system. The treatment for these diseases is therefore a significant cost factor in the health-care system of any industrialized country, as was illustrated in a recent National Bureau of Economic Research study on obesity in schoolchildren.³

Another example is the group of metabolic disorders, which in the majority of cases are caused by the failure of one or more internal organs. Most of these diseases are fatal if not treated immediately. Kidney failure (diagnosed when this organ's ability to extract and filter the blood falls below 10 percent of its full capacity) requires hemodialysis, of which there are two main forms: cleaning the blood directly through filtration and indirectly through osmosis within the stomach cavity.

For patients who undergo in-center hemodialysis, this represents a significant negative impact on their quality of life. They must spend from three to six hours every two days having their blood cleaned in this way, which effectively means that they can no longer work or attend school. The alternative is to clean the blood through the abdominal cavity by means of peritoneal dialysis, a process which involves pumping a glucose-saline solution into the cavity, letting osmosis clean the blood in the vessels in the abdominal tissue lining, and then pumping the fluid with waste products back out. This is conducted six to nine times in succession, with each cycle taking around 60–90 minutes to complete. The advantage of this technique is that access to the abdominal cavity can be obtained through a permanently implanted catheter, allowing the dialysis to proceed during the night with the help of a device (known as a cycler) at the patient's home. This represents a significant improvement in quality of life and enables the patient to lead a much more normal life.

The disadvantage of performing dialysis at home is that the water balance in the patient's body can only be monitored indirectly by medical personnel. A consistent and correct water balance is crucial to the long-term health and life expectancy of the patient, because too much or too little water causes cardiovascular stress, which can result in a risk of long-term damage to the heart and possible heart failure.

In the project described in this paper, we performed real-time monitoring of the water balance by using mobile technology. Aside from advantages for the patient's long-term prognosis and short-term quality of treatment, this technology promised a reduction in consequent disease occurrence and in the total cost of treatment.

By monitoring blood pressure and weight, it was possible to identify trends in the amount of water the patient was taking on (specifically, how rapidly water gain was occurring), thus enabling an early and reliable indication of whether over- or under-dialysis was present. The telemedicine platform eliminated an error-prone and unreliable measurement system based on manual measurement and recording of the measured values on paper during infrequent checks by medical staff. The platform recorded data in near real-time, and medical personnel were able to see trends in the data within minutes of a measurement being taken.

An additional goal of the study was to establish the key criteria for acceptance of a telemedicine system, from the point of view of both the patients and the medical staff responsible for the treatment. Without a high level of acceptance among all stakeholders, such a system would be of little use in the real world.

This section outlines the scope and the environment of our pilot study, which took place at the University of Heidelberg. In addition, it introduces and discusses the specific requirements of the solution.

The goal of the pilot study was to evaluate the medical value of telemedicine in general and to investigate user acceptance of the IBM telemedicine system. The main purpose of the system was to capture blood-pressure, heartbeat, and weight data generated by special sensors in a reliable way, to combine them with time-stamp information, to aggregate them on a portable communication device, and to transfer them in a secure and reliable way to a medical server. The server had to store the data and offer different views of patient data for the clinic staff, allowing them to analyze the therapy of their patients.

IBM provided the complete solution for the project, including hardware, software, and services. The hardware components comprised the medical sensors, the communication devices, and the server hardware. IBM supplied the software running on the peripheral communication devices and the server. The services included project management, technical consulting, hardware selection, hosting, training, and support. A detailed description of the solution architecture is described in Reference 4.

The system had to support three different user profiles. The main users were young dialysis patients and their relatives. For this group it was important that the system was reliable and had a simple user interface so that it could be operated without any expert knowledge. The second user group consisted of doctors and nursing staff who were responsible for regularly monitoring their patients' medical data to ensure its conformity with the expected course of therapy. This second group had an average knowledge of standard office IT (information technology) equipment (Web browsers, spreadsheets, etc.) but limited IT systems knowledge (concerning networks or firewalls, for example). The final user group consisted of IT professionals who supervised the system, analyzed the user behavior from a technical point of view (e.g., to ensure that patients' data was uninterrupted), and generated from the collected data special reports that were sent to the hospital staff for medical analysis.

The environment where the pilot study took place could be described as “uncontrolled.” The participating patients were chosen based on their medical eligibility and their willingness to try out new telemedicine technology. These patients tended to be “early adopters,” a characteristic which positively affected their acceptance of the new technology. As the patients were living in different cities and were allowed to travel with their medical device kit, the environments in which the measurements were taken were unknown. There was no guarantee that the network of the chosen GSM (Global System for Mobile Communication) provider would always be available with the necessary signal strength at the location where the measurements were recorded. There was also the risk of interference from radio appliances at the location where the medical device kit was used. At the clinic, the existing infrastructure was not directly controlled by the parties involved, as the network and firewalls were managed by an external IT department that had to approve and set up access to external systems.

The sensors for the telemedicine solution had to meet a range of requirements: They needed to be approved for use as medical products on the German market, and they had to be sufficiently reliable to be accepted by the doctors. From a technical perspective, they had to provide a built-in near-field radio communication module to be able to send the data wirelessly to the gateway. The communication link had to be established autonomously between the sensor and the gateway without user involvement. To prevent data loss during temporary wireless unavailability, the sensor had to be able to buffer measured values until they were transmitted successfully to the gateway.

Sensors deployed with the medical device kit in the field had to work reliably without special attention, such as frequent battery changing. The sensors therefore had to combine low energy consumption with a long battery life. An intelligent power management system was needed to minimize the power consumption of the wireless link and to switch off the sensor system after completing the measurement and the data transmission.

As the patients taking part in the pilot project were children, the sensors had to have characteristics suitable for pediatric use. For example, blood pressure devices needed to be fitted with special cuffs for children, which are significantly smaller than the adult versions. In addition, because a child's pulse has a lower amplitude, blood pressure sensors had to be more sensitive to perform reliable and correct measurements.

The requirements for the gateway were multifaceted. First, it had to provide a programming platform that could host the hub application controlling the data transmissions, program logic, user interface, and signaling. Second, the device had to support the GPRS (General Packet Radio Service) and Bluetooth** wireless standards at the very least. The device had to be powered with a battery capable of sustaining operation over at least three days without being recharged.

Because the hub software had to work autonomously, it needed to start automatically after the device was turned on and to connect to the devices and server without any user interaction. The device also needed protection against configuration by the user. This was to prevent users from abusing the device to access expensive or inappropriate data services. Furthermore, it was important to ensure that the availability and functioning of the hub device would not be compromised by users toying with the new feature-rich phone placed at their disposal. Another issue was that users changing their hub configuration could increase the risk of an outside attack on the hub device. If such an attack were successful, the attacker would have the chance to tap and even create or manipulate medical data, with potentially severe consequences for the patient's therapy and medication.

To avoid having to connect each sensor to the communication device by cable and to ease use of the system, data had to be transmitted by a local-area radio link (e.g. Bluetooth or Zigbee**) from the sensor to the communication device (gateway or hub). To prevent the hub from receiving data from any sensor device in the vicinity, a pairing process had to be used to tie the hub and sensors together virtually.

When the hub received sensor data, it combined it with a time stamp and gave an audible acknowledgement to the user. Received messages needed to be aggregated and transmitted in a reliable and secure way over a wide-area network carrier to the server. After successful completion of this transmission, the gateway again gave acoustic feedback to the user.

There were several possible options for transmitting data to the server. These included GSM, SMS (Short Message Service), GPRS, UMTS (Universal Mobile Telecommunication System), satellite link, and standard IP (Internet Protocol) carriers. (If users had not needed to be mobile, for example, those confined to bed, communication on an IP connection over a DSL router would also have been an interesting option.) Given that the sensor data contained only a few bytes, GPRS offered a low-priced solution, mobility for the user, and flexibility for integration on the server side, thanks to its IP-packet-based communication.

The server system had to be able to receive the medical measurements and store them anonymously without associating them with patients' names or personal data. Through a Web-based front end, users could access simple data graphs that were generated based on user-selected time intervals. The system had to be continuously available for receiving patient data. The performance requirements were not especially challenging because the system needed to support only a small number of medical devices and a limited number of persons querying the data.

This section provides an overview of the pilot study. It explains the technical setup, including the concepts and components employed, as well as the organization and implementation.

Figure 1 shows the IT infrastructure used for the pilot study. It includes the following components: medical devices, hub, back-end server, and Web client.

Figure 1

According to Visinescu,⁵ Bluetooth currently represents the best option for a personal area network for medical applications. As shown in the figure, we used weight scales and a blood pressure meter as medical devices and a Sony Ericsson P900 mobile phone as the hub (these devices and the hub were known as the “medical device kit”). The communication between the devices and the hub ran over a Bluetooth connection.

The hub collected and sent the data to the central server. For the uplink, we decided to use GPRS. The advantage of GPRS is that it provides a constant connection and that charges are based on the volume of data transmitted, which was small. For the GPRS service, we chose one of Germany's major mobile network providers to ensure high network coverage.

The back-end server was provided and maintained by the IBM team. It aggregated the data and stored the values in a database. The nursing staff was able to access this database with a remote Web client. The Web client was built on a Java** applet to ensure that the data could be displayed in real time.

The IBM team verified the received data on a daily basis. If no data was received within a predefined time frame, the IBM team called the patient to check whether the devices had not been used or a technical problem had occurred. All the data collected was exported to a spreadsheet file, which was sent to the nursing staff by e-mail as an additional information resource.

From a security point of view, each medical device kit was assigned an anonymous and unique identifier. This identifier was stored in the application running on the mobile phone and transmitted with each report to the back-end server. The mapping between the identifier and patient was done by the medical staff with the aid of the spreadsheet. This approach had two main advantages. The first was the protection of patient privacy. This meant that no patient names or addresses were stored on the hub or at the server site, and the mapping between patient identifier and personal data was performed externally.

The second advantage was easier handling of the medical device kit. No changes were necessary when assigning a kit to a new patient. The nursing staff only had to record the time frames and to assign the right patient data to the identifier.

Before the start of the pilot study, IBM and the hospital IT department set up the basic IT infrastructure. This included the installation and configuration of the server and Web client and the requisite connections. IBM also trained the nursing staff to use the medical device kit and front-end application.

The pilot study was organized in four runs. During each run, four patients simultaneously tested the IBM health solution for four weeks.

The medical team chose children and teenagers as patients for the trial. This group was targeted because youngsters usually have a higher technical affinity and would, it was hoped, adopt the new system easily. In addition, telemedicine could be particularly useful in this context, as experience has shown that manual blood pressure and weight data taken at home without telemedicine were often incorrect, due to infrequent and irregular measurement. All the children and teenagers selected were patients of the KfH Kidney Center for Children and Adolescents at the University Hospital of Heidelberg and were living in the southern part of Germany. The ages of the patient group ranged from 7 to 23, with an average age of 14.1. The highest number of patients came from the range of 13 through 16 years.

Each family received one of the medical device kits. The families were introduced to the system during their regular visits to the hospital. This included hands-on instruction on how to use the scales and blood-pressure devices and how best to position the mobile phone in the home.

IBM provided a support hotline to assist with any technical problems. The hotline was available during standard office hours. In urgent cases, the patients were able to leave a voice-mail message. In the case of a malfunction of the technical equipment, IBM provided an on-site replacement. As the purpose of this project was to remotely monitor patients, we had to ensure that the data was sent to the back end successfully. For this reason, the patients were not allowed to use the P900 as a normal phone.

After each run, the test family had to return the medical device kit. The results were reviewed and documented, and the patients underwent a medical evaluation, as described by Schaefer et al.⁶

A parallel medical study was conducted to document the results of the pilot study. This study included a statistical analysis of the obtained readings, as well as a questionnaire for the participants and the medical staff. Both parties were asked to provide feedback on usability and their experiences with the solution. In addition, all findings and benefits of the study (both qualitative and quantitative) were recorded.

This section describes the feedback received from the patients, their families, the nursing staff, and IT professionals. It also discusses problems and participants' experiences during the study.

There were no dropouts during the pilot study. Each patient completed the planned test period. During all phases of the study, we received highly positive feedback from the families. The patients were very pleased with the system; they felt more comfortable with it because it did not remind them constantly of the seriousness of their illness. Instead of writing down every measurement and calling the doctor once a week, the patients simply needed to step onto the scales and use the blood-pressure meter. Since all measurements were transmitted automatically and were immediately available to the medical team, patients and their families felt relief at not having to shoulder the burden of medical responsibility.

At the time of this writing, 12 patients had been interviewed about their feelings and experiences with the system. These interviews took place after the patients completed the test period, normally after four weeks, and were performed by the hospital using a questionnaire. Eleven of the 12 patients found the system easy to use. Ten patients saw advantages to using the technology for their dialysis treatment. Several families expressed relief because they could more easily share treatment responsibilities with the medical staff. Six patients, mostly teenagers, perceived the sending of their health data electronically as putting them under observation. If they could choose to continue to use this system beyond the scope of the pilot project, eight of 11 answering patients would do so, while three patients would not.

The hotline was used very rarely, indicating that the implemented system was quite stable and easy to use. The main issues encountered were medical equipment malfunctions. In such cases, the IBM team replaced the equipment.

Due to problems with the hospital network at the beginning of the project, during the first three weeks the nursing staff was not able to connect to the Patient Monitor Web site to see the measurements taken by the patients. During this phase, we sent a spreadsheet containing the measurements and some diagrams to the staff on a weekly basis. When the network problem was resolved, the medical staff checked all measurements obtained with the four test systems once daily. In the event of critical changes in the recorded values, the families were contacted by phone and instructed to change the treatment modalities.

Although the solution was well accepted by the medical staff, we received a number of suggestions for improvements regarding usability and the presentation of measurements. Specifically, there was a need to adjust the dimensions of the graphical display. It was also deemed important to include age-specific reference values for blood pressure. In addition, the medical professionals would have liked to have been able to generate descriptive statistics covering variable time frames online. They asked for a function to export data from the Web site in one of the standard spreadsheet file formats for further statistical analysis. Lastly, they requested an automatic alarm system to notify the medical team when measurements fell outside of an acceptable range.

The medical staff expressed the need to support other medical devices, such as other blood-pressure measuring devices and weight scales that are certified for medical use in Germany and are more suitable for children. They also said they would like to be able to monitor the status of the dialysis device remotely in addition to patient blood pressure and weight. Being able to receive event information from the dialysis device in combination with the medical data would allow them to fine-tune the therapy effectively.

Even though the pilot study was a success and the nursing staff were able to rapidly recognize instances of deterioration in response to therapy, we faced a number of technical issues at the beginning of this project that had to be solved by the IT professionals.

We were using one wireless connection to send the data to the phone and another to send it to the back end. Most of the problems arose in this area. Some patients living in rural areas and near borders had either poor reception or no reception at all. Otherwise, the GPRS connection between server and phone was very stable. In contrast, the Bluetooth connection between the medical devices and phone was not always reliable. The medical devices sometimes stopped sending data over Bluetooth, and we found that other Bluetooth devices could interfere with our system. Normally, the blood-pressure device and the scales tried to send data to the same hub that they had used the previous time. If this device was not available or not reachable due to interference, the medical device searched for other Bluetooth devices. This feature is essential when the hub needs to be replaced because it enables the medical devices to discover and find the replacement hub and send data to it, but in a busy environment where several Bluetooth devices are available, this can cause problems.

Another issue arose because of the strictly managed hospital network, which uses proxies for external communication. These proxies necessitated modifications to the client routing table and network configurations (allowing a direct connection to the back-end server) in order for the solution to function. In the future, the applet and back end can be modified so that they can work through proxies without these modifications and configuration changes.

Because the patients were young teenagers and children, we had to ensure that the blood pressure cuffs would fit their arms, and we were able to obtain pediatric-size cuffs from our vendor. Unfortunately, during the pilot study, we experienced erroneously high blood-pressure readings in measurements taken from small children in comparison with our reference blood-pressure device. When this issue was raised with the vendor, we were told that the blood-pressure meter used for the study was not intended for use with small children. As a consequence, we only accepted new patients for whom the cuffs fit properly.

One of the purposes of this pilot study was to gather real-world experience and data for evaluation and for medical studies. At the end of the project, the lead investigator presented the results of the study at a press event in Heidelberg.

The project has shown that a clear medical benefit can be gained from the technology used in the pilot study. We identified a distinct set of requirements with regard to the functionality of the platform. In many countries, access to and use of medical data are governed by strict data protection laws, and this is an area that requires additional work in the future, both to understand the detailed nonfunctional requirements and to implement a telemedicine system within the context of a working medical environment such as that found in a hospital or clinic.

Considerations relating to the scalability of the solution to enable hundreds, thousands, or millions of patients to use such a system also need to be explored in more detail. Particularly at the sensing device and at the hub level, such concerns can become the most significant cost factor in a telemedicine project.

In addition to documenting our experiences with a real-life telemedicine project, this paper raises a number of questions about how, why, and where telemedicine can effectively and efficiently be used to benefit patients:

• How can a telemedicine platform based on standard technology be financed? There are a number of absolutes in health-care financing, but each country has its own unique circumstances.

• Is telemedicine a means to reduce direct or indirect costs? Can it be used to encourage clients to change their health insurer?

• Is there a way to use telemedicine to extend the physical reach of doctors?

These are crucial questions that need to be answered in order to advance the development of the telemedicine market.

**Trademark, service mark, or registered trademark of the Bluetooth SIG, Inc., Zigbee Alliance Corporation, or Sun Microsystems, Inc. in the United States, other countries, or both.

Accepted for publication May 15, 2006; Published online December 12, 2006.