Nowadays, employment of new information and com-munication technology (ICT) based services has been established as a relevant means to support daily living and personalized health (PHealth) for different segments of young population, elderly or people with disabilities. Analyzing methodological approaches can sometimes be considered less relevant compared to the description of the technical components. Indeed, most of the innova-tions in this domain fail to be successfully deployed not due to the immaturity of technological components or a non user centered design, but above all for the several weakness and criticisms in the deployment process. Therefore, this paper address one of the most strategic and skill demanding areas in the PHealth and ambient assisted living (AAL) domain, and also the strategic role of early involvement of clinicians, end user, service pro-viders, stakeholders and business decision makers.

When speaking about deployment process it is impor-tant to clarify whether it is related to the deployment of a standardized and certified solution or it is related to thetrial of a clinical pilot or research project. Currently most of the deployment activities in this domain are not related to a stable long term services set up. On the other hand, most of them are related to the deployment of serv-ices in order to test PHealth or AAL prototypes or to con-duct clinical and social studies to estimate the impact of these services. With such a context, very often custom solutions according to dedicated specifications should be developed and deployed. This paper will deal with the methodology that is related to deploy this second type of solutions. In order to properly assess the successful deployment of a PHealth service and its specific impact, it is crucial to verify if it properly empowers the service related use case scenario and its business model. There-fore, it is mandatory to set in advance a clear description of the above contexts.

The start up of a new service is based on PHealth and AAL solutions representthe challenges for the various stakeholders such as caregivers, healthcare service pro-viders, engineers. The issue is not just related to having proper tested software and hardware that fulfils users’ requirements, but it is also mainly a matter of change management that is related to service organization and business process. With such a context it is really impor-tant for the clinicians, caregivers and social workers are committed and involved to the service trial. The roll out of PHealth services requires not only the adoption of new procedures but also new interactions modalities among the involved stakeholders. Such interactions can be described through a proper use case scenario where, it is possible to define the hardware and software components that are to be installed and the roles of each stakeholder. By adopting a design process such as unified process (UP) surely can help during analysis, design and develop phases but it lacks in details in the deployment phase [1].

As a matter of fact, the deployment and environment workflows of the UP contain less detail when compared to other workflows. For the deployment of a PHealth and AAL services it is fundamental to be able to design, track and monitor issues such as: proper involvement of stake-holders in the service workflow design, the functional and technical specifications for each system component, the contractual terms towards supplier and customers, data storage features, regulation aspects, system integration strategy, system installation and upgrade procedures, ser-vice levels of technical assistance, the clinical and quality of life indicators, training path for the stakeholders and users. As a result these aspects should be covered and predicted by a solid procedure during domain analysis phase and then, applied during the deployment phase.

In this context several issues are correlated but it is important to stress the difference between the impact assessment for the PHealth services and for the deploy-ment phase itself. For the first one, according to the use case scenario and related business model it is possible to set impact indicators, such as those that are derived by structured analytic cost benefit and cost efficiency analy-sis. On the other hand, for the deployment phase assess-ment it is possible to define success target values that are related to indicators such as those mentioned above or the number of iterations required and the transition time for service start-up.

The present paper describes the work performed by the authors in definition and implementation of a dedicated methodology to support the deployment of different PHealth and AAL services. Based on the experience and outcome collected in the deployment of services in differ-ent European countries, this paper focuses on the discus-sion about the application of a methodology that is tailored on the UP processes. In order to facilitate the understanding about the criticism that is encountered in their implementation, this section introduces briefly a real case of study that is applied in North and South Ireland.

Netwell project platform provides 30 patients, in con-junction with a specific care model in North and South Ireland along with the PHealth and AAL service solu-tions that ranges from Home automation, Telecare and PHealth services. The platform deployed in such a con-text is the DGHome^TM platform which is able to perform acquisition, storage, report generation and dispatch of different levels of aggregated information. At a patient’s home the Pc@Home^TM system collects the data from a set of devices that are deployed into the user’s environment. It processes and forwards them towards the DGHome^TM server. These services are based on a monitoring system that is spread on three levels and it integrates different devices for monitoring electrocardiogram, blood pressure, glucose levels, weight, movement activity, entrances con-trols, smoke and flood alarm. All these devices are inte-grated by means of a universal hub, Pc@Home^TM powered by I+ that is capable of data exchange between the DGHome^TM service centre and the patient’s house. Such a service collects and provides warning about the user’s unexpected behaviours or about the healthcare metrics. The warnings can be forwarded through the DGHome^TM service manager platform to the user, relatives or to a care-giver team, according to the patient profile and set-ting. As result, the service platform enables a service for a push/pull request of intervention by the proper profile.

Netwell platform provides a user friendly and seamless solution that is composed of several components: moni-toring devices made by different manufacturers and it communicates through different protocols with the uni-versal hub Pc@Home^TM, installed into the user environ-ment. Each Pc@Home^TM is connected to the DGHome^TM platform as a server side layer. It is able to integrate several service levels and authorization profiles. The DGHome^TM platform operates the reasoning and context aware mod-ule which is able to produce specific reports and generate timely warnings. In order to achieve a proper and suc-cessful deployment and due to the complexity of real sce-nario of social and healthcare service organizations. Such a technological platform requires a proper deployment strategy and procedure based on a specific deployment workflow and a set of quality procedures and checkpoints.

As a matter of fact, a monitoring service can embrace different kinds of actors (i.e., general practitioner [GP], medical specialist, nurse) and according to our methodol-ogy, all of them need to get involved in the service sce-nario description, acceptance test and proper long term trials. It is worthwhile to point out that the acceptance of a PHealth platform per se does not imply that the overall service organization is in place. Therefore, we strongly recommend performing acceptance test in real service setting testing daily operational conditions.

Quite often a single acceptance test is insufficient to verify major functionalities, bug fixing list and the requests for improvement are usually reuest across sev-eral test iterations. In some cases, for the proper deploy-ment of research related PHealth services it is important to foresee and establish a “beta testing phase” for a deeper and prolonged test of the overall service platform. The complexity that is related to the beta test has been raised during the Netwell, in particular it has been detected that the user requested some minor changes. They were irrele-vant from the technical prospective but very important for the user’s acceptance. Such a level of issues are very often related to a not clear definition of the service level provided by the platform and not well defined roles of stakeholders involved.

The experience and the methods that are applied by the authors for PHealth systems development and deploy-ment have been structured in a specific procedure in order to control critical deployment phases. A part of these pro-cedures has been implemented also in the controls com-ponents of the DGHome^TM and PC@Home^TM.

The chosen methodology to achieve such a goal is the UP framework. UP is an iterative development process [2]. This is intended to be tailored by the development teams in order to select those elements that best fit the specifica-tion and requirements. UP can help in the process of not only implementing an object oriented analysis, design and programming technology but also for the modelling business process [3].

In this paper the deployment process workflow is pre-sented in relation to some of the major problems that were encountered in the deployment phases. In particular, the case study that is presented discusses on the rationale of a process that is capable of scheduling activities, pre-vent and foresee canonical issues: this goal has been achieved by tailoring UP deployment discipline properly for the needs of such a context. The resulting output for the completion of each iteration is an artifact or series of artifacts.

This process is described in more detail by using a var-iation of unified modeling language (UML) notation. The following activities are represented as activity diagrams but swing lanes do not represent activities’ actors as usual: such lanes mean to identify activities to be performed for each UP phase (represented as lane), so every artifact produced in a phase will be used as input for the following.

In a project lifecycle or in product development, the deployment planning should be considered as important as any other process preliminary activities, such as func-tional requirements analysis or business modelling: this is why a basic inventory of bill material and a draft of a deployment plan should be defined in former phases of process lifecycle. For such a task it is really important to appoint a deployment manager.

The deployment manager will require a high degree of expertise and strong customer collaboration. Moreover, the deployment manager has to ensure a successful deployment which includes not only deliverable software but also the crosscheck and updation of training and sup-port material, organization of assistance coverage, defini-tions of timing and interdependencies among the different activities through the entire process cycle. From now on, the main phases of the deployment plan cycle are reported. During Inception phase, designers will collect a bill of material as a basic inventory in order to create a list of artifacts that are necessary to properly deliver the prod-uct, such as configuration items, documents, installation scripts, devices and packaging items.

This document will be enriched during the next phases. If the product includes some devices then, this discipline aims to list all of them. It describes the installation issues by considering the delivery country and which communi-cation channel will be adopted if the data exchange with such devices is needed [4].

The support material cycle covers the development of the full range of information required by the end users to install, use and maintain the PHealth or AAL system. It also includes development of the training material and assistance service definitions.

Developing the training material (i.e., user’s and tech-nical manuals, installation guides, product documenta-tion…) is important to be addressed as the beginning in order to fix the functional spec in a clear operational workflow. Some of the artifacts from the previous phases can help in the training material development, such as: software requirement specifications, use cases, naviga-tion maps and graphic interface stub. As well as the train-ing material definition, the assistance process definition should start in the earlier iterations of the elaboration phase and it should produce a draft for the Assistance Plan. This artifact should collect all the materials and considerations for defining an assistance service that is capable of covering the product lifecycle. In the latter phases of the UP, this document will be enriched with proper procedures to follow in order to notify any issue or how to contact the assistance service. A good service should also be capable of receipt and discern evolutionary assistance from the maintenance assistance: this approach will let the application to be fixed when needed and to evolve in time accepting and validating new requests.

The main purpose of this phase is to ensure that the product is accepted by the customer prior to its final release: these are formal testing sessions that are con-ducted by all the types of users. They are foreseen and supervised by the customers.

The testing sessions are performed at the development site by using a target environment. It is conducted to determine whether a system satisfies its acceptance crite-ria or not. The testing session is related to the “Transi-tion” phase of the acceptance test life cycle and it should be conducted in the real context of use. Such criteria should be defined from the Inception phase and then, it should be refined according to the project development. This produces an acceptance plan. This artifact describes how the customer will evaluate the requested specifica-tions in order to determine if they meet a predefined set of acceptance criteria. It’s important to remind that the acceptance plan, like most of the UP artifacts, is a “live document”, i.e., they evolve over time to best fit the project development process. This is the preliminary main session of the tests. Right from the construction phase it aims to discover issues and bugs. Much more test activities are planned in the deployment discipline.

In case of an unacceptable result, a change request will be raised for the anomalies: failures will be evaluated and fixed. Proper tests will be performed again. In this case, a bug tracking system (such as Bugzilla, JIRA…) is a good practice in order to capture, manage and store issues, defects, enhancements, new requests and changes.

This discipline aims to create a deployment unit that is ready to be effectively installed and used. This implies that the produced build will consist of the software and all the necessary accompanying artifacts are also required. In some projects’ workflow, this unit is created as a pro-totype for beta testing purpose. The unit will be submit-ted to final users: using this unit, the final users according to their defined roles should be able to install the soft-ware, configure devices, connect to the network (whereas such characteristics were requested) and use the applica-tion, interact with assistance service and also upgrade the system.

The design of a deployment unit starts in the elabora-tion phase according to the list of materials that are to be installed. Then, during the following phases it will be enriched with installation artifacts. These artifacts can be installation utilities, installation instructions, user manu-als or some hardware if needed, such as adaptors for power supply or for devices, and all that things to allow the final user to be able to install properly and enjoy using the product.

[Fig. 1.] Deployment main workflow. It isthe overall unified process (UP) process: each step will be iterated along project lifecycle through the 4 UP phases.

[Fig. 2.] Deployment plan cycle. It is represented in the four unified process phases for the deployment plan cycle.

[Fig. 3.] Support material cycle.

[Fig. 4.] Acceptance test cycle.

According to the complexity of the use case scenario and related information workflow, it is important to plan a set of beta tests. This kind of tests will be executed with proper representation of the final users and supervised by the customers. This activity will show on a large scale, application usability and stability: such tests should be excuted according to a specific test plan and test protocol across the use case scenarios. The main purpose is to increase the involvement and training on a field of intended users as well as to solicit their feedback. Feedback from the beta tests’ cycle should be treated as the refinement requests or bug fixing, by submitting a new change request.

These final tests will be performed at the deployment site in order to ensure that all system architecture works

[Fig. 5.] Beta test cycle.

properly. If something goes wrong, certain activities, such as hardware or software fixing, server re-deployment, have to be reiterated.

During the construction phase, the deployment man-ager should define specific test success parameters. In the transitions’ phase, these parameters will be used to evalu-ate the tests results.

The basic idea of this discipline is to take the deploy-ment unit with all its artifacts and package them for pro-duction.

Since the Elaboration phase the packaging issue should be taken into account, if required by the product. This discipline should consider all the questions about product artworks, manufacturing constraints and delivery services by configuring all the required hardware. The hardware configuration dedicated to the server in charge to operate the WEB application, the hosting site and the maintenance policies must properly defined before the deployment phase. As a matter of fact, several PHealth and AAL serv-ices are enterprise applications as they are based on the communication between the end user and a specialist who cares about his patients through a, centralized or dis-tributed, WEB based application. So, all the issues on server configuration and deployment of the server side application should be considered in the overall deployment process.

In the UP development framework that is based on the iterations of the described workflow across the UP phases, authors have defined and implemented a deployment path-way to structure, monitor and manage successful new PHealth and AAL service take offs. The paper does not directly address the issue of change management that should be properly planned according to the use case sce-nario. The paper mainly addresses on the description of a specific methodology and workflow to properly structure the deployment strategy. In this context specific indica-tors, such as number of deployment iterations, timely implementation of each phases, number of integrations and modifications requested can be used to assess the success of the deployment phase. Strong focus has been dedicated to direct involvement of the intended users dur-ing deployment phase. For instance one of the main issues to be properly taken into account during the serv-ice deployment is to provide a structured after sale serv-ice and technical assistance policy, both for service evolution and maintenance.

Currently in most of the PHealth services that are deployed for trials, the service and business case scenario are not often properly described in advance. Therefore, during the acceptance test several issues are highlighted to be improved or modified and as a result users’ commit-ment face a severe decrease.

According to our findings a proper deployment process can be considered as a new and relevant discipline in PHealth and AAL. The proposed UP approach opens a new discipline and research context for PHealth service deployment. This is not just in relation to the evaluation of the specific service outcomes, but it is also mainly tai-lored to empower specific workflow methodology and strategies to properly plan and verify the deployment pro-cess. In this regard, a proper involvement and participa-tion of the overall value chain of actors is also another strategic element for the start-up of a large scale PHealth and AAL services.

In conclusion, the present paper proposes a structured and embedded procedure that incorporates the deploy-ment workflow and it is based on a clear definition of the use case and business model scenario.