Keywords

1 Introduction

A business process is a collection of activities performed in coordination in order to achieve a particular business goal [8]. Current Business Process Management (BPM) landscape includes methods, techniques and tools developed over the last decades to support the design, analysis, enactment and management of operational business processes. BPM systems are process-aware in the sense that they require an explicit representation of business processes. This feature makes BPM systems very suited to handle structured processes where all the process execution paths are known in advance and captured in the process description. However, while many enterprise applications deal with structured processes, e.g., supply chain management, CRM, etc., there is an increasing number of applications where the underlying business process is unstructured or semi-structured. BPM models and concepts need to be extended to tackle such processes.

As part of the project Plas’O’SoinsFootnote 1, we are interested by the problems underlying the design and management of home care plans. Home care refers to health care or supportive care delivered by health care professionals in patients’ homes. The target objective for social and economic reasons, is to enable people that require care to remain at home instead of having, long-term, stays in hospitals or health care facilities. Several types of care may be provided to persons in their own homes including health services, e.g., hospital-level care, and activity of daily living such as bathing, dressing, using the toilet, etc. These services are delivered by an interdisciplinary care team. A care plan defines all the services provided for a given person and coordinates the involved health care professionals. Such a plan is usually constructed through a complex process involving a comprehensive assessment of patient’s needs (e.g., medical, nursing, social needs) as well as its social and physical environment.

Managing home care plans is challenging for several reasons. First, process modeling in the medical field is in general not an easy task [4]. Indeed, medical processes require usually complex coordination and interdisciplinary cooperation due to involvement of actors from various health care institutions. Moreover, home care plans display the following features that make them difficult to handle with traditional BPM technologies:

  • A home care plan can be viewed as a collection of repetitive activities, (e.g., medical acts) which are repeated during a given period. The activities are however enacted according to an irregular schedule. The irregularities of an activity have two main causes. At first, the activity very often has to follow the evolution of the needs which is usually irregular. This type of irregularity is characterized by strengthening or weakening in the rhythm of realization. Then, an activity which requires human resources has to respect life cycles appropriate to this type of resources and in particular rest time of the weekend. This type of irregularity induces interruptions in the rhythm of the realization. Specification of irregular activities requires the use of suitable temporal constraints.

  • Home care plans are essentially unstructured processes in the sense that each patient has its own specific care plan. Indeed, the care plan for each patient is developed on an individual basis because each patient is unique whether at its pathology or needs. Therefore, it is simply not possible to design a unique process capturing in advance the care plans of all the patients. In other words, a traditional approach “model once, execute many times” is not sustainable in our context.

To tackle the aforementioned problems, we aim in the Plas’O’Soins project at providing a high level specification environment that can be used by end users, in our case typically a medical coordinator, to design patient home care plans. The main features of our approach are described below.

  • the cornerstone of our approach lies in the definition of a DSL (Domain Specific Language), or more specifically a business DSL, tailored to express home care plans using high level abstractions. The proposed DSL is a graphical language which provides basic constructs suitable for home care stakeholders.

  • A supporting environment that enables to translate the produced specifications into a formal language, based on timed automata [2], and provides basic services to support analysis, verification, enactment and management of home care plans.

The paper is organized as follows. Section 2 discusses the difficulties underlying the design of care plans and presents the proposed DSL. Section 3 describes preliminary results regarding mapping of DSL-based specifications into timed automata and discusses automatic verification and monitoring of care plans in the proposed framework. We conclude and draw future research directions in Sect. 4.

2 A DSL-Based Approach for Specifying Care Plans

The design of a care plan is a complex collaborative process, managed by a primary medical coordinator and carried out by an interdisciplinary team. In order to understand such a design process and also to understand how a medical coordinator approaches the problem, we conducted in the context of the Plas’O’Soins project a thorough on-sites analysis of current practices in the field of home care. In particular, we carried out interviews with different professionals of home care institutions and we realized several analysis of key documents and procedures. This study showed the central role played by care plans as primary components of effective care coordination in patient’s home. In a nutshell, a care plan encompasses all the services provided for a given patient and is essential to schedule the delivery of such services in the patient’s home by health care professionals. More precisely, a care plan can be viewed as a collection of repetitive activities to be delivered to a given patient. An activity corresponds to a health care or a supportive care which is associated with temporal constraints (e.g., an irregular frequency) and to a required qualification (a nurse, a nurse auxiliary, etc). Table 1 shows a simple example of a content of a care plan for a given patient.

This example illustrates some important concepts of a care plan. The first column of Table 1 shows the period in which this plan is valid while the column Activity give the activities included in the plan (e.g., toilet, dress, injection). For each activity, the following information are given: (i) temporal constraints associated with the activity and expressed in terms of a Time slot (e.g., morning, afternoon or evening) and Repetition (e.g., every day except sunday), and (ii) the required qualification to carry out the activity (e.g., nurse auxiliary, nurse). Irregular activities are inherent to care plans. For example, a given activity, e.g., “toilet”, may be associated with complex temporal constraints, e.g., every two days except Sunday evening. Activities are then grouped together within interventions which are then performed in a rotating schedule in accordance with the specifications of the care plan.

Table 1. Excerpt of a care plan content.

From our analysis, it appears appropriate to provide tools to assist as much as possible the medical coordinator in the design of individual care plans as well as automated support for verification of the plans and monitoring of their executions. This is why in the Plas’O’Soins project, we propose a user-centeric approach based on a DSL.

2.1 A Domain Specific Language for Home Care Plans

A domain specific language (DSL) is a language designed to express a solution to a problem within a specific domain [7]. A DSL can be tailored to a business or industry domain. While DSLs have already been used to some extent in the fields of computer science and mathematics [6], their use in the health care domain is less widespread. We describe below the main concepts of a DSL tailored to express home care plans. The proposed DSL provides high level abstractions that can be used by a care coordinator to design a care plan for a given patient.

The main building block in a care plan is the notion of activity. An activity denotes a medical or a social service provided to persons in their own homes. The proposed DSL includes several predefined activities identified by our analysis of the application domain. Examples of predefined activities are:

  • Health services: monitor medications, drug injection, aftercare, etc.

  • Activities of daily living: bathing, assist with meal planning and preparation, dressing, maintain clean household, etc.

Each activity is associated with a description which provide additional information about the activity. In particular, a description of an activity includes the required qualification of the actors that are allowed to carry out the activity as well as the temporal constraints that specify when the activity must take place. More precisely, a temporal constraint is expressed as a triplet (Period, Days, Time ranges), where:

  • Period specifies the time period during which the activity is defined.

  • Days indicates the days within a period in which an activity must take place.

  • Time ranges indicates the time slots in which the activity can occur.

Figure 1 shows the formal expression of this triplet using the BNF ( Backus-Naur Form). Several triplets can be associated to a same activity in order to permit the specification of irregularities and exceptions. Triplet is the basic component of a general declarative language that we have proposed for specifying near regular repetition of activities [3].

Fig. 1.
figure 1

Formal expression for temporal properties.

Fig. 2.
figure 2

Example of the graphical user interface.

An appropriate external representation of the care plan is crucial to facilitate the work of the coordinator. Figure 2 shows the current GUI (Graphical User Interface) developed to support a coordinator in designing a care plan using the proposed DSL.

In addition to the notion of activity, another important concept of the DSL lies in the notion of Intervention. An intervention is a collection of activities that can be scheduled together. Interventions are defined by grouping together the activities that can be performed by a same professional and which occur in the same time range. Interventions may be specified manually by the coordinator or computed automatically from the specifications of the activities and then proposed to the coordinator for validation. Figure 3 shows the GUI corresponding to the interventions.

Besides the aforementioned concepts, the proposed DSL is enriched with additional constraints derived from the domain knowledge (e.g., medical knowledge represented in ontologies, etc). For example, various types of dependencies between activities may exist such as:

Fig. 3.
figure 3

GUI for predictive interventions.

  • Obligation to perform a given activity in a time period after a first one. For example, “a Lovenox injection must be followed by a blood test within a time limit of one week”.

  • Exclusion of an activity in a given period. For example, “a minimum of 12 h is requested between two insulin injections”.

2.2 Analysis and Monitoring of Care Plans

Once care plans are constructed using the DSL, they can be exploited for various purposes, as discussed below.

Static analysis of care plans. Such an analysis is performed at the design time, i.e., without actually executing the care plans, and targets the verification of various types of properties, such as:

  • Care plans verification. This analysis takes place within a specific care plan and aims at checking all the possible run-time errors that may occur in the considered plan. For example, it is important to check the realizability of a care plan, i.e., to check whether or not the activities included in the plan can be effectively scheduled and performed according to the constraints specified in the plan.

  • Interventions verification. This analysis takes into account interactions between the temporal constraints of an intervention and the constraints of the activities included in the considered intervention. For example, if an activity \(A\) appears in intervention \(I\), then it is worth to check whether the temporal constraints of \(A\) are compatible with those of \(I\).

  • Consistency verification. In some cases a specification must satisfy some dependencies between activities. For example, “a Lovenox injection must be followed by a blood test within a time limit of one week” or “a minimum of 12 h is requested between two insulin injections”. Indeed, a dependency between two activities entails dependencies between the corresponding Interventions. Hence, the verification of consistency must be extended to interventions.

  • Compatibility verification. This analysis takes into account the patient agenda in order to avoid to schedule activities in time slots in which the patient is not available.

Monitoring of care plans executions. This analysis is performed at execution time. Note that most of the activities of a care plan are manual, i.e., performed manually by professionals. In current state of affairs, the activities that have been performed are often recorded manually on paper. Our goal is to enable electronic recording of executed activities in order to keep track of the execution traces of care plans. Such information can then be used to monitor care plans. For example, compliance of executions traces w.r.t. a care plan may be checked in order to detect the executions that do not satisfy the constraints specified in the considered care plan. For instance, checking that for every execution which contains an activity Lovenox injection there is also an activity Blood test which follows Lovenox injection activity after one week. Also, the monitoring system may be used to lunch alerts to avoid an actual executions to deviate from the specification. For example, in a running care plan, if the activity Lovenox injection is executed then the monitoring system may require the execution of the activity Blood test (e.g., an alert is lunched one week after the Lovenox Injection activity is executed).

Therefore, formal verification of care plans is a crucial problem. To enable automatic verification, it is then essential to map the DSL concepts into a formal model. In our approach we use timed automata [2] to formally describe care plan constructed using the DSL and then we rely on the large body of theoretical results and existing implemented systems for this class of automata in order to support verification and monitoring of care plans.

3 A Formal Framework Based on Timed Automata

This section first recalls some basic notion from the theory of timed automata then it illustrates the mapping of care plans into timed automata and discusses the benefits of the proposed approach.

3.1 Timed Automata: Basic Notions

Timed automata were introduced in [1, 2] as an extension of finite state automata that enables explicit modeling of time. Informally, a timed automata is a finite state automaton enriched with clock variables. Moreover, transitions of timed automata are annotated with guards, expressed as time constraints, and clock resets. Several variants of timed automata have been proposed in the literature. We consider in this paper timed automata with \(\epsilon \)-transition (i.e., silent transitions) and also guards on the states, also called invariants. As an example, Fig. 4 depicts timed automata that is made of two states \(s_0\) and \(s_1\) and the clock variable x. this automaton includes a transition labeled \(\mathsf {Toilet}\) from state \(s_0\) to \(s_1\) which is guarded by the condition \(\mathsf {x >= 8h}\) as well as \(\epsilon \)-transition from state \(s_1\) to \(s_0\) which is guarded by condition \(\mathsf {x == 24h}\).

Fig. 4.
figure 4

Example of a timed automaton

Definition 1

(Timed automata). A timed automata is a tuple\(A= (S, s_0, \varSigma , X, Inv, T, F)\) where:

  • \(S\) is a finite set of locations or states of the automaton and \(F \subseteq S\) is set of final states,

  • \(s_0 \subseteq S\) is a set of initial locations,

  • \(\varSigma \) is a finite set of transition labels,

  • X is a finite set of clocks,

  • Inv: \(S \rightarrow \phi \textit{(}X\textit{)}\) associates an invariant to each state of the automaton,

  • \(T \subseteq S \times \varSigma \cup \{\epsilon \} \times \phi (X) \times 2^X \times S\) is a set of transitions. A transition (s, a, \(\phi \), \(\lambda \), \(s^{'}\)) represents an edge from location s to location \(s^{'}\) on symbol a. \(\phi \) is a clock constraint, and the set \(\lambda \subseteq X\) gives the clocks to be reset after firing such a transition.

A timed automaton recognizes timed words. Informally, given an alphabet \(\varSigma \), a timed word is a sequence \((\mathsf {a_0}, t_0), \ldots , (\mathsf {a_n}, t_n)\) where the \(a_i\)s belongs to \(\varSigma \) and the occurrence of times increase monotonically, i.e., \(t_0 \le t_1 \le \ldots \le t_n\). As an example, the sequence of activities \((Toilet, 10) \cdot (Toilet, 35) \cdot (Toilet, 59)\) is an execution which is accepted by the automata \(A_{Toilet}\) of Fig. 5 while the timed word \((Toilet, 6) \cdot (Toilet, 35) \cdot (Toilet, 59)\) is not recognized by this automaton.

3.2 Mapping Care Plans into Timed Automata

In this section we illustrate on an example our approach to map care plans constructed using the proposed DSL into timed automata. We propose a two steps approach which works as follows: (i) first, basic activities of a care plan are translated into timed automata, then (ii) a global care plan is generated by composition of the components.

Mapping of basic activities. Each activity \(a\) of a care plan is mapped into a timed automaton \(A_a\). The construction of \(A_a\) depends on the specification of the activity \(a\) and in particular its associated time constraints. We explain the mapping of a basic activity into a timed automaton using a simple example. Consider the following specification of a basic activity:

  • Activity name: \(Toilet\)

  • Days: Everyday.

  • Time range: Morning.

  • Period: \([06/10/2013-06/30/2013]\).

Fig. 5.
figure 5

The result of the mapping of the basic activities of the care plan

The corresponding timed automata \(A_{Toilet}{=}\!(S, s_0, \varSigma , X, Inv, T, F\!)\), depicted at Fig. 5, is defined as follows:

  • \(S=\{s^1_0, s^1_1, s^1_2 \}\) is the set of states with \(s^1_0\) the initial state of \(A_{Toilet}\).

  • \(F=\{ s^1_2 \}\) is the set of final states,

  • \(\varSigma =\{ Toilet \} \cup \{\epsilon \}\) is the set of transition labels,

  • \(X=\{x_d, x_p \}\) is the set of variables where the variable \(x_d\) is used to measure the flow of time during a day and \(x_p\) is the variable used to control the whole period. The variables \(x_d\) and \(x_p\) are expressed using as time unit the hour,

  • \(T\) is the set of the following transitions:

    • \((s^1_0, Toilet ,x_d \ge 8, \emptyset , s^1_1 )\), this transition specifies that when the automaton is at state \(s_0\), it can moves to state \(s_1\) upon the execution of the activity \(Toilet\). The conjunction of the state invariant \(x_d \le 12\) at \(s^1_0\) and the transition guard \(x_d \ge 8\) ensure that the activity \(Toilet\) can be performed only in the morning (i.e., when the value of \(x_d\) is between \(8\) and \(12\)).

    • \((s^1_1, \epsilon , x_d==24 \wedge x_p \le 480, \{ x_d\}, s^1_0)\), this transition enables the automaton to move back from \(s^1_1\) to \(s^1_0\), without performing any activity, at the end of the day (i.e., when \(x_d\) equals to \(24\)) within the specified period (i.e., \(x_p < 480\)). Upon this transition, the variable \(x_d\) is reset to \(0\) to record the beginning of a new day.

    • \((s^1_1, \epsilon , x_p == 480, \emptyset , s^1_2)\), this transition is fired at the end of the period (i.e., when \(x_p\) equals to \(480\)) and it enables the automaton to move to the final state \(s^1_2\) and terminate the execution.

In addition to the automaton \(A_{Toilet}\), Fig. 5 shows the following two additional automata constructed in a similar way:

  • The timed automaton \(A_{Injection}\) corresponding to the activity “Injection every two days at 9 am from 06/10/13 to 06/30/13”, and

  • The timed automaton \(A_{Dress}\) corresponding to the activity “Dress on Monday and Wednesday evening from 06/10/13 to 06/30/13”.

Care plan generation from activities automata. The second step consists in generating automatically the whole care plan from the basic activities. Interestingly, the care plan can be also described by means of a timed automata which is obtained by composition of automata representing basic activities that have been generated in the first step. The composition is achieved using the asynchronous product of activities automata which allow us to recognize all possible configurations of the care plan. We recall below the definition of asynchronous product (or shuffle) of timed automata.

Definition 2

(Shuffle of timed automata). Let \(A_1 = \textit{(}S_1, s^1_0, \varSigma _1, X_1, Inv_1, T_1\textit{)}\) and \(A_2 = \textit{(}S_2, s^2_0, \varSigma _2, X_2, Inv_2, T_2\textit{)}\) be two timed automata. The product of \(A_1\) and \(A_2\), denoted \(A_1 \times A_2\), is the timed automata (\(S_1 \times S_2, s^1_0 \times s^2_0, \varSigma _1 \cup \varSigma _2, X_1 \cup X_2, Inv, T\)), where Inv \(\textit{(}S_1, S_2\textit{)} = Inv \textit{(}S_1\textit{)} \wedge \) Inv \(\textit{(}S_2\textit{)}\) and the transition function T is defined as follows: \(T = \{\textit{((}s_1, s_2\textit{)}, a, \phi , \lambda , \textit{(}s'_1, s'_2\textit{)): ((}s_1, a, \phi _1, \lambda _1, s'_1\textit{)} \in T_1 and s_2 = s'_2 \textit{)} \,or\, \textit{(}s_2, a, \phi _2, \lambda _2, s'_2\textit{)} \in T_2\, and \,s_1 = s'_1\textit{)}\}\).

Figure 6 shows the product of the automata \(A_{Toilet}\) and \(A_{Injection}\) of Fig. 5. The resulting automata encompasses all the possible schedules of the activities \(Toilet\) and \(Injection\).

3.3 Formal Aanalysis of Care Plans Using Timed Automata

With a formal model describing the behavior of care plans at hand, it becomes now possible to handle automatic verification and monitoring of care plans. We discuss below how the proposed framework can be used to automate generation of Interventions and verification and monitoring of care plans.

Fig. 6.
figure 6

Intervention of every day morning from 06/10/13 to 06/30/13”

  • Automatic generation of candidate interventions automata. Given a time specification \(T\), we may want to generate the interventions corresponding to \(T\). The specification \(T\) may be defined as a precise time range (eg. Intervention of the morning, intervention of the evening, etc.), a combination of days and time ranges (eg. Intervention of the Monday morning, Wednesday afternoon, etc.) or a combination of time ranges, days and period (eg. Interventions of every Monday morning from 03/10/13 to 30/10/13, etc.). Candidate interventions are generated automatically using a composition of activity automata projected on the time specification \(T\). For example, Fig. 6 depicts an automaton representing an intervention that is carried out every day, morning, from 06/10/2013 to 06/30/2013. This automaton is obtained by first projecting the activity automata \(A_{Toilet}\) and \(A_{Injection}\) of Fig. 5 with respect the appropriate time specification (i.e., Time range = morning, Days = every day and Period =[06/10/2013-06/30/2013]) and then computing the asynchronous product of the result.

  • Care plan verification. For example, checking realizability of a care plan can be reduced to the emptiness problem of the corresponding automaton.

  • Intervention verification. Intervention are formally described as automata (in the same spirit of the previous mapping). Then intervention verification is achieved by checking the emptiness of the intersection of the activity automata with the intervention automata.

  • Consistency verification. Dependencies are expressed as automata and then consistency checking is formulated as a composition of interventions automata with a dependency automata.

  • Monitoring. Checking compliance of executions traces can be reduced to language recognition in timed automata. Moreover, it is possible to extend the proposed automata to manage alarms. For example, a care plan automata can be used to enforce that an alarm has to be activated one week after a Lovenox Injection has been performed.

4 Discussion

We described in this paper an ongoing research work devoted to the design of a DSL-based approach for specifying and monitoring (home) care plans. This work lies at the junction of two disciplines, computer science and medicine, and thereby it requires an active cooperation between the two communities. Care plans are inherently unstructured processes. This is due to the specificity of each patient, i.e., a specific care plan is required for each specific patient, as well as to the irregularity of repetitive activities within a plan. Nevertheless, we showed that using appropriate temporal expressions it is possible to specify the schedule of such activities. The obtained specification plays the role of a process model that must be enacted by a business process management or a workflow system. A detailed presentation of the temporal expressions used to specify the repetition of activities with irregularities is given in [3]. Curiously, few works were interested in this problem. A model closed to ours is proposed in [5]. However, in that model the repetitions are expressed trough a procedural language.

We rest on a formal framework based on timed automata to formally describe the care plans constructed using the proposed DSL. Our proposal includes in particular the representation of basic activities as timed automata and then the construction of a global care plan and specific interventions using operators, mainly composition and projection, on such automata. The paper discusses also how the proposed framework can be used for automatic verification of care plans and for monitoring their executions. Our future research directions will be devoted to the development of the theoretical framework based on timed automata. Our preliminary results pave the way for a more detailed exploration of the benefit of using formal verification and model checking techniques in our context.