Mobihealth: Mobile Health Services Based on Body Area Networks

This Technical Report is also published as Chapter 16 IN M-Health: Emerging Mobile Health Systems, Robert H. Istepanian, Swamy Laxminarayan, Constantinos S. Pattichis, Editors, 2006. Springer. 624 p. ISBN: 0-387-26558-9 As MOBIHEALTH: MOBILE HEALTH SERVICES BASED ON BODY AREA NETWORKS Val Jones*, Aart van Halteren, Ing Widya, Nikolai Dokovsky, George Koprinkov, Richard Bults, Dimitri Konstantas and Rainer Herzog. . * Val Jones, Centre for Telematics and Information Technology/Faculty of Electrical Engineering, Mathematics and Computer Science, University of Twente, PO Box 217, 7500 AE, Enschede, The Netherlands, [email protected]. 2 V. M. JONES ET AL. MOBIHEALTH: MOBILE HEALTH SERVICES BASED ON BODY AREA NETWORKS Val Jones*, Aart van Halteren, Ing Widya, Nikolai Dokovsky, George Koprinkov, Richard Bults, Dimitri Konstantas and Rainer Herzog. 1. INTRODUCTION In this chapter we describe the concept of MobiHealth and the approach developed during the MobiHealth project (MobiHealth, 2002). The concept was to bring together the technologies of Body Area Networks (BANs), wireless broadband communications and wearable medical devices to provide mobile healthcare services for patients and health professionals. These technologies enable remote patient care services such as management of chronic conditions and detection of health emergencies. Because the patient is free to move anywhere whilst wearing the MobiHealth BAN, patient mobility is maximised. The vision is that patients can enjoy enhanced freedom and quality of life through avoidance or reduction of hospital stays. For the health services it means that pressure on overstretched hospital services can be alleviated. During the project a generic BAN for healthcare and a generic m-health service platform was developed, trialled and evaluated. The MobiHealth BAN incorporates bodyworn devices and handles communication amongst those devices. The MobiHealth Service Platform manages (a population of) deployed BANs and handles external communication between the BANs and a remote healthcare location. During the course of the project the main BAN devices used were medical sensors. Biosignals measured by sensors connected to the BAN were transmitted to a remote healthcare location over 2.5/3G public wireless networks (GPRS and UMTS). The MobiHealth BAN and service platform were trialled in four European countries with a variety of patient groups. The trials focussed on home care, trauma care and outdoor settings. The remote healthcare locations involved were hospitals in Spain, The Netherlands and Sweden and a medical call center in Germany. The remote monitoring * Val Jones, Centre for Telematics and Information Technology/Faculty of Electrical Engineering, Mathematics and Computer Science, University of Twente, PO Box 217, 7500 AE, Enschede, The Netherlands, [email protected]. MOBIHEALTH: MOBILE HEALTH SERVICES BASED ON BODY AREA NETWORKS 3 services allow patients to follow their normal daily life activities rather than being confined to hospital or to their home during monitoring. The overall goal of MobiHealth was to evaluate the ability of 2.5 and 3G communication technologies to support innovative mobile health services. The main output of the project therefore is an assessment of the suitability of GPRS and UMTS to support such services. In addition the project delivers an architecture for, and a prototype of, a health BAN and a generic m-health service platform for provision of ubiquitous healthcare services based on Body Area Networks. The MobiHealth concept arose out of work at the University of Twente since 1999 (Jones et al., 1999; Jones 2001) and was further developed within the work of the Wireless World Research Forum (Jones et al., 2001b; Jones et al., 2001c; WWRF, 2001). The MobiHealth consortium involving 14 European partners was brought together during 2001. The project began on May 1st 2002 and is funded by the European Commission under IST FP5 and has been reported in (Jones et al, 2001a; Konstantas et al., 2002a,b; Widya et al., 2003a, Dokovsky et al., 2003). The project coordinator is Ericsson GmbH with the University of Twente taking the scientific lead. The MobiHealth System can support not only sensors, but potentially any body worn (medical) device provided it has a communication interface. (An example of another kind of device already used with the BAN is a Bluetooth enabled digital camera.) Hence the system has potentially very many applications in healthcare. Some of these are explored in other chapters in this book. The chapter entitled Telematic Reequirements for Emergency and Disaster Response (Widya et al, 2003b) models the extension of the MobiHealth Trauma application to large scale disaster and emergency scenarios. Another chapter entitled Remote Monitoring for Healthcare and for Safety in Extreme Environments (Jones et al, 2003) examines the potential of the MobiHealth approach for provision of remote monitoring services to support work and recreation in extreme environments. That chapter focuses on polar and underwater environments as examples. This remainder of this chapter presents the MobiHealth technology (Section 2), the trials and the evaluation (Section 3), and identifies some of the research issues raised by the project (Section 4). 2. THE MOBIHEALTH TECHNOLOGY A mobile health BAN and a generic service platform for BAN services for patients and health professionals were developed as part of the work of the MobiHealth project. Remote (patient) monitoring services are just one of the kinds of services that can be provided by such a platform. Here we focus on monitoring as an example of BAN services in order to present the MobiHealth technology. A wide range of patient monitoring equipment is used in healthcare. Traditionally monitoring equipment was operated by health professionals in hospitals or at other healthcare locations. Some of the equipment is quite bulky and heavy, but for some kinds of monitoring the use of small ambulatory monitors together with telemetry has improved mobility for patients within the hospital. Nowadays there is an extensive range of miniature wearable monitors available. Some are on sale to the public as consumer electronics products. A wrist worn blood pressure and heart rate monitor can be purchased for as little as 30 Euro. Such products can be used for example by cardiac patients to monitor their own health state and response to 4 V. M. JONES ET AL. medication. Another wrist-worn device allows diabetes patients to monitor their blood glucose non-invasively. Some products provide local processing only (such as readouts, logging of readings, reminders, warnings and alarms). Some also allow upload of data to a PC whilst others combine monitoring and (tele)communication functions. One example is a cardiac monitoring product embedded in a mobile phone, which transmits cardiac signals to a doctor or a to a distant healthcare location over public cellular networks. Some products incorporate positioning to provide positioning information in case of emergency so that the emergency services can locate the casualty easily. There are also many examples of commercially available wearable monitoring systems targeted at nonpatients. Examples are heart monitors for use by athletes during training and motion sensors and gas sensors used to protect workers in the chemical industry. With so many devices available, why do we need to introduce the concept of a Body Area Network? In the next section we explain the concept of Body Area Networks (BANs), and why we apply a BAN approach in MobiHealth. 2.1. Body Area Networks The concept of the Body Area Network originally came from IBM (Zimmerman, 1999) and was developed further by many other researchers, for example at Philips (van Dam, 2001), at the University of Twente (Jones et al., 2001a; Jones et al., 2001b), and at Fraunhofer (Schmidt, 2001). In the Wireless World Research Forum’s Book of Visions, we define a BAN as “a collection of (inter) communicating devices which are worn on the body, providing an integrated set of personalised services to the user” (WWRF, 2001). For the purposes of the MobiHealth project a BAN can be thought of simply as a computer network which is worn on the body and which moves around with the person (that is, it is the unit of roaming). A BAN incorporates a set of devices which perform some specific functions and which also perform communication, perhaps via a central controlling device. Devices may be simple devices such as sensors or actuators, or more complex multimedia devices such as cameras, microphones, audio headsets or media players such as MP3 players. The central controlling device (if there is one) may perform computation, coordination and communication functions. Communication amongst the elements of a BAN is called intra-BAN communication. If the BAN communicates externally, i.e. with other networks (which may themselves be BANs), this communication is seen (from the point of view of the BAN itself) as extra-BAN communication. 2.1.1. Intra-BAN Communication IntraBAN communication is carried over a wired or a wireless medium. Wired options include copper wires, of course, also optical fibre and many ‘wearable computing’ solutions where circuitry is embedded in or woven into or printed onto fabric or incorporated into ‘body furniture’ such as spectacles or jewelry. Wireless options include infrared light, microwave, radio and even skin conductivity. Two important standards for short range wireless communication are Bluetooth and Zigbee. Bluetooth (Bluetooth, 2003) is an example of a wireless communication standard (IEEE 802.15) based on radio waves. It supports speeds of up to 721 Kbps and offers a user-friendly way of ‘ad hoc’ networking providing automatic admission and removal of devices in a network. The range is up to approximately 100m. Although a very attractive MOBIHEALTH: MOBILE HEALTH SERVICES BASED ON BODY AREA NETWORKS 5 technology for BANs, the relatively high power consumption for wireless transmissions make long term unattended use of a Bluetooth BAN problematic. ZigBee (ZigBee Alliance) (also known as RF-lite) is a low cost, low power, two-way wireless communications standard (IEEE 802.15.4) and is particularly promising for BANs. ZigBee supports a relatively low data rate (< 250 Kbps), but combines this with long battery lifetime. The range is approximately 50m. 2.1.2. Extra-BAN Communications To support convenience and mobility for the BAN user, extra-BAN communication is in general based on wireless technologies. A range of technologies is available including Bluetooth, WLAN, GSM, GPRS and UMTS. The selection of transmission technology will depend largely on range and (transmission) speed requirements. There are other important criteria (e.g. reliability, security) for communication links, but these can be fulfilled by application level protocols. Bluetooth and WLAN (Wireless Local Area Network) are short and medium range communication technologies (Bluetooth 10m and WLAN 100m) and depend on a local infrastructure (within a building for example). GSM, GPRS and UMTS are wide area technologies, offering the possibility for the wearer of the BAN to be truly mobile (i.e. have the freedom to go anywhere without losing connectivity). GSM (also called 2nd Generation, or 2G, technology) is as a voice network and has national coverage in many countries. Pan-European coverage is made possible by means of international agreements between network operators. GSM can also be used as a data network and offers a minimum guaranteed speed of 9.6/14.4kbps. GPRS (an instance of the so-called 2.5G technologies) is a voice and data network running over the GSM infrastructure. GSM timeslots not assigned to voice connections can be used for data transmission, however voice has priority, creating potential quality of service problems for data transmission. GPRS offers transmission speeds of up to ~50kbps. New technological developments are expected to result in increased speed for GPRS communications. UMTS (a 3G technology) promises wideband communication speeds of up to 2Mbps. At time of writing UMTS rollout is underway but with coverage limited to heavily populated areas (e.g. urban areas). Initial UMTS networks are expected to support a transmission speed of 64kbps, with an option for 144kbps. 2.1.3. Body Area Networks for Healthcare The Body Area Network is a generic concept which can have many applications in various domains. When the devices of a BAN measure physiological signals or perform other actions for health-related purposes we call this kind of specialization of Body Area Networks a health BAN. As a further specialisation, a BAN whose devices are biosignal sensors enables patient monitoring. Clearly there can be different kinds of sensors for monitoring different biosignals. Thus we can envisage any number of specific health BANs for specific classes of patients/clinical conditions. Some example applications are: cardiac care, diabetes management, sleep analysis, asthma, epilepsy, EEG/EMG monitoring, SIDS, care of the elderly, assistive technologies for the disabled, movement analysis, feedback on medication (e.g. for Parkinsons disease), monitoring of drug delivery systems (e.g. morphine or insulin pump) and home cancer care. 6 V. M. JONES ET AL. If we combine health BANs with extra-BAN communications this enables remote monitoring of patients. This can be achieved by means of fixed networks, such as a fixed (wired) telephone line or an Internet connection, allowing the patient to be monitored at home instead of in hospital for example. However the fixed line limits the mobility of the patient to a fixed position during monitoring, or at least during regular uploading of locally stored monitor data. Store and upload is only feasible when there are no real-time requirements (such as emergency detection and alarms) and is dependent on storage capacity of the wearable device. Some applications generate only small amounts of biosignal data, but others are very data intensive. For example epilepsy monitoring with 32 channels generates 400-500 MB per day and 128 channel monitoring brings (daily) storage requirements into the Gigabyte range. Combining BANs with extra-BAN wireless communications enables remote (ambulatory) monitoring and full mobility for the patient with support of real-time applications. This means that the patient can pursue normal life activities, leave the house and even travel anywhere in the world, insofar as their health condition permits. In other words wireless communication services open up the possibility of location freedom (global roaming) for patients who are undergoing monitoring. In the following section we describe the approach of the MobiHealth Project to the use of health BANs for remote monitoring of patients. 2.2. The MobiHealth Body Area Network One problem with some of the currently available monitoring devices is that they are closed proprietary (non-interoperable) systems; some even operate in a standalone fashion with no option to upload measurements. Whilst these devices have utility and have clearly found a market, the usefulness of such devices can be enhanced in a number of ways. The vision of the MobiHealth project is to develop an open extensible BAN platform which allows integration of different health functions by means of a (wireless) plug-and-play approach. The use of the MobiHealth BAN together with 2.5/3G communications means that biosignals measured by the BAN can be transmitted to a remote (healthcare) location. This enables remote management of chronic conditions and detection of health emergencies whilst giving the patient the freedom to move anywhere outside the hospital. At time of writing the MobiHealth system is being tested by patients and health professionals in home care, trauma care and outdoor settings. The MobiHealth BAN also features in a sister project called xMotion where it is integrated into a UMTS based teleambulance demonstrator (xMotion, 2002).). 2.2.1. Architecture of the MobiHealth system The MobiHealth BAN consists of a central unit known as the MBU (Mobile Base Unit) and a set of body-worn devices, which may include sensors, actuators, and various multimedia devices. In principle the BAN may incorporate any wearable or implantable devices. Figure 1 shows the generic architecture of the BAN. MOBIHEALTH: MOBILE HEALTH SERVICES BASED ON BODY AREA NETWORKS 7 Figure 1. Generic architecture of the BAN. The MBU can be thought of as a gateway which handles extraBAN communication. It also handles coordination, local computation and communication amongst BAN devices. It can also host local applications such as a local viewer application, or (in future) more complicated functionality such as disease management applications. In MobiHealth the MBU was implemented on an iPAQ H3870. This device has builtin Bluetooth capabilities and can be extended with a GPRS jacket. Figure 2 shows the MBU running a viewer application to display biosignals measured by a sensor (in this case pulse plethysmogram measured by a pulse oximeter). Figure 2. MBU platform (iPAQ H3870), displaying output from pulse oximeter Sensor data is processed by a sensor front-end before being transmitted to the MBU. A range of front-ends can be associated with an MBU, enabling customization of the BAN. Although the MBU currently used in the MobiHealth trials is based on the HP iPAQ platform, future plans include porting to a cell phone platform such as the Sony Ericsson P800. The hardware components of a BAN are shown in Figure 3 which shows (left to right) an MBU, a sensor front-end (known as a “Mobi”) and a sensor set consisting of ECG electrodes and a motion sensor. 8 V. M. JONES ET AL. Figure 3. MBU, sensor front-end end and a sensor set The BAN is only part of the overall MobiHealth system. Figure 4 shows the hardware and software architecture of the MobiHealth system. The lower part of the figure shows the hardware configuration and the upper part shows the software components developed during the course of the project to implement the MobiHealth BAN and its support services. The MobiHealth system includes not only the BANs deployed in the community but also the Back End System (BESys). The BESys is the m-health service runtime environment, which hides the mobile nature of the service provider components (MBUs) and exports the service to the local environment of the healthcare centre. It is composed % # $ " & '( # $ % & ) " & , ! A ( + Figure 4. Hardware and software architecture , ! +, ! - % * MOBIHEALTH: MOBILE HEALTH SERVICES BASED ON BODY AREA NETWORKS 9 of several software components which may reside on one or more hardware nodes. Data is exchanged between the BAN and a remote (healthcare) location, which has its own (perhaps legacy) systems in operation. If the remote healthcare location is a hospital then this would be the HIS (Hospital Information System). The MobiHealth Back End System mediates between the HIS and the BAN. The Back End System may be located at the hospital or at another location entirely. The BAN is shown here with a set of sensors (S), a set of actuators (A) and a set of other devices, all connected (wired) to the sensor front end (FE). The FE communicates with the MBU wirelessly (over Bluetooth). The MBU software stack contains the BANware implemented on top of a Java virtual machine (J2ME, CDC and Personal profiles) (Sun Microsystems, 2003a) running under Linux. The Back End System runs on a server (possibly at the healthcare location, possibly at another site); it incorporates a Look Up Service (LUS) and hosts a surrogate, which represents and manages the BANs in the field. The end-user application may consist simply of a viewer application or (in future) some much more complex suite of applications interfacing to the clinical systems of the healthcare provider. The software components of the MobiHealth system were developed at the University of Twente and are available as Open Source software. 2.2.2. BAN Devices The generic BAN is customized with different device sets for different applications. Some of the BAN devices used during the MobiHealth project are electrodes for measuring ECG, pulse oximeters for measuring oxygen saturation, sensors for measuring NIBP (non invasive blood pressure) and motion sensors. A sensor is responsible for the data acquisition process. A sensor system ensures that a physical phenomenon, such as patient movement, muscle activity or blood flow, is first converted to an electrical signal. This signal is then amplified, conditioned, digitized and communicated within the BAN. Sensors can be either self-supporting or front-end supported. Self-supporting sensors have their own power supply and facilities for amplification, conditioning, digitization and communication. In case of front-end supported sensors, multiple sensors share a power supply and data acquisition facilities. Consequently, front-end supported sensors typically operate on the same front-end clock and jointly provide multiplexed sensor samples as a single data block. This avoids the need for synchronization between sensors. Self-supporting sensors are independent building blocks of a BAN and ensure a highly configurable BAN. However, each sensor runs at its own internal clock and may have a different sample frequency. Consequently, synchronization between sensors may be needed. The sensors used in the MobiHealth trials are: electrodes for measuring ExG (where ExG can stand for ECG, EMG or EEG), activity sensors, respiration sensors and pulse oximeter. Other BAN connected devices apart from sensors are: marker/alarm button and digital camera. Readings from external devices (such as NIBP or forced spirometry) can be entered manually on the MBU for transmission. 10 V. M. JONES ET AL. 2.2.3. Intra-BAN Communications The MobiHealth architecture allows for wired or wireless communications within the BAN, or a combination of the two. The current MobiHealth trials use wired communication from sensors to sensor front end and Bluetooth from the front end to the MBU. However the BAN has actually been implemented using both wired (front-end supported) sensors from TMSI and wireless (self-supporting) sensors from EISlab (Östmark et al, 2003). Both approaches use Bluetooth for intra-BAN communication. The front-end also allows ZigBee as an alternative intra-BAN communication technology. 2.2.4. Extra-BAN Communications For communication between the BANs and the Back End System (extra-BAN communication), 2.5/3G public networks are used. The MBU communicates via Bluetooth to a GPRS or UMTS handset (cell phone); from there the signals are transmitted to the remote location. In order to abstract from wireless transmission technology, BAN to Internet communication, and vice versa, is based on the IP protocol. National GPRS coverage is available in all the countries where the trials are conducted (Germany, The Netherlands, Spain and Sweden). The first localised UMTS (test) infrastructures became available in Germany and the Netherlands part way through the project (during 2003). At time of writing the Dutch trials were using both GPRS and UMTS for extraBAN communication. In the other trial countries GPRS was being used, with early prospects for UMTS tests. Availability of commercial UMTS services will broaden the range of applications which can be supported by the BAN. 2.3. The MobiHealth m-health Service Platform The m-health service platform supports the BAN based applications and isolates them from the details of the underlying communications services. It is this service platform which enables genericity and hardware independence. Hardware independence has already been demonstrated by use of sensors from different manufacturers and by the initial experiments with replacing the PDA implementation of the MBU by a cell phone implementation. 2.3.1. Service Platform Architecture Figure 5 shows the functional architecture of the service platform. The dotted square boxes indicate the physical location where components of the service platform execute. 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 intra-BAN and extra-BAN communication providers represent the communication services offered by intra-BAN communication networks (e.g. Bluetooth), and extra-BAN communication networks (e.g. UMTS), respectively. The m-health service layer integrates and adds value to the intraBAN and extra-BAN communication providers. The m-health service layer masks applications from specific characteristics of the underlying communication providers, MOBIHEALTH: MOBILE HEALTH SERVICES BASED ON BODY AREA NETWORKS 11 such as the inverted consumer-producer roles. Applications Applications Sensor / Actuator Services M-health service layer Intra BAN communication provider Sensors Mobile Base Unit (gateway + host) Extra BAN communication provider Computing infrastructure (Healthcare provider) Figure 5. Service platform functional architecture Applications which run on top of the service platform can either execute on the MBU (for local use by the patient or by a visiting nurse for example) or on the servers or workstations of the healthcare provider, for example at a health call centre or hospital. The services offered by the M-health service platform are: • BAN registration: the service platform maintains a list of active BANs and allows applications to retrieve the specific configuration of a BAN. • BAN discovery: applications can subscribe to the platform in order to receive a notification when a BAN becomes active (e.g. when a patient switches on a BAN). • BAN authorization and authentication: the service platform authenticates BANs and only allows authorized BANs to transfer data. • BAN data encryption: the platform encrypts data to be transmitted over unsecured networks • BAN configuration: the service platform allows online configuration and management of the BANs, such as activation and deactivation of specific sensors, or modification of sensor sampling frequency. • Data acquisition control: the service platform enables applications to start, stop or temporarily suspend the data acquisition process of a BAN. • Query and modify actuator status: applications can manipulate actuators from a distance. • BAN data storage: the service platform also offers intermediate storage services for the applications. The application can specify the minimum required lifetime of the stored data. • BAN data monitoring: the service platform can apply filtering algorithms to BAN data to determine if a significant event has taken place (e.g. a patient has fallen) and report this event to the application layer. Figure 6 shows a refined view of the m-health service layer. In this figure the m-health service platform user (e.g. a doctor at a hospital) is located remotely from a healthcare provider (in this case a health call center). The arrows indicate the flow of BAN data. The BANip entity is a protocol entity of the BAN interconnect protocol. Peer entities are found on the MBU and on the computing infrastructure (in the ‘fixed’ network). The BANip entities communicate through a proxy, which authenticates and authorizes the 12 V. M. JONES ET AL. BANs. The surrogate component uses the BANip protocol to obtain BAN data. It contains a representation of the deployed BANs (i.e. surrogates). The surrogate component is deployed in the fixed network and shields other components in the ‘fixed’ network from the BANip and direct interaction with the BAN (for example it hides the intermittent availability of the BAN and the use of private IP addresses (Rekhter et al., 1996) for GPRS terminals). Thus it solves the problems arising from the invertion of producer and consumer roles. The surrogate component can be accessed by any application protocol, including Remote Method Invocation (RMI). The storage entity uses RMI to interact with the surrogate as if it interacts with the remote BAN at the location of the patient, without the responsibility of managing BAN discovery, registration and authentication. The surrogate component is therefore the intermediary to which BAN data from the location of the patient is pushed and from which BAN data is pulled by the application component running in the hospital systems. BAN data may also be pushed by the surrogate to the application component. The storage entity provides a BAN data storage service to the App’s Applications M-health service component BANip Surrogate Proxy BANip RMI Storage RMI Extra BAN communication provider Mobile Base Unit (gateway + host) Call centre Secondary care centre Figure 6. Refined view of the service platform application layer. Configuration, discovery and monitoring services are offered as separate entities and have a similar structure to the storage entity shown in Figure 6. Applications which use the m-health service layer can range from simple viewer applications which provide a graphical display of BAN data to complicated applications which analyse and interpret the clinical data. The Ban Interconnect Protocol (BANip) was implemented using HTTP1.1. The BANip is implemented on the MBU as an HTTP client, which collects a number of samples into the payload of an HTTP POST request and invokes the post on the surrogate. A standard HTTP proxy acts as a security gateway for the surrogate. If the surrogate needs to control the MBU, these control commands are carried as the payload of the HTTP reply. The surrogate was implemented using the Jini Surrogate architecture (Sun Microsystems, 2003b). Jini provides the implementation for auto-discovery and registration of the BAN. In terms of the Jini architecture the surrogate is a service provider. Other components, such as the BAN data storage component, are service users from the perspective of the surrogate. Additional security was added by upgrading the BANip protocol from HTTP to MOBIHEALTH: MOBILE HEALTH SERVICES BASED ON BODY AREA NETWORKS 13 HTTPS. This ensures that BAN data is encrypted while it traverses the public wireless network and the Internet. More details of the BAN service platform implementation may be found in the project deliverables, available at the project website and in (Dokovsky et al, 2003). The following section gives an overview of the MobiHealth trials and evaluation. 3. VALIDATION OF THE MOBIHEALTH APPROACH: TRIALS AND EVALUATION The overall goal of the MobiHealth project is to test the ability of 2.5 and 3G infrastructures to support value added healthcare services. The trials span four European countries and are targetted at the areas of acute (trauma) care, chronic and high-risk patient monitoring and monitoring of patients in home-care settings. The trials cover a range of conditions including pregnancy, trauma, cardiology (ventricular arrhythmia), rheumatoid arthritis and respiratory insufficiency (chronic obstructive pulmonary disease). The trials cover use of patient BANs and health professional BANs (nurse BAN, paramedic BAN). The trials were selected to represent a range of bandwidth requirements: low (less than 12 Kbps), medium (12 – 24 Kbps) and high (greater than 24 Kbps) and to include both non-real time (e.g. routine transmission of tri-weekly ECG) and real time requirements (e.g. alarms, transmission of vital signs in a critical trauma situation). For each application the generic MobiHealth BAN is specialized by addition of the appropriate sensor set and corresponding application software. To illustrate the validation effort we mention here one trial from each participating trial site. . 3.1 Telemonitoring of patients with ventricular arrhythmia In Germany the MobiHealth system is tested and evaluated with a cohort of patients suffering from ventricular arrhythmias who are undergoing drug therapy for this condition. In such patients, ECG measurements have to be taken regularly to monitor efficacy of drug therapy. In this trial the patient BAN transmits ECG and blood pressure via GPRS to a Medical Service Centre, where vital signs are monitored by physicians and nurses. Instead of staying in hospital during monitoring, the patient can be at home and can even go freely outside the home. The intention is that through remote monitoring developing clinical trends can be identified and corrected before they become serious. From a health economic point of view the intervention is expected to save time and reduce costs (eg by reduction in number of hospitalizations, and by lowering drug costs). For the healthcare/medical evaluation blood pressure and ECG readings during the technology intervention are compared to baseline measurements. 3.2 Integrated Homecare in women with high-risk pregnancies This Dutch trial evaluates use of the MobiHealth BAN to support Integrated Homecare for women with high-risk pregnancies. Women with high-risk pregnancies are often admitted to hospital because of possible pregnancy-related complications. Admission is necessary for the intensive monitoring of the patient and the unborn child. Homecare with continuous monitoring of women with high-risk pregnancies, when feasible, is desirable 14 V. M. JONES ET AL. and can postpone hospitalisation and reduce costs. In this trial, pregnant women are monitored from home using the MobiHealth BAN and maternal and foetal signs are transmitted to the hospital. The objective of the trial is to evaluate if such monitoring services can be supported by 2.5-3G communications such that hospitalisation can be postponed and costs reduced. For the healthcare/medical evaluation, main outcome parameters are the number of days in hospital, the number of emergency interventions, patient satisfaction with hospital or telemonitoring and the reliability of the system to monitor the patients and to inform the gynaecologist regarding ECG and EMG data. Although the service, if introduced, is intended for high risk patients, for the trials themselves high risk patients are not included for obvious reasons. . 3.3 Support of home-based healthcare services This Spanish trial involves use of GPRS communication for supporting home-based care for elderly chronically ill patients, including remote assistance if needed. Trial subjects suffer from co-morbidities including Chronic Obstructive Pulmonary Disease. The MobiHealth Nurse BAN is used to perform patient measurements during nurse home visits and the MobiHealth patient BAN is used for continuous home monitoring and also outdoors during patient rehabilitation. It is very important to facilitate patients’ access to healthcare professionals without saturating the available resources, and this is one of main expected outcomes of the MobiHealth remote monitoring approach explored in this trial. Physical parameters measured are oxygen saturation, ECG, spirometry, temperature, glucose and blood pressure. The healthcare/medical evaluation focuses on acceptability of the technology solution in this health context and compares quality and process of care received under the technology intervention with that received under current practice. Comparison is in terms of numbers of in-patient hospital stays, ER visits, outpatient visits, primary care physician visits, social support visits, nurse home visits, prescriptions, phone calls (patient-nurse/ nurse-patient) and transports. 3.4 Home care and remote consultation for recently released patients in a rural area In this Swedish trial the trial subjects are patients with multiple chronic diseases including cardiac failure, diabetes and respiratory disability who have been recently discharged from hospital and who are living at home in a low population density rural area. Measurements (including blood pressure, heart rate, oxygen saturation and blood glucose, as appropriate) are transmitted to a remote physician or a registered district nurse (RDN). The intention is that the remote health professional receives clinical data which offers a better basis for a good and safe decision on whether the patient needs transfer by ambulance to hospital. The expected benefit is that this intervention will reduce the number of cases where the patient is moved to hospital unnecessarily. The healthcare/medical evaluation will focus on qualitative instruments measuring user experiences of the intervention by the involved roles: staff, patients and their next-of-kin. The trials are evaluated in terms of accuracy and validity of measurements, usability of the GPRS and UMTS networks, business and market potential and also in terms of social and ethical effects. MOBIHEALTH: MOBILE HEALTH SERVICES BASED ON BODY AREA NETWORKS 15 All trials are evaluated according to four perspectives: Technology, Healthcare/Medical, Market and Social. It cannot be expected that any definitive clinical outcomes can be established with the patient numbers and timescales involved. In fact under the context of the Call the primary evaluation focus must be on the technology, specifically on the potential for value added services over 2.5 and 3G communications. The results of the evaluation will be available in 2004. 4. FUTURE CHALLENGES AND RESEARCH ISSUES RAISED In the wider context, assessment and evaluation of the value of innovative m-health solutions and the incorporation of worthwhile m-health technologies into existing healthcare systems in terms of structure, organization and working practices presents many challenges. Legal issues and hospital responsibilities such as ownership of the data and legal liability are complicated by the international dimension enabled by the opportunity of seamless access to services for free roaming patients. With the new possibilities come new challenges. These challenges give direction for future research across a range of disciplines. For our own discipline of computing science, we see (horizontal) research issues arising from MobiHealth in connection with adaptive applications and communications, and vertical research issues such as security, quality of service and scalability. Some of these research issues are listed below: Mobile service platforms: how to make scalable, platform independent, generic BAN service platforms which can be rapidly configured for different applications and device sets. Ad hoc networking: investigation of the role of BANs and PANs and the relationship and communication within and between them. How to provide seamless vertical handover between wireless technologies, across the wired/wireless divide and across operator domains. Adaptive applications and IUIs: how to design intelligent adaptive (dynamically reconfigurable) BAN applications, and how to design Intelligent User Interfaces for the resulting BAN services. How to ensure security, privacy, safety, correctness and quality of service of systems and information based on wireless communications infrastructures, ambient intelligent environments and ad hoc networking. Scalability: how to support large populations of deployed BANs as part of offered clinical services. This implies high performance distributed computing, broadband wireless communication and automation of clinical analysis and interpretation. For some applications automated analysis will involve complex real time pattern recognition and application of (temporal) abstraction to effect clinical interpretation. This in turn implies that BAN applications interface to large scale and comprehensive clinical knowledge bases and inferencing systems. Emerging technologies such as GRID computing may play a role at the infrastructure level by providing the fast processing, high volume storage and reliable communication resources required. We expect that in the longer term the current style of implementation of (health) BANs will disappear, replaced by nanoscale devices and contactless sensing from the ambient intelligent environment. We call this vision the Ambient Intelligent BAN or AmI BAN). AmI BAN devices might be implanted rather than worn externally on the body or 16 V. M. JONES ET AL. in clothing. These devices could include for example actuators to control drug delivery systems, nanomanipulators or neural stimulators interfacing directly to motor neurons. The vision of the future depends on scientific research and technological advances not only in computing science but also from other technical disciplines including electrical engineering, physics and nanoscience. Wearable computing, nanotechnologies, contactless sensing, implantable devices and low-power or self-powered devices are some of the enabling technologies prerequisite to the realization of the vision. Together these multidisciplinary developments can open the way for seamless collaboration between BANs, PANs and the ambient intelligent environment. Even for the medium term future many problems remain. Apart from the challenges for computing science and other technical disciplines, experience in many application domains indicates that the success factors for take up of technical innovation come from the larger extra-technical context. These factors include organisational and professional issues from the application domain concerning the impact on ways of working, and user acceptance. In the healthcare domain, first and foremost the technology must gain public acceptance and be perceived as bringing benefits to patients. Of primary concern are potential health benefits, but impact on quality of life for patients and for the patients’ families are also part of the very important patient ‘utility function’. Clinical effects such as efficacy can be addressed by means of clinical trials. Determining the effects of new health technology on process and outcome of care and subjective factors such as user satisfaction and quality of life are the domain of Health Services Research (HSR) studies. Research in the areas of e-health and e-learning indicates that innovation is embraced by users only when they perceive immediate benefits. Regarding the organisational aspects of healthcare, exploitation of a technical innovation may imply extensive and radical business process re-engineering of the (national) healthcare system. Such implications have caused many (technically sound) health technology innovations to fail in the past. Unless business process re-engineering is driven by and accepted by the stakeholders, including the patients, the profession, the payers (eg. health insurance companies) and the policy makers, the most promising health technology innovation is likely to fail. Evolutionary change is more likely to succeed than revolutionary change and we believe that provision of m-health services as a supplementary part of the service package from healthcare providers is one possible path in such incremental change in service delivery. The economic impact of introduction of new technology can also make the difference between success and failure in take-up of the innovation. This is the area of study for health economists. A comprehensive cost benefit analysis should take into account all the direct and indirect financial costs (including cost savings) and set them against the nonfinancial factors, that is the benefits (such as improved health outcomes or increased user satisfaction) and the disbenefits, for all the stakeholders. A further set of challenges involves the ethical, legal and regulatory issues associated with the use of BANs and the offering of mobile healthcare services. 5. CONCLUSIONS At time of writing the MobiHealth project has been running for 17 months (since May 2002). In the rather short duration of the project a great many problems and challenges MOBIHEALTH: MOBILE HEALTH SERVICES BASED ON BODY AREA NETWORKS 17 have been encountered and much progress has been made. The starting point was a vision of ubiquitous mobile health services based on Body Area Networks. During the project we have designed and prototyped a health BAN and a BAN service platform and developed services for different patient groups according to the requirements specified by the clinical partners. Patient trials have begun during which evaluation data will be collected and analysed. MobiHealth has resulted in an early prototype of the BAN, engineered mainly by integration of existing technologies without focusing on miniaturization or optimisation of power consumption. The main focus has been on the architecture, design and implementation of an m-health service platform. The result is a first version of a service platform whose architecture is comprised of a set of clearly defined components. Perhaps ironically, the greater the potential of such services for the population at large, the bigger the problem of scalability of solutions becomes. We believe our solution to be scalable. Each of the service components can be replicated on multiple servers and, with implementation of a load balancing strategy, can serve a large user group. We expect the platform to be scalable to a large-scale remote healthcare monitoring situation, defined as 100,000 plus BANs. During the course of the project we believe we have reached a better understanding of the services such a platform should offer. Prospects of substituting the IPAQ MBU platform with a Sony Ericsson P800 seem promising. As well as allowing substitution of the MBU platform, the generic service platform enables integration of BAN devices from different manufacturers. During the current project sensors from different sources, including front-end supported and selfsupporting sensors, have been integrated into the BAN. Thus the objective of platform independence is being fulfilled. It should not be thought however that all problems have been overcome even with use of current technologies. Ambulatory monitoring is more successful for some biosignals than others, for example some measurements are severely disrupted by movement artifacts. Some monitoring equipment is still too cumbersome for ambulatory use, because of the nature of the equipment or because of power requirements. In the area of wireless (tele)communication technologies (even with 2.5 and 3G) we still suffer from limited bandwidth for some applications, such as those which require serving many simultaneous users with conversational applications requiring high quality two-way audio and video, or generation of 3D animation in real time. The use of BANs and wireless communications in personal healthcare systems still raises important challenges relating to security, integrity and privacy of data during transmission. This applies to both local transmission (eg. intra-BAN, BAN-PAN) and long range (eg. extra-BAN) communications. End-to-end security and Quality of Service guarantees need to be implemented. Safety of hardware (eg. electrical safety, emissions, interference) and reliability and correctness of applications must also be a priority in deployment of mobile services. Comfort and convenience of sensors or BANs worn long term for continuous monitoring is important for usability and user acceptance. Timeliness of information availability in the face of unreliable performance of underlying network services is another issue. Provision of seamless services across regional and national boundaries multiplies these difficulties. Powering always on devices and continuous transmission will continue to raise technical challenges. Business models for healthcare and accounting and billing models for network services need to evolve if technical innovations are to be exploited fully. Standardisation at all levels is essential for open 18 V. M. JONES ET AL. solutions to prevail. At the same time specialization, customisation and personalisation are widely considered to be success criteria for innovative services. Emerging technologies such as nanotechnology, smart sensors, ambient intelligent environments, grid computing, advanced power management and new implantation techniques open up many future possibilities for innovative mobile health services, however we expect that, along with these advances, issues such as quality of service, safety, security and privacy will pose ever more interesting challenges in the future. 6. REFERENCES BlueTooth, 2003; http://www.bluetooth.org/ van Dam, K, S. Pitchers and M. Barnard, ‘Body Area Networks: Towards a Wearable Future’, Proc. WWRF kick off meeting, Munich, Germany, 6-7 March 2001; http://www.wireless-world-research.org/. Dokovsky, N., A.T. van Halteren, I.A. Widya, “BANip: enabling remote healthcare monitoring with Body Area Networks”, In proceedings of IEEE Conference on scientiFic engIneering of Distributed Java applIcations (FIDJI 2003), Luxemburg, November 2003. Jones, Val, Rob Kleissen, Victor V. Goldman (1999), Mobile applications in the health sector, Presentation at Mobile Minded Symposium, 22 September 1999, University of Twente. Jones, Val, Mobile applications in future healthcare, Presented at CTIT Workshop, University of Twente, 8 February 2001. Jones, V. M., Bults, R. A. G., Konstantas, D., Vierhout, P. A. M., 2001a, Healthcare PANs: Personal Area Networks for trauma care and home care, Proceedings Fourth International Symposium on Wireless Personal Multimedia Communications (WPMC), Sept. 9-12, 2001, Aalborg, Denmark, http://wpmc01.org/, ISBN 87988568-0-4 Jones, V. M., Bults, R. A. G., Konstantas, D., Vierhout, P. A. M,. 2001b, Body Area Networks for Healthcare, Wireless World Research Forum meeting, Stockholm, 1718 September 2001; http://www.wireless-world-research.org/ Jones, Val, Richard Bults, Pieter AM Vierhout, Virtual Trauma Team, 2001c, Wireless World Research Forum meeting, Helsinki, 10-11 May 2001; http://www.wirelessworld-research.org/ Jones, Val, Nadav Shashar, Oded Ben Shaphrut, Kevin Lavigne, Rienk Rienks, Richard Bults, Dimitri Konstantas, Pieter Vierhout, Jan Peuscher, Aart van Halteren, Rainer Herzog and Ing Widya, Remote Monitoring for Healthcare and for Safety in Extreme Environments, IN M-Health: Emerging Mobile Health Systems, Robert H. MOBIHEALTH: MOBILE HEALTH SERVICES BASED ON BODY AREA NETWORKS 19 Istepanian, Swamy Laxminarayan, Constantinos S. Pattichis, Editors, Kluwer Academic/Plenum Publishers. Konstantas, Dimitri, Val Jones, Richard Bults and Rainer Herzog, 2002a, MobiHealth Wireless mobile services and applications for healthcare, International Conference On Telemedicine - Integration of Health Telematics into Medical Practice, Sept. 22nd-25th, 2002, Regensburg, Germany. Konstantas, Dimitri, Val Jones, Richard Bults, Rainer Herzog, 2002b, MobiHealth – innovative 2.5 / 3G mobile services and applications for healthcare, Thessaloniki, 2002. MobiHealth, 2002; http://www.mobihealth.org Östmark, Åke, Linus Svensson, Per Lindgren, Jerker Delsing, “Mobile Medical Applications Made Feasible Through Use of EIS Platforms”, IMTC 2003 – Instrumentation and Measurement Technology Conference, Vail, CO, USA, 20-22 May 2003. Rekhter, Y., B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear et al., “Address Allocation for Private Internets”, RFC 1918, February 1996. Schmidt, R., 2001, Patients emit an aura of data, Fraunhofer-Gesellschaft, www.fraunhofer.de/english/press/md/md2001/md11-2001_t1.html Sun Microsystems, 2003a. CDC: An Application Framework for Personal Mobile Devices, June 2003, http://java.sun.com/j2me Sun Microsystems, 2003b, Jini Technology Surrogate Architecture Specification” July 2001, http://surrogate.jini.org/ Widya, A. van Halteren, V. Jones, R. Bults, D. Konstantas, P. Vierhout, J. Peuscher, 2003a. Telematic Requirements for a Mobile and Wireless Healthcare System derived from Enterprise Models. Proceedings IEEE ConTel 2003: 7th International Conference on Telecommunications, June 11-13, 2003, Zagreb, Croatia. Widya, I., Vierhout, P. A. M., Jones, V. M., Bults, R. A. G., van Halteren, A., Peuscher, J. and Konstantas, D., Telematic Reequirements for Emergency and Disaster Response derived from Enterprise Models, 2003b, IN M-Health: Emerging Mobile Health Systems, Robert H. Istepanian, Swamy Laxminarayan, Constantinos S. Pattichis, Editors, Kluwer Academic/Plenum Publishers. Wireless World Research Forum, 2001, The Book of Visions 2001: Visions of the Wireless World, Version 1.0, December 2001; http://www.wireless-worldresearch.org/ xMotion , 2002; http://www.ist-xmotion.org/ 20 V. M. JONES ET AL. ZigBee Alliance, “IEEE 802.15.4, ZigBee standard”, http://www.zigbee.org/ Zimmerman, T.G., 1999, ‘Wireless networked devices: A new paradigm for computing and communication’, IBM Systems Journal, Vol. 38, No 4. 7. ACKNOWLEDGEMENTS Our thanks go to the European Commission, who fund the MobiHealth project under the IST FP5 programme, and to the MobiHealth partners. Thanks are also due for the support of the University of Twente (Faculty of Electrical Engineering, Mathematics and Computer Science, CTIT, and APS group). View publication stats