- Research Article
- Open Access
Development and Evaluation of a Python Telecare System Based on a Bluetooth Body Area Network
EURASIP Journal on Wireless Communications and Networking volume 2011, Article number: 629526 (2011)
In the context of e-Health (i.e., the application of information and communication technologies to the health area), remote monitoring is one of the most representative applications and one of the e-Health services which implies more technologic and logistical challenges.
The term "chronic diseases" (applied to disorders such as diabetes, asthma, cardiovascular diseases, cancer, or depression) is employed to refer to health problems that, while not being transmissible diseases, persist over time and require some degree of care. Epidemiological data from 2000 indicate that, globally, nontransmissible diseases and mental disorders have entailed a mortality rate of 59% and 46% of the total morbidity . Additionally, there are predictions that, for 2020, both types of conditions will lead to a 78% of the global morbidity in developed countries . Moreover, it cannot be neglected that these diseases impact not only on the health of the population but also on the economic resources of the citizens and states. For example, in the United States where health cost per capita is higher than the average of other developed countries , the total expenditure on health due to chronic diseases increased from 78% in 2002 up to 84% in 2009 [3, 4].
The efficient management of chronic diseases represents a challenge due to the significant impact on the population health (quantified in terms of morbidity and mortality rates) and on health expenditure. In this scope, both European countries and the United States have deployed new and more efficient health care models, focused on the prevention of chronic diseases and their consequences. Although there are different methods, specifically conceived to manage every kind of disease, all of them require the active involvement of the patient for the control of the symptoms and the corresponding therapy as well as for the tracking of the evolution accomplished by the physicians (normally during a lengthy period). This vision of the health care implies a close communication with the patient and, therefore, a greater number of home visits, which obviously increase the cost of the sanitary system. However, the application of information and communication technologies, and specially home telecare or home telemonitoring, allows extending the health care outside the hospital by virtual medical visits, combining the tracking of the patients with a cost reduction. Besides, the information retrieved from the continuous monitoring of patients during long periods represents a key tool for the advances in the diagnosing of a disease, for the description of its evolution and for the forecast of possible complications, including the early prevention of the occurrence of severe events that may require the hospitalization . At last, the implantation of this new model of care would bring about the following benefits: an improved quality of life of the patients, a decrease in the rate of hospitalizations, fewer outpatient visits, and an increased patient satisfaction .
Up to now, the advantages of telemonitoring for chronic diseases care have been exposed. Nevertheless, the usefulness of telemonitoring is more evident when mobile communications and wireless technologies are combined. Traditionally, the medical telemonitoring systems have consisted of home telecare units that send biosignals or medical alarms to the medical premises from a PC connected to the fixed telephony network . However, the progress in the field of smart medical sensors together with the expansion of wireless and mobile communications, has enabled the creation of new monitoring systems which allows increasing the mobility and the comfort of the patients.
These systems are normally based on the usage of wireless sensors and a smartphone or PDA (Personal Digital Assistant), which is in charge of forwarding the data received by the sensors, to the monitoring point [8–10]. The application of these technologies to telemonitoring is known as m-Health (mobile health) or pervasive-Health [11, 12], in a process in constant evolution that leads to the concept of u-Health or ubiquitous-Health . The ubiquitous telemonitoring involves a significant improvement in the management of chronic conditions, allowing continuous and real-time monitoring during the normal patient activity. The aim under the u-Health concept is to provide the telemonitoring service from any place and in any time, without limiting it to the home environment. Certainly, as noted in , the chronic care must be provided in these conditions.
The paper is structured as follows. Section 2 summarizes the objectives of the proposed architecture. The explanation of the developed prototype is detailed on Section 3. Section 4 includes the tests which have been executed to evaluate the power consumption, under different conditions of monitoring, and the web browser compatibility of the web application intended for remote monitoring. Finally, Section 5 recapitulates the conclusions and presents the current research lines of the on-going work.
One of the architectures usually employed for monitoring systems is based on wireless short range networks: BANs (Body Area Networks) or PANs (Personal Area Networks). Bluetooth  and 802.15.4/ZigBee  are the most widely used standards for the deployment of these types of networks. In the typical topology defined for short-range wireless networks, a central element (coordinator, master etc.) is normally in charge of coordinating the network and forwarding the information sent by the sensors to the remote monitoring point. Additionally, in the monitoring center, the data received from the BAN or PAN networks are stored and processed in order to detect and notify risk events (e.g., medical alarms) . Some examples of research jobs and even commercial products, which employ telemonitoring applications based on short-range wireless networks, are presented in [14, 31–34].
In this paper, we describe and analyze a prototype of a biomedical monitoring system with an architecture based on a Bluetooth BAN. The system is deployed without requiring the development of any specific hardware, just combining commercial Bluetooth vital parameter sensors and a conventional smartphone.
In contrast with other studies describing similar experiences, we pay special attention to the evaluation of specific issues which may impact on the system operation. In particular we focus our analysis on (i) the performance evaluation of the technique used by the network to forward the patient's location and health status, (ii) the power consumption of the smartphone that is used to forward the information received from a Bluetooth sensor, and (iii) the browser compatibility of the web application developed for the remote and real-time tracking of the patient.
3. System Description
The developed prototype of the monitoring system is integrated by the next subsystems, as shown in Figure 1.
A Bluetooth BAN which is formed by a pulse-oximeter, a GPS receiver, and a smartphone. The smartphone along with the Python-developed control application acts as the Node of Control (NC) or master node (coordinator) of the Bluetooth piconet.
A Central Control Server (CCS) consisting in a web server with Python support, which centralizes the monitoring information received from the NC.
The remote Control and Monitoring Units (CMUs): a web application in charge of the control and monitoring of the BAN network. The developed web application should run in any conventional computer or mobile device with an Internet connection and a web browser.
All these components of the system and the communications interfaces between them are described in the following sections.
The Body Area Network is integrated by the following components.
A Nonin 4100  pulse-oximeter and a GPS receiver, both provided with Bluetooth interfaces.
The Nonin 4100 pulse-oximeter measures several vital parameters, such as the heart rate (HR), the saturation of peripheral oxygen (SPO2), and the perfusion level. The pulse-oximeter supports two operational modes: (i) under simple mode 1, the device sends only 3 octets per second with basic information about the health status (basically the SPO2 value and the heart rate); (2) under the verbose mode 2, the device transmits three packets per second. Every packet includes 25 five-octet frames, which encapsulate the information of the plethysmogram, two different averaged estimations of the HR and the SPO2, and the battery status. On the other hand, the GPS receiver has been included considering the application of the system in a real scenario. The GPS would allow the emergency team to locate the patient in case of detecting alarm conditions.
A Nokia smartphone with Symbian OS S60  (Series 60 User Interface), Python support, and Bluetooth and Wi-Fi  interfaces has been employed as the hardware platform for the NC component. The main reason to select a smartphone is the wide diffusion of these handheld devices in the market of consumer electronics. In fact, the total sales of smartphones in 2009 have attained a 36.4% of the global sales of mobile phones . Besides, another advantage of using smartphones is the familiarity of general users with these electronic gadgets as well as the quick and easy installation of applications, such as what is concluded in .
For the NC component a Python application, whose graphical interface is shown in Figure 2, has been developed. This application provides the following functionalities:
local configuration of the BAN (selection of sensors to be monitored),
establishment and management of Bluetooth communications with the BT devices of the BAN,
local monitoring: For this mode of operation, the application only shows a screen depicting the data received from the sensors,
remote monitoring: The application connects with the CCS server in order to forward the data measured by the sensors,
management and execution of the configuration commands which are received from the CMU unit through the CCS,
detection and notifications of events that occur when the heart rate (HR) and saturation of peripheral oxygen (SPO2) are out of the normality range (whose values can be remotely programmed).
3.1.2. Central Control Server (CCS)
The internal structure of the CCS server is shown in Figure 3. The main component is the PyMHealth application, developed with Python programming language. This application has been deployed on CherryPy , an object-oriented HTTP (Hyper Text Transfer Protocol)  framework encoded in Python, which provides both a web server and an application server. Besides, as persistent layer, SQLObject  has been employed as it supplies a common object-oriented interface for different database management systems (DBMSs): PostgreSQL, MS SQL Server, SQLite, Sybase, and MySQL. Particularly, in a first prototype, MySQL  has been selected as DBMS, due to its simplicity and because its source code is available under the terms of the GNU General Public License .
The other components in the CCS are the following:
An open source MQB (Message Queue Broker) that fully implements the Java Message Service 1.1 (JMS) , Apache ActiveMQ : it has been used to forward the data of the patients to the CMUs. For the communication of the PyMHealth application with this broker the messaging protocol STOMP (Streaming Text Orientated Messaging Protocol)  has been chosen.
A comet server, Orbited : this element allows that external applications interact with the messaging broker with HTTP protocol. Comet servers are web servers that permit sending data to a web client as soon as these data are generated, without waiting for any HTTP request from the client.
3.1.3. Control and Monitoring Units (CMUs)
3.2. Interfaces between Subsystems
3.2.1. Communication between the Node of Control (NC) and the Central Control Server (CCS)
For the communication between the NC and CCS components, based on HTTP Protocol, two channels are employed.
Control Channel. This channel is conceived for the transmission/reception of configuration commands. By means of this channel the NC component periodically sends GET HTTP requests to the CCS in order to get the pending configuration commands. The frequency for this polling process is also a configurable parameter of the NC.
The way in which HTTP is utilized differs for these channels.
In the case of the data channel, standard HTTP mode is used for periodic transmissions. On the other hand, for continuous transmissions, HTTP pipelining mode is employed. This nonblocking mode allows sending several consecutive requests without having to wait for the corresponding HTTP responses from the server. For this purpose, pipelining mode requires that the underlying HTTP connection operates in persistent mode. Consequently, the latency is minimized as the handshake and the overhead of establishing a new connection for each request is eliminated. Thus, the reuse of existing connections significantly improves the performance of the application.
The Control Channel utilizes the HTTP polling mode. This mode permits the client to query the server at regular intervals in order to get data which are asynchronously updated in the server.
The management of both data and control channels is centralized in a dedicated thread formed by three active objects. Two of them are responsible for the data channel: one is only in charge of sending HTTP requests, while the other one receives the responses from the server. Concurrently, the third active object periodically polls the server querying about the pending commands.
3.2.2. Communication between the Central Control Server (CCS) and the Control and Monitoring Units (CMUs)
To acquire the data received by the CCS from the NC, the CMU units could periodically send HTTP requests to the server. In that case, the period of these requests should be short enough to guarantee the real-time signal monitoring. However, this conventional method could negatively impact on the system performance in several respects: less available bandwidth, more battery consumption (which would entail a serious problem for portable CMU units) and an unnecessary overload of the server. Alternatively, in order to avoid these drawbacks, the data received from NC are asynchronously forwarded by the CCS to the CMU units. For this purpose, the publish/subscribe model, also known as streaming HTTP, has been adopted. This communication model is a functionality provided by the Orbited daemon, a Comet server based on Twisted  (a Python event-driven framework for asynchronous communication between processes).
4. Evaluation Tests
This section includes (i) the performance evaluation of the HTTP pipelining mode, used by the NC component to forward the patient's location and health status; (ii) the power consumption tests which are carried out for the NC component, under different monitoring conditions; (iii) the compatibility tests that have been executed for the CMU units with different browsers.
4.1. Performance Evaluation of HTTP Pipelining
The goal is to evaluate the performance of the HTTP pipelining mode, used by the NC component to forward the patient's data to the CCS. The evaluation has been carried out in terms of Round-Trip delay Time (RTT), by comparing the pipelining technique with other HTTP modes. For this test, several Python client applications have been developed for the following operating HTTP modes.
HTTP Socket. The socket directly sends HTTP messages through the TCP interface implemented by socket.py.
HTTP Nonpersistent. This mode employs the httplib.py Python module for the standard distribution of information with non-persistent connections.
HTTP Persistent. It also uses the httplib.py module. However, in this case the TCP connection is not closed until the HTTP connections have concluded.
HTTP Pipelining(Header). a variant of the previous mode that applies pipelining to the header.
HTTP Pipelining. It employs the httplib.py module, at lowlevel, to implement the pipelining mode.
Under all these modes, the client establishes a sequence of HTTP connections, measuring the resulting RTT. By averaging successive iterations of the tests, the measured average RTT for every client is graphically represented in Figure 5. The graph also shows the results obtained through a raw TCP socket (which obviously involves less overhead and less delay). As it can be observed, the pipelining technique is the most efficient method when compared with the other methods provided by the httplib.py module.
4.2. Power Consumption Tests
This subsection describes the analysis of power consumption that has been conducted for the NC component. In particular, the consumption tests have been executed on a Nokia N95 smartphone, acting as the NC. During all the measurements, "Nokia Energy Profiler 1.2" application  (a specific software for Symbian S60 3rd Edition, FP1, and later versions) has been used. This application generates an owner file, which can be exported to CSV (Comma Separated Values) format, containing information about several performance metrics of the smartphone, such as power and current consumption, average and instant battery voltage, CPU load, RAM memory usage, and downlink (download) and uplink (upload) speeds through the employed IP stack. Basing on the measurements logged in this file, the power consumption has been evaluated when the Python application of the NC component is running.
Initially, the efficiency of HTTP pipelining mode, employed by NC component in the continuous transmission, has been compared with the standard HTTP mode. From the results, it can be concluded that HTTP pipelining mode, which is the most efficient technique in terms of delay, introduces a 12% decrease of the battery autonomy.
Additionally, the results have been compared with the measurements obtained with an equivalent transmission software developed for Java ME (Java Micro Edition) platform , when the pulse-oximeter device operates in mode 2, without getting location information and in the next cases:
With GSM (conventional mobile) communication enabled.
With GSM communication disabled.
Remote monitoring: with GSM communication disabled. For these tests, standard HTTP (nonpersistent) is used for both Python and Java ME versions of the program. Two cases are considered:
continuous transmissions of the sensor information,
periodic transmission: Every 10 s, an HTTP request with all packets received during this interval is sent to the CCS.
From the results which are shown in Figure 6, it can be inferred the following:
Local monitoring: with the Java ME encoded client a greater autonomy is obtained in the NC, independently that GSM communication is enabled (12%) or disabled (18%). Nevertheless, the difference is not very significant if we take into account that Python is a very high-level language (VHLL), even more than Java.
Remote monitoring and continuous transmission: Python program outperforms Java ME version with a 32% increase in the autonomy.
Remote monitoring and periodic transmission: the energy efficiency which is achieved with the Java ME version is remarkably higher to that measured for the Python version (with a 69% of reduction in the battery consumption). For this case, it is worth pointing out that the method used to send the data to the CCS (with JSON encoding) prevents from improving the performance. Specifically, the efficiency loss is mainly provoked by the Wi-Fi transceiver and the additional CPU load that implies the serialization of data according to JSON format: with Java ME version, the instantaneous rate in the uplink, every 10 s, does not exceed 4.3 KB/s while the measured CPU load is 18%. Conversely, with Python version, a rate of 22 KB/s is achieved and the CPU load rises to 51%. Therefore, although JSON simplifies the encoding and decoding processing, it is less efficient than binary transmission, which is the method used by Java ME version.
4.3. Web Browser Compatibility Tests
Existing web browsers (Safari, Firefox, IE, Opera, Chrome, S60 Browser, among the most popular ones) [52, 61–65] are theoretically supposed to fulfill the web standards defined by organizations such as World Wide Web Consortium (W3C) . However, in the actual implementations, there are different interpretations of the standards and compatibility problems may appear. Furthermore, certain aspects of the implementation of the standards may be inefficient for mobile platforms, such as those that are based on Symbian S60. In addition, novel features, as support of XMLHttpRequest object, are only specified in draft versions of the standard , although this feature has been incorporated to the most popular browsers, due to the wide diffusion of AJAX technologies in the web applications context. Therefore, it is presumable that the employed web technologies will not be error-free and will not work with the same efficiency in all the typical browsers . For these reasons we have considered of great interest the evaluation of the compatibility of the web application developed for the CMU units when it is run on different web browsers. In fact, in a first step, it has been verified if the connections with Orbited server through STOMPClient object can be properly established for the web browsers. The results are summarized in Table 1.
In a second stage, upon checking that the implementation of STOMP client is not compatible with all the considered browsers (problems appear with the browsers in mobile platforms), other tests have been executed in order to find out the reason which causes this malfunction. Specifically, the relationship between the behavior of the XMLHttpRequest object and the numbers of simultaneous persistent connections that a browser can support has been studied. The underlying problem is that an Orbited STOMP Client requires, at least, the usage of two simultaneous persistent HTTP connections. In order to estimate the numbers of simultaneous persistent connections that a browser can support, a specific server over CherryPy has been developed. The results are shown in Table 2. In this table it can be observed that Nokia S60 browser is not able to establish more than a single connection. So, we can conclude that this is the reason why STOMP client does not properly work. Consequently the CMU cannot be executed in a smartphone due to the limitations of current browsers for mobile platforms.
Remote monitoring systems represent one of the most promising technological research areas in the health context, especially because its application to the management of chronic diseases would have a significant economic impact. However, to ensure that the potentialities of remote health monitoring are fully developed and guaranteed, more practical trials and realistic testbeds (with real patients) are needed, especially to assess the economic viability of the monitoring applications. Nevertheless, besides the need for empirical studies to evaluate the cost-effectiveness, it cannot be neglected that the maturity of the technologies involved in the development of the applications may seriously impact on its performance. The presented paper has focused on the evaluation of different Web technologies that can be employed to deploy the system software for the remote monitoring of biosignals. Specifically, the paper has presented a prototype of a monitoring system based on BAN (Body Area Network) that is worn by the patient. This BAN integrates diverse Bluetooth sensors and a smartphone. The smartphone along with the Python-developed control application acts as the coordinator node (NC, Node of Control) of a Bluetooth piconet formed by the sensors. This component forwards the data received from the Bluetooth devices to a Central Control Server (CCS).
The presentation of the prototype is accompanied by a study on specific issues which can impact on the applicability of the system software, in particular, (i) the HTTP pipelining technique which is used by the NC component to forward the patient's location and health status; (ii) the power consumption of the NC component (smartphone), which is compared with the measured consumption when an equivalent Java ME software is employed; (iii) the web browser compatibility of the web application developed for CMU units.
From the results it can be concluded that HTTP pipelining mode, employed by NC component in the continuous transmission, is the most efficient method, although it implies a decrease in the battery autonomy with respect to the standard HTTP mode. Additionally, although the employed JSON encoding format is lighter in weight than XML, it is less efficient than the binary transmission, which is the method used by the Java ME version. The energy efficiency which is achieved with Java ME version is significantly higher than that measured with Python.
As it refers to the web browser compatibility, it has been verified that the STOMP client does not work properly for all considered browsers. The reason which causes this malfunction is the number of persistent HTTP connections that the browsers can support, as an Orbited STOMP Client requires at least two connections.
The described prototype is currently being extended to other technologies. In particular, a Java prototype for Android platform is being developed. For this new prototype other biosensors are going to be integrated. In addition, other operation modes will be implemented. For example, in order to minimize the power consumption, a surveillance mode is planned to be included. Under this mode, only severe events would be notified to the server. Additionally, the physicians will be able to remotely configure the periodicity of specific measurements, such as the blood pressure and the electrocardiogram.
Pruitt S, Annandale S, Epping-Jordan J, et al.: Innovative Care for Chronic Conditions: Building Blocks for Action. World Health Organization, Geneva, Switzerland; 2002.
National Centre For Chronic Disease Prevention and Health Promotion : Power of prevention: chronic disease...the public helath challenge of the 21st century. 2009, http://www.cdc.gov/chronicdisease/pdf/2009-Power-of-Prevention.pdf
Anderson G: Chronic Conditions: Making the Case for Ongoing Care. The Robert Wood Johnson Foundation; 2002. http://www.rwjf.org/pr/product.jsp?id=14197
Anderson G: Chronic Care: Making the Case for Ongoing Care. The Robert Wood Johnson Foundation; 2010. http://www.rwjf.org/pr/product.jsp?id=50968
Penzel T, Kesper K, Becker HF: Biosignal monitoring and recording. In Information Technology Solutions for Healthcare, Health Informatics. Edited by: Hannah KJ, Ball MJ, Zielinski K, Duplaga M, Ingram D. Springer, London, UK; 2006:288-301.
Duplaga M, Winnem OM: Model of chronic care enabled with information technology. In Information Technology Solutions for Healthcare, Health Informatics. Edited by: Hannah KJ, Ball MJ, Zielinski K, Duplaga M, Ingram D. Springer, London, UK; 2006:248-270.
Güler NF, Übeyli ED: Theory and applications of telemedicine. Journal of Medical Systems 2002, 26(3):199-220. 10.1023/A:1015010316958
Tounsi M, Qureshi B: A Bluetooth-enabled mobile intelligent remote healthcare monitoring system: analysis and design issues. International Journal of Healthcare Technology and Management 2008, 9(5-6):473-484.
Neubert S, Arndt D, Thurow K, Stoll R: Mobile real-time data acquisition system for application in preventive medicine. Telemedicine and e-Health 2010, 16(4):504-509. 10.1089/tmj.2009.0123
Winkler S, Schieber M, Lücke S, Heinze P, Schweizer T, Wegertseder D, Scherf M, Nettlau H, Henke S, Braecklein M, Anker SD, Koehler F: A new telemonitoring system intended for chronic heart failure patients using mobile telephone technology—feasibility study. International Journal of Cardiology. In press
Istepanian RSH, Jovanov E, Zhang YT: Introduction to the special section on m-Health: beyond seamless mobility and global wireless health-care connectivity. IEEE Transactions on Information Technology in Biomedicine 2004, 8(4):405-414. 10.1109/TITB.2004.840019
Varshney U: Pervasive healthcare and wireless health monitoring. Mobile Networks and Applications 2007, 12(2-3):113-127. 10.1007/s11036-007-0017-1
Jeong K, Jung EY, Park DK: Trend of wireless u-health. Proceedings of the 9th International Symposium on Communications and Information Technology (ISCIT '09), September 2009 829-833.
del Pozo F, de Toledo P, Jiménez S, Hernando ME, Gómez EJ: Chronic patient's management: the Copd example. In M-Health: Emerging Mobile Health Systems, Topics in Biomedical Engineering. Springer, London, UK; 2006:575-585.
Tura A, Quareni L, Longo D, Condoluci C, van Rijn A, Albertini G: Wireless home monitoring and health care activity management through the Internet in patients with chronic diseases. Medical Informatics and the Internet in Medicine 2005, 30(4):241-253. 10.1080/14639230500170587
Ciorap R, Zaharia D, Corciovǎ C, Ungureanu M, Lupu R, Stan A: Wireless device for monitoring the patients with chronic disease. Revista Medico-Chirurgicala a Societatii de Medici si Naturalisti din Lasi 2008, 112(4):1115-1119.
Perakis K, Haritou M, Stojanovic R, Asanin B, Koutsouris D: Wireless patient monitoring for the e-inclusion of chronic patients and elderly people. Proceedings of the 1st International Conference on Pervasive Technologies Related to Assistive Environments (PETRA '08), July 2008 1-4.
Chen G, Yan B, Shin M, Kotz D, Berke E: MPCS: mobile-phone based patient compliance system for chronic illness care. Proceedings of the 6th Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous '09), July 2009 1-7.
Sultan S, Mohan P: How to interact: evaluating the interface between mobile healthcare systems and the monitoring of blood sugar and blood pressure. Proceedings of the 6th Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous '09), July 2009 1-6.
Capozzi D, Lanzola G: An agent-based architecture for home care monitoring and education of chronic patients. Proceedings of the Workshop on Complexity in Engineering (COMPENG '10), February 2010 138-140.
Jaana M, Pare G, Sicotte C: Home telemonitoring for respiratory conditions: a systematic review. American Journal of Managed Care 2009, 15(5):313-320.
Paré G, Jaana M, Sicotte C: Systematic review of home telemonitoring for chronic diseases: the evidence base. Journal of the American Medical Informatics Association 2007, 14(3):269-277. 10.1197/jamia.M2270
Cleland JGF, Lewinter C, Goode KM: Telemonitoring for heart failure: the only feasible option for good universal care? European Journal of Heart Failure 2009, 11(3):227-228. 10.1093/eurjhf/hfp027
Istepanian RSH, Zitouni K, Harry D, Moutosammy N, Sungoor A, Tang B, Earle KA: Evaluation of a mobile phone telemonitoring system for glycaemic control in patients with diabetes. Journal of Telemedicine and Telecare 2009, 15(3):125-128. 10.1258/jtt.2009.003006
Cunha AB, Capretz MAM, Raptopoulos L: Support systems for Telehealth services: critical operational and ICT complementary assets for large-scale provisioning. Proceedings of the IEEE Toronto International Conference in Science and Technology for Humanity (TIC-STH '09), September 2009 340-345.
Python Python Programming Language, http://www.python.org/
Garrett JJ: Ajax: A New Approach to Web Applications. February 2005, http://www.adaptivepath.com/ideas/essays/archives/000385.php
Bluetooth SIG Bluetooth, http://www.bluetooth.com
ZigBee Alliance http://www.zigbee.org
Morón MJ, Luque JR, Gómez-Jaime A, Casilari E, Díaz-Estrella A: Prototyping of a remote monitoring system for a medical personal area network using python. Proceedings of the 3rd International Conference on Pervasive Computing Technologies for Healthcare—Pervasive Health (PCTHealth '09), April 2009 1-5.
MobiHealth project http://www.mobihealth.org
Oliver N, Flores-Mangas F: HealthGear: a real-time wearable system for monitoring and analyzing physiological signals. Proceedings of the International Workshop on Wearable and Implantable Body Sensor Networks (BSN '06), April 2006 61-64.
Zhang Y, Xiao H: Bluetooth-based sensor networks for remotely monitoring the physiological signals of a patient. IEEE Transactions on Information Technology in Biomedicine 2009, 13(6):1040-1048.
Healthcare@Home Healthcare@Home: Patient-Centered Grid Based e-Healthcare, http://www.healthcareathome.info/index.html
Nonin Medical Nonin 4100 Bluetooth, Wireless Pulse Oximeter, http://www.nonin.com/OEMSolutions/4100
Nokia Symbian S60 Platform, http://www.s60.com
Wi-Fi Alliance http://www.wi-fi.org
Gartner Inc : Gartner Says Worldwide Mobile Phone Sales to End Users Grew 8 Per Cent in Fourth Quarter 2009; Market Remained Flat in 2009. http://www.gartner.com/it/page.jsp?id=1306513
CherryPy CherryPy project, http://www.cherrypy.org
W3C HTTP—Hypertext Transfer Protocol, http://www.w3.org/Protocols HTTP—Hypertext Transfer Protocol,
SQLObject SQLObject Project, http://www.sqlobject.org
MySQL MySQL Comunity Server, http://www.mysql.com/downloads/mysql
GNU GNU General Public License, http://www.gnu.org/licenses/gpl.html
Oracle Java Message Service (JMS) API, http://www.oracle.com/technetwork/java/index-jsp-142945.html
Apache Software Foundation Project Apache ActiveMQ, http://activemq.apache.org
STOMP Project Streaming Text Orientated Messaging Protocol, http://stomp.codehaus.org
The Orbited Project Orbited: Real-Time Communication for the Browser, http://orbited.org
W3C HTML DOM Specification, http://www.w3.org/DOM
W3C XMLHttpRequest W3C Working Draft, http://www.w3.org/TR/XMLHttpRequest
Microsoft Windows Internet Explorer, http://www.microsoft.com/windows/internet-explorer/default.aspx
Microsoft Introduction to ActiveX Controls, http://msdn.microsoft.com/en-us/library/aa751972%28VS.85%29.aspx
Microsoft Microsoft XML Core Services (MSXML), http://msdn.microsoft.com/en-us/library/ms763742%28v=VS.85%29.aspx
ECMA International Standard ECMA-262. ECMAScript Language Specification, http://www.ecma-international.org/publications/standards/Ecma-262.htm
W3C Extensible Markup Language (XML), http://www.w3.org/XML
T. M. Labs Twisted Project, http://twistedmatrix.com/trac/wiki/TwistedProject
Nokia Nokia E61 specifications, http://www.forum.nokia.com/devices/E61
Oracle : Java ME—the Most Ubiquitous Application Platform for Mobile Devices. http://www.oracle.com/technetwork/java/javame/overview/index.html
Apple Computer Sarfari Browser, http://www.apple.com/safari
Mozilla Foundation Mozilla Firefox, http://www.mozilla.com/en-US/firefox
Opera Software Opera Browser, http://www.opera.com
Google Chrome Browser, http://www.google.com/chrome
Nokia Nokia Mini Map Browser, http://www.nokia.com/microsites/s60-browser-site
W3C World Wide Web Consortium (W3C), http://www.w3.org
Apple Developer Network Web Page Development: Best Practices, http://developer.apple.com/internet/webcontent/bestwebdev.html
This work has been supported by Spanish National Project no. TEC2009-13763-C02-01.
About this article
Cite this article
Morón, M.J., Gómez-Jaime, A., Luque, J.R. et al. Development and Evaluation of a Python Telecare System Based on a Bluetooth Body Area Network. J Wireless Com Network 2011, 629526 (2011). https://doi.org/10.1155/2011/629526
- Remote Monitoring
- Body Area Network
- Continuous Transmission
- Remote Monitoring System
- Java Message Service