Service Oriented Architecture for Patient Monitoring Application

Service Oriented Architecture for Patient Monitoring Application Victor Foo Siang Fook, Jayachandran Maniyeri, Aung Aung Phyo Wai, Pham Viet Thang and Jit Biswas Institute for Infocomm Research, 21 Heng Mui Keng Terrace, Singapore – 119613 {sffoo, mjay, apwaung, vtpham, biswas}@i2r.a-star.edu.sg Abstract— This paper presents a new approach that exploits service oriented architecture (SOA) for patient monitoring application. In particular, we describe the use of web services, UPnP and semantic web in a loosely coupled manner to monitor dementia patients, model sensors and pervasive devices as services, and enable proactive action for handling patients by automatically triggering intervention services. The proposed architecture enables the development of a sophisticated monitoring system to facilitate care-giving and clinical assessment of patients in a context enlightened fashion within an administrative domain and across the internet that exceeds the current state-of-the-art in terms of scalability, interoperability, intelligence and robustness.

I. INTRODUCTION Service oriented architecture, SOA, is an architectural style for building software applications that use services available in a network such as the web. It promotes loose coupling between software components so that they can be reused. Applications in SOA are built based on services. A traditional approach didn't enable open interoperable solutions, but relied on proprietary APIs and required a high degree of coordination between groups. Service is an implementation of well-defined business functionality, and such services can then be consumed by clients in different applications or business processes. Many in the industry see SOA as a way to speed up the application development process. They also see in SOA a way to become more agile and more adaptable in responding to changing business needs. SOA is emerging as the premier integration and architecture framework in today's complex and heterogeneous computing environment, and is slowly adopted by the healthcare industry. Although there are some works describing prototyping of service oriented computing for specific healthcare applications, there is limited work taking into account the applicability of the approach for healthcare applications in a generic manner. This paper will seek to bridge the gap by describing the subtle design, implementation and deployment issues from both hardware and software perspective of a service oriented architecture to provide support for healthcare applications. To start with, we target healthcare applications on monitoring the behavior, activities and movement of patients with dementia which can give vital information about the progression or the onset of typical behavior, and thereby enable proactive action. For example, we are interested in monitoring the 1-4244-9701-0/06/$20.00 ©2006 IEEE.

agitation behavior of dementia patient using multimodality of sensors. When a patient monitoring system detects that the patient is agitated, it can automatically activate just-intime music or simulated presence therapy service to lessen the agitation without human intervention. Likewise, we may be interested in tracking the whereabouts of dementia patient using location service provided by the monitoring system. When it detects that the patient is about to wander out of his home or hospital ward, it can automatically activate a smart door locking service. In this paper, we present a service oriented patient monitoring system for continuous assessment of patients with dementia in a hospital ward with automated intervention services. Section 2 discusses related work. Section 3 describes the design considerations and details of our SOA for healthcare applications. Section 4 describes an implementation of our patient monitoring system for dementia patients in a hospital with preliminary system testing. Section 5 concludes with a discussion on future work. II. RELATED WORK Previously, a number of system architectures have been developed to support application monitoring people and elderly. The PlaceLab project [1] in MIT developed portable sensors that are able to study the vital signs of the resident in a constant manner. The CareMedia project [2] at Carnegie Mellon University uses video and audio information to automatically track people, label individuals, and characterize selected actions and activities. The Aware Home Research Initiative [3] in Georgia Tech Institute of Technology has built technologies and specific applications such as support for the elderly. In [4] by Harvard University, a sensor network system for emergency response called CodeBlue was developed that integrates many sensors and wireless nodes into a disaster response setting, and a common software architecture was developed to provide facilities for ad hoc network formulation. While these applications focus our focus on monitoring, they usually cater to a specific application and sensor suite, and do not adopt the service oriented approach. Then there are the pervasive self-care infrastructure [5] project and semantic emergency response system [6] that utilizes web services and OSGi for healthcare applications. Our work is similar in that it also uses web services to provide a reusable framework to ease application

development. However, our work is different from them as we try to adopt a standard base approach in a loosely coupled manner, in particularly using UPnP, web services and providing ontology based knowledge base that can adapt to various situations for knowledge sharing, reasoning and intervention services. Our long term plan is to leverage on HL7 [7] to create more meaningful data that can be reused in the medical field. HL7 is the emerging standard for healthcare applications dealing with clinical and administrative data. HL7 focus is to create standards for the exchange, management and integration of electronic healthcare information. It provides an information model and standards for exchanging information. We want to adopt a standard base approach since this makes our work easily acceptable to industry and hospitals which are geared towards adoption of relevant healthcare standards. One of the architecture that we are particularly interested in is the canonical architecture proposed by the Clinical Context Objects Workgroup (CCOW) [8], which is a set of standard proposal under considerations within the ANSI framework, and a part of the HL7 standard which is used for e-Health applications in hospitals across the world. If our SOA are compliant to the CCOW standards, they automatically enjoy interoperability and sharing of information with existing services and applications in hospitals. III. SOA FOR PATIENT MONITORING APPLICATIONS In this section, we will describe our design considerations and service oriented concepts for patient monitoring applications based on our working experience with doctors and nurses. A. Design Considerations The service oriented architecture should address the need for scalability and flexibility of services provisioning by providing generic architectural supports. It should be interoperable and facilitate rapid system reconfiguration as the assessment needs and health conditions of the patient are subjected to change. It should enable rapid system development as new clinical knowledge and new measurement scales are introduced within the evolving field of patient monitoring. It is also important to support intervention management by supporting flexible and standardized schemes for automated intervention triggering and activity planning/drug therapy management facilitation. Furthermore, it is necessary to consider usability of such architecture, and it should facilitate better human computer interaction, intuitive and intelligent query results and reports to hospital staff or caregivers. As future patient monitoring applications will use multimodality of sensors to infer highly complex behavior of patients, the service oriented architecture should also deal with complex interaction of multi-modality sensors. It is essential to provide a layer to separate the service interface (the what) from its implementation (the how) which may involve

performing signal pre-processing, feature extraction and event detection on raw sensory data form different sensors to convert digital bit streams into high-level representation of an individual’s physical, behavioral and psychosocial functioning. Such services are consumed by clients that are not concerned with how these services will execute their requests. Furthermore, the architecture should provide services that are self-contained by performing predetermined tasks and loosely coupled for independence. Lastly, there must be a mechanism whereby the services can be dynamically discovered and composite services can be built from aggregates of other services. B. Choice of Loosely Coupled Approach using UPnP, Web Services and Ontology Based on the design considerations, we adopt a loosely coupled approach using UPnP, Web Services and Ontology when designing our SOA for patient monitoring applications. We will explain the reasons in the following section. 1) Why UPnP? UPnP is an open architecture for pervasive peer-to-peer network connectivity of intelligent appliances, wireless devices, and PCs of all form factors. UPnP standard is chosen for its flexibility, standards-based connectivity, web services-like architecture and available support from the industry. There are many UPnP enabled devices available in the market today and UPnP SDKs already available for different programming environments and platforms, to ease the development process. UPnP uses common IP based protocols, to span different physical media, to enable real world multiple-vendor interoperation. With UPnP, there are no device drivers, the protocol is media independent and UPnP devices can be implemented using any programming language, on any operating system. Each UPnP device offers well defined services that can be discovered automatically within single administrative networks. 2) Why Web Services? Web services are interoperable software systems that use open, XML-based standards and transport protocols to exchange data with calling clients. This interoperability is gained through a set of XML-based open standards, such as WSDL, SOAP, and UDDI. These standards provide a common approach for defining, publishing, and using web services. Web services can help create modular, platformneutral software components and recombine them as new business models. SOA and web services are two different things, but web services are the preferred standards-based way to realize SOA. They provide a way for applications to expose their functionality over the web, regardless of the application's programming language or platform. Interoperability can also be realized through the use of web services which allow different distributed web services to run on a variety of software platforms and hardware architectures.

3) Why Ontology? In the context of knowledge management, ontology is referred as the shared understanding of some domains, which is often conceived as a set of entities, relations, functions, axioms and instances. There are 3 main reasons for integration of ontology for use in the service oriented architecture – knowledge sharing, logic inference and knowledge reuse [9, 10]. There is significant effort going on in the W3C to provide richer and explicit descriptions of Web resources. In essence, the Semantic Web is a set of standards for exchanging machine understandable information. Among these standards, Resource Description Framework (RDF) provides data model specifications and XML-based serialization syntax, and Web Ontology Language (OWL) enables the definition of domain ontologies and sharing of domain vocabularies. There is current effort in a HL7 working group called SNOMED [11] which provides a common language for easier understanding of healthcare data across specialities. It will be very useful work if we can use SNOMED clinical terms to create meaningful data at the Ontology side that can exploit the full benefits of using ontology in the medical field. We also believe that Web ontology can be deployed in modeling and reasoning about context information of patient monitoring. C. Proposed Architecture Figure 1 and 2 shows the proposed service oriented architecture based on UPnP, web services and ontology. The description of the components will be described in the following section. However, we do not go into the details of each of the objects that make up the classes as they are not the focus on the paper. search

Database

Web Services

Subscribers

UPnP Device

Control Point(s)

advertise device/service description control

Fig. 2. Web Service and Ontology Components in SOA

The web service and ontology support components can be taken to consist of three subcomponents: ƒ Presentation/web objects: include user interface related objects such as web pages, CGI scripts, etc. ƒ Application objects: include core application classes to support the healthcare application. ƒ Interface objects: include web service related classes to support inter-application communications. Figure 3 provides an alternative view of the web services development that is reflective of the deployment status of the current version. The Ontology Service encapsulates calls to the underlying Java classes by forwarding calls to the appropriate healthcare entity classes. The application classes are built around Sesame objects which provide core functionality to manipulate and query the ontology base. Sesame, in turn, provides the schematic mapping and mechanism to access triples stored in the database.

events UPnP Device Bridge

Sensing and Pervasive Device (Non-UPnP)

Fig. 1. UPnP Component in SOA Fig. 3. Web Service Component Through Application Server

The UPnP web service has also been included. It is, for now, the Ontology web service’s only client/caller as well as callee. The UPnP component invokes the OntologyService’s “add” web service method to post an

event occurrence. The chain of processing leads to an event monitoring agent requesting for intervention services such as music to be played/stopped by invoking the UPnPService’s “audioControl” web service method depending on the event that has taken place. The architecture above also shows the end to end connectivity from the low level sensors to a high level reasoning engine located at a remote site. UPnP devices, bridges and control points are implemented to dynamically sense and monitor the context of the patient from various sensors within the autonomous system. The control points are then connected to a central knowledge base through web services. The devices can be controlled through the control points by executing supported actions in the devices. The acquired context of the patient can then be disseminated to remote locations through web services. 1) Modeling of Pervasive Devices and Sensors as Services Next, we will describe the modeling of the sensing and pervasive devices as services for patient monitoring applications as shown in Figure 4 using the service oriented architecture middleware which is based on UPnP, web services and ontology.

Fig. 4. Modeling of Sensors and Pervasive Devices as Services

2) Modeling of Sensing Devices to Provide Services The sensing devices such as the ultrasound sensors, video camera, acoustic sensors and etc. will be modeled as a service as shown in Table 1. TABLE 1 MODELING OF SENSORS AS SERVICES

Sensor Light

Temper ature

Services

Purposes

Vision Calibration Light intensity measurement Temperature Measurement

Provide a calibration parameter for vision-based sensors Give a status of light condition in vicinity of patient Provide a measurement in order to control ambient temperature inside the patient room Provide a calibration parameter for other sensor modalities biased on temperature changes Provide a solution of identifying different people entering/leaving the room

Temperature compensation RFID

Personal Identification

PIR Acceler ometer

Ultraso und

Location Tracking Proximity Detection Movement Detection Tilt Classification Positioning

Motion Tracking

Microp hones FBG

Video

Activity Observation Noise Level Detection Behavior monitoring Motion classification

Track the position of the patient around the room or ward Detect the events of person passing-by within the sensor coverage area Detects the vibration and movements made by patients who are confined to bed or chair Determine the orientation or position of patient on the bed or chair Provide the crude position of the patient or other people is inside the room Track the movements of patient confined to a small region ( small room, hall way inside ward) Detect the coarser-grained activities of patient while confined to one place Measure and detect the vocalization activities from patient Monitor the behaviors and/or sleep patterns of patient on the chair and bed Recognize and classify the fine and coarse grained movements of the patient

We will not describe all the services modeled by the sensors but will illustrate with a few examples. As an example, we model RFID sensors to provide two kinds of services. The first one is the “identification” service for identifying the patient and people stayed around the patient at a particular time using different tags. The second service is “location tracking” to detect the location of the patient. In another example, the video camera provides event recognition service and the ultrasound provides motion recognition service. The typical XML device and service description files for sensing devices such as RFID will contain the following sections to describe these devices and services as shown in Figure 5a and 5b. …….. urn:schemas-upnp-org:device:rfid:1 RFID Company_X http://www.company_x.com ….. uuid:compxrfiddev 123456789012 ….. urn:schemas-upnp-org:service:rfid:1 urn:schemas-upnp-org:serviceId:rfid:1 /service/rfid/description.xml /service/rfid/control /service/rfid/eventSub ….. /presentation Fig. 5a. Section of XML device description file for Sensing Device

……. GetName …… GetLocation ….... …... PersonName string ……. …….

……. Play Pause ……… GetPlayMode ….... …… PlayMode string ……. …….

Fig. 5b. Section of XML service description file for Sensing Device Fig. 6. Section of XML service description file for Pervasive Device

3) Modeling of Pervasive Devices to Provide Services IV. Likewise, the service modeled by the pervasive devices such as the smart door, smart alarm, smart display, etc. is shown in Table 2. TABLE 2 MODELING OF PERVASIVE D EVICES AS SERVICES Pervasive Devices Smart Display

Alarm

Services Visual Notification Simulated Presence Therapy Personal Alert

Smart Door

Wandering Prevention

Smart Music Player

Sound Notification Music therapy

PDA / Mobile Phone

Remote status monitoring

Smart Medicine Box

Automatic medicine taking

Usage Examples Visual notification or amusement programs based on patient preference High risk patient that should confined to one place try to get out unattended Prevent the patient to walk around without anybody noticed Play amusement or religious sound to relief the stress View and Check the vital status of patient anywhere anytime Remind and apply the correct medicine at the right time

As an example, we model a smart music player to provide music therapy service. A sample XML service description file for describing the services offered by it is given in Figure 6 below.

PATIENT MONITORING SYSTEM & SYSTEM TESTING

This paper is presented in the context of a meaningful smart hospital application which monitors the agitation behavior of dementia patient that is based primarily on sensor data sources and pervasive devices. Our collaboration with a local hospital [12, 13, 14, 15] involves the semi-automated monitoring of elderly patients with dementia in a hospital ward for the purpose of detecting the onset of agitated behavior. Figure 7 shows some of the sensors and devices we deployed in the hospital ward to help doctors to perform agitation behavior monitoring. Most of the sensors used in the current project do not support UPnP. It is required to UPnP enable these sensors by running bridging software in the PCs where these sensors are connected to. For wireless motes, data is captured at the PC where the base station is connected to. The received data is processed to extract desired features and offered as part of the service offered by the system. The process of creating services for a typical application can be explained as in the following scenario. Consider the case of RFID antennas located at different places for patient monitoring. An RFID tag can be attached to a patient’s body with a unique ID for identifying the patient. RFID can be used to create location and identity services as explained before. A simple UPnP device created for the RFID system will offer these services to any subscribers that are interested in knowing the location of a patient. The tag-ID will be mapped to the patient’s name and the antenna, where the tag is detected, to a location.

Smart Alarm Mic

Smart Display

RFID

HL7 standards and deploy it in a real life setting adopted widely by hospitals and the healthcare industry. REFERENCES

Smart Music System

PC/Laptop

Video Camera

Mote Base Staion

BS MOI

Wireless Motes with sensors attached (light, pir, ultrasound, etc.)

FBG Pressure sensors

Fig. 7. A Patient Monitoring System

Likewise, there can be many other UPnP enabled devices in the hospital, each of them offering variety of services that can be dynamically discovered and subscribed to. A new service can be introduced to the hospital to give more customized care for the patients. This new service can exploit the existing services through a discovery process. Say, for example the hospital wants to introduce just-in-time treatment such as music therapy for its patients. In this case, we consider media devices such as audio players, TVs and computer systems. Each of these devices can be UPnP enabled to provide MediaRenderer capabilities offering services to playback and audio file and/or to play video on the TV or computer monitor. A MediaServer UPnP device can be added to the system as part of new deployment. The MediaServer can dynamically add content to its repository and make it available for subscribers. Preliminary system testing shows that our proposed SOA approach is feasible for supporting patient monitoring applications. The performance is also reasonably good as the delay in activation of the services provided by the pervasive devices and sensors response is reasonably small though it is subjected to network delay. We are currently working towards developing all the services modeled in the paper and evaluating the system in a more comprehensive manner. V. CONCLUSION & FUTURE WORK We present a SOA approach for patient monitoring using UPnP, web services and ontology. The loosely coupled service oriented architecture designed is the first step for us to make our work more acceptable to industry and hospitals. We are now furthering our work to assist doctors in doing a mass deployment of sensors and pervasive devices in a hospital ward for monitoring the behaviors of patients. While development is in its early stage, the joint effort with a local hospital should see us achieving our long term objective to make it compliant to

[1] Rialle, et al.,”An experiemental Health Smart Home and its distributed Internet-based Information and Communication System”, MEDINFO 2001, IOPress, pp. 1479-1483 [2] K. Matsuoka, “Aware Home Understanding Life Activities”, Proceedings of 2nd International Conference On Smart Home and Health Telematic, pp. 186-193, IOS press 2004 [3] Abowd, et al., “The Aware Home: A Living Laboratory for Technologies for Successful Aging”, Proceedings of the AAAI Workshop and Automation as Caregiver, pp. 1-7 [4] K.Lorintz, et al., “Sensor Networks for Emergency Response: Challenges and Opportunities”, Pervasive Computing, 2004 [5] G. Roussos, et al., “A Blueprint for Pervasive SelfCare Infrastructures”, IEEE International Workshop on Pervasive Computing and Communications Workshop, 2006 [6] Kalasupur, et al., “Service Oriented Pervasive Computing for Emergency Response Systems”, IEEE International Workshop on Pervasive Computing and Communications Workshop, 2006 [7] HL7, http://www.hl7.org [8] CCOW, http://www.ccow-info.net [9] T. Berners-Lee, et al.,“The Semantic Web”, Scientific American May 2001 [10] F. Van Harelen, et al., “Owl Web Ontology Language Reference”, http://www.w3.org/TR/owl-ref/ [11] SNOMED, http://www.snomed.org [12] J. Biswas, et al., “Agitation Monitoring with Persons with Dementia based on Acoustic Sensors, Pressure Sensors and Ultrasound Sensors: A Feasibility Study”, ICADI 2006 [13] V. Foo, et al, “An Ontology-Based Context Model in Monitoring and Handling Agitation Behavior for Persons with Dementia”, IEEE International Conference on Pervasive Computing and Communications Workshops, 2006 [14] V. Foo, et al., “Fiber Bragg Grating Sensor for Monitoring and Handling Bedridden Patients”, to appear in Proceedings of 4th International Conference On Smart Home and Health Telematic [15] J. Biswas, et al., “A System for Activity Monitoring and Patient Tracking in a Smart Hospital”, to appear in Proceedings of 4th International Conference On Smart Home and Health Telematic