Healthcare to go: the MobiHealth system
Mobile health monitoring using wireless networks, E&T investigates.
If you're sick, you go to the doctor. However, the emergence of high-bandwidth public wireless networks and miniaturised mobile computers is making it increasingly likely that, in future, the doctor will come to you - at least virtually.
Mobile healthcare services, such as the MobiHealth system with which we are involved, will remotely monitor the vital signs of patients and provide them with feedback using a body-area network (BAN) connected to a mobile-healthcare service platform over a next-generation wireless network.
We're trying to make it possible for patients to be able to send full, detailed and accurate vital signs measurements to a healthcare provider, and to receive medical advice from a distance, irrespective of where they are and when they need the information. We want to achieve an equivalent quality of data to that obtained in a medical centre, implementing the concept of 'ubiquitous medical care'.
The MobiHealth project, initially supported by the European Commission's Fifth Framework programme, ran from 2002 to 2004 and began developing a value-added mobile health service platform for patients and health professionals. The resultant service platform became known as MobiHealth, and was further developed through the European HealthService24 research project, a Dutch national project known as Freeband Awareness (which ran from 2004 to 2008), and the current European MyoTel project (funded under the Seventh Framework Programme).
The resultant MobiHealth Service Platform is owned by MobiHealth BV, a 2007 spin-off from the University of Twente. It enables remote patient-monitoring and treatment by combining advanced wireless communications with a wireless body area network linked to sensors. It makes it possible for doctors and other healthcare professionals to manage chronic conditions remotely and also to detect health emergencies without immobilising the patient.
The MobiHealth system includes sensors that continuously monitor a patient's vital signals, such as blood pressure, heart rate, respiration, and the electrical activity of the heart. A wireless BAN links the sensors, actuators, communication and processing facilities, which are all worn about the patient's body. The heart of the system is a mobile base-unit (MBU), which aggregates the vital sensor measurements and transmits them using a high-bandwidth mobile network to an application server, which would usually be located within the healthcare provider's premises. The server dispatches the measurements to the healthcare provider, where they are examined by medical personnel. It's equally possible to automatically monitor and provide patient feedback through the MobiHealth system.
Communication between entities within the BAN uses short-range wireless networks such as Bluetooth, while links to the application server are provided over 2.5/3/3.5G wireless technologies or Wi-Fi.
The sensors on the MobiHealth system monitor and capture a physical phenomenon, such as patient movement, heart rate, muscle activity or blood flow, and convert it to an electrical signal, which is then amplified, conditioned, digitised and communicated within the BAN. The sensors can be autonomous, or rely on a local front-end. Autonomous sensors have their own power supply and facilities for amplification, signal conditioning, digitisation and communication. This means they can be used as independent building blocks in a BAN, making it highly configurable. The technical challenge with this approach lies in the fact that each sensor runs to its own internal clock and may have its own sampling frequency. This means it may be necessary to develop synchronisation mechanisms between the sensors. Front-end supported sensors share a common power supply and data-acquisition facilities, which means that they typically share a front-end clock and jointly provide multiplexed sensor samples as a single data block. This avoids the need for synchronisation between sensors.
We have experimented with implementing the MobiHealth healthcare BAN using both front-end supported and autonomouse sensors. We've used a TMSI front-end with a four-lead electrocardiogram (ECG) sensor and respiration belt. It uses Bluetooth for communication with the BAN. ECG electrodes, a movement sensor, a temperature probe, pulse oximeter and an alarm button could also be attached to this front-end. The mobile base unit was implemented on an HTC PDA.
Service platform architecture
The healthcare BAN is only one part of the MobiHealth service platform, which integrates the mobile part with an application server back-end. The diagram above shows the overall functional architecture of the MobiHealth service platform as it is today. The square boxes show where parts of the service platform are executed. The rounded boxes represent the functional layers of the architecture. The m-health service platform consists of sensor and actuator services, intra-BAN and extra-BAN communication providers and an m-health service layer. The m-health service layer integrates and adds value to the intra-BAN and extra-BAN communication providers.
Applications that run on top of the service platform can either be deployed at the mobile base unit for on-site use - for example by a visiting nurse - or at the application server in the healthcare provider's domain. Applications that use the m-health service layer can range from simple viewer applications that provide a graphical display of the BAN data, to complicated applications that analyse the data and provide personalised feedback to a patient.
MobiHealth system trials
The MobiHealth project set out in 2002 to discover whether 2.5G and 3G communications networks could enable remote managed care based on mobile healthcare systems. In the HealthService24 project we researched the market potential for remote monitoring systems. In the current MyoTel project, we're researching the market potential for myo-feedback-based remote monitoring and treatment systems for patients suffering from chronic shoulder/back pain. The Freeband-Awareness project tried to develop a context-aware service platform, by adapting service delivery to the user's location, time and activity.
To address each question, we ran trials using the MobiHealth system. The trials also enabled us to elicit detailed end-user requirements and to identify issues in the development of mobile health services. They also allowed us to identify shortcomings in the existing and forthcoming service and networks infrastructure.
The trials were targeted at acute care, chronic and high-risk patient monitoring, and home care. A range of medical conditions was covered including high-risk pregnancy, trauma, cardiology (arrhythmia), rheumatoid arthritis and respiratory insufficiency (chronic obstructive pulmonary disease - COPD). The HealthService24 trials focused on high-risk pregnancy, cardiac arrhythmia and COPD. The Freeband-Awareness trials focused on epileptic and spasticity patients. The MyoTel project trials focused on monitoring and treatment trials for patients suffering from chronic shoulder/back pain. In this trial, feedback (auditory, tactical or visual) is sent to the patient if the system observes that he/she tenses the shoulder-back muscles for longer than 15 minutes.
In each project, the basic end-user requirement included lossless and in-order data delivery. Moreover, the trials represented a range of bandwidth requirements: low (less than 12 kbit/s), medium (12kbit/s to 24 kbit/s) and high (greater than 24kbit/s). The system also had to handle both delayed data, such as non-real-time - for example, a routine transmission of tri-weekly ECG data - and real-time requirements, such as the transmission of alarms or vital signs in the case of an epileptic seizure. For each application, the generic MobiHealth BAN was customised with the appropriate sensor set and corresponding application software.
From the MobiHealth project trials, we learned that mobile remote monitoring of a patient's vital signs is possible over GPRS and UMTS public networks. We discovered that these public networks are designed for applications where the end user is a consumer of information, that is, where a typical user will send small amounts of data and receive large amounts of data. The MobiHealth system, however, is based on the reverse model: the end-user is the producer of information and not the consumer.
The network and terminal devices in their current configuration are not designed to support high-bandwidth transmission emanating from the end user, which limits the volume of data that the MobiHealth system user can send to the application servers. We also encountered a set of standardisation and interoperability issues when setting up the consecutive generations of a prototype of the MobiHealth system.
Already in the MobiHealth project we have proved that mobile remote monitoring of patients is potentially cost-saving, as it reduces frequent routine examination at hospital and increases a patient's quality of life. The HealthService24 trials showed that GPRS/UMTS networks are sufficiently reliable for non-critical cases and, as with the later MyoTel project, that remote monitoring of patients saves money because it changes the ratio of care professionals to patients. We proved that there is a market potential. However, trial members wanted the body area network devices to be miniaturised, better integrated and to offer more than eight hours of battery life.
The trials also enabled us to develop application protocols for health monitoring and treatment that adapt to the location and activity of the patient being monitored and treated. In this project we also elicited requirements and prototyped solutions for security and privacy in the MobiHealth system.
The path to MobiHealth BV
The MobiHealth project was spun off as a company in 2007, with the aim of giving patients a more active role in the healthcare process while at the same time enabling healthcare payers to manage costs more efficiently. The healthcare BAN and supporting MobiHealth Service Platform are emerging technologies that support this aim.
The first BAN prototype emerged in spring 2002, engineered mainly by integrating existing technologies without focusing on miniaturisation or optimisation of power consumption. Instead, we focused on the architecture, design and implementation of an m-health service platform. The result was a first version of a service platform whose architecture is comprised of a set of clearly defined components. In further research projects, we researched precise end-user requirements and developed the service platform accordingly. The current MobiHealth Service Platform is a versatile remote mobile monitoring system that enables patient mobility, and supports different modes of data transmission (such as standalone monitoring, non-real-time and real-time with delays below one second), while synchronising all wireless sensor systems data.
The platform supports up to eight wireless sensor systems. It is scalable for large-scale mobile remote health monitoring and treatment, and flexible enough to support any new (wireless) sensor and actuator systems as they emerge. We have also researched ways to make automatic health monitoring applications adapt to changing network characteristics, and application resiliency during network handovers.
We're now researching business models for healthcare, and accounting and billing models for network services. We're using open standards where we can, while recognising that specialisation, customisation and personalisation are widely considered to be important to the success of innovative health monitoring and treatment services.