An Ontology- and Constraint-based Approach for Dynamic Personalized Planning in Renal Disease Management

Healthcare service providers, including those involved in renal disease management, are concerned about the planning of their patients’ treatments. With efforts to automate the planning process, shortcomings are apparent due to the following reasons: (1) current plan representations or ontologies are too fine grained, and (2) current planning systems are often static. To address these issues, we introduce a planning system called Dynamic Personalized Planner (DP Planner) which consists of: (1) a suitably light-weight and generic plan representation and (2) a constraintbased dynamic planning engine. The plan representation is based on existing plan ontologies, and developed in XML. With the available plans, the planning engine focuses on personalizing pre-existing (or generic) plans that can be dynamically changed as the condition of the patient changes over time. To illustrate our dynamic personalized planning approach, we present an example in renal disease management. In a comparative study, we observed that the resulting DP Planner possesses features that rival that of other planning systems, in particular that of Asgaard and O-Plan. Keywords-patient care planning; treatment protocols; dynamic treatment planning; personal health services.


INTRODUCTION
Healthcare service providers are undoubtedly concerned about updating their patients' health records or profiles, and the planning of their patients' treatments to support the efficient and effective delivery of healthcare services.However, not all healthcare service providers are carrying out planning activities effectively, especially when it comes to automated or computer-based planning, due to shortcomings in current planning systems.
The first problem is that most of the current plan representations or ontologies are too fine grained (detailed).This means that the plan representations or ontologies are not suited for all situations and for all levels.We need to have a portable and intuitively easy representation that facilitates the storage and manipulation of generic plans.The second problem is that current planning systems are often static.This means planning is carried out once without taking into account changes that may take place as time goes on.These plans also do not consider past events.Dynamic planning is therefore required to allow plans to be updated as new situations arise.
To address the concerns above, we present a methodology for generic and dynamic healthcare planning, resulting in a system called the Dynamic Personalized Planner (DP Planner) [1].For this purpose, we define (1) a suitably light-weight and generic plan representation based on existing plan ontologies, and (2) a constraint-based dynamic planning engine.

II. STATE OF THE ART
A popular approach for plan representation is via ontologies, i.e. plans are designed based on project specific ontologies and domain description languages [2].Fig. 1 shows the structure of the Plan Ontology proposed by Tate [3].Another useful plan ontology for generic planning is the task-specific ontology and approach called Asbru which uses skeletal plans [4].Asbru represents skeletal plans using a taskspecific, intention-based, and time-oriented language.It can be used to design specific plans [5].In Asbru, a plan contains a name and a set of arguments (time annotation and knowledge roles).All plans and actions have a temporal dimension and the plan's execution is controlled by a number of conditions such as filter, setup, suspend, reactivate, abort and complete [6].Fig. 2 shows the Asbru plan ontology structure.
Besides plan ontologies (which contribute towards plan representation), there are also a number of plan generation initiatives.An example of such an initiative is the RAX Planner/Scheduler (RAX-PS) [7].The RAX-PS generates plans www.ijacsa.thesai.org that are temporally flexible, allowing the execution system to adjust to actual plan execution conditions without breaking the plan.The result is a system capable of building concurrent plans.
Fig. 3 shows the architecture of the planning system in RAX-PS.For the RAX-PS, the domain model describes the dynamics of the system [8] to which the planner is being applied, i.e. the Deep Space One Spacecraft.The plan database is initialized by a plan request which consists of an initial state and a set of goals.The initialized database is then modified by a search engine to generate a complete and valid plan.This complete plan is then put into operation by an execution agent.The heuristics and planning experts are also integral parts of the Deep Space One planning system.The heuristics guide the search engine while the planning expert interfaces with external systems which provide critical inputs such as altitude and speed.
The Capture the Flag (CTF) [9] game project uses the notion of critical points (time during the execution of an action or plan where a decision might be made) to define states in the continuous domain.These states are then used to efficiently evaluate plans.An action or a plan posts a goal, G.This invokes the CTF planning algorithm [10].
In the effort to generate outputs that are dynamically assembled from smaller fragments, the Personalized Healthcare Information (PHI) system [11] composes personalized documents that conform to an individual's health profile.The composition of PHI is carried out in a three-step procedure which are (1) selection of a set of Topic Specific Documents (TD), where each selected TD addresses some of the individual's healthcare concerns, (2) combination of the selected TDs to produce an aggregated PHI document, and (3) verification of the accuracy of the aggregated PHI document.Each individual illness/concern/issue noted in the health profile is addressed by at least a single TD.Constraint satisfaction techniques are used to ensure that the aggregated PHI document is medically consistent.Fig. 4 shows the processes for PHI composition.We have found the PHI system's approach in using constraints attractive as this approach could be adapted in our DP Planner to ensure the coherency of plan fragments that are assembled to form a complete plan.

III. THE DYNAMIC PERSONALISED PLANNING METHODOLOGY
The dynamic personalized planning approach consists of two phases: 1. Plan ontology definition and representation.

A. Phase 1: Plan Ontology Definition and Representation
In defining the plan ontology, the Asbru plan ontology was adopted as the basis for the DP Planner's plan ontology in view that it is reasonably concise compared to other ontologies that were surveyed.Besides this, some elements of Goals, Operators, Methods and Selection (GOMS) analysis [12] were also incorporated.GOMS is a method for analyzing and modeling the knowledge and skills that a user must develop in order to perform tasks on a device or system.
Referring to Fig. 6, the plan is positioned at the highest position in the plan hierarchy, and is basically the task that needs to be performed.Examples of plans are those for kidney patient treatment monitoring, gestational diabetes mellitus monitoring, student performance monitoring, etc.The plan consists of a sequence of plan fragments.These plan fragments are the necessary steps to achieve the task and can be viewed as the most crucial component of the plan ontology.

Each plan fragment consists of seven attributes:
 Name: Identifies a plan.o Pre-condition: This is to ensure that certain conditions are met before the execution of a particular plan fragment.
o Current condition: This ensures that certain conditions are currently met in a particular plan fragment.
o Post-condition: This is to ensure that certain conditions are met after the execution of a particular plan fragment and before the next plan fragment.
2) Plan representation Fig. 7 illustrates an example of a plan represented in XML for the treatment of a patient with renal disease.Note that the plan ontology can be naturally implemented in XML as the hierarchical nature of ontologies maps very well into the nested nature of XML.With the defined DP Planner plan ontology and representation, the DP Planner planning engine implementation is discussed next.

B. Phase 2: Planning Algorithm Definition
The DP Planner's planning strategy involves reusing plans that are stored in the plan repository and subsequently personalizing these plans according to the constraints defined by the user.
The planning algorithm is divided into two parts (see Fig.

1) Generic plan generation
Firstly, user inputs are matched against each of the existing plans in the plan repository.A concentration unit is calculated during the matching process to compare the closeness of the match.This unit is based on the number of matches between the user's inputs (pre-conditions and current conditions) with those of the plan fragments which constitute each plan.The similarity between the user's pre-condition and current condition inputs, and those of a particular plan, P, is expressed as C P , (see Equation 1).
(1) where n = number of matches of pre-conditions + matches of current conditions, and T f = total number of plan fragments in a plan.The values of C for each plan will be compared.The plan with the highest value will be chosen as the generic plan.After a generic plan has been identified, the process of plan personalization will follow

2) Plan personalization
The personalization method employs a combination of (1) a simple matching and linking technique, and (2) a constraintbased approach to form certain restrictions [9] so that only plan fragments that meet the predetermined criteria and user's inputs can form the finalized and personalized plan for a particular user or situation.Personalization is only carried out when the user's status is active, i.e. the plan is still relevant to the user's condition.For a start, the user will be asked for the outcomes of following the activities defined in a particular plan fragment.These outcomes are called post-conditions.Here, a simple matching technique will be applied to match the postconditions of a particular (current) plan fragment with the preconditions in the next plan fragment.If these match each other, that next plan fragment in the generic plan will be recommended as the subsequent plan for the user.However, if they do not match, the plan (or sequence of plan fragments) will terminate at that current plan fragment.
The matching technique is applied to ensure that each plan fragment in the finalized plan links to each other (see Fig. 9).This is to ensure that the final plan generated by the system corresponds to the needs of the user.After ensuring that the plan fragments in the generic plan fulfils the initial matching of post-conditions with the pre-conditions, the actual personalization can then take place using constraints.Constraints are utilized to ensure the consistency of the multiple fragments of a plan in order to form a complete plan.The individual plan fragments must not contradict each other or lead to improper recommendations [11].Therefore, for the purpose of the DP Planner, a constraint is simply a variable which restricts the execution of a particular plan fragment.It also describes the relationship between plan fragments in a plan.Ultimately, the constraints are used to find suitable replacements for plan fragments which are not suited for the plan fragments preceding or following it.Fig. 10 illustrates how constraints are used to personalize a generic plan.In Fig. 10, the generic plan's Plan Fragment 4 shows constraint 5 (C5) = yes.However, let us assume this does not fulfill a constraint specified by the user, i.e. the user has C5 = no.Therefore, plan personalization is carried out to find a plan fragment in the plan repository which fulfils the user's constraint.The example in Fig. 10 shows Plan Fragment 5 in Plan A has C5 = no.Therefore, our system will use this plan fragment to replace Plan Fragment 4 in the generic plan provided other details are also met (e.g.pre-conditions, postconditions, etc.).
IV. RESULTS: EXAMPLE CASES Fig. 11 shows the command-line system interface which obtains inputs from the user to generate a generic and personalized plan in the domain of renal disease.

A. Generic Plan Generation
From Fig. 11, the interaction labeled A gets the inputs of pre-conditions while the interaction labeled B gets the inputs of current conditions from the user (bold text indicates text entered by the user).Both of these conditions will be used to match the pre-conditions and current conditions in the plans found in the plan repository.As described in Section III.B.1, this matching is carried out to find the plan that best matches the user's pre-condition and current condition inputs, i.e. the plan with the highest concentration of matches value (see Equation 1) is identified.Then, a copy of that plan is created as an XML file and assigned with a new ID.The values for the pre-conditions and current conditions are assigned with those inputted by the user while dates, times, and post-conditions are left empty.

B. Plan Personalization
After the generic plan has been generated, personalization then takes place.Firstly, the user will be presented with the first plan fragment in the plan as shown in Fig. 11 (labeled C).Then, the planning system will prompt the user about their status, i.e. whether active (user is implementing the plan) or not active (not implementing the plan).Either response will result in a different output for the user.Hence, we show the results of different cases in the following sub-sections.This process is repeated with other plan fragments (labeled D to H in Fig. 11).

1) Case 1: Status is active
This case is for situations when the user is implementing a particular plan fragment.When this happens, the system will prompt for details about the user's post-condition as shown in Fig. 12.Assuming that the user's input for post-condition was Percentage of renal damage = 95% therefore, this input will be matched with the next plan fragment's pre-condition.If they match, the constraints of the next plan fragment will be highlighted to the user: Diabetes = yes?: (T=True/F=False) as shown in Fig. 12.If the user fulfils the constraint, the next plan fragment will be presented.The output for this user will be generated as shown in Fig. 13.
Figure 12.Part of the system interface when status of the user is "active".Figure 13.Part of the system output when status of the user is "active".

2) Case 2: Status is not active
This case shows that the user is not implementing a particular plan fragment.When this is indicated by the user, the system will not perform any personalization in the subsequent plan fragments.Therefore, the planning process is deemed to www.ijacsa.thesai.orgbe complete.The output for the user will be generated as shown in Fig. 14.Here, the result is personalized by removing the subsequent plan fragments that are not necessary.
Figure 14.Part of the system output when status of the user is "not active".

3) Case 3: Inputs do not fulfill conditions or constraints in the generic plan
This situation can be further divided into three sub-cases as follows: 1. Inputs which do not fulfill conditions in the generic plan.
2. Inputs which do not fulfill some conditions but fulfill constraints in the generic plan.
3. Inputs which do not fulfill constraints in the generic plan.
In the first case, consider the example system interface in Fig. 15.Assume that the post-condition in the generic plan is Percentage of renal damage = 95%, and this does not match with the user's input which is Percentage of renal damage = 60%.Therefore, the personalization process is terminated and the entire planning process is deemed to have completed.As a result, the planning system generates the output as shown in Fig. 16 as the personalized plan for this case.In the second case, consider the example system interface in Fig. 17.Let us assume that the post-condition in the generic plan, i.e.Patient condition = stable (see Fig. 18), does not match the user's input which is Patient condition = not stable (Fig. 17).Therefore, the process terminates.As a result, the planning system generates the personalized plan as showed in Fig. 19.In the third case, consider the example system interface in Fig. 20.Let us assume that the user does not fulfill the constraint of High blood pressure = yes, the planning system would search the plan repository for a plan fragment which fulfils the user's input.This plan fragment is then retrieved and www.ijacsa.thesai.orgused to replace the one in the generic plan which did not fulfill the user's input.Fig. 21 shows the personalized plan for this case.In general, the generic and personalized plan generation processes performs up to expectation.However, as a limitation of the DP Planner system, these processes would not function fully when a replacement cannot be found in the plan repository.When the system encounters this situation, it will advise the user to refer the case to a medical practitioner.Table 1 shows the comparison between the DP Planner with other planning systems, i.e.Asgaard, O-Plan, Prodigy, STRIPS, PLANET and RAX-PS.From our observation, Asgaard and O-Plan are established planning systems that the DP Planner can be compared to in view that they have the relevant plan ontology, plan representation, as well as the planning engine for their planning system.Further comparisons with Asgaard and O-Plan are discussed in the following subsections.

A. Plan Ontology Definition and Representation
Asgaard was inspired by Belief-Desire-Intention (BDI) model [14] while DP Planner was developed based on Goals-Operators-Method-Selection (GOMS) model.Using the BDI framework, Asgaard has been used to build large-scale, highly capable agent system [15].Therefore, Asgaard is more suited for domains with large and complex but partly vague and incomplete knowledge.In contrast, DP Planner is based on the GOMS framework that has not been used to develop largescale systems.GOMS has been mainly used to represent human knowledge necessary for performing certain tasks and complex human activities.As a result, DP Planner which is based on GOMS is more suited in domains with obvious knowledge, i.e. knowledge that is confirmed and complete, for performing certain tasks and knowledge.
Due to its simplicity, the DP Planner plan ontology was developed without the need for any ontology tool such as Protégé.The DP Planner plan representation in XML is also intuitively easy to understand.Asbru (which is Asgaard's plan representation language) uses a machine-readable language (Backus-Naur Form or BNF syntax) to annotate guidelines based on the task-specific ontology.
Asbru also requires the use of an ontology editor such as Protégé for the acquisition of clinical guidelines based on the same ontology and GMT (Guideline Markup Tool) to translate the guideline into a formal representation written in XML [16].DP Planner's ontology is also easier and simpler compared to O-Plan which has its own detailed ontology structure.The O-Plan plan representation is in Task Formalism form and will change in different O-Plan agents in which it is situated.This is quite complex compared to DP Planner in which the plan representation remains in XML form in any situation.

B. Planning Algorithm Definition
DP Planner generates a generic plan by retrieving an existing plan with similar characteristics to the current planning requirements, and adapting the generic plan by reusing existing plans to produce a personalized plan.This is akin to a casebased approach with adaptation.Asgaard employs a similar approach to DP Planner whereby it also applies plan adaptation in its planning process.
However, the difference is that Asgaard adopts the transformational type of adaptation whereas DP Planner adopts a derivational analogy type followed by the transformational type.Derivational analogy potentially reduces the search space by ignoring the unnecessary choices.This is achieved using the DP Planner's similarity measurement technique.This is only suitable in situations when most of the previous plans require extensive adaptation and when the cost of saving rationale is low [15].The cost of saving rationale here means the ability to fulfill the requirements of a particular plan fragment that was defined as a constraint.However, it presupposes that the derivational traces exist.In contrast, when this is not possible, transformational analogy is the better choice because the plans themselves can be used for adaptation.Thus, in DP Planner, derivational analogy is applied in generic plan generation while transformational analogy is applied in the plan personalization in view that the cost of saving rationale is higher.
In general, Asgaard appears more robust in view that it is a fully deployed system, and that it has a monitoring component which monitors changes to the user's situation, while DP Planner is not a deployed system and therefore relies on users to report any changes.www.ijacsa.thesai.orgO-Plan on the other hand is based on software agents and provides a hierarchical planning architecture to support planning and control with temporal and resource constraint handling [17].O-Plan is also designed as a fully deployed system.O-Plan's architecture shows that it has five major components which are Domain Information, Knowledge Sources, Support Tools, Plan State, and Controller.O-Plan also has the agent architecture since it has a Task Assignment, Planner and Execution agent.
In O-Plan, its plan repair algorithm involves two tables (see Fig. 22): TOME (Table of Multiple Effect), and GOST (Goal Structure Table) [18].An execution failure occurs when one or more of the expected effects at a node-end fail to be asserted.Each effect is recorded in the TOME and when an action depends on an effect asserted earlier, it is recorded in the GOST (Step 1).
When an execution failure occurs, the TOME will be updated and its relation with GOST entries will be found.If it is related with any of the GOST entries, then the Knowledge Sources is used to fix the problem (Step 2).The Knowledge Sources are responsible for determining the consequences of unexpected events or of actions that do not execute as intended, for deciding what action to take when a problem is detected, and for making repairs to the effected plan (Step 3 and 4) [17].When comparing the DP Planner's approach with that of O-Plan, it seems that the DP Planner approach is simpler as only two stages are needed to solve the failure whereas O-Plan requires four stages to solve the failure (see Fig. 23).

VI. FUTURE WORK
Presently, the DP Planner is implemented in a local environment.Its capabilities can be extended further by deploying it in a grid environment with distributed plan repositories and planning engines.For this purpose, the open source Globus Tool Kit can be utilized to allow sharing of computing power, databases and other tools online across corporate, institutional, and geographic boundaries autonomously and safely.The Globus Tool Kit is used in tandem with the Open Grid Services Architecture with Data Access and Integration (OGSADAI) which provides a service group registry that can be used to identify database services that offer specific data tables [19].
In order to communicate with OGSADAI, the DP Planner would potentially require middleware software to communicate with the DBMS which will store the planning data.Fig. 24 shows the OGSADAI with Globus in a possible DP Planner planning scenario.Here, the planning engines and plan repositories are distributed across different locations and each of these planning engines accesses the XML database containing the plan repository (or medical treatment plans) via Xindice (a suggested XML DBMS) while the planning results are delivered through the Client Tool Kit middleware whereby it provides the communication channel between the requesting node and the processing planning engine [20].

VII. CONCLUSION
There are many types of planning systems currently available in the literature though most are static in nature.In this paper, we presented (1) a plan ontology and representation, and (2) a dynamic planning engine which makes use of generic plans and plan fragments, based on our plan ontology, as a planning template.The processing of the planning engine is based on similarity measure, matching, linking, and constraint techniques.In the comparative study carried out, it was observed that the DP Planner possesses features that rival that of other planning systems, in particular that of Asgaard and O-Plan.It is hoped that the DP Planner will make planning initiative more efficient and effective in delivering applicable plans to users especially to healthcare providers and patients.www.ijacsa.thesai.org

Fig. 5
Fig. 5 briefly shows the two phases together with the techniques and approaches used.


Goal: States the target to be achieved. Date: States the date of plan execution (if required). Time: States the duration of plan execution. Constraints: Information of the plan execution limit. Condition: Situations in which the task takes place. Status: Keeps track of the situation of plan execution.Some of the plan component's attributes have detailed subattributes.Examples are as follows:  Date has six sub-attributes: Earliest Date Start (EDS), Latest Date Start (LDS), Earliest Date Over (EDO), Latest Date Over (LDO), Minimum Date Duration (MinDD) and Maximum Date Duration (MaxDD),  Time also has six sub-attributes: Earliest Time Start (ETS), Latest Time Start (LTS), Earliest Time Over (ETO), Latest Time Over (LTO), Minimum Time Duration (MinTD) and Maximum Time Duration (MaxTD).Condition consists of three sub-attributes:

Figure 7 .
Figure 7. Plan representation in XML format.

Figure 9 .
Figure 9.The linking between plan fragments in a plan.

Figure 10 .
Figure 10.The use of constraints in plan personalization.

Figure 11 .
Figure 11.The process of finding the best-matched plan in the plan repository.

Figure 15 .
Figure 15.System interface for inputs which do not fulfill conditions in the generic plan.

Figure 16 .
Figure 16.Personalized plan for inputs which do not fulfill conditions in the generic plan.

Figure 17 .
Figure 17.System interface for inputs which do not fulfill some conditions but fulfill constraints in the generic plan.

Figure 18 .
Figure 18.Generic plan for inputs which do not fulfill some conditions but fulfill constraints in the generic plan.

Figure 19 .
Figure 19.Personalized plan for inputs which do not fufill some conditions but fulfill constraints in the generic plan.

Figure 20 .
Figure 20.System interface for inputs which do not fulfill constraints in the generic plan.

Figure 21 .
Figure 21.Personalized plan for inputs which do not fulfill constraints in the generic plan.

Figure 23 .
Figure 23.Solving execution failure in DP Planner.

Figure 24 .
Figure 24.The DP Planner in a grid computing environment.

TABLE I .
COMPARISON OF DP PLANNER WITH OTHER PLANNING SYSTEMS.