Middleware in ubiquitous computing system with

0 downloads 0 Views 783KB Size Report
Nov 26, 2009 - otherwise, to republish, to post on servers or to redistribute to lists, requires prior ... main focus is on message standards such as ISO13606 and HL7 rather than .... domain (optionally installed with Weblogic Server) deploys all.
Middleware in Ubiquitous Computing System with MedRec Architecture Mangal Sain

HoonJae Lee

Wan-Young Chung

Dept. of Ubiquitous IT, Graduate School of Design and IT,

Division of Information Network Engineering, School of Internet Engineering Dongseo University,

Division of Electronics, Computer and Telecom Engineering,

Dongseo University, Busan 617716, South Korea

[email protected]

Busan 617716, South Korea

[email protected]

ABSTRACT

Pukyong National University, Busan 608737, South Korea

[email protected]

1. INTRODUCTION

With the advent development in Ubiquitous Healthcare system it’s becoming one of the emerging areas of research. Due to mobile, dynamic, unpredictable and heterogeneous environment of ubiquitous computing systems it’s really hard to develop system software for ubiquitous computing. Primarily this middleware provide solutions to common tasks in ubiquitous computing, such as discovery, information processing, communication, synchronization, deployment, and group management etc. As we already implemented MUHIS (middleware for Ubiquitous Healthcare Information system) in our previous work, here we try to build architecture for MedRec, the web application. To build architecture for MedRec which will play the key role in MUHIS we try used J2EE technology and XML language. After designing the architecture we also implement it on Personal Healthcare information system and test in various condition which show that MUHIS can fulfill all requirement which are needed from a middle interface. This work also illustrates the contents recommendation and control service agents with the property, operation, and task for the context-aware active services. Our proposed architecture will also provide diagnoses report to the doctors for further instructions. The diagnoses report will consist of healthcare data analysis results and history of patient.

As we know there significant amount of work has been done in terms of middleware and various graphical user interfaces between application and Middleware. All of them tried to develop a Middleware for various application but in most of them architecture and technologies were considered only for specific applications at specific platforms. This paper presents the system architecture of MedRec for Middleware for Ubiquitous Healthcare Information System (MUHIS)[1]. MUHIS provide a graphical framework with the use of LiveGraph and MedRec for the development and execution of context-aware applications for Ubiquitous Healthcare System. There are several application exist in Ubiquitous Healthcare developed for USNLab such as Healthcare monitoring using ECG and Accelerometer sensor, Mobile Healthcare, Indoor location estimation etc show in Figure1. To communicate between all application and data source MUHIS is developed with the help of LiveGraph, Oscilloscope and MedRec. MUHIS collect all the information regarding context awareness from different application and delivering appropriate information. It also provides a GUI to interact different user to access different application on different location. MUHIS is developed in that context so that each application can adopt themselves according to different service and situations. We already implanted MUHIS in personal healthcare system in previously. In this paper we tried to enhance the work by adding MedRec and its several features and by providing their architecture and services context-aware services and apply these services to personal healthcare environments. After adding these services in MUHIS service it’s a more intelligent, Interactive and relevant than previous applications. In this paper the main concern of our work will be on MedRec architecture, application development, availability of tools and their utilization and build a GUI which can play an key role in ubiquitous healthcare. To build such application or robust platform, developers mostly rely on third party middleware, tools and libraries to respond the emerging trends of their target domain. For each healthcare application the requirement are different point to point. Due to that we first analyze several existing application such as

Categories and Subject Descriptors H.4.3 [Information Systems Applications]: Communication Application —Information browsers.

General Terms Measurement, Design, Experimentation

Keywords MUHIS, MedRec, J2EE, XML, context aware,

"Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ICIS 2009, November 24-26, 2009 Seoul, Korea Copyright © 2009 ACM 978-1-60558-710-3/09/11... $10.00"

149

this paper we tried to enhance our work from previous by adding MedRec interface which not only provide the GUI but also provide some diagnosis module.

CAMUS[2], MiLAN[3], MOBIWARE[4], LIME[5] etc and try to find the best solution in the form of MUHIS. All above middleware developed for different framework and each of them have different criteria to build. Like some of them developed only to concentrate with context aware, some on mobile network, some with sensor network. Every middleware have unique way to define a specific problem or constraints. In this paper we try to build a middleware and their GUI know as MedRec which can fulfill all requirement even if it can work on personal healthcare home environment or it can deploy on mobile healthcare.

3. SYSTEM DESIGN So far, communication between various application and user interaction in ubiquitous computing is quite complicated because of heterogeneity of hardware devices, different device drivers, their different capability and different communication protocol which they used for communication. To resolve this problem we proposed a MedRec architecture which simplifies the application development in ubiquitous computing middleware by providing a common layer towards applications has to be provided. Our design prototype consists of several Healthcare Application deployed on multiple physical hosts which is accessible everywhere through internet by a web application MedRec.

2. RELATED WORK Healthcare system is one of the most emerged areas of research these days; there are several personal and public healthcare research group and society which are working on healthcare information system and management. OpenEHR [6], HIMSS [7], HL7 [8] are some of them which are working from many years. In OpenEHR a person all health data is stored once in a lifetime, vendor-independent and person centered. Their main focus is on message standards such as ISO13606 and HL7 rather than exchange of data between EHR-systems. It also explains the storage, management, retrieval and exchange of health data into system. OpenEHR specification includes service and information model for EHR, demographics, archetypes, clinical workflow and are designed to be the basis of medico-legally sound, distributed versioned EHR infrastructure. HiMSS is a Healthcare Information and Management Systems Society which represents more than 2,000 nurses and brings together 18 distinct nursing informatics. It is the premier professional member organization exclusively focused on providing leadership for the optimal use of healthcare information technology.

In personal healthcare information system, web application is able to collect the whole data onto main server, process them and convert into useful information with the help of MUHIS and LiveGraph. The main controller of the application is programming interface which is developed in J2EE Technology which is centralized service in our architecture is deployed on application server. Due that we can do all the information processing on server instead of application, in that way we can save lot of memory usage, execution time and data transfer time. These days all personal healthcare devices are developed with only through Industry standard and with big organization and with big project. As stated earlier there are several applications and research has been done but if we consider real time healthcare application and real data processing on this area it still need big attention.

HL7 was formed to build hospital information system, which is now a volunteer as a non-profit organization involved in to build international healthcare standards worldwide. HL7 and its other member also provide a framework for exchange information, integration, sharing and retrieval of information. The main problem with Healthcare system is lack of shareable and computable Information. After studying all above technologies and research work we tried to build such an application which can overcome the above problem and play an important role in Healthcare Information system. We build an application which can take both kind of data (offline and live data) and process that data into useful information like diagnosis message which are still missing all open source application. To handle such data processing and information sharing we also build a middleware which exist between data source and GUI, which build with J2EE technology & Weblogic Server. System architecture is inspired by OpenEHR and HL7 and we tried to build an application which consist probably most of the quality of OpenEHR and HL7. To make advancement in our Healthcare system especially in communication and data sharing, middleware is added, which encourage and can be useful to implement more application with this system.

Figure 1. System architecture for USNLab Project Figure 1 show the system architecture for USNLab project which consist several application such as Mobile Healthcare system, Healthcare monitoring using ECG and accelerator sensor, Indoor location estimation using WSN, 3D navigation indoor tracking system etc. MUHIS firstly deployed in Personal Healthcare System and successfully implemented. To build a user interface for whole ubiquitous healthcare system is very big, expensive and time consuming effort so in this paper we focus only for personal healthcare system which consist health monitoring system using ECG and accelerometer sensor, but it doesn’t mean that for each other application we have to build different GUI or User Interface. As this application is build with J2EE technology and based on Model–view–controller(MVC)[9] which is an architectural

As we know there are several application and research organization which are working to make ubiquitous healthcare application more feasible by adding several features into them. In

150

accessing the database managed by the patient and admin web apps on their own domain.

pattern used in application development that pattern isolates business logic from input and presentation, permitting independent development, testing and maintenance of each module.

In presentation layer MedRec apps uses Java Server Pages (JSPs) tags and Jakarta Struts 1.0 intelligence to populating Enterprise Java Beans that request Actions within the service tier. The flow of MedRec can be understood from following way;

In the figure 1, there are several users in correspondence to different application. All users are connected with the database through MedRec(GUI) and Middleware, which exist between data source and different healthcare application. To process and execute all application data and information we use application server which reduce the memory, execution time and reduce the load on User Interface i.e. web application due that it increase lot of speed and performance of each application. As we can see there is another data source which we mentioned as MIT-BIH database, hence for a start only the MIT-BIH database is implemented. The work on creating user interface is done by big business entity or manufacturing firms and organization because most of the devices are developed by them. Different user accessing Personal healthcare module with the help of different sensor embedded in USN sensor mote, can take measure through Oscilloscope (implement in personal healthcare module). The MedRec application suite consists of three separate applications for the patient, physician, and administrator user roles. Using a separate application for each user role allows you to distribute each application function across different Weblogic Server instances as needed. For example, the MedRec sample domain (optionally installed with Weblogic Server) deploys all three applications on a single server instance for easy demonstration purposes. The MedRec tutorials also deploy the applications in a single-server domain, which is typical for development environments. However, we can also deploy the MedRec and Physician applications on two different server instances (in separate domains) to illustrate the use of Web Services between the applications. The MedRec project directory also contains subdirectories for compiling the client applications that access MedRec via Web Services.



Login posts to Login.do.



Web container detects *.do pattern in the web.xml deployment descriptor and redirects to



Jakarta Struts 1.0 Action Servlets, which



dissects the incoming URL and based on the actionmapping in struts-config.xml



redirect to the Login Action controller Servlets (which extends the Base Action) processing JavaBeans needed by the request.



After success, the structs-config.xml Actions map provides the page redirect value (the Patient Home Java Server Page).



Java code within the Patient Home Java Server Page is evaluated to HTML and



sent back as a response to the client user browser for display.

Figure 3. MedRec Application Suite in a Multiple-Server Domain MedRec is developed with J2EE technology and XML Language which provides a framework for administrator, doctors and patients to manage healthcare system. Where patient data includes:

Figure 2, MedRec web Architecture



Patient personal Data — Patient’s information, social security number etc.



Patient health records—Details about a patient’s vital signs and symptoms as well as the physician’s diagnosis and prescriptions.

name,

login

The MedRec application suite consists of two main J2EE applications and supporting application that loads the MedRec informational page. The main applications support one or more user scenarios for MedRec:

MedRec includes a service tier of Enterprise Java Beans (EJBs) that work together to process requests from client applications in the presentation tier and from Web applications, Web services workflow applications. The application includes message-driven, stateless session, stateful session, and entity EJBs. The MedRec physician web app should be housed in a different server/domain



151

medrecEar — medrecEar is a module through all patients can login thourgh web application(patientWebApp) to feed and edit their personal information, or can request that their



profile can be added to the system. Patients can also view their previous health medical records of previous visits with their physician. Administrators use the administration Web Application (adminWebApp) to approve or deny new patient profile requests. medrecEar provides all the control and authority with business logic used by the MedRec application, as well as the Web Service used by different clients. •

physicianEar — Regular user such Physicians and nurses can log in to the application through physician Web Application (physicianWebApp) to access all patient profiles, create and review patient medical records, and prescribe medicine to patients.



startupEar — The startupEar application is a simple Web Application that automatically starts a Web browser and loads a MedRec informational page when you start the installed MedRec domain. This application is not discussed during the development tutorials, but is compiled and deployed as part of the complete MedRec build process.

Figure 4. Block Diagram for USN sensor mote

All applications are deployed in a single-server domain which generally used for development process for convenience of deployment and testing. Figure 3 shows how each application would be deployed to multiple servers in a production environment.

This sensor mote can be use with base station which transfers the data into MedRec. MedRec also consist a modified oscilloscope (which comes with Tinyos and develop in java) program which process all the data into diagnosis message. That information is processed and executed on the application server on LiveGraph. We can also analyze the data with previous record and if we want we can send all this processed data on database. Later this data can be accessible anywhere with the patientWebApp

3.1 COMMUNICATION ARCHITECTURE To measure all these diagnosis we used some specific sensor. Here we are going to explain some of them which are embedded in sensor mote which is developed by USNLab Project.

To detect QRS we are using Pan-Tompkins QRS algorithm [12]. This QRS detection uses an ECG signal channel and it was designed to work at 200Hz. The main features of QRS detection algorithm are it is easily modified and efficient for different sampling rates. This algorithm is improved according to our software analysis requirement and is developed in C#.net language to comfort with P and T-wave detection and accelerometer analysis at server.

A. For measurement of ECG we used MEK MM200 ECG module with the following specification •

with 2-Channel ECG Wave Form (5-Lead)



Heart rate & waveform



15 arrhythmia classification and 2-channel



ST- Level Detection impedance respiration wave form,

Operating voltage range: 2.4V to 5.5V

All above sensor are embedded in our USN sensor mote. In Figure 4 we can see the block diagram how different sensor can be connected and with the help of Tinyos we manage whole architecture.

B. For accelerometer we used LIS3L06AL MEMS INERTIAL SENSOR: 3-axis - +/-2g/6g ultra-compact linear accelerometer with the following specification. •

2.4V to 3.6V single supply operation



±2g/±6g user selectable full-scale



0.5mg resolution over 100hz bandwidth



Embedded self test

• Output voltage, offset and sensitivity ratiometric to the supply voltage •

High shock survivability



to be integrated to PCB to connect to sensor node

C. For S temperature we are using STLM20 Ultra-low current 2.4V precision analog temperature sensor. •

±1.5°C temperature accuracy at 25°C



Ultra-low quiescent supply current: 8.0μA(max)

Figure 5, Logical View of Healthcare Data Processing with J2EE Server To analyze different sensor data such as abnormality in ECG, Accelerometer and temperature we are defining new module

152

application like OpenEHR, HiMSS, HL7 etc, and try to incorporate all those feature in MedRec application. Temporarily all the database is handled with MedRec Weblogic Server later that can be implemented with oracle or specific database.

which two basic phase. First one is data analyzer and another one is System call. From figure 5 we can take an idea how this process work. It shows the logical view of healthcare data processing in J2EE architecture. In MedRec we also added other measurement module for spo2, tremor, and body temperature. With figure 5 we can get the information how data transfer between various modules. Like first data is being captured by various sensors with specified data format, for time being we are using MIT-database to implement this application. After that data is transferred to data analyzer where it processes the information and classified into different parts. After classification that according to system calls that information can be shared with various modules.

3.2 DATA FORMAT In this paper our goal was to provide a capability for real time (software) analysis various application. Here we try to analyze ECG signal with activity monitoring at server. After detecting an abnormality then transfer that data into server and which can be use later on by some specific user like himself, nurse and physician and if user wants that data can used for other purpose like research etc. The services provided to client from server made possible by using MedRec. Designing of Healthcare data format is still in progress due to incompatibility between healthcare data packet format like ECG packet format, Accelerometer packet format. We are using healthcare packet format provided in table 1 and table 2 and having experiment with middleware suitability.

Figure 6. MedRec deployment on various physical hosts In figure 6, shows the specific module for particular user in healthcare information system. Each user can register their information regarding name, address and all other required information in MedRec Database. Administrator can assign different Rights and authentication to all users. Like patient can’t modify his or her information once he feed in the module. He can only see the current health status and feedback given by physician. Physician can see and update the patient’s information. These entire rules can be divided according to specific structure of healthcare system. This whole application is distributed into two phase. First one is web application which used as a front end for all user and administrator to access all the information anywhere through internet. Another form is backed where actual processing has been performed with LiveGraph, oscilloscope etc on application Server. Ubiquitous Healthcare system consist several research levels.

Table 1 ECG Packet Format Head Data Part(5 bytes) Message address

Active Message Handler

Group

2 bytes

I byte

1 byte

ID

Payload Data part( 26 bytes)

Message Length

Mote Id

Count

1 byte

2 bytes

2 bytes

ADC

Data

Chanel 2 bytes

20 bytes

Table 2 Accelerometer data format Address 2 byte

AM type

Group ID

1 byte

1 byte

This paper mainly focuses on creation of User Interface for high level. Figure 7, shows and ECG interface with normal and abnormal status and heart rate variability graph on server. The outputs of QRS detection algorithm are shown in figure from Fig.11. After detecting MWI then the software will measure R-R interval and QRS width with the calculation of heart rate. Searching for P-wave is done after deleting QRS complex from the ECG signal and replaced by a base-line and again band pass with 3Hz~11Hz. T-wave duration is calculated within the specified duration of window and point slope function. Basically we build this whole personal healthcare module to minimize the interference of physician. If we analyze the data on MATLAB then it need lot of prior knowledge and training but in our application anyone who have some knowledge to operate a simple application can easily operate our application named Personal Healthcare Module.

Data Length 1 byte

TOS Header Node ID

Last Sample Number

Channel

Data

2 byte

2 byte

2 byte

20 byte

4. SIMULATION AND WORK RESULT MedRec is playing a Key role in whole ubiquitous healthcare system. It’s developed in J2EE technology and XML language with Weblogic server. There are several module has been created to provide help in MedRec LiveGraph, Oscilloscope etc which provide technical support to MedRec. The concept to build MedRec is taken by Weblogic example program. We implement that application with the basic characteristic of several studied

153

6. REFERENCES [1] Mangal Sain, Hoon Jae Lee, Wan-Young Chung, “MUHIS: a middleware approach using LiveGraph,” IMPACT '09. International Multimedia, Signal Processing and Communication Technologies, 2009. [2] Aekyung Moon, Hyoungsun Kim, Hyun Kim, and Soowon Lee,"Context-Aware Active Services in Ubiquitous Computing Environments," ETRI Journal, Volume 29, Number 2, April 2007. [3] Heinzelman, W.B. Murphy, A.L. Carvalho, H.S. Perillo, M.A, "Middleware to support sensor network applications", IEEE Network," January/February 2004. [4] Angin, O.; Campbell, A.T.; Kounavis, M.E.; Liao, R.R.-F.; "The mobiware toolkit: programmable support for adaptive mobile networking," IEEE Personal Communications, August 1998

Fig 7 An ECG interface with abnormal status and heart rate variability graph on server: R-R interval= 504ms, QRS width = 56ms, QT interval= 362ms, PR interval= 58ms and HR = 119. The data is taken by file no. 106 from MIT-BIH arrhythmia database.

[5] Murphy, A., Picco,G., and Roman, G.-C. LIME: A Middleware for Physical and Logical Mobility. Proc.21st International Conference on Distributed Computing Systems ICDCS, 2001.

We tried to make this application user friendly so it can be useful to everyone who works on computer. With the help of web applications we can transmit whole data directly to specified database and make it global application.

[6] http://www.openehr.org/home.html. [7] http://www.himss.org/ASP/aboutHimssHome.asp.

5. CONCLUSION AND FUTURE WORK

[8] http://www.hl7.org/.

Due to mobile, dynamic, unpredictable and heterogeneous environment of ubiquitous computing systems, it require a specific middleware requirement and which should consider, like heterogeneity of devices and operating system, loose coupling of services, distribution, naming and discovery, interoperation, security, fault-tolerance and disconnection, extensibility etc. Middleware like CORBA component model and Enterprise Java Beans are designed for wired distributed systems where disconnection between services does not occur. Web Service is tied to a specific communication protocol, lacking the flexibility to use other communication protocols that may satisfy special environments. By adding MedRec to middleware we try find the real form of ubiquitous healthcare system. MUHIS provide a base to communicate between various applications which allow a middleware to be connected with a server for utilizing context information and ultimately giving proactive services to users. This paper also proposes contents recommendation service agent and context-aware task on the basis of the service framework and task development methodology of MUHIS. In this paper we also provide on GUI MedRec which is the key to implement our application. With the help of MedRec any user can access various modules and access their information too. With the help of sensor mote we also implement sensor data into useful diagnosis and then transfer that data to database.

[9] http://java.sun.com/blueprints/patterns/MVC.html. [10] J.Pan and W.J. Tompkins, "A real-time QRS detection algorithm", BME-32, pp.230-236, 1985. [11] Wan-Young Chung; Bhardwaj, S.; Purwar, A.; Dae-Seok Lee; Myllylae, R.;"A Fusion Health Monitoring Using ECG and Accelerometer sensors for Elderly Persons at Home" 29th Annual International Conference of the IEEEEngineering in Medicine and Biology Society, 2007. EMBS 2007 [12] Jea, David; Balani, Rahul; Hsu, Ju-Lan; Cho, Dae-Ki; Gerla, Mario; Srivastava, Mani B.; "Diagnostic quality driven physiological data collection for personal healthcare", 30th Annual International Conference of the IEEE Engineering in Medicine and Biology Society, 2008. EMBS 2008. [13] Sannella, M. J. 1994 Constraint Satisfaction and Debugging for Interactive User Interfaces. Doctoral Thesis. UMI Order Number: UMI Order No. GAX95-09398., University of Washington. [14] Geoff Coulson1, Gordon S. Blair, Michael Clarke, Nikos Parlavantzas;, “The design of a configurable and reconfigurable middleware platform” Distributed Computing · Mobile and Wireless Computing, 4th International Workshop, IWDC 2002, Calcutta, India, December 28-31, 2002, Proceedings.

In our future work we will concentrate on data format and on various algorithms which can be implement on other application. We will try to implement this framework on other applications.

154

Suggest Documents