the 
 growth in population ageing in most industrialized nations and the related 
 increasing percentage of   chronic disease diffusion is posing several problems 
 at different levels of our society ( political , 
  social , and familiar / personal 
 levels ) .
statistics 
 data   provide a clear picture of the problem dimensions : according to recent results 
 of a survey funded by the european commission , europe 
 and japan 
  will experience the most pronounced ageing trends up to 2050
. the share of the 
 above 60 age group will be around 37% in europe and even more in japan , and 
 slightly lower in north america ( 27% ) .
the percentage of the eu population over 
 the age of 65 is expected to reach more than 28% by 2050 , with an estimated 
 group of 80 million people that will need care and assistance services , in 
 particular for chronic diseases .
new 
 care models for chronic condition management have been proposed which define 
 guidelines for policy planning , as well as principles for social community and 
 health - care system organization and effort coordination .
these models ,   usually 
 named continuous - care 
 models , 
 promote home - based continuous care for chronic patients . they emphasize the 
 fact that the effectiveness and efficiency of long - term condition care depend 
 strongly on the capability of both the patients and their relatives to manage 
 their cases ( self - management ) and on the collaboration of all involved care 
 providers .
patients , family members , health - care teams ( e.g. , clinicians , 
 general practitioner , nurses , etc . ) , and social community members ( e.g. , social 
 workers , volunteers ) should be properly informed , motivated , and prepared in 
 order to effectively collaborate together .
one 
 of the first examples is the chronic care model ( ccm ) , which is a conceptual , 
 evidence - based framework developed in the usa 
  .
this model proposes 
 innovative organizational aspects aiming at improving the effectiveness and 
 efficiency of assistance to patients affected by chronic conditions .
the who 
 has recently proposed the innovative care for chronic conditions ( iccc ) 
 framework , which widens the ccm in order to meet the needs of the international 
 community .
therefore , 
 advances in information and communication technologies ( icts ) and ambient intelligence 
 ( ami ) context - aware system design are required in this framework in order to 
 address two main objectives .
the final objective is to improve the quality of 
 life of both patients and their closest relatives . as a matter of fact , while 
 it is obvious that chronic conditions may cause limitations to a patient 's 
 everyday activities , it should not be overlooked that they may dramatically 
 decrease the quality of life for a patient 's family members as well . in 
 order to care for the elder , relatives may be asked to make drastic life 
 changes , such as quitting their jobs and giving up their social lives . for such 
 a purpose ,
an ulterior objective is the implementation of ict platforms capable 
 of supporting long - term care service provision while enabling cost savings and 
 effective heterogeneous resource management ( e.g. , professionals , biomedical 
 instruments , etc . ) . from 
 the viewpoint of ami and context - aware system designers ,
services which should be provided 
 by an ami system have been classified into the following categories :   ( a ) emergency treatment ( services for 
 emergency detection and management ) ; ( b ) autonomy enhancement , that is , user 
 assistance services for primary needs and/or everyday activities ( nutrition , 
 taking medication , monitoring vital signs , etc . ) ; comfort services , that is , 
 services enabling better life quality ( e.g. , education , socialization , etc . ) .
these 
 services should be adaptive , easy to use , and strongly personalized according 
 to user requirements , needs , and disabilities . in most existing ami 
 context - aware systems , the focus is on the requirements of the person needing 
 assistance ( the  patient  ) , whereas requirements coming from the heterogeneous 
 community of people , who are involved to different extents in patient care and 
 assistance ( the  caregivers  ) , are often not taken into account when designing 
 the system . in 
 this paper
, we describe some results obtained through our current research on 
 the design and development of a service - oriented architecture for continuous 
 care provisions leveraging on context - aware and mobile technologies , called emilia romagna mobile health assistance network ( ermhan ) .
its aim is to enable 
 the development and delivery of an extensible set of care services which allow 
 patients to be assisted at home in a familiar environment and support the 
 activity and mutual collaboration of care providers who are involved to a different 
 extent in patient care and assistance .
proper and effective information sharing 
 for action and cooperation support by involved care providers is specifically targeted , 
 due to their work in mobility conditions , their association to different 
 organizational domains ( e.g. , hospital and municipality ) , and their various 
 roles ( such as general practitioner , specialist , nurse , family members , etc . ) .
, we highlight the contribution of 
 our work and discuss existing related research activities .
section 3 describes 
 the specific objectives of our work with special focus on the context - aware 
 approach and in section 4 we describe the ermhan system architecture and some 
 implementation details about the two main components , the multichannel health - care service manager and the context 
 management system . in section 5 , we discuss some preliminary system 
 evaluation results and user testing activities .
section 6 concludes the paper 
 by highlighting the most relevant results of our work and future research 
 directions .
several 
 research domains can be considered of interest in delivering ami and pervasive 
 health services for chronic diseases , spanning from smart homes , assistive 
 technologies and home - based health monitoring , to context - aware hospitals .
one of the first relevant contributions 
 has been provided by researchers working at the georgia tech aware home , a prototype of a smart home , where sensing 
 and perception technologies are used to gain awareness of inhabitant activities 
 and to enable services for maintaining independence and quality of life for an 
 ageing population .
the inhome 
 project   aims at   providing the means for improving the quality 
 of life of elderly people at home , by developing technologies for managing 
 their domestic environment and enhancing their autonomy and safety at home ( e.g. , 
 activity monitoring , simple home environment management , flexible av streams 
 handling , flexible household appliance access ) . among more recent works ,
the 
  ubiquitous home  is a real - life test - bed for home - based context - aware service 
 experiments   in japan . 

a set of implemented context - aware services has been evaluated by means of 
 real - life experiments with elderly people . in the field of assistive technologies 
 and home - based health monitoring systems ,
several examples exist : vivago is an 
 alarm system which provides long - term user activity monitoring and alarm 
 notification ; the caremedia system 
  uses multimedia 
 information to track user activities .
the  hospital of the future  prototype 
 is an example of a context - aware computing system in a hospital environment .
it 
 consists of a series of context - aware tools : an electronic patient record ( epr ) , 
 a pill container , and a hospital bed which displays relevant patient record 
 information , such as the medicine schema , according to contextual information ( e.g. , 
 nurse position , patient , medicine tray ) .
have recently 
 proposed a context - aware mobile system where mobile devices are capable of 
 recognizing the setting in which hospital workers perform their tasks , and let 
 users send messages and access hospital services according to these contextual 
 elements . despite 
 the multitude of relevant contributions in the above - mentioned research fields , 
 only recently research activities on pervasive services for ageing and chronic 
 disease management have begun addressing these requirements by means of a 
 holistic approach , taking systematically into account standard guidelines and 
 reference models for continuous care .
have applied 
 social network analysis methodology to the study of continuous care networks ; 
 they conducted a series of interviews in order to explore the space of 
 eldercare ( i.e. , who was involved in the care , what types of care were needed , 
 and what types of care were being provided ) ; based on user study results they 
 offer some design guidelines for the development of successful computer - supported 
 coordinated care ( cscc ) systems .
pervasive 
 self care is a conceptual framework for the development of pervasive self - care 
 services .
this study has 
 been promoted in the framework of self care , an initiative by the department of 
 health in the uk 
  that aims at treating patients with long - term conditions near home .
the 
 proposed reference model , inspired by the principles of service - oriented architecture 
 ( soa ) , distinguishes three main spheres : the body sphere ( a body area network 
 supported by a router which interacts with body sensors and with the home 
 sphere ) ; the home sphere ( a home server that collects and preprocesses sensed 
 data ) , and the self - care service sphere ( the data processing and sharing 
 subsystem ) . some 
 experimentation results are given in , where a telemedicine system is used 
 for the home care of patients suffering from chronic obtrusive pulmonary 
 disease ( copd ) ; the integrated telemedicine system provides professionals with 
 shared and ubiquitous access to patient health records and patients with direct 
 access to nurse case manager , telemonitoring , and televisit services .
the 
 design of ict tools for chronic disease management should take into account 
 flexibility and extensibility requirements .
these requirements are common to 
 all kinds of distributed systems , but especially are applied to this 
 application domain , due to its intrinsic characteristics , such as different 
 national and local regulation frameworks , the heterogeneity of health centers 
 and communities involved in care service delivery , and the patient 's health 
 status development over time . in such a complex and changing environment , cost - effective 
 solutions should be conceived as extensible and flexible service platforms . for 
 that reason , while the research activities surveyed above have focused on the 
 conceptual design or implementation of applications that target specific 
 chronic diseases and not on a specific chronic disease from the very beginning , 
 our approach has been to design and deploy a service platform that provides 
 general purpose services and could be easily extended and specialized in order 
 to match specific requirements of real cases .
the 
 aim of our research has been to design and implement ermhan , an extensible 
 service platform supporting care teams in providing long - term assistance 
 services .
extensibility and flexibility of the ermhan service platform are mainly 
 achieved by means of modular and service - oriented design and the adoption of 
 open and standardized data formats and communication protocols .
the platform design is based on the 
 definition of basic functional blocks and their interconnection by means of web 
 services standards . as a matter of fact ,
web services are recognized as an open 
 and standardized way of achieving interoperation between different software 
 applications , running on heterogeneous platforms and/or frameworks .
semantic 
 web technologies have been applied to data representation and processing in 
 order to provide instruments that ease the development of pervasive and 
 personalized care services .
more specifically , semantic web is used in order to 
 ( a ) represent knowledge by means of ontology - based formalisms ; ( b ) reason over 
 knowledge using rule - based and ontology - based engines ; ( c ) apply reasoning 
 techniques in order to implement personalized healthcare plans .
the 
 prototype we have developed provides basic and general - purpose services for 
 information sharing , distributed , and multichannel personalized access to 
 patients ' records and personalized real - time monitoring and alarm management on 
 a per patient basis .
implemented services include access to complete and 
 updated patient records ( including patient health status , description of care 
 provider interventions ) , even in mobility conditions ( at the hospital or at 
 patient 's home ) and through different devices ( at least personal digital 
 assistants and desktop pcs ) ; notification of patient health status conditions 
 and alarms , but without overwhelming care operators with too much information 
 ( this might have the drawback of disturbing users and providing them with  no 
 information  ) .
more effective information delivery could be achieved by routing 
 intervention requests according to patient health status gravity and required 
 expertise for intervention .
based 
 on its flexibility , the ermhan service platform can be specialized to address 
 the needs of specific patient cases .
to achieve this objective , the basic 
 services provided by the ermhan platform can be integrated with those offered 
 by other systems , such as assistive technologies , home automation systems , 
 specific chronic disease prognoses , and diagnosis systems . in the 
 following sections ,
we provide further details about the modeling approach and 
 system architecture of ermhan platform .
the 
 objective of this research is the design and prototypal development of a 
 context - aware mobile service platform ( ermhan ) for long - term home - based care 
 services delivery to chronic patients .
ermhan 
 aims at supporting the main characteristics of emerging chronic care models : ( a ) 
 home - centered long - term patient followup ; ( b ) shared care provided by a network 
 of heterogeneous care providers ( named  continuous care network  ) ; ( c ) 
 adaptation of care plans on a per patient basis . with 
 the term  continuous care network
 we refer to the broad range of people 
 involved to different extents in the care of the elder , such as patient 
 relatives , the multidisciplinary teams at different health - care levels ( e.g. , 
 general practitioners , specialists ) , social operators , volunteers , and so forth .
they 
 belong to different organizations ( e.g. , hospitals , municipality , private 
 institutions ) , may work in more than a single location , and do not usually have 
 regular face - to - face contacts with other network members .
due 
 to the complexity of the care network , its ad hoc nature , and loosely coupled 
 structure , we have identified a set of basic services to be provided to care 
 providers : ubiquitous access to patient - health records ( via mobile device or 
 desktop pc ) ; role - based information sharing among different network members 
 belonging to different organizations ; capability of adapting health plans on a per - patient basis .
more 
 specifically , health - plan personalization is implemented in ermhan in terms of 
 personalized context - aware rules for alarm detection and management , as 
 described in the next paragraph .
even 
 if the aim of our work is to provide services to care providers , and 
 consequently developing assistive technologies are not the main target of this 
 work , ermhan provides some basic services for patient assistance , for example , medication 
 reminders , manual alarm activation , and communication request services . as the 
 focus of this work is on the architecture for service integration and delivery , 
 human computer interaction ( hci ) issues , such as usability and accessibility , 

the 
 ermhan reference   application scenario consists of two main domains ( see figure 1 ) : 
 the patient home , that is , 
 the environment where the patient lives , often with some relatives , and where 
 patient monitoring and assistive technologies would be deployed;the care centre , that is , 
 the domain of the organization responsible for care service integration and 
 delivery ( e.g. , hospitals , nursing homes or municipalities ) . for the sake of 
 simplicity , in our scenario
this is presented as a single logical point of 
 care , providing ict services to care operators who can belong to different 
 organizations .
actors considered in our scenario are doctors ( general 
 practitioners and specialists ) and nurses .
more complex scenarios involving 
 other organization domains ( e.g. , voluntary associations , pharmacies , etc . ) 
 will be analyzed in future research activities . 
 
the patient home , that is , 
 the environment where the patient lives , often with some relatives , and where 
 patient monitoring and assistive technologies would be deployed ; the care centre , that is , 
 the domain of the organization responsible for care service integration and 
 delivery ( e.g. , hospitals , nursing homes or municipalities ) . for the sake of 
 simplicity , in our scenario
this is presented as a single logical point of 
 care , providing ict services to care operators who can belong to different 
 organizations .
actors considered in our scenario are doctors ( general 
 practitioners and specialists ) and nurses .
more complex scenarios involving 
 other organization domains ( e.g. , voluntary associations , pharmacies , etc . ) 
 will be analyzed in future research activities .
this 
 paragraph describes what we do intend for  context awareness  in the framework 
 of home - based continuous care and the context model that has been adopted in 
 ermhan .
context 
 awareness is a general concept that refers to the capability of a system to be 
 aware of its physical and logical environment and to intelligently react 
 according to this awareness .
the definition of context is likely to change 
 according to the application domain and related purposes . in 
 our application scenario ,
context awareness is meant as the capability of the 
 system to acquire and interpret relevant information with respect to the main 
 goal ( patient quality of life ) and to perform actions aiming at achieving such a 
 goal .
thus , the context may include information about patient health status , 
 inferred by sensed biomedical parameters ( e.g. , vital signs ) , and home 
 environment ( e.g. , temperature and relative humidity ) .
even social context 
 ( i.e. , information regarding people populating the patient care network ) may be 
 considered as relevant information to be exploited for context - aware assistance 
 service delivery .
the acquisition of these context data can be profitably 
 exploited by the system in order to infer relevant situations related to 
 patient status , ( such as critical condition and alarm detection ) and trigger 
 proper actions in order to facilitate the care providers ' operations ( i.e. , 
 alerting care providers for intervention ) .
an 
 ontology - based context model , written in web ontology language ( owl 
 ) , is employed 
 throughout the entire process of sensing , interpreting , managing , and 
 exchanging context information .
we have extended a general purpose 
 ontology - based context model   with concepts 
 and relations describing the home care setting .
the 
 owl - based context model is used in order to represent system knowledge about 
 patient health status by means of ontology - based formalisms .
the context model 
 provides a uniform representation of data coming from heterogeneous sources , 
 such as biomedical sensors , home monitoring systems and users ' manual input . 

ontology and rule - based reasoning are applied over the context model in order 
 to check the consistency of context information and to infer further knowledge . 

rule - based reasoning is applied in the ermhan system in order to infer patient health 
 conditions , detect alarm conditions originating from a patient health status or 
 other events ( e.g. , the patient does not take medication ) , and select the 
 alerting policy which is most suitable according to alarm level and other 
 context information ( e.g. , availability of care providers for intervention ) .
the 
 main advantage of this approach consists in representing the business logic of 
 the system in an explicit and declarative way .
thus , adaptation of health plans 
 on a per patient basis can be realized by allowing care providers to specify 
 rules tailored to the patient case .
hereafter 
 we describe the main features of the context modeling and reasoning 
 capabilities implemented in the ermhan system .
a complete description of our 
 ontology - based context model for home health monitoring and alerting in patient 
 care networks is out of the scope of this article and is fully 
  described in .
the patient - domain ontology includes context items 
 about patient biomedical parameters , location , and activity .
this information 
 is used by the system to automatically infer patient health status and detect 
 alarm situations by means of rule - based reasoning .
biomedical parameters 
 instances are represented together with some relevant properties , such as 
 measurement values and parameter ranges . each range is specified in terms of 
 upper and lower thresholds and related alarm level ; when a measured value falls 
 out of the thresholds , an alarm of the corresponding level is detected .
patient 
 health status is thus determined by comparing biomedical parameters ' measured 
 values with a set of parameter ranges .
we have specified four basic alarm 
 levels ( very low , low , medium , high ) , but the model can be easily extended to 
 include further levels.the home environment ontology includes 
 context data that describes the patient home environment .
for instance , 
 monitoring environmental parameters ( such as temperature and relative humidity ) 
 are needed in order 
 to maintain a healthy environment and detect alarm situations .
alarm triggering 
 based on environment parameters is analogous to the one based on biomedical 
 parameters , described above.the social context ontology represents 
 care network resources ( health teams , social community members , etc . ) and their 
 relations .
care network members that are represented as concepts in this 
 ontology include the patient , patient relatives , who take active part in 
 implementing the assistance plan , health operators ( medical and paramedical 
 staff ) who are in charge of patient care ; social community organizations which 
 offer assistance services ( e.g. , transport and companion services ) . the social 
 context ontology is also used to represent other information which is 
 considered relevant to the ermhan application purposes , such as the 
 availability of a health operator for an intervention and the distance of a 
 relative from patient location ( travel time ) . at present
, users can provide 
 this information via a web form provided by the profile management services , by 
 choosing among predefined values ( e.g. ,  available , 
as part of future work , we will investigate the use of context - aware systems 
 that can help in semi - automatically updating and managing such information ( e.g. , 
 gps positioning and inference mechanisms).the alarm management ontology represents 
 the policy that should be instantiated to manage an alarm .
such policy 
 describes the steps that should be performed in the event of an incoming alarm . 

rule - based reasoning over this ontology model is used to select the suitable 
 alarm handling policy according to different context items , such as the 
 incoming alarm level , the patient identifier , and the availability of care team 
 members ( i.e. , the information represented by the social context ontology ) . 
 
the patient - domain ontology includes context items 
 about patient biomedical parameters , location , and activity .
this information 
 is used by the system to automatically infer patient health status and detect 
 alarm situations by means of rule - based reasoning .
biomedical parameters 
 instances are represented together with some relevant properties , such as 
 measurement values and parameter ranges .
each range is specified in terms of 
 upper and lower thresholds and related alarm level ; when a measured value falls 
 out of the thresholds , an alarm of the corresponding level is detected .
patient 
 health status is thus determined by comparing biomedical parameters ' measured 
 values with a set of parameter ranges .
we have specified four basic alarm 
 levels ( very low , low , medium , high ) , but the model can be easily extended to 
 include further levels .
for instance , 
 monitoring environmental parameters ( such as temperature and relative humidity ) 
 are needed in order 
 to maintain a healthy environment and detect alarm situations .
alarm triggering 
 based on environment parameters is analogous to the one based on biomedical 
 parameters , described above .
the social context ontology represents 
 care network resources ( health teams , social community members , etc . ) and their 
 relations .
care network members that are represented as concepts in this 
 ontology include the patient , patient relatives , who take active part in 
 implementing the assistance plan , health operators ( medical and paramedical 
 staff ) who are in charge of patient care ; social community organizations which 
 offer assistance services ( e.g. , transport and companion services ) . the social 
 context ontology is also used to represent other information which is 
 considered relevant to the ermhan application purposes , such as the 
 availability of a health operator for an intervention and the distance of a 
 relative from patient location ( travel time ) . at present
, users can provide 
 this information via a web form provided by the profile management services , by 
 choosing among predefined values ( e.g. ,  available , 
 busy ,   not available  ) . 
 as part of future work , we will investigate the use of context - aware systems 
 that can help in semi - automatically updating and managing such information ( e.g. , 
 gps positioning and inference mechanisms ) .
the alarm management ontology represents 
 the policy that should be instantiated to manage an alarm .
such policy 
 describes the steps that should be performed in the event of an incoming alarm . 

rule - based reasoning over this ontology model is used to select the suitable 
 alarm handling policy according to different context items , such as the 
 incoming alarm level , the patient identifier , and the availability of care team 
 members ( i.e. , the information represented by the social context ontology ) . as 
 mentioned above
, the ermhan system uses rule - based reasoning over the context 
 ontology instances for triggering alarms and defining policies for handling alarms .
alarm 
 triggering is based on the analysis of context data represented in the patient 
 and home - domain ontologies . 

we have defined a set of first - order rules so as to determine if an alarm has 
 to be triggered and which level should be activated according to measured 
 context data and corresponding thresholds .
high  when the heart rate frequency is less 
 than 40 beat / minute and the systolic blood pressure is higher than 160 mm / hg : if 
 ( heartratefrequency<40 and    systolicbloodpressure>160 ) the   healthstatus 
 has alarmlevel  high .
 likewise , 
 when an alarm has been triggered , rule - based reasoning is used to determine 
 which alert policy should be actuated for handling the alarm situation . in 
 ermhan , an alert policy is represented as a set of instructions specifying whom 
 should be alerted and how ( via sms , mail , phone call ) and if acknowledgment is 
 required . in table 1 , we define a basic example policy for each alarm level . for 
 instance , we suppose that when a  medium  level alarm is detected , the system 
 should perform the following actions ( see table 1 ) . 
 alerting 
 an operator via sms or email . first , a general practitioner is alerted .
if 
 he / she does not send the acknowledgment within a fixed - time interval , other operators ( e.g. , 
 nurses ) are alerted until one of them sends an acknowledgment . at the end , if 
 no acknowledgment is received , the system alerts an emergency operator , 
 available 24/24 and 7/7 .
the list of operators to be contacted is dynamically 
 created by the system by selecting the caregivers which are assigned to that 
 patient and are 
available  for intervention.at the same time at least 
 one of family members should be alerted , but acknowledge is not required . 
  alerting 
 an operator via sms or email .
if 
 he / she does not send the acknowledgment within a fixed - time interval , other operators ( e.g. , 
 nurses ) are alerted until one of them sends an acknowledgment . at the end , if 
 no acknowledgment is received , the system alerts an emergency operator , 
 available 24/24 and 7/7 .
the list of operators to be contacted is dynamically 
 created by the system by selecting the caregivers which are assigned to that 
 patient and are 
at least 
 one of family members should be alerted , but acknowledge is not required .
adaptation 
 of system behavior on a per - patient 
 basis can thus be achieved by care providers by specifying personalized alarm 
 levels , parameter thresholds , and alert policies tuned to the individual 's 
 conditions .
the 
 ermhan system architecture , shown in figure 2 , is made of the following main 
 components . the multichannel health - care service manager ( mhsm ) .
this component delivers mobile 
 health - care context - aware services to patients , relatives , and care providers , 
 targeting a variety of user devices .
it is deployed in the care centre domain 
 and includes a front - end component deployed in the patient - home domain . the context management system . 

this component deals with the acquisition of context data from heterogeneous 
 sources , the management , and storage of ontology - based context instances , 
 reasoning over context knowledge , and the delivery of relevant contextual 
 knowledge to context - aware applications ( e.g. , mhsm ) .
mhsm and context management systems have 
 been designed as completely separate and independent modules .
this has been 
 done in order to strongly decouple context data acquisition , management , and 
 context - aware service delivery .
the 
 multichannel health - care service manager ( mhsm ) is the ermhan component that 
 provides mobile context - aware health - care services to end - users .  
mhsm 
 provides end - users with proper services according to their roles and related 
 requirements .  
thus , end - user roles which have been taken into account are 
 medical , paramedical , and the emergency centre staff .
nonetheless , we have also 
 considered some basic requirements for patients and patients ' relatives .
each member can access ermhan services 
 remotely , via a desktop pc or a pda .
medical staff members can access and update the patient 
 record using a personal digital assistant ( pda ) or desktop pc .
information 
 sharing among care professionals is achieved by providing them with the 
 capability of accessing a uniform view of patient information .
permission for 
 reading and modifying patient record fields is tailored according to the user 's 
 role ( e.g. , general practitioner , specialists , etc.)()alerts management service .
when an alarm is triggered ( manually by the patient or 
 automatically by the context management system ) , the alerts management service contacts 
 the staff through the appropriate channels ( e.g. , mail and/or sms ) . as 
 specified by the alert policy , alerts can be sent as informative messages or as 
 intervention requests , depending on the alarm gravity level . in the latter 
 case ,
the caregiver is asked to acknowledge the alert reception and to confirm 
 the intervention request .
more details about the alert policy are provided in 
 the next subsection.()profile management service .
the medical staff members can specify their own 
 availability for the intervention ( e.g. , available , not available , busy ) .
this 
 information is taken into account by the rule - based reasoning process used to 
 select the operators which should be contacted in the alert policy . 
 
each member can access ermhan services 
 remotely , via a desktop pc or a pda .
medical staff members can access and update the patient 
 record using a personal digital assistant ( pda ) or desktop pc .
information 
 sharing among care professionals is achieved by providing them with the 
 capability of accessing a uniform view of patient information .
permission for 
 reading and modifying patient record fields is tailored according to the user 's 
 role ( e.g. , general practitioner , specialists , etc.)()alerts management service .
when an alarm is triggered ( manually by the patient or 
 automatically by the context management system ) , the alerts management service contacts 
 the staff through the appropriate channels ( e.g. , mail and/or sms ) .
as 
 specified by the alert policy , alerts can be sent as informative messages or as 
 intervention requests , depending on the alarm gravity level . in the latter 
 case ,
the caregiver is asked to acknowledge the alert reception and to confirm 
 the intervention request .
more details about the alert policy are provided in 
 the next subsection.()profile management service .
the medical staff members can specify their own 
 availability for the intervention ( e.g. , available , not available , busy ) .
this 
 information is taken into account by the rule - based reasoning process used to 
 select the operators which should be contacted in the alert policy . 
 
medical staff members can access and update the patient 
 record using a personal digital assistant ( pda ) or desktop pc .
information 
 sharing among care professionals is achieved by providing them with the 
 capability of accessing a uniform view of patient information .
permission for 
 reading and modifying patient record fields is tailored according to the user 's 
 role ( e.g. , general practitioner , specialists , etc .
) alerts management service . when an alarm is triggered ( manually by the patient or 
 automatically by the context management system ) , the alerts management service contacts 
 the staff through the appropriate channels ( e.g. , mail and/or sms ) .
as 
 specified by the alert policy , alerts can be sent as informative messages or as 
 intervention requests , depending on the alarm gravity level . in the latter 
 case ,
the caregiver is asked to acknowledge the alert reception and to confirm 
 the intervention request .
more details about the alert policy are provided in 
 the next subsection . profile management service .
the medical staff members can specify their own 
 availability for the intervention ( e.g. , available , not available , busy ) .
this 
 information is taken into account by the rule - based reasoning process used to 
 select the operators which should be contacted in the alert policy .
paramedical staffthe paramedical staff ( e.g. , general 
 assistance operators , nurses , etc . ) can access the system remotely , by means of 
 a pc or a pda .
similarly to the medical staff , but with different role - based 
 access rights , they can access the following services : patient record 
 management , alerts management services , and profile management services . the paramedical staff ( e.g. , general 
 assistance operators , nurses , etc . ) can access the system remotely , by means of 
 a pc or a pda .
similarly to the medical staff , but with different role - based 
 access rights , they can access the following services : patient record 
 management , alerts management services , and profile management services . emergency staffthe emergency staff is composed of  always 
 available  operators .
they are notified by the alerts management service in 
 order to respond to emergency situations ( highest critical alarm level ) or when 
 other health operators have not responded to lower level alarms ( e.g. , medical 
 staff ) .
they are notified by the alerts management service in 
 order to respond to emergency situations ( highest critical alarm level ) or when 
 other health operators have not responded to lower level alarms ( e.g. , medical 
 staff ) .
patientwe considered the following patient requirements for 
 eliciting a basic set of services : the capability of easily communicating with 
 relatives or health operators , manually activating alarms , and having support for 
 implementing the health assistance plan .
requirements depending on specific 
 patient conditions ( e.g. , physical impairments , cognitive disabilities , etc . ) 
 have not been considered in this study .
the patient is equipped at home with a 
 tablet pc and uses services through a front - end available on the tablet pc 
 touch screen .
more specifically , services which are available to patients at 
 home include the following . 

( )reminders service : the system alerts the patient that medication has to be taken . the alert 
 signal is an audio and video alarm which is remotely triggered on the front - end 
 deployed at patient home.()help requests : the patient can manually generate an alarm , in order to request an 
 urgent intervention by the emergency staff.()communication 
 requests : the patient can request to be contacted by some relatives . 
 
we considered the following patient requirements for 
 eliciting a basic set of services : the capability of easily communicating with 
 relatives or health operators , manually activating alarms , and having support for 
 implementing the health assistance plan .
requirements depending on specific 
 patient conditions ( e.g. , physical impairments , cognitive disabilities , etc . ) 
 have not been considered in this study .
the patient is equipped at home with a 
 tablet pc and uses services through a front - end available on the tablet pc 
 touch screen .
more specifically , services which are available to patients at 
 home include the following . 

( )reminders service : the system alerts the patient that medication has to be taken . the alert 
 signal is an audio and video alarm which is remotely triggered on the front - end 
 deployed at patient home.()help requests : the patient can manually generate an alarm , in order to request an 
 urgent intervention by the emergency staff.()communication 
 requests : the patient can request to be contacted by some relatives . 
 
reminders service : the system alerts the patient that medication has to be taken . the alert 
 signal is an audio and video alarm which is remotely triggered on the front - end 
 deployed at patient home .
help requests : the patient can manually generate an alarm , in order to request an 
 urgent intervention by the emergency staff . communication 
 requests : the patient can request to be contacted by some relatives .
patient 
 relativesthe patient 's 
 family members provide general assistance to the patient during daily routine 
 activities at home and should be kept informed about patient conditions when 
 outside the home ( via the alert management service and profile management 
 service ) .
services targeting relatives can be accessed via mobile devices with 
 minimal technical requirements ( i.e. , cell phones with an xhtml browser ) .
the patient 's 
 family members provide general assistance to the patient during daily routine 
 activities at home and should be kept informed about patient conditions when 
 outside the home ( via the alert management service and profile management 
 service ) .  
services targeting relatives can be accessed via mobile devices with 
 minimal technical requirements ( i.e. , cell phones with an xhtml browser ) .
multichannel health - care service manager implementationthe 
 mhsm has been designed and developed as a multichannel web application written 
 in java language , leveraging the j2ee jsp / servlet technology framework .
the 
 mhsm has been developed as a 3-tier architecture including the following.(1 ) 
 a 
 back - end tier , named mhsm information management and storage , handles and 
 stores the following information resources : the patient record , containing 
 patient personal data , personal assistance plan , vital sign thresholds , 
 medical , sanitary and assistance diaries , and prescriptions ( e.g. , taking medication , 
 vital sign measurement scheduling ) ; user profiles , containing end - user personal data , 
 organizational roles , caregiver availability status ( for medical and 
 paramedical staff and patient relatives ) ; organization models , representing the 
 care network structure , ( i.e. , care network members and patients under care).(2 ) 
 an 
 intermediate tier hosts 
 the business logic of the ermhan services ( patient record management , alerts 
 management , profile management , reminder management , patient help , and 
 communications request management).(3 ) 
 an 
 upper tier , composed of a multichannel front - end generation service , generates 
 user interfaces tailored to the capabilities of the different end - user mobile 
 devices ( e.g. , display size , resolution , memory and processing capabilities , 
 etc . ) .
the target devices for this scenario are pdas , tablet pcs , cell - phones , 
 and laptops .
the model view controller design paradigm   has been 
 adopted in order to properly manage user interface generation , business and 
 navigation logic , and content generation.the 
 platform uses the web services technology standards ( soap , wsdl ) to interact 
 with external components , such as the context management system .
a communication management service implements an sms gateway and 
 the smtp protocol in order to provide sms and e - mail alerts to care network 
 members ( the adoption of further communication channels and protocols will be 
 evaluated in the future ) .
this component has been designed and developed by the 
 industrial partner of the kamer project ( hp italy ) .
the 
 mhsm has been designed and developed as a multichannel web application written 
 in java language , leveraging the j2ee jsp / servlet technology framework .
( 1 ) 
 a 
 back - end tier , named mhsm information management and storage , handles and 
 stores the following information resources : the patient record , containing 
 patient personal data , personal assistance plan , vital sign thresholds , 
 medical , sanitary and assistance diaries , and prescriptions ( e.g. , taking medication , 
 vital sign measurement scheduling ) ; user profiles , containing end - user personal data , 
 organizational roles , caregiver availability status ( for medical and 
 paramedical staff and patient relatives ) ; organization models , representing the 
 care network structure , ( i.e. , care network members and patients under care ) . ( 2 ) 

an 
 intermediate tier hosts 
 the business logic of the ermhan services ( patient record management , alerts 
 management , profile management , reminder management , patient help , and 
 communications request management ) .
( 3 ) 
 an 
 upper tier , composed of a multichannel front - end generation service , generates 
 user interfaces tailored to the capabilities of the different end - user mobile 
 devices ( e.g. , display size , resolution , memory and processing capabilities , 
 etc . ) .
the target devices for this scenario are pdas , tablet pcs , cell - phones , 
 and laptops .
the model view controller design paradigm   has been 
 adopted in order to properly manage user interface generation , business and 
 navigation logic , and content generation .
the 
 platform uses the web services technology standards ( soap , wsdl ) to interact 
 with external components , such as the context management system .
a communication management service implements an sms gateway and 
 the smtp protocol in order to provide sms and e - mail alerts to care network 
 members ( the adoption of further communication channels and protocols will be 
 evaluated in the future ) .
this component has been designed and developed by the 
 industrial partner of the kamer project ( hp italy ) .
this 
 section describes the context management ( cm ) system architecture that we have 
 developed to ease the implementation of context - aware assistance services for 
 chronic patients .
the 
 cm system is based on a general - purpose framework providing basic features for 
 context data acquisition , reasoning , and delivery .
it is composed 
 of two different node types . 
 the patient context manager ( patientcm ) .
these data are preprocessed by the patientcm in order to detect abnormal 
 conditions and are transmitted to the mhsm in order to update patient records 
 with new measurement values .
sensed data are injected into the patient and home - domain 
 ontology instances and rule - based reasoning processes are performed over this 
 context base in order to detect incoming emergency situations and trigger 
 corresponding alarms . the central context manager
is then notified of the 
 occurrence of an alarm.the central context manager 
 ( centralcm ) .
this component is deployed in the care centre domain . when an 
 alarm situation has been detected by a patientcm ,
the centralcm processes 
 context information about patient health status and care team member 
 availability , in order to define an alert policy for informing care team members 
 and request their intervention in case of emergency .
it handles the alarm 
 management and social context ontologies by creating related instances updated 
 with context information about patient health status , triggered alarm levels 
 and information about care team member availability . based on this context 
 information , reasoning rules are applied in order to define the proper alert 
 policy for alarm handling . the resulting alert policy
these data are preprocessed by the patientcm in order to detect abnormal 
 conditions and are transmitted to the mhsm in order to update patient records 
 with new measurement values .
sensed data are injected into the patient and home - domain 
 ontology instances and rule - based reasoning processes are performed over this 
 context base in order to detect incoming emergency situations and trigger 
 corresponding alarms . the central context manager
is then notified of the 
 occurrence of an alarm . the central context manager 
 ( centralcm ) .
when an 
 alarm situation has been detected by a patientcm , the centralcm processes 
 context information about patient health status and care team member 
 availability , in order to define an alert policy for informing care team members 
 and request their intervention in case of emergency .
it handles the alarm 
 management and social context ontologies by creating related instances updated 
 with context information about patient health status , triggered alarm levels 
 and information about care team member availability .
based on this context 
 information , reasoning rules are applied in order to define the proper alert 
 policy for alarm handling . the resulting alert policy
context data acquisition : this component receives context data from context providers 
 via soap messages ( e.g. , web service - enabled sensor networks ) , or via sensor 
 adapters .
context 
 knowledge base : this is a knowledge base composed of ontology - based context 
 models and instances stored in a database , a rule - based reasoner and rule 
 files .
context broker : this component distributes context data to external components by 
 notifying the interested applications when the context has changed or by 
 providing updated information in a request / response chain . both notification 
 and request / response paradigms are implemented through a soap message exchange 
 . in each context manager , the 
 communication between internal components has been implemented according to the 
 observer design pattern , that is , through suitable eventlisteners that listen 
 for events and encapsulate the information to be processed .
therefore , 
 such decomposition allows each internal component to process its own specific 
 information independently .
the centralcm and patientcm have been 
 implemented as j2ee web applications and their external interfaces are exposed 
 as web services .
this 
 paragraph provides further insight into the context management system architecture 
 ( see figure 3 ) by describing the system behavior in an alarm detection and 
 management scenario .
figure 4 provides a simplified graphical representation of 
 this scenario as a sequence of numbered steps .
general 
 practitioners and nurses can access and modify patient health information through 
 the mhsm interface ( step 1 ) .
in particular , general practitioners can update 
 remote monitoring parameters , such as scheduling sensed data acquisition and 
 related alarm thresholds .
for instance , a practitioner can specify that the 
 body temperature should be measured at 7 am and 5 pm every day , that a measured 
 value higher than 38c should trigger a medium - level alarm if reached at 7 am , and a high - level alarm 
 if reached at 5 pm .
the mhsm sends this information to the centralcm which 
 routes the message to the proper patientcm ( step 2 ) .
the centralcm.patientservicemanager component offers a web service interface which can be invoked by the mhsm in 
 order to communicate messages such as updates of patient diagnostic test 
 scheduling and vital sign alarm thresholds .
the centralcm manages a message 
 queue for each patientcm and messages that come from the mhsm are then routed 
 to the proper message queue .
this 
 periodical polling is also used to monitor the status of both the patientcm 
 operation and the connection between the patientcm and the centralcm . when the 
 centralcm does not receive the expected periodical poll by a patientcm ( this 
 condition may be caused by connection failures or patientcm malfunctions )
, it 
 triggers a corresponding alarm and the emergency staff is alerted to handle 
 this technical problem by activating the required procedures .
the patientcm.centralcmclient parses the message payload and produces 
 suitable events , such as timingevents for scheduling biomedical data 
 acquisition .
new 
 timing events are consumed by the patientcm.dataacquisitionscheduler . 
 according to the prescriptions contained in the timingevents objects , the 
 scheduler allocates corresponding timers triggering the patient 's biomedical 
 data acquisition ( e.g. , body temperature , heart rate frequency ) from web 
 service - enabled body sensor networks ( step 3 ) .
the patientcm.datacollector exposes a web 
 service interface which is invoked by the sensor networks to communicate new 
 acquired vital sign values .
these data are then passed on to the datadispatcher , 
 that notifies the mhsm of these data for patient record updating ( step 4 ) and 
 the ontomanager module for updating the patient and home environment ontologies 
 instances .  
rule based reasoning is then 
 applied to the knowledge base in order to detect possible alarms and produce 
 alarmevents .
for instance , if the sensed body temperature is higher than 38c a medium - level alarm is triggered .
the patientcm.alarmnotifier notifies a new alarmevent to the centralcm , by invoking the centralcm.alarmmanager component ( step 5 ) .
the centralcm.alarmmanager receives new 
 incoming alarms notified by the patientcm and routes them to the centralcm.ontomanager which has to create an alert policy 
 for alarm handling .
firstly , it feeds the knowledge base ( composed of the alarm 
 management and social context ontologies ) with instance data , such as 
 attributes of the alarmevent ( patient identifier and alarm level ) and updated 
 information about the patient social context ( health operators availability ) 
 which are made available by the mhsm .
the centralcm.policynotifier is the 
 component which sends the alert policy to the mhsm , by invoking a specific web 
 service ( step 6 ) .
the mhsm then implements the policy 
 by sending proper alerts to the contact lists ( step 7 ) .
filtering 
 techniques are implemented by the centralcm.alarmmanager to handle 
 sequences of alerts related to the same emergency situation . as a matter of 
 fact , while an alarm is being handled , notification related to the same 
 situation can be generated again by the patientcm ( e.g. , because of new vital 
 sign measurements ) .
the filtering technique is thus applied to avoid 
 overwhelming health operators with redundant alerts .
this 
 section discusses the ermhan system results in terms of performance evaluation 
 and user testing activities .
the 
 following considerations are concerned with a performance estimation of the 
 ermhan context management system obtained by collecting average alarm 
 generation and transmission times in a basic configuration .
the server hosting the centralcm has an external ip 
 and accesses the internet through the university wide area network .
the 
 patientcm can access the internet through a standard low - band with dsl 
 connection ( 640 kbps ) .
more precisely , the pc hosting the patientcm has a 
 wireless connection to an 802.11 g dsl gateway .
patientcm : 
 amd athlon64 3200 + , 1024 mb ram.centralcm : 
 intel pentium 4 2.0 ghz , 768 mb ram . 
 
the 
 performance measurement is based on the following parameters : the alarm detection time ( talarm ) which is the time 
 interval between   the acquisition of an out - of - range biomedical parameter value 
 and the triggering of   the corresponding alarm obtained by means of rule - based 
 reasoning   ( section 3.1.2 ) ; the transmission 
 delay ( ttransm ) which is   the time needed for transmitting 
 a message through the connection between patientcm and centralcm ; the alert 
 policy time ( tpolicy ) , which is the time elapsing 
 at the centralcm side between the reception of an incoming alarm originating from 
 the patientcm and the generation of the corresponding alert policy .
the sum of 
 these time intervals determines the overall time needed for the alert policy 
 generation from time the out - of - range biomedical parameter is acquired ( tmanagement ) : 

 ( 1)tmanagement  =  talarm  +  ttransm  +  tpolicy . 
 
the 
 value of   tmanagement does not vary significantly with respect to 
 alarm levels .
nonetheless , alarm levels influence the kind of alert policy 
 generated by the centralcm and implemented by the mhsm .
an evaluation including 
 also policy implementation and the notification to at least one care provider 
 should also take into account the following time intervals ( see figure 5 ) : the 
 time needed for transmitting the alert policy from the centralcm to the mhsm ( ttransm2 ) ; the time needed by the mhsm for 
 instantiating the alert policy ( tmhsm ) ; the sms latency ( tsms ) which is the delay for transmitting 
 smss to health operators ; the delay for transmitting alert to the care centre 
 in order to notify emergency operators ( tem ) .
the 
 formula for calculating the global time interval ( tglobal ) from the alarm detection to the alert 
 notification to care providers differs according to the alarm level and 
 corresponding alert policy . for 
 very - low- 
 and
low - level alarms , the following formula is applied : 
 ( 2)tglobal  =  tmanagement  +  ttransm2  +  tmhsm  +  tsms . 
  for 
 medium - level alarms , the calculation has to take into account the fact that 
 health operators ( general practitioners and nurses ) are notified in sequence : a 
 first operator is alerted via sms , if he / she does not respond within a 
 specified time interval ( ttimeout ) , 
 another operator is notified . after n failed attempts (
n is 
 specified in the alert policy ) , the alarm is communicated to an emergency 
 operator ( tem ) . if 
 a care provider confirms the sms reception after n attempts ( n  n ) , 
 ( 3)tglobal=  tmanagement  +  ttransm2  +  tmhsm  +  n(tsms  +  ttimeout ) 
 otherwise 
 ( 4)tglobal=  tmanagement  +  ttransm2  +  tmhsm  +  n(tsms  +  ttimeout )  +  tem . 
  for 
 high - level alarms 

the following formula is 
 applied : 
 ( 5)tglobal  =  tmanagement  +  ttransm2  +  tmhsm  +  tem . 
  as mentioned above
, this paragraph focuses on 
 performance estimation of the context management system in delivering the most 
 critical service ( alarm detection and handling ) .
thus , our evaluation is based 
 on measured values of talarm , 
 ttransm , and tpolicy .
values of further parameters ( ttransm2 tmhsm , tsms and tem )   are not available for dissemination as they have been collected by the 
 industrial partner ( hp italy ) .
moreover , values of tsms and tem   are dependent on the characteristics of the network infrastructure . in a real 
 implementation scenario , these parameters might be optimized according to 
 appropriate technological choices , such as using public or professional radio - mobile 
 networks for sms delivery ( i.e. , gsm and tetra , resp . ) and a dedicated fixed line 
 for communicating with the emergency operators , as well as establishing proper service 
 level agreements with network operators . to 

estimate the performance of the implemented system in detecting and managing 
 alarms , we have simulated the generation of 60 sample alarms for each of the 
 four alarm levels (  very low ,   low ,   medium ,  and  high  ) .
such samples have 
 been acquired by monitoring the activity of the context management system upon 
 an interval of five working days , during working hours , in order to stress the 
 system during worst traffic conditions ( i.e. , peak traffic hours ) . in more 
 detail , experiments were performed during two time slots : 10:00 a.m.2:00 p.m. ( time 
 slot 1 ) and 2:00 p.m.6:00 p.m. ( time 
 slot 2 ) . 

table 2 reports the mean and standard deviation values in 
 milliseconds of alarm detection time ( talarm ) , alert policy time ( tpolicy ) , and the overall alarm management 
 time ( tmanagement ) , 
 which is calculated as the sum of talarm , tpolicy , and the transmission 
 delay ( ttransm ) .
measured 
 values of talarm as well 
 as tpolicy do not vary 
 significantly across alarm level .
tpolicy measured values are higher than talarm ones as the major part of the processing load is leaning to the patientcm side , 
 according to the architecture of the context managers . measured values of the overall tmanagement vary significantly according to network 
 traffic conditions which directly influence ttransm values . in this experiment , we can estimate an 
 overall alarm time swinging between 8 and 10 seconds , with a transmission delay 
 that can be evaluated in about 5 seconds .
the higher values of the standard 
 deviation for alarm times can be charged on interferences in the patientcm 
 wireless connection and on the network conditions in the restricted observation 
 window ( five working days ) considered for this evaluation .
we 
 expect that a more performant connection would significantly improve the alarm 
 management time , and a wider observation interval ( i.e. , one month ) would 
 produce more uniform statistics for this indicator . in 
 order to minimize reasoning tasks execution time ( inference on ontology 
 instances ) , we perform reasoning on small ontologies populated by a small 
 number of instances , since ontological reasoning execution times grow at least 
 linearly with respect to the ontology size .
this time 
 could be further optimized by performing part of the reasoning task before the 
 service request .
future research activities will thus focus on analyzing which 
 reasoning tasks could be performed prior to service requests and consequently 
 on reengineering the patientcm and centralcm . as 
 ermhan services have been designed to support care networks and thus to address 
 requirements of care providers ,
testing is primarily to be focused on 
 evaluating health operators ' acceptance of implemented features .
a 
 trial has been performed in a nursing home in piacenza 
  for system evaluation by 
 professional caregivers .
further trials are planned in a nursing home in florence 
  in the near 
 future , for more extensive evaluations by chronic condition patients . for these 
 future tests , a sensing system for vital signs and environmental monitoring 

testing activities will thus focus also on evaluating patient 
 acceptance with regard to deployed services ( i.e. , monitoring , medicine 
 reminder , help , and communication request services ) . in 
 the testing stage already conducted in piacenza , 
 biomedical and environmental sensing was simulated by a web application . 

biomedical parameters that were represented in the model included heart rate 
 frequency , pulse oxymetry , systolic and diastolic blood pressure , body 
 temperature , and glycemia .
the web application provides services for manual 
 input or predefined scenario simulation for context data acquisition . during 
 each session
the 
 project staff took care of simulating the acquisition of biomedical and 
 environmental parameter values and the occurrence of alarms through the 
 dedicated web interface ; health operators were asked to react to such events by 
 using the ermhan system as they were in the  real world ,  such as ignoring 
 alerts or confirming the intervention request reception and taking charge of 
 the case .
practitioners were also asked to perform day - by - day operations through the system , 
 such as accessing and updating patient records , modifying the scheduling of 
 biomedical parameters acquisition and related alarm thresholds . at the end of 
 these trials , the testers ' opinions about system features have been collected 
 through interviews and questionnaires .
this 
 first trial session was conducted with 11 test users ( including both general 
 practitioners and nurses ) . as a consequence , we are far from having 
 statistically significant data available , but we are able to illustrate some 
 preliminary results which can be drawn from questionnaire responses .
a large 
 majority of users were quite satisfied by the system 's overall features ( more 
 than 60% ) .
the capability of accessing patient health records has been judged 
 useful and easy to use ( but some users had already tested similar features in 
 other experimental systems ) .
the alarm management service and the capability of 
 specifying availability for intervention were judged especially useful ( 42% of 
 users ) and useful ( 50% of users ) .
most users appreciated the capability of 
 remotely modifying the alarm thresholds and data acquisition scheduling on a 
 per - patient basis ( 18% expressed high appreciation , 73% good appreciation , 9% 
 were neutral ) .
a group of users ( 30% ) complained about some misalignment 
 between mhsm patient record presentation and paper - based records in use in 
 their nursing home ( especially in terms of use , information organization and 
 classification ) .
this aspect will be further investigated in future testing 
 activities and properly analyzed when defining a methodology for customized 
 deployment if ermhan is applied industrially .
in 
 this paper , we have presented ermhan , a context - aware mobile service platform 
 supporting mobile caregivers in their daily activities .
ermhan has demonstrated 
 its capability of providing an extensible set of services aiming at supporting 
 care networks in cooperating and sharing information for the goal of improving a 
 chronic patient 's quality of life .
ermhan 
 has been designed as a modular system , and its components have been implemented 
 by adopting standard technologies ( e.g. , internet protocols , xml , web services ) . 
 this approach makes the system easily extensible to match specific patient 
 requirements within an ambient intelligence environment .
future work will concentrate on 
 security and dependability issues as well as on extending the features provided 
 by the service platform . in the home domain , this will mainly consist in 
 deploying body and home sensor networks , and integrating input / output devices 
 for patients ( e.g. , alarm button and tv displays ) . as for the care centre 
 domain , the main developments will include designing graphical user interfaces 
 for system configuration and customization ( e.g. , customization of predefined 
 alarm management policies and patient case sheets for health centers providing 
 specialized services ) ; adopting existing standards ( e.g. , hl7 ) for assuring 
 interoperability with hospital back - end systems .
leveraging 
 on the ermhan modular design , future work will also deal in analyzing and 
 integrating existing user interfaces and applications designed according to hci 
 ( human computer interaction ) principles , especially interfaces designed for 
 people with cognitive   and physical 
 impairments .
such 
 advancements , together with more extensive testing activities , including 
 patients ' evaluation of system features , are needed for a final assessment of 
 the proposed platform .
 continuous care models for chronic diseases pose several technology - oriented challenges for home - based continuous care , where assistance services rely on a close collaboration among different stakeholders such as health operators , patient relatives , and social community members . here 
 we describe emilia romagna mobile health assistance network ( ermhan ) a multichannel context - aware service platform designed to support care networks in cooperating and sharing information with the goal of improving patient quality of life . in order to meet extensibility and flexibility requirements , 
 this platform has been developed through ontology - based context - aware computing and a service oriented approach . 
 we also provide some preliminary results of performance analysis and user survey activity . 
1. INTRODUCTION
2. RELATED WORK
3. CONTEXT-AWARE MODELING AND REASONING
FOR HOME-BASED CARE
4. ERMHAN SYSTEM ARCHITECTURE
5. SYSTEM EVALUATION AND TESTING ACTIVITIES
6. CONCLUSIONS