PAPER A SOA AND KNOWLEDGE-BASED TELEMONITORING FRAMEWORK: DESIGN, MODELING, AND DEPLOYMENT A SOA and Knowledge-based Telemonitoring Framework: Design, Modeling, and Deployment http://dx.doi.org/10.3991/ijoe.v9i6.3312 W. Zhang, K. Thurow and R. Stoll University of Rostock, Rostock, Germany Abstract—Telemonitoring systems have proven to greatly reduce medical costs while improving the quality of medical care. Today, the main factors restricting the development and popularization of Telemonitoring systems include scalability and compatibility. The current sensor devices lack unified standards and deliver complicated data structures. This paper presents the design for an ontology- based context model, and related middleware, that provide a reusable and extensible application framework for Remote Healthcare and assistance at home. We define the semantic information to describe attributes of sensors, services and working procedures. Developers may rewrite the service definition to adapt to new requirements as needed. Index Terms—telemonitoring; SOA; knowledge; modeling; ontology INTRODUCTION I. A Telemonitoring System can be defined as a technological means for sending remote physiological information and medical signals through a communication network to a monitoring center for analysis and diagnostics. Remote monitoring systems generally include three components: a monitoring center, Telemonitoring device, and a communication network connecting the two. This system integrates applications and devices like medical sensors, smart phones and data-store centers to provide health care services. Telemonitoring systems currently face many challenges, primarily because the sensor technology, Telemonitoring’s key technology, is still in the early stages of development. In the fields of architecture and service, the system faces the following two technical challenges: - Dynamistic. The types of medical sensing devices are varied and lack unified standards. The present Telemonitoring system is mostly researched and developed for a specific sensing device. In other words, an unique connection code and working process is designed for each type of sensor, greatly reducing the system’s scalability and presenting a significant obstacle for the popularization of Telemonitoring systems today. - Heterogeneity. The heterogeneity between the Telemonitoring systems and the commonly used medical systems like HIS, LIS, causes data and service interaction difficulties which may easily create an “information island”. Example: Home HeartRate monitoring is a typical application scenario of Telemonitoring. 1) First, the patient needs to wear a medical sensor that can measure his heartbeat. 2) The heartbeat data collected by the sensor is first transmitted to a local data processing center Gateway (usually a smartphone) which will send the data to a remote medical center. 3) The medical center will store the acquired data in the database then transfer the medical data to a data- process-module which returns the processed results to the smart phone client. 4) Under certain conditions, an alarm is triggered as a reminder to the patient. This example shows that, to solve the above problems, a Ubiquitous Telemonitoring System should have the following three abilities: • The system should have the ability to discover, integrate and control new medical sensors. • The sensor should connect with the local data processing gateway and transmit corresponding physical parameters according to medical service needs. • In the medical service center, there should be open interactive data interface services. All types of medical services and data processing services should be published using open standards so that they can be discovered and employed by external systems. METHODS II. Context-Aware Middleware A. The first and second problem can be solved by establishing a Context-aware Middleware [1]. In order to extricate remote medical applications from tedious sensor data acquisition and management, this paper proposes a Telemonitoring Context-Aware Middleware (TCAM). With TCAM, the upper-layer applications would not be concerned about acquiring the context data, but only about the business logic itself. As shown in Table 1, applications based on TCAM are divided into three layers. TCAM separates the collection of context information and the development of aware applications. It provides a Subscriber API (i.e. Subscriber Application Programming Interface [2]) for the developer of the upper-layer application; TCAM is then responsible for completing the data collection of various kinds of sensors, including physical, virtual and logic sensors. 48 http://www.i-joe.org