Managing Changes in Citizen-Centric Healthcare Service Platform using High Level Petri Net

The healthcare organizations are facing a number of daunting challenges pushing systems to deal with requirements changes and benefit from modern technologies and telecom capabilities. Systems evolution through extension of the existing information technology infrastructure becomes one of the most challenging aspects of healthcare and the adaptation to changes is a must. The paper presents a change management framework for a citizen-centric healthcare service platform. A combination between Petri nets model to handle changes and reconfigurable Petri nets model to react to these changes are introduced to fulfill healthcare goals. Thanks to this management framework model, consistency and correctness of a healthcare processes in the presence of frequent changes can be checked and guaranteed.


INTRODUCTION
The traditional method of receiving healthcare required a patient to visit their doctor's office, or a hospital; now doctors, hospitals, and healthcare ecosystems are increasingly brought to the patient. The baby boomer generation is entering a new stage of their life; they are adopting and demanding better delivery models for quality and access to care [1]. This has caused a paradigm shift in the healthcare system.
The new culture is patient centered utilizing care coordination that is focused on successful outcomes that depend on new innovations, technology and meaningful data, including collection, delivery, ease of use, intelligence, and reporting [2]. As human life expectancy continues to increase and aging populations lead to higher health treatment costs, telehealth is on the top of the regulators agenda.
The focus on the climbing cost to deliver and maintain quality healthcare is no longer in the peripheral view, but a clear line of sight for the patients, healthcare providers, regulators, and payers. This brings new requirements for healthcare professionals to share information, communicate and collaborate in real time from multiple locations, because medicine is a collaborative science.
Communications become a strategic asset for a strongly needed healthcare transformation technology. It must be deployed to this field in order to ensure better context for medical decisions, reduce administrative costs and improve patient safety by reducing errors. The healthcare community has recognized the need to transform from the current hospital centralized treatment-based mode to prevention-oriented comprehensive healthcare mode in which hospitals, communities, families and individuals are closely involved. The new mode needs to provide individuals with intelligent health information management and healthcare services. It allows them to enjoy medical prevention and healthcare services in their daily life.
The advancement of information technology (IT) brings more opportunities for innovations in the healthcare area. The use of service oriented technologies such as SOA, Web Services (WS) allows service providers to reduce and simplify integration process, to abstract network capabilities (e.g., call control, presence, location, etc.), and create personalized and blended services (both internally and with 3rd party partners) [3]. These technologies facilitate the construction of service systems with higher reusability, flexibility, extensibility, and robustness.
Cloud computing is evolving as an important IT service platform with its benefits of cost effectiveness and global access. Built upon Enterprise Service Bus (ESB) as an integration backbone [4], this paper presents a novel citizencentric healthcare service platform. One of the much-touted potentials of this platform is the ability to construct healthcare composite Web services on demand, relieving telecom operators from the intricate details of how technologies work so they can focus on the business aspects.
As healthcare services aggregated in the proposed healthcare service platform increases, the complexity of managing changes will grow and the manual management of changes becomes not practical [5]. One of the greatest promises of the healthcare platform is ability to self-adapting to guarantee goals achieving. Abstracting changes in business relationships claim a framework to manage changes without any impact. For instance, the proposed healthcare platform needs to achieve the plug-in/plug-out Web services with little overhead while guaranteeing properties. These properties can be classified either functional or non-functional. Functional properties address the functionalities that healthcare platform have to fulfill. The non-functional properties refer to events surrounding the functional properties.
Change management is a critical component in the deployment of healthcare platform. We identify two ma approaches dealing with changes: top-down and button A top-down approach focuses on changes that are usually business mandated. These changes are motivated by the business goal, and do not consider the uncertainty of the underlying member services. The second type of changes is referred to as bottom-up changes because Web service providers are the initiators of changes. Bottom-up changes are initiated by the member services. These changes are initiated in the Web service environment, and eventually translate into top down changes. A service operation may become unavailable and trigger dependencies services and users in order to replace this service. In this paper, we will concentrate on this aspect.
In this paper, we present a conceptual module for management of bottom-up changes using Petri nets. In our work, we use Petri nets to model handling and adaptive changes in healthcare platform. We model changes using Petri nets because of their applicability to a Web services composition modelling.
The behaviour of a composite Web services is described by the evolution of its Petri net model [7]. As the Petri net evolves, the system goes through different safe and unsafe states that can be completely defined by the marking of a Petri net model. Furthermore, Petri nets map directly to our change specification. They also preserve all the details of our change specification while modelling the changes accurately. For instance, Petri nets can easily represent the safe an unsafe states of web services composition. They represent changes between these states as transitions. In addition, the use of reconfigurable Petri nets allows us to incorporate our mapping rules into the Petri net model. This allows us to completely model our change specification.
The remainder of this paper is organized as follows. In Section 2, we use the healthcare platform architecture of and a scenario from this domain to motivate our work. It will also be used as a running example. Section 3 presents a bottom specification of changes. In Section 4, we describe our change management model which is based on Petri nets. Fin conclude in section 5.

II. HEATHCARE SERVICE PLATFORM ARCHITECTURE
In this section, we present the global context of and an overview about service oriented architecture computing and enterprise service bus. Then, the healthcare services platform architecture is exposed and some basic concepts and definitions are explained.

A. Context and Background
Below we have summarized a few key technologies that should be of significant value to the design of healthcare architecture.

1) Service Oriented Architecture (SOA):
architecture, applications and more discrete software functions are network-based, loosely coupled and available on demand authorized users or to other applications or services. Although SOA is not a new concept, the emergence of Web services as a (IJACSA) International Journal of Advanced Computer www.ijacsa.thesai.org component in the We identify two main down and button-up [6]. down approach focuses on changes that are usually changes are motivated by the business goal, and do not consider the uncertainty of the The second type of changes is up changes because Web service up changes are initiated by the member services. These changes are initiated in ly translate into topservice operation may become unavailable and users in order to replace on this aspect. e present a conceptual module for up changes using Petri nets. In our work, we use Petri nets to model handling and adaptive changes in healthcare platform. We model changes using Petri nets because of their applicability to a Web services composite Web services is described by . As the Petri net evolves, different safe and unsafe states that can be completely defined by the marking of a Petri net model. map directly to our change specification. They also preserve all the details of our change specification while modelling the changes accurately. For instance, Petri nets can easily represent the safe an unsafe states esent changes between , the use of reconfigurable Petri nets allows us to incorporate our mapping rules into the Petri net model. This allows us to completely model our change er is organized as follows. In Section 2, we use the healthcare platform architecture of and a scenario from this domain to motivate our work. It will also be used as a running example. Section 3 presents a bottom-up we describe our change management model which is based on Petri nets. Finally, we RCHITECTURE present the global context of our work architecture, cloud the healthcare services platform architecture is exposed and some basic Below we have summarized a few key notions and to the design of Service Oriented Architecture (SOA): In this IT applications and more discrete software functions based, loosely coupled and available on demand to applications or services. Although Web services as a standard way to expose, describe, access and combine services has given new life to this approach to computing The key idea of SOA is the following: a service provider publishes services in a service registry requester searches for a service in the registry. He finds one or more by browsing or querying the registry. The service requester uses the service description to bind ideas are shown in Fig. 1. 2) Cloud Computing: Cloud computing computing refers to an IT service model and platform that provides on-demand based IT services over Fig. 2). The five essential characteristics are: on service, broad network access, resource pooling, rapid elasticity, and measured service [8]. The three services models include: · SaaS (Software as a Service) which delivers so service on demand, such as, salesforce.com Customer Relationship Management (CRM) service and Google Gmail; · PaaS (Platform as a Service) which provides the computing platform for companies to deploy and customize business applications on demand, Google App Engine and Microsoft's Azure; · IaaS (Infrastructure as a Service) which offers data center, infrastructure hardware and software resources on demand, such as, Amazon Elastic Compute Cloud (EC2) and VMware vCloud Datacenter. Both of these resources provide virtual computers for renters to run their business applications.
The four major deployment models include: private cloud, public cloud, community cloud, and hybrid cloud. Companies normally adopt different service models and deployment models depending on their unique business processes and demands on IT services.
Cloud computing today is an evolution and application of modern ICT including server virtualization, autonomic computing, grid computing, server farm, network storage, and web service.
ter Science and Applications, Vol. XXX, No. XXX, 2011 2 | P a g e standard way to expose, describe, access and combine services has given new life to this approach to computing.
following: a service provider publishes services in a service registry [7]. The service requester searches for a service in the registry. He finds one or more by browsing or querying the registry. The service requester uses the service description to bind service. These Reference architecture of web services-SOA Cloud computing called also utility refers to an IT service model and platform that demand based IT services over the internet (see . The five essential characteristics are: on-demand selfservice, broad network access, resource pooling, rapid . The three services models S (Software as a Service) which delivers software service on demand, such as, salesforce.com -Relationship Management (CRM) service PaaS (Platform as a Service) which provides the computing platform for companies to deploy and business applications on demand, such as, Google App Engine and Microsoft's Azure; IaaS (Infrastructure as a Service) which offers data center, infrastructure hardware and software resources such as, Amazon Elastic Compute Cloud (EC2) and VMware vCloud Datacenter. Both of these provide virtual computers for renters to run The four major deployment models include: private cloud, public cloud, community cloud, and hybrid cloud. Companies normally adopt different service models and deployment odels depending on their unique business processes and Cloud computing today is an evolution and application of modern ICT including server virtualization, autonomic computing, grid computing, server farm, network storage, and 2) Enterprise Service Bus: ESB is one piece of an infrastructure that might help facilitating the implementation of a SOA, but it is not a perquisite. There are many aspects of an ESB that fit well with the SOA model, and denying its possible usefulness would be counterproductive, but the two are not completely inter dependent [4]. · Event triggering.
If we consider some of these functional elements it can be seen that items such as application adapters fall neatly into the product category, while routing and messaging are more of an architectural consideration.
(IJACSA) International Journal of Advanced Computer www.ijacsa.thesai.org is one piece of an infrastructure that might help facilitating the implementation of a SOA, but it is not a perquisite. There are many aspects of an ESB that fit well with ulness would be counterproductive, but the two are not completely interhe base functional elements within an ESB. It If we consider some of these functional elements it can be seen that items such as application adapters fall neatly into the product category, while routing and messaging are more of an

B. System Architecture
First, we present our Healthcare Service Platform (HSP). It intends to provide personalized healthcare services for the public. The healthcare value chain is complex. It consists only of healthcare providers, but also of payers (government, employers and patients), fiscal intermediaries, distributors and producers of pharmaceuticals and devices The HSP does not attempt to address this complete value chain. It focuses on the delivery of healthcare services. It is an end-to-end reference architecture that focuses on meeting the needs of citizens, patients and professionals. diagram is given in Fig. 4.
We distinguish three main components, i.e. body sensor networks (BSN), IaaS cloud, healthcare delivery environment.
· BSN: according to circumstances and personalized needs, appropriate health information collection terminals (i.e. sensors) are configured for different individuals. BSN is used to provide long t continuous monitoring of patients under their natural physiological states. It performs acquisition, integration and real personal heath information anywhere · IaaS cloud: modern healthcare is information dri Healthcare providers are making progress in building an integrated profile of patients. This data sits in systems throughout the enterprise including the HER and many other electronic systems throughout the enterprise and community achieves the rapid storage, management, retrieval, and analysis of massive heath data. It mainly includes Electronic Medical Record considers also personal health data acquired from BSN. · Healthcare delivery environment health information management system expensive in-patient acute care with preventative, chronic care, offers disease management and remote patient monitoring and education/wellness programs.
ter Science and Applications, Vol. XXX, No. XXX, 2011 3 | P a g e First, we present our Healthcare Service Platform (HSP). It intends to provide personalized healthcare services for the The healthcare value chain is complex. It consists not only of healthcare providers, but also of payers (government, employers and patients), fiscal intermediaries, distributors and producers of pharmaceuticals and devices [9].
does not attempt to address this complete value the delivery of healthcare services. It is an end reference architecture that focuses on meeting the needs of citizens, patients and professionals. Its architectural We distinguish three main components, i.e. body sensor networks (BSN), IaaS cloud, healthcare delivery environment.
BSN: according to circumstances and personalized needs, appropriate health information collection terminals (i.e. sensors) are configured for different individuals. BSN is used to provide long term and continuous monitoring of patients under their natural performs the multi-mode acquisition, integration and real-time transmission of anywhere [10].
odern healthcare is information driven. Healthcare providers are making progress in building an integrated profile of patients. This data sits in rprise including the HER and many other electronic systems throughout the [11]. This component achieves the rapid storage, management, retrieval, and analysis of massive heath data. It mainly includes (EMR) repository. It considers also personal health data acquired from BSN. delivery environment: it includes a personal health information management system. It replaces patient acute care with preventative, management and remote and ensures health Fig. 4. HSP architecture

C. Healthcare Web Services Provided by HSP
In PHISP, we adopt the design idea of SOA and Web service technology for its design and implementation. The majority of its functional modules are developed and packaged in the form of services [8]. Here, we overview some of them as follows.
· PhysInfoWS: this service can acquire some general physiological signals such as body temperature, blood pressure, and saturation of blood oxygen, electrocardiogram, and some special physiological signals according to different sensor deployment for different users. User's ID number is required. · EnvInfoWS: for a unique ID number, this service acquire temperature, humidity, air pressure and other environmental information for this user. · SubjFeelWS: it can acquire the user subjective food intake, etc., and the information is often by the user from the terminal. · CoronaryDiagWS: it can analyze the information according to a series of analysis models, which are built for coronary heart disease, and then produce preliminary diagnostic results. · AssessmentWS: this service can assess the status of the patient's health risk based on the diagnostic results and the EMR information of the patient. · EmrWS: this service can output the user's medical history information. · GeoWS: it can return the user's location. · EmerWS: it can raise an alarm to the user in case of illness. · GuideWS: it can provide the patient with preventive measures especially items that need attention.
(IJACSA) International Journal of Advanced Computer www.ijacsa.thesai.org In PHISP, we adopt the design idea of SOA and Web service technology for its design and implementation. The majority of its functional modules are developed and packaged view some of them as some general temperature, blood pressure, and saturation of blood oxygen, electrocardiogram, and some special physiological sensor deployment for different users. User's ID number is required. unique ID number, this service can acquire temperature, humidity, air pressure and other jective feelings, , etc., and the information is often provided it can analyze the information according to a series of analysis models, which are built for coronary heart disease, and then produce this service can assess the status of the based on the diagnostic results and output the user's medical : it can raise an alarm to the user in case of it can provide the patient with preventive attention.

D. Healthcare Service Scenario
A way to motivate and illustrate this work, we presents an example of healthcare service scenario. We main layers: service, business and HSP consists of available web services, and the business layer represents the Web service like operations t a particular application domain. We refer to the selected services as member services (see Fig. 5 Key healthcare environment objectives include: · Allowing people to stay in their homes age. By doing this, we can reduce the burden of dedicated care facilities and improve quality of life for a substantial proportion of the aging population. · Using televisions to keep in touch. camera technology is in conjunction with an IPTV set top box and connection back to a Contact Center. · Using wireless toys for always communications. The wireless home network itself enables a new class of device that has significant healthcare implications. Let us assume that a citizen establishes a need for a business objective (healthcare service). Typically, he starts with formulating the business strategy (or goal). During the planning, some services can be identified: AccountingService, SpecialistService, InsuranceService. Second, the senior citizen specification listing the services to be composed graphical interface. We assume that HS selected and orchestrated. The third step where member services that match the specified high level configuration are selected and invoked.
We describe here the ideal scenario: the subscribe to HealthService. Then all information regarding who contacts it and when are forwarded to HealthService forwards also the received data to SpecialistService in charge of checking the received values. After analyzing the received values, the team sends a ter Science and Applications, Vol. XXX, No. XXX, 2011 4 | P a g e strate this work, we presents an service scenario. We distinguish three HSP. The service layer consists of available web services, and the business layer represents the Web service like operations typically ordered in a particular application domain. We refer to the selected 5).
objectives include: stay in their homes to an older By doing this, we can reduce the economic burden of dedicated care facilities and improve quality of life for a substantial proportion of the aging Using televisions to keep in touch. Another use of camera technology is in conjunction with an IPTV setack to a Contact Center.

Using wireless toys for always-on monitoring and
. The wireless home network itself enables a new class of device that has significant Healthcare Service Scenario based on HSP establishes a need for a service). Typically, he starts with formulating the business strategy (or goal). During the identified: HealthService, , FinancialServcie and senior citizen develops a specification listing the services to be composed through a HS, AS, SS, FS and IS are selected and orchestrated. The third step is the orchestration where member services that match the specified high level configuration are selected and invoked.
We describe here the ideal scenario: the senior citizen Then all information regarding are forwarded to AccountingService. forwards also the received data to in charge of checking the received values. the received values, the team sends a confirmation or an adjustment of the medication dos FinancialService and InsuranceService are executed to the process.

E. Modeling Healthcare process using High Level Petri Nets
The modeling of healthcare process is as crucial as the implement of healthcare service platform. The formal representation of real healthcare process with Hierarchical Petri-Nets is easy to understand. Fig. 6 shows a Hierarchical Petri Net that describes our healthcare service scenario offered by HSP.
From the above, the first part of hierarchical healthcare process net N with refinable transition named 'Health Service is shown below. It is refined with the attachment of web services net N'. The planned web service is the assembly of the set of web services presented previously ( EnvInfoWS, SubjFeelWS, CoronaryDiagWS, AssessmentWS, EmrWS, GeoWS, EmerWS, GuideWS).
However some changes to member services may handle some inconsistency in the composition and orchestration. Each service layer change presents a functional and non change that may happen in a member service. For example, in case of non availability SpecialistService, a change management is required to ensure that the healthcare system is remaining profitable.

III. CHANGE SPECIFICATION
Managing bottom-up changes is highly dependent on the services that compose the system. Therefore, it is quite important to define the changes that may occur to web services and then map them to into the system level.
In this section, we present bottom-up changes. We define the set of handling changes. Handling change (q for changes that occurred at the service level (for example Web service availability) while adaptive changes ( W ) are relat changes at the business level (for instance the selection of alternative service).

Modeling Healthcare process using High Level Petri Nets
The modeling of healthcare process is as crucial as the implement of healthcare service platform. The formal entation of real healthcare process with Hierarchical shows a Hierarchical Petri Net that describes our healthcare service scenario offered From the above, the first part of hierarchical healthcare et N with refinable transition named 'Health Service is shown below. It is refined with the attachment of web web service is the assembly of the set of web services presented previously (PhysInfoWS, aryDiagWS, AssessmentWS, However some changes to member services may handle some inconsistency in the composition and orchestration. Each a functional and non-functional ocess modeled by hierarchical Petri nets availability of a , a change management is required to ensure up changes is highly dependent on the services that compose the system. Therefore, it is quite important to define the changes that may occur to web services up changes. We define q ) is defined for changes that occurred at the service level (for example Web ) are related to changes at the business level (for instance the selection of

A. Changes overview
For each change, a transition will be associated between two states: precondition and postcondition. In presented, a precondition for SS unavailability is that it was available and the postcondition is that it has unavailable state. Handling changes will be modeled using Petri nets. Our classification of triggering changes is based on the traditional approaches from the fields of software engineering and workflow systems [7]. A handling change is initiated at the service level such as the operations Therefore, we can distinguish several handling changes based on Web service properties.
The Web service properties can be sorted into two categories: functional and non-functional. handling changes: functional and non-functional -Non-functional changes: we assume that the non parameters represent the dependability and response a associated with a member service. Service dependability can be set to two possible values (i.e., available or unavailable). Alternatively, service cost values may take more than two possible values. Fig. 7. Handling changes categories -Functional changes: this category of changes is relate service WSDL description [12]. We changes as a combined execution of elementary operations: remove and then add. We distinguish two different functional changes: structural and behavioral (see Fig. changes are related to the operational aspects of a Web service. For example, a structural change in a service can be a consequence of change offered to a citizen. Functional changes to a memb service occur when its WSDL description is modified.
-Adaptive changes: Adaptive changes may occur at the composition and orchestration levels. Fig. changes considered in our model. In our scenario, when the healthcare system is interrupted by a change in the change after suspending execution. This may be accomplished by raising a fault, compensating for the change at the composition layer, and calling of an alternate service.
ter Science and Applications, Vol. XXX, No. XXX, 2011 5 | P a g e a transition will be associated between two states: precondition and postcondition. In our scenario unavailability is that it was available and the postcondition is that it has switched to Handling changes will be modeled using Petri nets. Our classification of triggering changes is based on the traditional of software engineering and . A handling change is initiated at the service level such as the operations, the availability, etc. Therefore, we can distinguish several handling changes based operties can be sorted into two functional. Fig. 7 shows the functional.
we assume that the non-functional parameters represent the dependability and response aspects Service dependability can be set to two possible values (i.e., available or unavailable). Alternatively, service cost values may take more than two : this category of changes is related to a . We consider functional changes as a combined execution of elementary operations: . We distinguish two different functional ehavioral (see Fig. 6). Structural to the operational aspects of a Web service. For example, a structural change in a healthcare change in the operations offered to a citizen. Functional changes to a member Web service occur when its WSDL description is modified.
Adaptive changes may occur at the Fig. 8 shows the adaptive In our scenario, when the is interrupted by a change in SS, it reacts to the change after suspending execution. This may be accomplished by raising a fault, compensating for the change at the composition layer, and calling of an alternate service.
For example, if SS becomes unavailable, business layer will be search for equivalent service to continue execution to ensure that there is no high level impact on user demands.

Fig. 8. Handling changes categories
Now, we will discuss the impact of q changes to healthcare business layer. A mapping details how change instances in one layer correspond to changes in another layer. These mapping must remain consistent in the presence of frequent changes. Handling changes have a reactive impact on the business layer. For instance, a q change in availability maps to W change of change instance.

I. CHANGE MODEL
In this section, we introduce a change model to accurately identify eventual types of changes in a composite Web services.

A. Handling Changes Model using Petri Nets
Petri nets or PN are a well-founded process modeling techniques that have formal semantics. They have been used to model and analyze several types of processes including protocols, and business processes.
Visual representations provide a high-level, yet precise language, which allows reasoning about concepts at their natural level of abstraction. Services are basically a partially ordered set of changes. Therefore, it is a natural choice to map it into a Petri net. Moreover, the semantics delivered by Petri nets can be used to model the standard behavior of composite Web services described by BPEL [7].
We formalize the change model for triggering changes by introducing Petri-Net-Handle (PNH) which is defined follows. The algebraic structure of PNH = (P, T, F, P following conditions hold: www.ijacsa.thesai.org ilable, business layer will be search for equivalent service to continue execution to ensure that there is no high level impact on user demands. changes to the business layer. A mapping details how change instances in one layer correspond to changes in another layer.
in the presence of frequent changes. Handling changes have a reactive impact on change in availability a change model to accurately of changes in a composite Web founded process modeling techniques that have formal semantics. They have been used to model and analyze several types of processes including level, yet precise language, which allows reasoning about concepts at their natural level of abstraction. Services are basically a partially Therefore, it is a natural choice to map i net. Moreover, the semantics delivered by Petri nets can be used to model the standard behavior of composite ering changes by Handle (PNH) which is defined as -P is a finite set of places representing the states of Web service. -T is a finite set of transitions representing changes to Web service. -F is called the web services action flow. -P 0 is the input place, or starting state of the Web service -P n is the output place, or the ending state of the Web service Fig. 9 represents the model of non-functional changes to Web services. It is composed from five places and four transitions. PS is the initial place of PNH N . It represents the initial state of the Web Service. PS consists of four tokens, each representing one of the four non-functional changes. corresponding to change is fired each to represent dynamic evolution. If more than one change occurs, the corresponding token for each change type is fired.
For instance, if a member services (i.e Web service) becomes unavailable, the transition will be enabled and the corresponding token will be fired. Table I. gives summary about non-functional changes. 6 | P a g e is a finite set of places representing the states of is a finite set of transitions representing changes to is called the web services action flow. is the input place, or starting state of the Web is the output place, or the ending state of the Web functional changes to Web services. It is composed from five places and four transitions.
. It represents the initial state of consists of four tokens, each representing functional changes. The token each to represent dynamic . If more than one change occurs, the corresponding For instance, if a member services (i.e Web service) becomes ailable, the transition will be enabled and the functional changes. When a service becomes unavailable, the token (repr the availability property) is moved from PS to PS behavior is observed when the service becomes unrel represents alterAvailibility, and TRe alterReliability. The same logical structure can be applied for functiona changes.

B. Modeling Adaptive Changes with Reconfigurable Petri Nets
We have surveyed extensions of Petri nets for modeling reactive changes. Reconfigurable Petri-nets provide formalism for modeling these changes. It is a class of high level They support internal and incremental description of changes over a uniform description. Reconfigurable Petri nets are an extension of Petri nets with local structural modifying rules performing the replacement of one of its subnets by other subnets [13]. The tokens in a deleted place are transferred to the created one.
We formalize the change model for adaptive introducing PNAC (PNAC) which is defined as follows. The algebraic structure of PNAC= (P, T, F, R, I) where: -P= {P 1 … ,P n } is a non empty and finite set of places -T={T 1 ,...,T n } is a non empty and finite set of transitions disjoint from ) (   10 shows a PNAC representing service orchestration. The adaptive changes using Reconfigurable Petri net representing state (see Fig. 11), removal of servic addition of service (see Fig. 13) are presented

C. Change Management Framework
We use our Petri net change specification as the basis for handling changes in our healthcare framework of change management modules: detection and reaction.
After the change specification is defined, we begin the management. Detecting the respective changes is the first step of change management. shows a PNAC representing initial statechange in adaptive changes using Petri net representing modification on service , removal of service (see Fig. 12), and resented.
We use our Petri net change specification as the basis for healthcare environment. The of change management is divided into two After the change specification is defined, we begin the management. Detecting the respective changes is the first step . Reconfigurable Petri nets for Reactive changes- All changes identified in the handling changes models are subject to detection. Detection involves an agent that monitors the Web service. Each change type has an associated set of rules for detection. For example, a SpecialistService change the input parameters (i.e required information provided by patient), when this change occurs, the healthcare must detect this change using some predefined detection rules.
Each detected change must be forwarded to monitoring service; and then the composition strategy must be updated. The notification and polling mechanism are mainly the techniques to awareness that a change has occurred. These techniques require that a monitoring service periodically send "Refresh" and "Alive" messages to detect unavailable services and also renew membership. All changes identified in the handling changes models are agent that monitors the Web service. Each change type has an associated set of SpecialistService may change the input parameters (i.e required information provided healthcare system must detect this change using some predefined detection rules.
Each detected change must be forwarded to monitoring service; and then the composition strategy must be updated. The notification and polling mechanism are mainly the ness that a change has occurred. These techniques require that a monitoring service periodically send efresh" and "Alive" messages to detect unavailable services The changes are detected at the service layer and represented as an incidence matrix. Some rules are identified for detecting functional and non functional changes.
We define a rule for mapping the change into the defined Petri-net: first of all, the current service state is corresponded to a set of precondition places in the triggering Petri net and the updated service state as the set of postcondition places in the triggering Petri net. Then, a comparison between the values precondition and postcondition places of the Petri net is done. Depending on result retuned, a token is placed in the respective precondition place. This token will enable the change transition only if a difference is found.
Let us consider the example where the serv change availability (due to maintenance reasons) and the other attributes remain constant. In this case, we map the change into the non-functional Petri net. The service agent responsible of monitoring of WS will generate the corresponding to the Petri net model interaction with healthcare service platform to detect effective changes in the execution environment and map it into a Petri net model defined in this section ( for example, unavailability of a WS). The Centralized agent is the module that reacts to these changes and purpose a reconfiguration in the execution environment to guarantee consistency and correctness of the healthcare processes. Fig. 14 shows the different modules designed for management framework to detect and react to different changes in healthcare services.
Based on the information sent by service agent we define how to execute adaptive change. After receiving the matrix indicating the change that occurred, the handling change is mapped to the appropriate reactive change. We can list some ter Science and Applications, Vol. XXX, No. XXX, 2011 8 | P a g e . Reconfigurable Petri nets for Reactive changes-after The changes are detected at the service layer and represented as an incidence matrix. Some rules are identified for detecting functional and non functional changes.
We define a rule for mapping the change into the defined of all, the current service state is corresponded to a set of precondition places in the triggering Petri net and the updated service state as the set of postcondition places in the triggering Petri net. Then, a comparison between the and postcondition places of the Petri net is done. Depending on result retuned, a token is placed in the respective precondition place. This token will enable the change transition only if a difference is found. Let us consider the example where the service WS service change availability (due to maintenance reasons) and the other attributes remain constant. In this case, we map the change service agent responsible of monitoring of WS will generate the incidence matrix to the Petri net model. This agent is in interaction with healthcare service platform to detect effective changes in the execution environment and map it into a Petri net model defined in this section ( for example, unavailability . The Centralized agent is the module that reacts to these changes and purpose a reconfiguration in the execution environment to guarantee consistency and correctness of the healthcare processes. Fig. 14 shows the different modules framework to detect and react to different changes in healthcare services.
Based on the information sent by service agent we define how to execute adaptive change. After receiving the matrix indicating the change that occurred, the handling change is ed to the appropriate reactive change. We can list some considered reaction techniques in our system: -In case of add, the newly service member will be considered. It can be taken into account balancing context or as back-up alternative - In case of unavailability of a service, if it is critical then the orchestration will be paused. heartbeat is activated to check the status of the service; the orchestration will wait the service availability otherwise orchestration (depending on configurable heartbeat number) Fig. 14. Adaptive Petri net generator module in change management framework

II. CONCLUSION AND FUTURE WORK
In this paper, we first presented a novel architecture of healthcare services platform. Second, we exposed up approach focusing on handling changes that may occur in this system and then mapped to adaptive changes. We use formal change model based on High Level Petri N accurately represent these changes. Future work includes an extension of change framework. We plan to include a top-down approach to specifying changes. A full simulation prototype taking into account priority in changes and the estimation of frequency based on measures represent actions enhance actual healthcare platform. In case of add, the newly service member will be taken into account in load up alternative. of unavailability of a service, if it is critical then the orchestration will be paused. Since a activated to check the status of the will wait the service orchestration will exit number).

REFERENCES
generator module in change ORK architecture of . Second, we exposed the bottomup approach focusing on handling changes that may occur in this system and then mapped to adaptive changes. We used a Petri Nets to management down approach to full simulation prototype taking into estimation of their represent actions planned to