Data Management for Mobile Healthcare Monitoring
SADEGH M. ASTANEH , MARIO N. MALCANGI
Dipartimento di Informatica e Comunicazione
University of Milan
Via Comelico 39/41 Milano
ITALY
[sadegh.astaneh , mario.malcangi]@unimi.it
Abstract: To overcome drawbacks of traditional hospital management systems, this paper presents a new data -management system based on sensor networks and cloud computing. Cloud-computing features are included in the system’s definition, framework and basic capabilities. The system is designed to tightly link various medical departments and coordinate among various medical institutions. Using sensor networks with mobile devices yields added flexibility and functionality for several medical-sensor devices and shows great practical potential. Employing healthcare information technology should lead to more efficient, safer, and higher-quality care. We believe a new scheme for cooperation between data, devices, and systems is mandated. This scenario requires that a variety of information from different sources be integrated. The data comes from several separate sources, ranging from patient monitors to sensors located nearby that provide environmental data, electronic medical records stored by the hospital, hospital administrative information, and financial and healthcare resource management. Indeed, technology currently implemented by the network wireless microcontroller supports this kind of healthcare data management. In this light, we present a network layer and a middleware layer for sensor networks to support such networking and data management here.
Key-Words: -e-Health ,Wireless Sensor Network, Cloud Computing, SOA, Framework
1 Introduction
Information and communication technology (ICT) plays an essential role in supporting daily life in today's digital society. Such technology is now ubiquitous and vital to delivering better and more efficient healthcare services. Use of health information technology should lead to more efficient, safer, and higher-quality care. We believe a new scheme for cooperation between data, devices, and systems is needed. Sensor networks consist of tiny low-powered computing devices with extremely restricted computational, communication and battery capabilities. Each device may be equipped with a physical sensor for reading temperature, sound, pressure or other physical phenomena and can operate both as a sensor and a wireless router. One of the major tasks of sensor networks is the distributed collection and processing of sensor readings over extended periods of time. Scalability, self-configuration, ease of deployment and low cost have made sensor networks very attractive solution for a healthcare applications.
Let us consider a scenario where sensors are used for a mobile patient monitoring. Thousands of sensors are installed in hospital, houses and along the medical center. The information coming from
sensors is used for monitoring the patient and load in the health electronic record of patient. Each sensor is measuring temperature, pressure, cardiac activity or some site-specific phenomena of interest. The data generated by sensors has to be collected through the use of mobile collectors (installed in hospital, house or Wi-Fi or cellular interface). Some parts of the network will be particularly helpful as the mobile users can physically move towards the location and collect data from patient sensor. Using this approach there is no need for centralized infrastructure. Setting up multiple Data Collection points in different parts of sensor network, each data collection point has to be connected to a backbone (either through wired or wireless interface). Mobile users can query the network and send data from any location in sensor network.
Service-oriented architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration in computing. A system based on a SOA will package functionality as a suite of interoperable services that can be used within multiple, separate systems from several business domains.
SOA defines how to integrate widely disparate applications for a Web-based environment and uses multiple implementation platforms. Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point for such a SOA implementation. Cloud computing is a technology that uses the Internet and central remote servers to maintain data and applications. Cloud computing allows e-Health and businesses to use applications without installation and access their personal files at any computer with Internet access. This technology allows for much more efficient computing by centralizing storage, memory, processing and bandwidth.
As an example, let us take the scenario of a home care patient after hospitalization for cardiac infarction.
The above scenario requires the integration of different medical devices, of environmental data acquired by sensors located near the patient, of patient data available from the electronic medical records stored by the hospital, and of hospital administrative information about admission/discharge of patients, and the management of financial data and health care resources.
Although the current technologies used from Wireless Micro-controller offer the necessary means to support this kind of health care.
For these reasons, we would develop a network and middleware layers for sensor networks, supporting developments in networking and data management is presented. In particular benefits of the integration of personal medical devices into a Medical Information System and how wireless sensor networks and open protocols could be employed as building blocks of a patient monitoring system. The Wireless Micro-controller should ensure integration of the sensor network monitoring the patient with the medical devices and with the administrative and patient data available in the hospital networks.
In the our architecture of a modular, service-oriented, Sensor Middleware for data acquisition
and processing and complex event processing (CEP) technology is used which can handle large volume of events from distributed wireless sensor network (WSN) Node and sensor readers in real time. Our Model permit to aggregate a number of heterogeneous, off-the-shelf, devices from which clinical measurements can be acquired and to provide access and integration with an IEEE802.15.4 network.
Figure 1.2
2 Problem Formulation
The full benefits of e-Health services and tools will not reach patients unless a high level of interoperability is integrated at the heart of their design and deployment. Healthcare providers need to co-operate extensively with each other, and with their suppliers, to ensure that their services are well connected.
Co-operation is vital e-Health systems must be interoperable in order to facilitate and foster collaboration between healthcare professionals and organizations, as well as between healthcare professionals and their patients. National and regional policy-makers and stakeholders must co-operate in order to resolve the various associated legal, organizational and policy issues.
Interoperability is not just a technical matter; issues such as patient confidentiality are also significant. In order to achieve e-Health interoperability, legal, ethical, economic, social, medical, organizational, and cultural aspects all need to be addressed. It could even be argued that the technical requirements for e-Health interoperability are the easy part of the
challenge. Software complexity of e-Health interoperable systems is increasing at an alarming rate. Today, a large part of this complexity is caused by shortened product cycles, requirements for drastically increased functionality, and an increasing number of variations of the same product (e.g. different hardware and operating systems). These trends have caused software costs to become a larger percentage of almost any manufacturer's development cost.
Today, software development largely consists of adapting existing functionality to perform in a new environment. In the last 20 years, a large number of standard building blocks have become available and they are heavily used in today's products; a prime example is the success of open software. However, the use of these libraries is not without problems. Integrating many different libraries can be daunting because many libraries have become complex and require their own libraries to function -- even if that functionality is never needed for the product. This trend requires monolithic software products to undergo a heavy testing cycle. Add unsynchronized evolution of the different libraries and it becomes clearer why software development is so costly today. A key issue is that today's software environments focus on writing new software, instead of integrating existing software into new systems. In reality, integrating existing code has become a large part of the work of software developers. Therefore, there is a need for tools that standardize the integration aspects of software so that reusing existing components becomes reliable, robust and cheap.
3 Problem Solution
The major contribution of this project is to design middleware based on the dynamic module system for Java™ called OSGi technology. The OSGi Service Platform provides functionality to Java that makes Java the premier environment for software integration and thus for development. Java provides the portability that is required to support products on many different platforms. The OSGi technology provides the standardized primitives that allow applications to be constructed from small, reusable and collaborative components. These components can be composed into an application and deployed. The OSGi Service Platform provides the functions to
change the composition dynamically on the device of a variety of networks, without requiring restarts. To minimize the coupling, as well as make these couplings managed, the OSGi technology provides a service-oriented architecture that enables these components to dynamically discover each other for collaboration. The OSGi Alliance has developed many standard component interfaces for common functions like HTTP servers, configuration, logging, security, user administration, XML and many more. Plug-compatible implementations of these
components can be obtained from different vendors with different optimizations and costs. However, service interfaces can also be developed on a proprietary basis.
OSGi technology adopters benefit from improved time-to-market and reduced development costs because OSGi technology provides for the integration of pre-built and pre-tested component subsystems. The technology also reduces
maintenance costs and enables unique new
aftermarket opportunities because components can be dynamically delivered to devices in the field. Our middleware should provide application developers with higher level programming abstractions, which would allow developers to concentrate on the logic of the application rather than on implementation of low-level functionalities. This should facilitate software development and reduce development costs.
Traditionally, the goal of the middleware has been to provide a set of programming and communication abstractions to facilitate the software development for heterogeneous systems. In mobile computing middleware is also responsible for context awareness and adaptation. The abstraction and generalization usually come at the expense of efficiency.
Our promises seamless integration of different products including Message Broker, Web Services Application Server, Enterprise Service Bus and Business Process Server.
According above, WSN applications collect and integrate data from a lot of logic and emanative sensor nodes. In wireless sensor networks, a large number of sensor nodes exchange data and stop only until query information shows that the source node and sink node disappear simultaneously. Therefore, the traditional request / response communication mechanism does not meet this demand. For example, while only customer requesting and responsing information synchronously, can they establish a connection. This method will lead to a lot of the
energy consumption of sensor nodes, which does not conform to the key design of wireless sensor network middleware.
The pub/sub communication generics satisfy the application model of wireless sensor network. In this communication mechanism, information publishers can publish messages for many subscribers. In this basic model, information is transmitted through the contents matching and the connection. In addition, subscribers and publishers are fully decoupled in the space, time and control flow, which would reduce the energy consumption effectively. This loosely-coupled is the most main superiority in the ad-hoc and pervasive environment (such as WSN).
3.1 Service oriented architecture
Service oriented architecture (SOA) is the pattern most often used to integrate heterogeneous systems so, if business decisions written as rules can be exposed as services, then business rules can also be integrated into SOA systems. SOA efforts of any enterprise mainly focuses on integrating disparate systems. Behind most of these application silos are heterogeneous data stores. The Data Services Server augments SOA development efforts by providing an easy to use platform for creating and hosting data services.
3.2 The FRAMEWORK
The core component of the OSGi Specifications is the OSGi Framework. Our Framework is an Service oriented architecture (SOA) OSGi-based platform implementation on which all the Java products, provides the core runtime for the features of these products to be implemented as components, which makes each and every product simply a runtime and a set of feature components. For example, ESB by default ships with the Mediation component, Proxy Services component, Task component, etc. Most interestingly, you could take features from one product and apply those features on to another product to customize the behavior of the middleware application. With this, Framework provides the ability to adapt the middleware to your architecture where as in many other cases it adapts your architecture to the middleware. The Framework provides a standardized environment to applications (called bundles). The Framework is divided in a number of layers.
Figure 3.1
• L0: Execution Environment
• L1: Modules
• L2: Life Cycle Management
• L3: Service Registry A ubiquitous security system is deeply intertwined with all the layers.
The L0 Execution environment is the specification of the Java environment. Java 2 Configurations and Profiles, like J2SE.
The L1 Modules layer defines the class loading policies.
The L2 Life Cycle layer adds bundles that can be dynamically installed, started, stopped, updated and uninstalled.
The L3 layer adds a Service Registry. The service registry provides a cooperation model for bundles that takes the dynamics into account.
3.3 The Message Broker
Our Middleware for integration of distributed wireless sensor network (WSN) based on Message Brokers, is a WSN middleware realizing publish/subscribe communication. It has three stages to achieve communication. First, advertises information into network when the WSN nodes access useful content (such as temperature, etc.); then, advertising information using multi-hop routing algorithm to route to sink nodes, user connect sink nodes to choose and subscribe the wanted topic. Finally, the subscribed information will be broadcast to the network nodes. After receiving the subscribed topics, the node will publish the data they collect to the network.
MB enable applications to exchange communications asynchronously or publish messages for timely access by many subscribers. For example, environmental data acquired by sensors located near the patient stored on MB and consumers can subscribe to the latest data of patient that interests them.
Messaging is a fundamental component of Enterprise Application Integration (EAI) and Event
Driven Architectures (EDA), and most Message Brokers support JMS, a standard API for messaging.
JMS however does not specify how Message Brokers should work or interoperate and proprietary
Message Brokers are a major source of lock-in. The 100% open source and open standards based our Framework Message Broker implements reliable and secure message queuing and publish-and-subscribe
event distribution to enable message-driven and event-driven applications. Our Message Broker
supports AMQP, the only open standard for enterprise messaging. Is based on Apache Qpid/Java
project for AMQP protocol and JMS API. Apache Qpid is a cross-platform Enterprise Messaging system which implements the Advanced Message
Queuing Protocol (AMQP), providing message brokers written in C++ and Java, along with clients
for C++, Java JMS, .Net, Python, and Ruby.
Figure 3.3
3.4 The Business Processes
Business processes are the lifeblood of an enterprise. The our Business Process Server includes features for managing, securing and defining business processes within an organization. Powered by Apache ODE, it provides a complete Web-based graphical console to deploy, manage, and view processes and process instances, as well as the capability to deploy custom extensions for the WS-BPEL language.
Business Process Execution Language or WS-BPEL lets people orchestrate tasks and activities exposed as Web services. Our Business Process Server can execute process descriptions written in WS-BPEL. Since BPEL is structured and based on XML, it is now far easier for business users to model and execute business processes using open source graphical tools like Eclipse BPEL Designer.
3.5 Data Services
Data services are essentially Web services that provide unprecedented access to data stored in heterogeneous data stores, thus enabling easy integration of data into business processes, BI applications and any service in general.
Data Services Server offers:
• Access to enterprise data scattered across heterogeneous data sources in a unified manner.
• Optimization and more processing power to every service consumer.
• Access to real time data providing more accurate, up-to-date information for applications.
• Greater integrity of frequently modified data.
3.6 The Web Service Application Service
Web Services Application Server (WSAS) of our Framework, is the service hosting environment of the SOA stack. It provides the ability to host Axis2 services, Axis services, EJB services, Data services, POJO services, Spring services and many more. Additionally, it provides the ability to configure the Quality of Service (QoS) parameters of the hosted services.WSAS also provides a set of monitoring tools to monitor the system such as, SOAP Tracer, System Statistics, System Logs and so on.
We can use the mediation functionalities on the service hosting environment, and how this mediation can be very powerful in certain cases. We have only explored logging the message at the mediation, but we could easily extend this to provide more interesting and complex mediations including message transformation, message validation, message filtering and throttling, response caching for time consuming steady services, database reporting and so on.
3.6 .1 Mediation Important for SOAs
Mediation, in its English meaning, is conflict resolution between two parties. In reference to inter-device communication, it involves resolving messaging conflicts between client and server. If you design the Service Oriented Architecture (SOA) for your enterprise in a way that satisfies all client requirements, then you might not need mediation. However, the fact that the world is evolving either requires you to upgrade your SOA implementation periodically or to employ mediation to adapt your implementation to updated requirements.
Most organizations have legacy services they cannot change and require those legacy services to be supported by the current SOA. For example, you may want to add security to an existing non-secure service in order to make it usable by the current architecture. Mediation is thus vital for successful implementation of the SOA, since it provides much-needed extensibility for your enterprise.
4 Conclusion
The use of OSGi technology makes our middleware widely applicable because the platform is a small layer that allows multiple Java™-based components to efficiently cooperate in a single Java Virtual Machine (JVM). It provides an extensive security model so that components can run in a shielded environment. However, with the proper permissions, components can reuse resources and cooperate, with one another, unlike what happens in other Java application environments. The OSGi Framework provides an extensive array of mechanisms to make this cooperation possible and secure.
The rigid definition of the OSGi Service Platform enables components suited to a broad variety of devices, from very small to very big.
Adoption of the OSGi specifications can therefore reduce software-development costs, as well as
provide new business opportunities. References:
[1] Lejiang Guo, Fangxin Chen, Li Chen and Xiao Tang, The building of cloud computing environment for e-health, IEEE, 2010 International Conference on E-Health Networking, Digital Ecosystems and Technologies.
[2] I. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci. A survey on sensor networks.
Communications Magazine, IEEE, 40(8):pp. 102– 114, 2002.
[3] M. Batalin, G. Sukhatme, and M. Hattig. Mobile robot navigation using a sensor network. In In IEEE International Conference on Robotics and
Automation, pages 636–642, New Orleans, Louisiana, Apr 2004.
[4] S. Bhattacharya, H. Kim, S. Prabh, and T. Abdelzaher. Energy-conserving data placement and asynchronous multicast in wireless sensor networks. In Proc. of the 1st international conference on Mobile systems, applications and services, pages 173 – 185, 2003.
[5] V. Dyo and C. Mascolo. Adaptive distributed indexing for spatial queries in sensor networks. In Proc. of the 8th Int’l workshop on Mobile Databases and Distributed Systems (MDDS’05), pages pp. 1103–1107, August 2005.
[6] W. Emmerich. Engineering Distributed Objects. John Wiley & Sons, Chichester, UK, 2000.
[7] Del Hoyo-Barbolla, E.; Arredondo, M.T.; Ortega-Portillo, M.; Fernandez, N.; Villalba-Mora, E.; A new approach to model the adoption of e-health, Electrotechnical Conference, 2006.
MELECON 2006 IEEE Mediterranean. [8] E. Ammenwerth, P. Knaup, C. Meier et al., Digital libraries and recent medical informatics research. Meth. Inform. Med. 40 (2001), pp. 163– 168.
[9] M.J. Ball, 2000. International Efforts in Informatics: Creating a Global Village for
Healthcare. M.D.Computing May/June 2000, 50–53.
[10] M.J. Ball and J.C. Lillis , E-health: transforming the physician/patient relationship. Int. J. Med. Inform. 61 (2001), pp. 1–10.
[11] H. Tahayori, E. Pagani, G. Degli Antoni, M.S. Astaneh, Enhanced Sensor Network: A Specialized Infrastructure for Context-Aware Applications , Proc. IADIS International Conference on Applied Computing, Feb. 2007
[12] H. Tahayori, E. Pagani, G. Degli Antoni, M.S. Astaneh, Context Network, Electrical and Computer Engineering, 2007,Canadian Conference
[13] D. Della Giustina, M. Riva, F. Belloni, M. Malcangi, Embedding a Multichannel
Environmental Noise Cancellation Algorithm into an Electronic Stethoscope, International Journal of Circuits/System and Signal Processing, Issue 2, Volume 5, 2011
[14] M. Fanfulla, M. Malcangi, M. Riva, D. Della Giustina, F. Belloni, Cardiac sounds segmentation algorithm for arrhythmias detection by fuzzy logi, International journal of circuits/systems and signal processing, ISSN 1998-4464, 2011 Jan, pp. 192-200
