当前位置:首页 >> >>

Ambient Intelligence Support for Tomorrow’s Health Care Scenario Based Requirements and Ar

Ambient Intelligence Support for Tomorrow’s Health Care: Scenario Based Requirements and Architectural Specifications of the eu-DOMAIN Platform
F. Chiarugi, G. Zacharioudakis, M. Tsiknakis, J. Thestrup, K. M. Hansen, P. Antolin, J. Camara Melgosa, P. Rosengren and J. Meadows
to utilize services offered remotely. The server tier is the implementer of the conceptual and operative domain models and realizes the main intelligence of the system through a domain model interpreter and several specific managers. The communication infrastructure takes care of all the communication types existing in the system with the use of the most recent technologies especially for wireless communications. A eu-DOMAIN demonstrator has been successfully set-up for the hypertension risk management in high-risk diabetes groups and we expect that the utilization of eu-DOMAIN platform in the eHealth sector will thoroughly demonstrate the envisioned goals of AmI.

Abstract—Ambient Intelligence (AmI) is a vision developed in the last years promoting future scenarios where people will be surrounded by intelligent intuitive interfaces that are embedded in all kinds of objects and an environment that will be capable of recognizing and responding to the presence of different individuals in a seamless, unobtrusive and often invisible way. The traditional human-machine interactions will be modified as a consequence of the continuous trend of pushing computing elements in the background in the attempt of increasing the operation automation in an innovative way where traditional user interfaces will not be needed anymore for guiding the user in its interaction with the system. In these future scenarios the traditional computation model will be transformed into a new paradigm where computers will be comprised in the surrounding intelligent environment, able to interact in innovative ways with the common user and dynamically tailored to the user needs, and wireless communication will be more and more used. In this paper we present the architectural design of the euDOMAIN, a multi-domain platform, which takes advantage of AmI in its overall design, created for the future healthcare and technical service scenarios but able to be easily adapted to different domains. The eu-DOMAIN platform consists of the client and the server tiers, and the communication infrastructure. The client tier encompasses the interactions with the external world like devices and users where devices are managed through “disappearing” computers like gateways and users are generically interfaced through terminals (PCs, PDAs, mobile phones, etc.). The OSGi framework provides mechanisms to discover devices of several manufacturers (for those devices that use protocols that allow discovering, such as Bluetooth) within the range of the gateway, to expose hosted services and
Manuscript received on June 30, 2006. This work is supported by the European Community, under the Sixth Framework Programme, Information Society Technology, within the STREP project “enabling users for - Distance-working & Organizational Mobility using Ambient Intelligence service Networks”, 2004-2007 [IST2003-004420 eu-DOMAIN]. F. Chiarugi, G. Zacharioudakis, and M. Tsiknakis are with the Biomedical Informatics Laboratory, Institute of Computer Science, Foundation for Research and Technology - Hellas, Heraklion, Crete, Greece (phone: +30-2810-391658; fax: +30-2810-391428; e-mail: {chiarugi,gzaxar,tsiknaki}@ics.forth.gr). J. Thestrup is with In-JeT ApS, Copenhagen, Denmark. K. M. Hansen is with the Department of Computer Science, University of Aarhus, Aarhus, Denmark. P. Antolin is with Telefonica I+D, Valladolid, Spain. J. Camara Melgosa is with Software AG SA, Tres Cantos, Spain. P. Rosegren is with CNet Svenska AB, Danderyd, Sweden. J. Meadows is with C International Ltd, Warwick, United Kingdom.

mbient Intelligence (AmI) is a conceptual vision about a future world in which ICT is used to create a userfriendly and intelligent support of personal interaction. The concept of AmI provides a “vision of the Information Society where the emphasis is on greater user-friendliness, more efficient services support, user-empowerment, and support for human interactions. People are surrounded by intelligent intuitive interfaces that are embedded in all kinds of objects and an environment that is capable of recognizing and responding to the presence of different individuals in a seamless, unobtrusive and often invisible way”[1]. AmI builds on three recent key technologies: ubiquitous computing, ubiquitous communication and intelligent user interfaces – some of these concepts are barely a decade old and this reflects on the focus of current implementations of AmI. Ubiquitous computing means integration of microprocessors into everyday objects like furniture, clothing, white goods, toys, even paint. Ubiquitous communication enables these objects to communicate with each other and the user by means of ad-hoc and wireless networking. An intelligent user interface enables people in the AmI environment to control and interact with the environment in a natural (voice, gestures) and personalised way (preferences, context) [2]. In AmI people are empowered through a context aware environment that is sensitive, adaptive and responsive to their needs, habits, gestures and emotions. AmI merges two important trends “ubiquitous computing” and “social user interfaces” [3]. It is expected that, by providing an intelligent environment, quality and cost control can be improved and innovative intelligent personal health services



can be developed [4]. How does the emergence of the AmI paradigm influence our vision of health care? Important trends in modern healthcare include citizen mobility and the consequent move towards shared or integrated care where an individual’s healthcare is the responsibility of a team of professionals in a geographically extended healthcare system. In this new scenario, the possibility of consulting and collecting clinical information from different points is becoming a common need for citizens and physicians. Moreover, the increase in the life expectance has produced an older population that may need continuous assistance especially in cases of serious or chronically ill people that wish to live independently. A clear benefit is obtained when high quality of care can be delivered outside the hospital premises allowing people at risk or patients with proved health problems to continue their usual life at their homes and work places. Remotely delivered care for prevention or follow-up situations is becoming increasingly feasible, through sophisticated eHealth services facilitated by intelligent environmental and biomedical sensors, portable monitoring devices, hand-held or wearable technologies, the Internet and wireless broadband communications. In this perspective, with focus to the provision of high quality of care, assuring life independency, the significant new research challenge is the use of ubiquitous computing, social user interfaces and inexpensive wireless communication technology, for the creation of intelligent eHealth spaces that can accelerate the extensive deployment of sensor technology in tomorrow’s eHealth services. In this paper we present the architectural design of the euDOMAIN, a multi-domain platform, which takes advantage of AmI in its overall design, created for the future healthcare and technical service scenarios but able to be easily adapted to different domains. About 10 million Europeans travel everyday across Europe to do their work outside their normal workspace. The eu-DOMAIN platform is focused to improve their ability to optimise their professional work, increase the competitiveness and visibility of their host organisations and generally improve the quality of life for European citizens. II. MATERIALS AND METHODS The eu-DOMAIN platform develops a new, innovative European AmI service platform for automatic, context sensitive offering and contracting of mobile web services across heterogeneous networks. It connects not only people and content but also buildings, devices and machines in an interoperable network and contributes to the availability of a structured AmI middle-layer. It enables a mobile worker to access his “virtual user profile” wherever he needs to work, intelligently accessing the services and devices he needs, and allows content providers to offer advanced “augmented reality” services to their users, creating new ways of collaborative working.

A major effort was devoted to research and development in infrastructure components that can be integrated into a workable validation platform upon which the scenarios of different domains can be evaluated against user requirements defined at the onset of the project. The technological infrastructure was foreseen to contain the following main components (see figure 1):

Local Area Device Networks ZigBee WLAN

Ad-hoc Vehicle Networks Local Area Device Networks Ethernet LON/PLC/EIB W LA N


eu-DOMAIN Residential Gateway

eu-DOMAIN Vehicle Gateway

Wide Area Network

eu-DOMAIN Service Gateway

Wide Area Network

Wide Area Network Backbone

eu-DOMAIN Serverpark

Figure 1: The foreseen technological infrastructure of the euDOMAIN platform.

? Ambient Intelligence platform: distribution of location specific, application specific and network intelligence pools and definition of information object classes. ? Web services provisioning and content delivery: web provisioning tools, protocols, negotiation tools, billing and other components of the service and content delivery chain. ? Client architecture: service gateways for buildings and vehicles with location and application specific intelligence pools. ? Communication infrastructure: a prototype communication infrastructure for use in system integration and validation of the eu-DOMAIN platform. ? Server architecture: a powerful eu-DOMAIN server park providing the main network AmI functionality.

The functionality and architecture of each component were foreseen to be as detailed below. Ambient Intelligence platform: Users need different levels of intelligence support depending on location and situation and the platform must be able to adapt to system dynamics. The eu-DOMAIN operates with three different pools of intelligence (as seen from the users’ point of view): ? Location Specific Intelligence, i.e. intelligence support based on the actual location of the user and the situation to be supported. ? Application Specific Intelligence, i.e. intelligence support targeted to an actual service provider application like alarm services, healthcare, etc. ? Network Intelligence, i.e. the under laying intelligence support that is not tied into neither a specific application or to a specific location, e.g. web provisioning of weather forecasts. Users have automatic access to the eu-DOMAIN network via multimodal interface devices through fixed or mobile communication according to the location and context in which the dialogue is going to take place. Web services provisioning and content delivery: Third party service providers may deliver web services via the euDOMAIN network and the service gateway directly to the user. The services can be either one-way service delivery or two-way interactive services. The platform also allows for provisioning of traditional one-way HTML content and for advanced semantic web searches. The services are automatically negotiated, e.g. via XML and semantic web W3C Resource Description Framework (RDF) [5] protocols. Client architecture: Each location has installed one or more service gateways. They form dynamic, local intelligence clusters and access points to existing local area networks, through which, two-way communication with other installations in the building (e.g. alarm systems, energy control, etc.) can be established. The gateway can communicate simultaneously with other systems in the location via built in device nets, e.g. LONWorks, WLAN or ZigBee wireless data protocol. The gateway also facilitates access to internal and external content repositories, e.g. electronic health record (EHR) systems, manufacturing systems, etc. Service gateways are configured with an Open Service Gateway initiative (OSGi) framework [6] for bundled services thus being able to download a wide variety of services made available from different manufacturers and service providers for the range of services to be delivered by the eu-DOMAIN network. Further, the service gateway provides the location specific intelligence, i.e. the intelligence that can and should be provided locally, without involving higher hierarchy intelligence layers. Communication infrastructure: All service gateways communicate with the eu-DOMAIN network servers with IP protocols via available Wide Area Networks (broadband,

dial-up or mobile networks) for complete interoperability. The main novelty aspect of the platform is the ability to perform automatic roaming across heterogeneous networks in order to provide interoperable services. Figure 2 shows the communication infrastructure:

Figure 2: eu-DOMAIN communication infrastructure.

Server architecture: The server park is the central element in the eu-DOMAIN service platform. A powerful eu-DOMAIN server park provides the network AmI functionality. The servers handle both the eu-DOMAIN network intelligence and the application specific intelligence. In the testing phase, all servers are hosted in the same location, but in real life, application servers will be hosted with various service providers in geographically distributed locations. Substantially, the eu-DOMAIN platform will be based on a multi-tier architecture able to integrate sensors/actuators of several manufacturers. Devices that use a wireless communication channel will be preferred in a full exploitation of the AmI concepts, but platform flexibility will also permit the use of traditional cable-connected devices waiting for a complete maturity of the wireless device market when third-party devices with full disclosed or standard protocol will be available to integrators and service providers. III. RESULTS A. An operative scenario for the healthcare domain The first operative scenario for the healthcare domain was related to the hypertension risk management in high-risk diabetes groups. It should be noted that all characters in the scenario are fictitious. Mrs. Tahira Khan is a 65-year-old lady who recently arrived in the UK to join her son and daughter-in-law – Kamal and Asma in Birmingham – after her husband died. Tahira speaks little English and has relatively poor literacy in her own language. Shortly after her arrival in the UK, she sees Dr. Hayworth, their local GP, for a health check. It transpires that she has had type II diabetes for about three years and has made no efforts to change her diet. The GP

explains her condition and outlines various pathways that she must consider to cope with her disease. Dr. Hayworth passes the EHR details (Tahira must sign the email with her electronic signature for the authorization) to the Muslim Health Diabetes Support Service who has a special contract to support such client groups. Tahira is seen and assessed by Sania, the outreach healthcare assistant. Sania identifies a series of her personal health and social care needs. She is mildly overweight and confused about her condition and her initial three blood pressure readings are high (the mean is 160/100). This information is uploaded from the blood pressure device in real time into her patient record. From anywhere, Dr. Hayworth, her local pharmacist and the local health and social care team can access her details on-line. Given the likely hypertension Tahira is referred to a 24hour ambulatory blood pressure monitoring via the euDOMAIN network that recently was installed in Birmingham. Sania shows to Kamal a list of suitable and trusted devices for blood pressure monitoring and Kamal finds one of them and brings it home. The device is able to automatically configure itself and Dr. Hayworth is informed electronically when the device is operating, and after having checked the readings, he gives his permission (using his certificate) to upload the results automatically into her EHR. He also sets up his own monitoring scheme, which will make eu-DOMAIN platform monitor Tahira and warn him, if her mean blood pressure is outside preset limits for more than three consecutive days. A technician also visited Kamal’s home to install the AmI environment. Based on a range of house sensors, the euDOMAIN will be able to monitor critical situations when Tahira is alone in the house. It will also be able to make intelligent decisions in respect to who and how to organise assistance. Minor things will involve the immediate family, Kamal and Asma, via mobile telephones. Just in case, Kamal makes sure that he also has access to the data, so he can follow his mother’s progress and receive regular detailed status reports on his email. Dr. Ahmad, the case manager, now initiates her medical treatment plan. After a short, on-line electronic discussion between Dr. Hayworth and Dr. Ahmad, the diabetes consultant and the pharmacist start an anti-hypertensive treatment. At the same time, Dr. Hayworth enables his nurse practitioner Mrs. Cumberland to be responsible for the dayto-day contact with and monitoring of Tahira. As part of the initial assessment, Tahira already had the initial 24-hour ambulatory monitoring and Mrs. Cumberland switched the device bought by Kamal to “compliance mode” from her PC. The device will now only send information, when Tahira uses it, but eu-DOMAIN will monitor how frequently she uses it and remind her, if her measurements become too infrequent. Dr. Ahmad has suggested twice daily monitoring of blood pressure for a month with each reading uploaded into a

blood pressure profile of the Tahira’s EHR. Kamal will now receive a text message when there is a suspected deviation from her norm profile. All goes well and within three weeks whilst remain asymptomatic, Tahira’s blood pressure reaches the target of 140/85. At the review by Dr. Hayworth, Tahira is shown her blood pressure profile on-line and her efforts at increasing her physical activity, improving her diet, and losing weight are all praised. Her management plan is now altered so that she will be seen every six monthly for a full diabetes review whilst she monitors her blood pressure weekly with the blood pressure device. Behind it all, Kamal and Asma are very pleased that Tahira’s condition was discovered in time and that the euDOMAIN infrastructure now allows them to live a normal family life, without daily fear of the potentially dire consequences of his mother’s diabetes. B. The eu-DOMAIN Platform: Architecture To support heterogeneous devices, terminals, and content providers, the eu-DOMAIN is divided into four tiers containing devices, terminals and gateways, servers, and external services respectively. The high-level overview of the eu-DOMAIN platform is shown in figure 3. Briefly, the tiers have the following structures: ? The Device Tier contains devices which are sensors, actuators, and processors installed at a location. An example of a device is a blood pressure monitoring device which is accessible via serial line or Bluetooth. Devices communicate with the eu-DOMAIN platform solely through their connection to a gateway. euDOMAIN does not assume any specific protocols on behalf of devices. ? The Client Tier contains terminals and service gateways. Terminals (i.e. PDA) provide the user interface to the eu-DOMAIN platform through web browsers. Gateways are dedicated hardware boxes installed at a location and implementing the concept of the “disappearing” computer. They mediate between devices and the server tier through physical connections to devices and through a network connection to the server tier, and are responsible for integrating devices into the platform transparently to the user. ? The Server Tier contains servers implementing the euDOMAIN platform functionality per se. Multiple euDOMAIN applications (such as facility management from different service providers or facility management and eHealth services) may run on the same euDOMAIN server deployment. ? The Service Tier contains services external to euDOMAIN which are accessible through web services. An example of a service would be a web service-based interface to the producers of equipment for a facility management application. Again, the eu-DOMAIN platform does not make any assumptions on the type of web service interface that external services provide.

From a logical point of view, the eu-DOMAIN architecture contains concepts supporting the integration of people, tasks, services, and devices realized as objects in a domain model. The domain model (what in many information systems is called “Business Logic”) reflects the key concepts of eu-DOMAIN. At runtime the domain model contains all data and operation that must be implemented in order for higher level functions to work, hence the model can be seen as the meta-information about the implementation. The domain model solution described here makes no assumptions about how these features will be implemented, focusing only in how to allow all these features to be used by every other part of the system. The concept of intelligence as described previously is distributed in all the tiers of the architecture (see figure 4): ? The Application Intelligence offers the features domain users know about, the end functions of the system that are useful to domain users. ? The Location and Network Intelligence provide the technical infrastructure to make the above possible. The location intelligence relates to client infrastructure, at the gateway side, and the network intelligence relates to the rest of the infrastructure, like server-side, clientserver communications or external communications.

Figure 3. Overview of the eu-DOMAIN platform.

The main components of the Client Tier are: (a) an Open Service Gateway initiative (OSGi) implementation that provides for managed deployment and execution of lightweight Java components in the form of bundles; (b) Device Access Services which handle interaction with devices through the protocol of the device including driver issues; (c) Platform Services which implements functionality needed across eu-DOMAIN applications and that includes OSGi common services such as an http service and log service; (d) Domain Model which packages a client-side domain model; (e) Web Browser on terminals provides end user interaction capabilities with the eu-DOMAIN platform. The main components of the Server Tier are: (a) the Domain Model provides an interface for all concepts in specific application domains (such as Patient, Bill and Location) through which components may access domain data and functionality; (b) Interpreters contain rule-based parameterizations of functionality for eu-DOMAIN such as alarm handling and device management; (c) Managers contain specific implementations of functionality for euDOMAIN such as billing or log handling; (d) Servers are the primary access points to and from other tiers in the euDOMAIN architecture. All components are in principle accessed through a web service interface for interoperability and scalability reasons. If two components are running on the virtual machine and an invocation between them is made, the invocation is optimized as a local call and not a web service invocation.

Figure 4. The different intelligences of eu-DOMAIN.

The location intelligence encompasses the data, processes and knowledge in general related to the operation and management of the elements of eu-DOMAIN which are under the responsibility of a given gateway and is the part which makes the gateway work, while remaining fully hidden from domain users as technical infrastructure. The network intelligence encompasses any knowledge in general related to the operation and management of eu-DOMAIN as a whole. It is the part which allows the whole of euDOMAIN to work, but which still has no meaning at all for domain users because it is technical infrastructure. The application intelligence comprises the knowledge in general which provide domain users with the functionality they need. It is the part of the system which provides the functions that make sense at the domain level, i.e. which handles concepts that some domain user knows about. C. The eu-DOMAIN Platform: Medical Devices The eu-DOMAIN enabled devices are described as: actuators, sensors, or processors that are installed and operated in a eu-DOMAIN location. At any point in time, devices are connected, wired or wireless to one gateway, but

devices may move between gateways as a consequence of user mobility. Devices that use a wireless communication channel are preferred in a full exploitation of the AmI concepts, but platform flexibility also permits the use of traditional cableconnected devices waiting for a complete maturity of the wireless device market. Given that there are advantages and disadvantages in both these technologies, it is likely that future solutions will consist of integrated systems, in which wired and wireless devices co-exist in the network. The most common connections for wired devices are: serial cable RS-232, serial cable USB, parallel cable, network cable (typically Ethernet or Fast Ethernet), whereas most common standard for wireless devices are: IEEE 802.11x, Bluetooth and ZigBee. Different medical devices have been integrated in connection with the implemented healthcare scenario (hypertension risk management in highrisk diabetes groups) in order to cope with both office and home care situations. The devices were selected taking also into account the availability of an open or disclosed protocol for the data format and transmission to a host computer. For the home environment, the Omron 637IT wrist blood pressure monitor has been selected. This device is an autonomous and fully automatic blood pressure monitor that can be plugged to a computer via USB connection. Its main features are: measurements of systolic pressure, diastolic pressure and heart rate including the date in the storage for further study, USB cable for PC connection, graph display for weekly overviews and large display showing blood pressure and heart rate. For the hospital environment the Welch Allyn Propaq Encore vital sign monitor has been selected. The data can be transferred to a computer by serial cable RS232 and several vital signs can be simultaneously monitored: ECG, heart/pulse rate, non-invasive blood pressure, motion tolerant pulse oximetry, impedance respiration, temperature. In order to test the platform with a Bluetooth connected medical device, the Nonin wearable oximetry Avant 4000 with Bluetooth wireless technology was also successfully integrated in the eu-DOMAIN platform. This device is able to measure the pulse oximetry and the pulse rate. IV. DISCUSSION AND CONCLUSIONS The primary user objectives of eu-DOMAIN are the development of innovative applications with on-demand delivery of services in order to enhance the work environment for mobile users and workers and their integration with intelligent surroundings wherever they are: buildings, vehicles, public spaces, etc. The services will be seamlessly accessible through the use of mobile and fixed service gateways embedded in the surrounding structures, e.g. buildings or vehicles, and will support completely new ways of collaborative working like augmented reality support and workgroup knowledge sharing. eu-DOMAIN gateways with distributed intelligence

allow for various collaborating group members working together via heterogeneous networks (mobile or fixed communication infrastructures). The services will be location and context sensitive in order to provide targeted decision support. The location information will be provided by wide-area GPS services whereas the context sensitivity will be provided by automatic interaction with the surroundings. Extreme focus on usability and intelligent interfaces will aim at alleviating issues of computer illiteracy and broadly promoting eInclusion. The eu-DOMAIN service platform will facilitate collaborative working with seamless delivery-on-demand of services from content repositories to people, machines and devices, will enable mobile AmI awareness allowing the user to integrate his virtual user profile into any location and thereby providing context aware decision support combined with delegation of work, and will give content providers the possibility of delivering new web services, e.g. augmented reality to mobile users, thus creating new collaborative work environments and new methods of working across geographically distributed organisations. A first eu-DOMAIN demonstrator has been successfully set-up for the hypertension risk management in high-risk diabetes groups and we expect that the utilization of euDOMAIN platform in the eHealth sector will thoroughly demonstrate the envisioned goals of AmI. A second demonstrator will focus the industrial services sector, and specifically facilities management. The complete euDOMAIN platform will be made available in a period after the completion of the project in order to stimulate take-up activities in other application domains. ACKNOWLEDGMENT This work is supported by the European Community, under the Sixth Framework Programme, Information Society Technology, within the STREP project “enabling users for – Distance-working & Organizational Mobility using Ambient Intelligence service Networks”, 2004-2007 [IST-2003004420 eu-DOMAIN]. The authors would like to thank all the partners of the euDOMAIN consortium for their support and help in the work on which this paper is based. REFERENCES
[1] [2] [3] [4] EC-ISTAG, “Scenarios for Ambient Intelligence in 2010,” Final Report, Feb 2001. J. Ahola, “Ambient Intelligence,” ERCIM News no. 47, October 2001. M.S. Raisinghani, et al., “Ambient intelligence: changing forms of human computer interaction and their social implications,” Journal of Digital Information, Vol. 5, Issue 4, August 2004. M. Spanakis, P. Lelis, F. Chiarugi, C. Chronaki and M. Tsiknakis, “R&D challenges in developing an ambient intelligence e-health platform,” Proc. of EMBEC 2005, Prague, Czech Republic, November 2005. World Wide Web Consortium. Available: http://www.w3c.org/. OSGi Alliance. Available: http://www.osgi.org/.

[5] [6]



All rights reserved Powered by 甜梦文库 9512.net

copyright ©right 2010-2021。