Design and Execution of Integrated Clinical Pathway: A Simplified Meta-Model and Associated Methodology

Abstract

Integrated clinical pathways (ICPs) are task-oriented care plans detailing the essential steps of the therapeutic pathway referring to a specific clinical problem with a patient’s expected clinical course. ICPs represent an effective tool for resource management in the public and private health domains. To be automatically executed, the ICP process has to be described by means of complex general purpose description language (GPDL) formalisms. However, GPDLs make the process model difficult to grasp by a human. On the other hand, the adoption of a reduced set of graphical constructs prevents a fully automated process execution due to the lack of information required by a machine. Unfortunately, it is difficult to find a balance between modelling language expressiveness and the automated execution of the modelled processes. In this paper, we present a meta-model based on a GPDL to organize the ICP process knowledge. This meta-model allows the management of ICP information in a way that is independent from the graphic representation of the adopted modelling standard. We also propose a general framework and a methodology that aim to guarantee a high degree of automation in process execution. In particular, the corresponding execution engine is implemented as a chatbot (integrated with social media), which plays a two-fold role: during the actual execution of the entire ICP, it acts as a virtual assistant and gathers the patient’s health data. Tests performed on a real ICP showed that, thanks to the proposed solution, the chatbot engine is able to engage in a dialogue with the patient. We provide discussion about how the system could be extended and how it could be seen as an alternative to Artificial Intelligence (AI) and Natural Language Processing (NLP)-based approaches.

1. Introduction

In the last two decades, there has been a growing interest in investigating the correlations existing between the funds spent in private/public health care and the actual quality of medical care services, as perceived by the citizens accessing them [1]. This issue, known as disease management, is defined as the complex decision-making process aiming to determine a programme of coordinated healthcare interventions, with the aim of minimizing both the healthcare costs and the effects of disease on individuals. Moreover, thanks to the numerous studies in the field of artificial intelligence applied to the medical and biomedical field, we now have many additional tools to support specialists in their tasks [2,3,4,5,6]. A growing benefit is also provided thanks to the spread of fast network connections allowing the exchange of large amounts of clinical data, also useful for remote diagnosis or follow up [7,8]. Many devices will interact with the surrounding environment and users. Many of these devices will exploit machine learning models to decode the meaning and behavior behind sensors’ data, to implement accurate predictions and make decisions.

Clinical domain stakeholders (doctors, nurses, health managers, etc.) agree that, once a disease is diagnosed, the corresponding clinical activities must be framed in a well-defined process. This systematic approach not only improves the outcomes but also optimizes the resources, avoiding an unnecessary waste of time, redundant activities and overlapping responsibilities [9]. One of the main approaches in this clinical area is the Integrated Care Pathway (ICP) [10]. It is worth noting that the medical community has not yet adopted a unique international standard approach for ICP process modelling. Nevertheless, one can assert that an ICP is typically described by clinicians as a flow chart, which requires a very simple set of symbols for modelling tasks and conditions.

A modelling language aiming to capture all the details of the process is not only difficult to learn but also not required by clinical stakeholders. In fact, as seen in Figure 1, an ICP can be described through two graphical symbols (boxes and arrows) and hyperlinked for tasks details or Evidence Based Medicine (EBM).

Nevertheless, a higher number of graphical elements in a process-modelling language is mandatory when a machine-readable execution phase is required. Unfortunately, it is difficult to find a balance between modelling language expressiveness and the automated execution of the modelled processes.

To date, research has focused more on finding solutions to the machine-executability issue of the ICP process, acting on the design language [12,13]. This approach resulted in an increase in the complexity of the process graphical representation, which, in turn, became an obstacle to the adoption of the proposed solutions.

In this paper, we will show that it is possible to explore new possibilities by acting on the representation of the process knowledge, independently from the language adopted for the process design.

We aim to provide a method for obtaining a machine executable ICP. The proposed method is based on the definition of a meta-model that maps the process knowledge. Such a meta-model is first processed through a methodology consisting of six-steps. Then, the processed meta-model is used by a chatbot engine to carry out the automatic execution of the ICP process. The proposed method does not require the adoption of a complex process-modelling language by the medical community.

The paper is organized as follows. Section 2 reports the main literature related to our research work. Section 3 illustrates a proposal of a simplified meta-model for knowledge process management. Section 4 reports a strategy for ICP execution, an architecture for implementing the execution engine as a social media chat-bot and the related methodology. Section 5 discusses the results. Section 6 reports conclusions and outlines some future research work.

2. Theoretical Background

The methodologies for modelling a process are quite consolidated [14]. However, in the healthcare domain, they are scarcely adopted for designing, integrating and managing processes.

Business process modelling methods (BPMMs) can be used to model an ICP [15]. Most BPMMs have high effectiveness in terms of human-to-human communication and ease of understanding but are very far from a machine-executable [16] process description.

Flowcharts, which are well known sets of graphic symbols aiming to describe a sequence of operations, can serve as a graphical means for communicating from one person to another the time-ordering of events or actions. An EPC (event-driven process chain) has the same purpose and is used in several application contexts for modelling, analysing and redesigning business processes. A recent review [16] showed how an EPC provides adequate approaches and tools for modelling and verifying simple business requirements through atomic events.

None of the abovementioned formalisms provide enough detail to allow the machine execution of a process model; however, they are effective for human-intelligible models. The idea of the adoption of a meta-model associated with a set of graphical symbols is not new in the literature. One of the best known process description languages is the Business Process Modeling Notation (BPMN2.0) language [17,18], which provides a graphical representation for specifying business processes in a business process model. Version 2.0 consists of two main parts: the graphical symbols and their representation in the meta-model, a UML Class diagram that shows all the relationships among entities. The BPMN2.0 [19] reference documentation also includes a set of classes useful for extending the standard with new symbols according to some specific domain requirements not available in the basic language. Thanks to this extension potentiality, many authors have proposed new features for including objects significant for clinical pathway design in BMPN2.0. Stroppi et al. introduced a general method for BPMN2.0 extension, which represents a reference methodology [13]. A time role taxonomy, popular in most business processes, was proposed by Arevalo et al. [20], while Braun et al. [21,22,23] proposed various BMPN2.0 extensions in order to best match clinical pathway process requirements.

Table 1. Use modality and corresponding classes in the BPMN2.0 meta-model.

BPMN2.0 Use Modality	Class in the Meta-Model
Simple	start, end, task, sequence flow, AND, OR, subprocess
Descriptive	add task types, event types, swim lanes, message flows, data objects
Analytic	full enterprise architecture modelling
Executable	complete set for executable models

reports the level of use defined by the standard and the corresponding classes in the meta-model. BPMN2.0 provides a detailed meta-model for machine execution, but unfortunately, it is too complex for humans. The model describing a process can be automatically executed by a machine only if all the constructs provided by the meta-model specified in the standard are used, i.e., the Executable level also implies compliance with the Simple, Descriptive and Analytic levels. This is necessary in order to allow a machine to update the status of a process instance as it is being executed. Therefore, the process description must include information from all the classes of the underlying layers: Simple, Descriptive and Analytic.

This means that, if we need to model a machine-executable process, the language has a high level of complexity, while if the aim is only to communicate to a human the main phases of the process, the complexity is low, but its execution by machines is not possible.

The IDEFx (Integration Definition for Function Modelling) [24] language family was created for industrial purposes. In particular, the IDEF0 formalism is very effective in terms of process human-understanding and so is most used for BPR (business process reengineering). The basic construct includes a box that defines the process and a set of flows useful for giving information about input, output, resources and constraints along the process. IDEFx is also used for clinical pathway process design [25].

Investing in process modelling languages seems to be unprofitable in balancing complexity and executability. An alternative way is to provide a simplified Business Process Definition Metamodel (BPDM) [26] that organizes the knowledge of the process by delegating the burden of executability to a dedicated module such as a chatbot engine.

Today, the strategy of using Business Process Management (BPM) [27], integrated with conversational agents, in order to guide patients in a structured way in the healthcare domain represents a novel trend for exploration [28].

As stated in [29], there are two main research streams investigating the dialogue management of chatbots in healthcare. The former uses AI for generating sentences. The latter deals with a scripted chatbot, based on giving structured answers to frequently asked questions.

We propose a conversational agent aiming to follow a given clinical pathway, modelled as a codified goal (the clinical outcome) to be achieved through a process. Conversational agents that have this kind of behavior are referred to as task-oriented chatbots. In [30], human–chatbot conversations are demanded to a conversational state machine. A similar approach is proposed by the authors in [31], where the behavior of the chatbot is mapped on a process graph and behaves according to a finite state machine. It is necessary to underline that in both cases, the state of the system is stored in metadata associated with the nodes of the process graph. The chatbot engine selects the next tasks to be performed, by analyzing the status information and external events. Recently, the authors in [32] proposed a methodology for automatically converting a BPMN designed process into a data structure executable through a chatbot. The proposed method (which partially shares with ours the process graph normalization phase) uses NLP techniques to generate chatbot sentences in response to requests from a user who is following the process tasks.

In most contributions, the chatbot is in charge of understanding how to formulate the answer. This justifies the use of methodologies and technologies related to the AI and NLP domain [33]. Recently, in [34], the authors pointed out that NLP techniques are adopted by a low percentage of the 100 most popular Facebook Messenger chatbots.

In order to provide a framework of the benchmark for the proposed task-oriented chatbot,

Table 2. Most popular chatbots in heathcare domain.

Chatbot Name	Main Functions	Underlying Methodology and/or Technology	References
SafedrugBot	Helps doctor access right information about drug dosage; breastfeeding pathway assistant	It retrieves information from open data dataset	[35]
Florence chatbot	Reminds patients to take pills; tracks body weight, tracks moods; finds a doctor or pharmacy nearby	AI and machine learning	[36]
IBM Watson	Symptom checker, analyzes high volumes of data, understands complex questions posed in natural language, and proposes EBM answers	AI, natural conversation, deep learning techniques to derive question’s intent	[37]
Izzy	Helps women track periods; provides information on the user’s sexual issues and menstrual health	Conversational agent	[38]
Forksy	Tracks calories; promotes healthy eating habits	Automated feedback powered by AI technology	[39]
Babylon Health	Remote consultation with healthcare professionals and doctors; patient’s medical database; symptom checker	Consultation driven by AI Probabilistic Graph Model with nodes annotated by medical ontologies (Snomed, NCI)	[40,41]
Buoy Health	Assists patients in diagnosis	AI for diagnoses. Algorithm was trained on clinical data from over 18,000 clinical papers	[42,43]
CancerChatbot	Offers detailed information on cancer and related topics	NLP, flow dedicated to training supporters in how to talk to a cancer patient and how to be helpful	[44]
Sensely	Tracks health symptoms using both text and speech communication; diagnosis formulation	AI to recommend diagnoses based on patient symptoms	[45]
GYANT	Symptom checker	Artificial intelligence-enabled platform, machine-learning intelligence, physician oversight	[46]
Woebot	Studies patient mood and personality and suggests remedies as a therapist for the depression	Artificially intelligent chatbot designed from simulating human cognitive-behavioral therapy (CBT)	[47,48,49]
HealthTap	Vast repository of knowledge available to patients	AI; question prompts to submit symptoms	[50]
Your.Md	Symptom checker	AI and machine learning. It constructs a Bayesian network with massive medical knowledge to compute the most likely cause of an indisposition	[51]
Ada Health	Symptom checker; analyzes patient-related data, past medical history, symptoms and risk factors	AI-based database, machine learning	[52]
Infermedica	Symptom checker through natural language processing, using chat (text) and images	AI and machine learning, automated generation of Bayesian network models	[53]
Bots4Health	Sexual and reproductive health; chats about a wide range of health issues	Conversational interfaces, Chatfuel and Dialogflow NLP API	[54]
eMMA	Electronic medication assistant, clinical data repository	ConversationAl user interface (CUI), query mode answer retrieval by key words	[55]

. Most popular chatbots in heathcare domain. Table 2 shows the most popular task-oriented chatbots along with the underlying technologies/methodologies.

3. A Simplified Meta-Model for Process Knowledge Management

In this section, a simplified meta-model for process information management that is compliant with most GPDLs is proposed. This means that the knowledge contained in the graphical model of the ICP process realized by means of a GPDL can easily flow into the meta-model. The meta-model is defined according to two steps.

The first step is to define the domain by means of an enhanced entity relationship (EER) model [56]; the EER data model for ICP process templates and related process instances is shown in Figure 2.

It should be noted that the proposed EER model is general since it can be applied to any application domain where it is necessary to design and execute a process. The verticalization of the meta-model on the domain is accomplished through the appropriate definition of the set of attributes inserted in node_data, which, in our case, concerns ICPs. To achieve a low-complexity end result, an interesting methodology also proposed for the simplification of BPMN has been used [57].

The EER data model has to take into account the following criteria:

• The number of constructs of the process model must be not too large.
• Features that can be derived from the context of an element of the model should not lead to the definition of specialized subtypes.
• Features that may evolve during the lifecycle of an element should be represented as properties, not as types.
• Multi-dimensional classification is more efficiently represented by properties than by types.
• Pure notational differences should not be reflected in the data model.

To apply the meta-model for the execution of process designed for the management of clinical pathways, it is necessary to verify that some requirements are met:

• Req. 01: The data model must map the complete process structure.
• Req. 02: When a patient enters in a clinical pathway, the related process instance has to be assigned to him/her.
• Req. 03: The data model should contain the clinical pathway process template and its instances when assigned to a specific patient.
• Req. 04: It is necessary to track and/or reconstruct all the documentation that belongs to each task for the specific clinical pathway process instance.
• Req. 05: The data model should contain information about the costs that belong to each phase/task of the process.
• Req. 06: The data model should include the minimal set of process descriptors such as task sequences, parallel flow, iterations, conditions and events.
• Req. 07: It is mandatory to assign responsibility to each task.
• Req. 08: It is mandatory to track timing perspective information about each task.

The EER reported in Figure 2 has to be developed taking into account the requirements listed above as well as the following assumptions:

Assumption 1: The process concept is mapped in an oriented graph in which each node could be a TASK, a CONDITION, a PARALLEL execution or an EVENT.

Assumption 2: A process template is obtained by using the self-relationship Father applied to the entity PROCESS_NODE.

Assumption 3: A process instance is obtained through the relationship has_for_instance that represents the link between the process node in the template and the execution tokens inside an instance.

Assumption 4: A Type attribute in the PROCESS_NODE entity is set to:

• “TR”: If the node is a Template Root.
• “IR”: If the node is an Instance Root.
• “PN”: If the node is a template Process Node.
• “LN”: If the node is a Log Node (these are events related to tasks performed but not planned in the template process).

Assumption 5: If a node does not have a child node, then the node is an end node of a clinical pathway template.

Assumption 6: If the process presents a condition flow, then the related graph structure is fed by a node for any condition that might occur, as shown in Figure 3. Condition flow instances, oriented graph and self-relationship values where S and E are the start and the end nodes. The same logic is used for nodes that start a process sequence in parallel.

Assumption 7: In order to give information on financial and economic impacts, each task is characterized by the cost of the included actions (COST_ACTION); each type of cost is classified into categories (BRANCH).

Assumption 8: Different SUBJECTs can be assigned to each task with different responsibilities.

Assumption 9: The INPUT_OUTPUT entity contains information about what a task needs to be performed and what an instance task will produce. When an output is generated, all the documentation about it is stored as a RESOURCE.

Assumption 10: EACH task of a specific process instance assigned to a patient may have many execution states: “NOT_EXECUTED” (assigned by default to a task), “IN_EXECUTION” (started at a specific date/time but not finished) or “EXECUTED” (has started at a specific date/time and finished at a specific date/time). The cardinality of the relation between TASK and EXECUTION_TOKEN shows that a task could be executed many times, such as when medical consultations or clinical examinations are repeated.

Assumption 11: The amount of waiting time to be waited between one task and the next one is expressed as the weight of the oriented arc in the process graph, thanks to the attributes of the relation father Time_delay_quantity and Time_delay_unit.

Details of specific attributes assigned to each entity have been omitted from the EER diagram. The attributes are linked to the application domain (in our case, the ICP) and to the levels of executability that we want to give to the process and will be extremely detailed if the execution is delegated to a machine, while it is possible to remain at a higher level if the executor is a human. We will address this specific issue later.

Table 3. Mapping between process design standards and entities in the proposed meta-model.

Process Design Standard	Entity in the Data Model
IDEF0	PROCESS_NODE, TASK, INPUT, OUTPUT
FLOW CHART	PROCESS_NODE, TASK, CONDITION, INPUT, OUTPUT
UML ACTIVITY DIAGRAM	PROCESS_NODE, TASK, SUBJECT, CONDITION, INPUT, OUTPUT
EPC	PROCESS_NODE, TASK, CONDITION, EVENT, INPUT, OUTPUT
BPMN 2.0	PROCESS_NODE, EVENT, TASK, SUBJECT, CONDITION, INPUT, OUTPUT

shows the mapping between the most used process design methods entities and the proposed meta-model.

The second steps of the meta-model definition consist of representing the EER data model in terms of a UML class diagram. Figure 4 shows the UML classes designed for process data management by applications.

4. ICP Process Execution Assisted by a Chatbot

4.1. ICP Execution: What Really Matters

In the application context of ICPs, the concept of “process execution” is not meant as fully automated execution: physicians and nurses are not robots. On the other hand, there is the need to encode a pathway validated by clinical evidence to determine all the required resources with the goal of maximizing the outcomes.

The role of the clinicians in an ICP is fundamental since each case has its own unique characteristics and must be treated according to “conscience and medical competence”. Therefore, the concept of “process execution” for a model should have the characteristic of a high level of discretion by professional stakeholders who must cooperate to minimize conflicts and maximize results.

The research domain dealing with this kind of interaction is referred to as a computer-supported cooperative work (CSCW) [58] in which technology intervenes not to govern every micro-stage of the process but to perform the following classes of tasks:

• Proactively involving the patient at every stage of the process.
• Suggesting what the next step to be performed is (meaning to govern the state of the process).
• Making teamwork agile.
• Eliminating redundancies.
• Reducing conflicts.
• Suggesting actions that will reduce costs and still have the same outcome.
• Optimizing the use of resources.

The execution of a process that encodes an ICP is successful if it is entrusted to a chatbot [59] able to interact with stakeholders through mechanisms included in social media. The user is comforted by the impression of interacting with a person, while on the other side of the “virtual wall”, an “intelligent” software exploits the process data contained in the meta-model to interact with the user through informal and easily understandable language.

4.2. ICP Execution Strategy

Looking closely at the meta-model that contains the information about the process previously described, it is clear that the level of detail of the process data is not suitable to allow a complete execution by a machine. To make the process executable according to the meta-model proposed in Figure 1, it is necessary to carry out the following activities:

• Assigning a clinical path template to a patient.
• Continuously monitoring the process status.
• Automating the status changes for each task in the process.
• Identifying actions that deviate from the standard path.
• Proposing or suggesting future actions envisaged by the standard route.
• Reminding those responsible for task execution and possibly making them aware of delays.
• Asking for feedback on the state of task execution.
• Asking for feedback on the quality of the template process, in order to improve it.
• Sharing results both at the task level and at the process level as a whole.

The chatbot’s role is to lead the patient to provide information useful for determining a change in state in the clinical process instance. To conduct the dialogue with the patient, the chatbot uses some sentences contained in the process template.

The proposed process execution strategy is to allow a chatbot to access the topological structure of the template process, stored into the meta-model, and use it to start a conversation with the user that aims to advance the status of the process instance associated with the user. In particular, the chatbot will have the following behaviors:

Task Sequence (Figure 5).

The chatbot uses a PROCESS_NODE attribute called patient description, which contains a description of the task to be performed. In this case, the task can be one of the following:

-

Informative task: A task that aims to provide information and does not require the production of specific results. The chatbot sends the information message stored in patient_description and then moves the execution token to the next task;

-

Processing task: In this case, the task requires the production of specific outputs. The chatbot guides the user to produce the expected results. When all the results have been produced, the chatbot independently moves the execution token to the next task.

Condition (true/false) (Figure 6).

The chatbot uses the PROCESS_NODE patient_description attribute in order to express the conditional situation to the user (e.g., ask a question); at the same time, it proposes the possible answers in exclusive mode using the patient_description attribute inserted in its two child nodes and leaving the user the possibility to indicate the right branch. After the choice, the chatbot will move the execution token to the next node of the one representing the branch related to the choice made.

Condition (multiple choices) (Figure 7).

This is the same behavior as in the condition case, but the user can activate multiple child branches of the process_node that expresses the condition. The chatbot will then move the execution token to the children of all the selected branches.

Parallel branches (Figure 8).

The chatbot will automatically move the execution token to all the child nodes of the parallel PROCESS_NODE.

4.3. A Proposal of an Integrated Framework for ICP Execution

To implement the outlined strategy, it is necessary to define the architecture of a framework that enables all the potential of virtual chatbot guidance, integrating external specialized services useful for enriching the clinical process from an experiential point of view. Examples of services could be information security, the integration of Internet of Things (IoT) technologies for the acquisition of environmental and personal clinical data, data analysis and business intelligence, territorial logistics, and the semantic annotation of information.

The framework also includes the integration of technologies aimed to support the medical team to transform an ICP designed only for clinical stakeholders into a patient-centric path. Moreover, it is necessary to define a general methodology that allows this transformation.

Figure 9 shows the structure of the proposed framework, and the next section more deeply describes the methodology that allows the transformation of a clinical pathway into its digital twin executable with the support of a chatbot.

4.3.1. Data Layer

In the reported logical architecture, the DataLayer contains the meta-model related to the integrated care paths both in the process template version (Process Design Data) and in the process instance version (Process Execution Data). The container also accumulates data coming from events external and/or internal to the process (Event Data) that represent a source of information useful for updating the execution status of the process. This type of information could be further refined by drawing on public data that can be acquired from social channels. The logical module in charge of this type of interface is Social Media Data.

4.3.2. ICP Management Application Layer

It represents the back-end side of the integrated care path management system. This layer includes the following modules:

ICP Design tool: This represents the technology used to create and design a process template. The minimum set of graphical constructs that this module must provide are a task (a task can be atomic or not decomposable or represent a sub-process), condition, parallel, and flow (the last is always an oriented arc that connects the other elements).

ICP Normalization: This is a graphical tool that allows the normalization of a template process. The term normalization is intended to indicate a specific phase of the process generation methodology that has the main purpose of disambiguating the flow elements present in the template process.

Patient Centred-ICP generation: An integrated care path is a process designed to be read by medical stakeholders. The reported architecture can be defined as patient-centric, i.e., it sees the patient as the main (though not the only) actor through which the instance of the clinical process evolves over time. This implies that the language that the system must convey must have the characteristics of informality and adequacy with respect to the level of knowledge of the average patient or the relative caregiver. This logic module makes it possible to generate a version of the process template that addresses this type of user, preserving the topology of the clinical process from which it derives. This step can be performed by the medical staff or the case manager nurse.

ICP-Graph Generation: It is the module that transforms the graphical representation of the process (possibly expressed in a markup language such as XML) into an instance-template within the Process Design Data of the Data Layer.

4.3.3. Security Layer

This is the level in the architectural stack that has the task of overseeing computer security in the interactions between all the users of the system. As previously mentioned, the proposed platform uses a chatbot to acquire information useful for updating the execution status of the clinical process. To this end, a dialogue is triggered between users and chatbots whose objective is to increase the overall digital knowledge of the patient. This implies the need to manage data such as diagnosis, prescriptions, clinical analysis and diagnostic analysis. The system should safely manage access to this information, allowing the patient to decide whether to make it available by defining policies on to whom, how and when. Various strategies can be identified for implementing this layer, and one of the most promising is to use blockchain to manage the data access permission policy [60,61].

4.3.4. CSCW Layer (Chatbot Back End) and Chatbot Front End

These two modules implement the conversational agent that aids the execution of a clinical process. The task of this chatbot is to lead the patient to provide information useful for determining a change in status in the clinical process instance to which the patient has somehow been registered. To conduct the dialogue with the patient, the chatbot uses some sentences contained in the process template. These sentences are generated downstream of the design through the Patient Centred-ICP Generation module by a professional figure such as the Case Manager nurse, who is trained to talk to patients in an assertive and empathetic way. The chatbot uses the topological structure of the process, the flow elements and the phrases it contains to understand the execution status and/or to push the patient to update it. For this purpose, it has to use different gimmicks (functionalities) that can push the patient to use it. Services such as the secure archiving of medical-clinical documentation, agenda for the recording of appointments, the management of visits and analyses, and the voluntary recording of clinical events are all useful services provided to the patient that simultaneously feed an archive of events from which to extract useful knowledge for clinical pathway management.

4.3.5. Back-End ICP Process Dashboard

This is the data-analytics module whose functions are available to clinical users in order to analyze the execution status of the process instances on each patient and eventually intercept deviations from the standard path coded in the process template. Another important feature that this module should implement is the ability to quantify the costs of the execution of the process instances by providing benchmarking tools for comparison against the standard costs defined in the template process. Deviations from the standard path (e.g., the execution of an unplanned or repeated diagnostic examination without a real need) can lead to increased costs for the National Health System without impacting the outcome in the least. Having the ability to quantify these actions allows the optimization of the template process and/or the undertaking of awareness-raising campaigns to increase awareness of the direct and indirect effects of these types of unnecessary actions.

4.3.6. Business Management Software

This represents the link between the process management platform and the information systems already in use by clinical stakeholders. These include GPs’ patient management software, clinical/hospital information systems, the National Health Service (NHS) registry, and regionally managed information systems. The module should also allow the management of digital identity and integrate with the national Public Digital Identity System (SPID). The chatbot uses SPID for the recognition of the patient in the initial linking phase with their process instance. This makes access to the system agile and ensures security in the management of sensitive data.

4.3.7. IoT Devices APP

This represents the set of mobile applications that interface with IoT devices present in the environment or worn by the patient in order to measure clinical parameters. The data generated by these devices should flow into the Data Layer and be available to the chatbot, as they may trigger events that change the execution status of a process. The chatbot, in turn, may mediate these data to medical personnel, always with the patient’s consent. The specific place where data from IoT devices are stored in the meta-model is represented by the EVENT entity with a PROCESS_NODE specialization, which is related to its data in OUTPUT.

4.4. Methodology for Executable Clinical Pathway Generation

This section defines a methodology that allows the transformation of an ICP designed for medical stakeholders into a patient-centric clinical pathway that can be performed with the assistance of a chatbot according to the architecture previously highlighted. Figure 10 shows the steps defined by the methodology.

The first step is formalization. This phase is typically carried out by an interdisciplinary medical team involving case managers. The aim is to design a clinical pathway process in which medical guidelines and evidence converge. At this stage, the clinical team is not constrained to using a specific formalism for the process descriptive diagram.

If the clinical team does not used a standard formalism, some flow ambiguities might occur. In this case, a disambiguation activity is carried out. We refer to this step as Normalization (Step 2 in Figure 9).

The third step addresses the issue of the centrality of the patient with respect to the treatment pathways. A clinical process designed to be read and interpreted exclusively by doctors is not understandable by the patients to whom it is addressed because the medical language is too technical. It is therefore necessary to proceed to a transformation of the text that describes each task in a language that is comprehensible by patients. This transformation could be performed by the Case Manager or the most suitable professional figure in this critical phase. The task that generates the patient-centered clinical process variant is defined as the ICP4Patient generation (step 3).

At this point, it is possible to generate a graph related to the template process by feeding the Process Design Data that will be the container of all the clinical pathways templates managed by the ICP-Graph Generation platform (Step 4). Once the template process is inserted into the meta-model, it will be possible to link patients to the template process by feeding the data of the process instance (User ICP Linking—Step 5).

From this moment on, the General Practitioner invites the patient to interact with the chatbot. The status of the process is then updated by the chatbot by triggering a continuous conversation with the patient using pre-coded sentences in the template process. At the same time, the medical staff can monitor the status of the process, acquire knowledge for each patient, and take actions in the case of need or upon chatbot request (Steps 6 a-b-c).

5. Results

To validate the proposed method, an implementation of the architecture described in Section 2 has been carried out. The instant messenger selected for the test phase is the Telegram platform, which makes its APIs available through the REST-API technology [62]. Telegram APIs have been used for the development phase of the chatbot, while the data meta-model has been implemented on MySQL DBMS.

With regard to the clinical process, the PDTA (the Italian Diagnostic Therapeutic Pathways) designed in the Emilia Romagna region for the treatment of headaches was taken into consideration. Figure 11 shows the process reported in the official Italian Emilia Romagna region publication [63].

The scheme presents several flow ambiguities, including an incoherent and non-standard graphic notation. In addition, it also has many specialist clinical terms. Moreover, the diagram shows tasks described not in an atomic way but by aggregating various activities to be performed.

By applying the steps of the proposed methodology, a normalized and patient-centered reformulation of the process has been produced. It should be emphasized that in the normalized version of the process, the language becomes informal and refers to the patient in the first person. The result is shown in Figure 12.

The normalized version of the process was used to generate the process graph, the latter was inserted into the database containing the simplified meta-model, and finally, the process instance was linked to a patient.

The telegram chatbot name is Health Care Assistant. Figure 13 shows the interface that the chatbot builds on the fly starting from the text of the template process. As seen, the simple normalization rules allow the establishment of a dialogue that is perfectly understandable to the patient. To encourage users to use the chatbot, services such as health document management have been developed. Moreover, an external service available in REST-FULL mode for the semantic annotation of the text has been integrated [64,65].

6. Discussion

The “burden of dialogue” is the first important difference between the proposed solution and the ones listed in Table 2. In AI and NLP-based approaches, it is the chatbot that is responsible for understanding the user. In our meta-model-based approach, the chatbot does not have to interpret the patient’s questions. The basic idea is to guide the patient to provide the right information for token routing during process-instance execution. The token-routing alternatives are encoded directly into the meta-model. For instance, in a conditional node, the chatbot uses the node label to ask “Are you over 50?”. The child nodes of the conditional node are both present in the process-tree. The patient declares on which branch to take, thanks to a menu of possible answers created on the fly.

As can be seen in Figure 1, the proposed chatbot follows the logic of the process by asking the patient to select one or more items among the set of closed answers encoded in the meta-model. The choice made among the closed answers is not prone to ambiguity. Since the application domain is healthcare, such a lack of ambiguity is fundamental for obtaining a trusted tool [66]. Nevertheless, the main drawback of the proposed approach is certainly reliability. For some questions, coded in the normalized meta-model, the patient might not know the answer. Whenever possible, these tasks are skipped. In all other cases, in order to avoid a dialogue-deadlock, some escape questions (i.e., “What does your GP say about it?” or “Please consult with your GP before answering...”) must be foreseen in the generation phase of the patient-centric process. A future development might address such reliability issues by synchronizing tasks performed by the patient with the tasks performed by medical staff within the meta-model.

A second aspect that needs to be discussed is the static nature of the dialogue. In AI + NLP chatbots, the dialog text (for instance, a question) is constructed so that it does not always appear the same for the same type of context. In our meta-model, each process node has the client interaction sentence defined as an attribute. This holds true also for answer nodes. Nevertheless, every time the process instance state passes through a specific node, the interaction mode does not change (i.e., there is the same question and same set of proposed answers). In an enhanced meta-model, the interaction sentence might be an entity related in [1:n] mode with the template process node. In this way, a dynamic dialogue might be obtained by applying an appropriate selection algorithm.

7. Conclusions

In this paper, we have proposed a simplified meta-model for managing process information in a way that is independent, using a graphical representation of the adopted design standard. In addition, in order to make a clinical process executable, a system architecture hypothesis has been formulated. Finally, a methodology has been proposed for transforming an integrated clinical pathway into a digital patient-centric twin executable through the mediation of a conversational agent. By this vision, social media becomes a container of patient health data and, at the same time, a virtual guide in the execution of clinical pathways.

However, there are many open questions to be addressed. First, it is important to define the strategies for interaction between bots and users to align the expected template process to the actual process instantiated. Often, patients, who are also driven by third-party opinions, follow alternative paths and ask for different opinions on the same issue. These deviations from the standard process template must be intercepted, inducing the patient to record these events through the bot.

The history of health events in patient social channels becomes a log on which to apply process-mining algorithms in order to extract evidence on the specific case and build knowledge useful for understanding outcomes and detecting extra costs in the process. Moreover, it is possible to extract useful information to improve the basic template on which the process is instantiated.

A further topic for future investigations concerns security issues in accessing health data through social media. Finally, issues related to the quality of the software should also be addressed when sensitive information, such as health information, is conveyed in social media through the interaction of chatbots.