Sie können Operatoren mit Ihrer Suchanfrage kombinieren, um diese noch präziser einzugrenzen. Klicken Sie auf den Suchoperator, um eine Erklärung seiner Funktionsweise anzuzeigen.
Findet Dokumente, in denen beide Begriffe in beliebiger Reihenfolge innerhalb von maximal n Worten zueinander stehen. Empfehlung: Wählen Sie zwischen 15 und 30 als maximale Wortanzahl (z.B. NEAR(hybrid, antrieb, 20)).
Findet Dokumente, in denen der Begriff in Wortvarianten vorkommt, wobei diese VOR, HINTER oder VOR und HINTER dem Suchbegriff anschließen können (z.B., leichtbau*, *leichtbau, *leichtbau*).
Der Artikel untersucht die Herausforderungen bei der Steuerung wissensintensiver Prozesse (KiPs) in der Entwicklung von Arzneimitteln, insbesondere von Arzneimitteln für fortgeschrittene Therapien (ATMPs). Es stellt eine Fallstudie vor, die kontextbewusste Unternehmensmodelle verwendet, um ATMP-Wissenschaftler bei der Einhaltung regulatorischer Bestimmungen zu unterstützen. Die Autoren präsentieren ein Metamodell, das Domänen-, Ziel- und Prozessmodelle integriert, um das komplexe Zusammenspiel zwischen wissenschaftlichen und regulatorischen Anforderungen darzustellen. Der Aufsatz unterstreicht die Bedeutung des Kontextbewusstseins bei der Handhabung dynamischer und ausführungsabhängiger Kontexte, was es Wissenschaftlern ermöglicht, fundierte Entscheidungen zu treffen und die Gesamteffizienz der Prozesse zu verbessern. Darüber hinaus wird in dem Artikel die Bewertung der vorgeschlagenen Modelle anhand einer Prototyp-Plattform diskutiert, um deren praktische Anwendbarkeit und potenziellen Nutzen für die Branche aufzuzeigen.
KI-Generiert
Diese Zusammenfassung des Fachinhalts wurde mit Hilfe von KI generiert.
Abstract
Due to their unique characteristics, knowledge-intensive processes (KiPs) are difficult to capture with conventional modeling and management approaches. One such KiP is the advanced therapy medicinal product (ATMP) development process. ATMPs are highly innovative medicinal products that are based on biomedical technology. ATMP development processes need to comply with complex regulatory frameworks. Currently, biomedical scientists that develop ATMPs manage the regulatory aspects of the ATMP development processes in an ad hoc fashion, resulting in inefficiencies such as reworks or even withdrawal of ATMPs from the market. This paper presents an explorative case study in which we use Enterprise Modeling and Context-aware Business Processes to support ATMP scientists in managing the regulatory aspects of ATMP development processes more efficiently and effectively. In our explorative case study, we use enterprise models to describe the important concepts and views in ATMP development processes. By introducing context-awareness to the models, we support ATMP scientists in performing relevant tasks to address the regulatory requirements efficiently and effectively under different contexts. We introduce the novel concept of execution-dependent dynamic context to properly define the context in ATMP development processes. Additionally, this paper takes a broader perspective on the case study by discussing the relevance of the solutions derived for the case study for other KiPs. Thereby this paper aims to present an exemplary approach for context-aware modeling of KiPs. The practical contribution of this paper are the models realized in a real-life ATMP development project. The scientific contribution of this paper is providing an exemplary approach for supporting knowledge workers who perform flexible, KiPs under dynamic contexts and introducing the notion of execution-dependent dynamic context.
Communicated by E. Serral Asensio, J. Stirna, J. Ralyté, and J. Grabis.
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
1 Introduction
Knowledge-intensive processes (KiPs) are business processes whose conduct and execution are heavily dependent on knowledge workers performing various interconnected knowledge-intensive decision-making tasks in a flexible way to achieve process goals [1]. KiPs differ from traditional business processes with their unique characteristics such as flexibility, expert knowledge dependency and goal orientation [1]. Considering their unique characteristics, it is difficult to effectively capture KiPs with conventional modeling and management approaches [2].
ATMP development is a knowledge-intensive process, where the scientists, as the knowledge workers, execute the process in a flexible way to achieve the goal of developing a safe and effective product. Currently, ATMP scientists manage the ATMP development processes in an ad hoc fashion, which results in inefficiencies. ATMPs are medicines for human use that are based on innovative biomedical technologies [3]. Being a medicinal product for human use, ATMPs need to comply with complex regulations about safety and efficacy [4]. Therefore, the two most prominent views in ATMP development processes concern scientific development and regulatory compliance. As a result of the ad hoc management of regulatory aspects by the scientists, ATMP development processes suffer from inefficiencies such as reworks and withdrawal of ATMPs from the market due to not being able to demonstrate regulatory compliance adequately [5, 6].
Anzeige
The cause of this is the complexity of the ATMP regulatory framework and scientists’ lack of regulatory knowledge and its impact on the scientific development process [7]. ATMP regulations describe high-level goals to be achieved to ensure that the ATMP being developed is safe and effective [8]. This is done by, for instance, demonstrating the physiological and biochemical properties of the product. Also, ATMP regulations are flexible; different regulatory requirements apply depending on the development context. Here, the development context covers a set of factors related to the ATMP, e.g., type of materials used, regulatory classification of materials. The complexity and context dependency of regulatory requirements make the management of regulatory aspects of ATMP development challenging for scientists. Therefore, there is a need to support ATMP scientists in managing the regulatory aspects more efficiently and effectively.
This paper first presents an explorative case study, initially presented in a prior conference paper [9], in which context-aware enterprise models are used to support ATMP scientists in managing the regulatory aspects more efficiently and effectively. The object of the case study is the biomaterial development process, which is a part of ATMP development processes, from the Horizon2020 iPSpine project.1 In iPSpine, an ATMP for lower back pain is being developed. As a part of this project, we are developing a digital platform on which we implement the enterprise models presented in the case study to enable efficient and effective management of ATMP development processes. Therefore, the case study is driven by the problems in iPSpine project. In addition, inspired from the insights gained through the case study, this paper takes a broader perspective and discusses the relevance of the solutions and concepts used in the case study for KiPs. Hence, the main aim of this paper is presenting an exemplary approach for context-aware modeling of KiPs with similar characteristics as the ATMP development processes.
Enterprise modeling is an effective approach to capture, understand and relate the elements of a complex system [10]. Enterprise modeling can support many purposes, for example, strategy development [11], change management [12] or process improvement [13]. In the case study, we use enterprise models to describe scientific and regulatory views in ATMP development. Using enterprise models such as domain, goal and process models, we capture, understand and relate the main elements in ATMP development processes in a structured way. To describe the main concepts and their relations in ATMP development, we use a domain model. We represent the scientific development process in a flexible process model and regulatory requirements in a goal model.
Fig. 1
ATMP development process and stakeholders (stakeholders and scope of this study in bold)
Building upon these models, we introduce context-awareness to the models to account for the effect of regulatory context on regulatory requirements and the scientific development process. By introducing context-awareness to these models, we make the link between different regulatory contexts, regulatory requirements and the scientific development process explicit and support scientists in performing relevant tasks to address the regulatory requirements under different contexts. Other approaches that support flexible and knowledge-intensive processes [1], like ATMP development processes, have emerged recently [14‐17]. However, these approaches are based on historical data. ATMP development is a new field with a huge variability between different projects, and there are no historical data from previous projects that can be used to guide new developments. Hence, we focus on context-awareness to provide support for ATMP development processes.
Anzeige
In enterprise modeling, context is often considered as different viewpoints in an enterprise architecture [18] or as enterprise context which covers the models presenting the complete picture of the enterprise/organization [19]. In our case study, we explore context-aware business processes, which deal with the notion of context on a lower and more operational level. Context-aware BPM deals with identifying factors that drive flexibility and variability in business processes [20]. Several authors investigated the notion of context for business processes intending to identify factors that affect the design and execution of a business process and make business processes context-aware by integrating these factors and their effect on the process models [21]. In this paper, we introduce the notion of execution-dependent dynamic context and use the notion of context-awareness in BPM to support scientists in working more efficiently and effectively toward regulatory compliance.
In this paper, we extend our prior paper [9] in several ways. First, we present a meta-model that explains and integrates the concepts we use to model context-aware medicinal product development processes in the case study. This meta model presents generic concepts that can also be used for context-aware modeling of similar KiPs. Second, as a result of the case study, we realized the need to introduce a new concept. This paper introduces the concept of execution-dependent dynamic context and discusses its relevance for modeling context-aware medicinal product development processes. Third, we present an extended evaluation done by implementing the models in our case study on a digital platform and discussing the ease of use and usability of our models based on questionnaires with the digital platform users. Furthermore, this paper positions the object of the case study, ATMP development processes, within the framework of knowledge-intensive processes (KiPs) and discusses the relevance of solutions presented in this paper for KiPs in general.
The remainder of this paper is organized as follows: Section 2 introduces ATMP development processes and the problem addressed in the case study, introduces the objectives of the case study and discusses the relevance of the problem and the solution presented in the case study for KiPs. Section 3 discusses how the objectives of the case study are addressed and presents a structure for the solutions using a meta-model. Section 4 presents the evaluation performed within the iPSpine project. Section 5 discusses related work. Lastly, Sect. 6 presents the discussion and concludes the paper.
2 ATMP development processes and the need for regulatory support
In this section, we introduce the ATMP development processes and the problem we address in our case study. We also frame ATMP development processes as knowledge-intensive processes and discuss the relevance of our solutions for knowledge-intensive processes.
2.1 ATMP development: a knowledge-intensive process
The development of ATMPs involves several stages, and the overall aim in these stages is to develop a safe and effective medicinal product. This is accomplished by collaboration of many stakeholders, where scientists and regulatory consultants are the main ones. Figure 1 describes the main phases and stakeholders in ATMP development.
Research shows that ATMP development processes are associated with many hurdles such as reworks and even withdrawal of the ATMP due to shortcomings in providing adequate evidence for regulatory compliance [5]. This contributes to increased development costs and time-to market. Lack of regulatory knowledge among scientists is an important factor for these hurdles [5]. Being an expert, a scientist, requires minimal guidance about the scientific aspects of ATMP development. However, establishing and maintaining the link between the scientific development process and the complex regulatory framework of the ATMP development are challenging for a scientist. In other words, there is a need to bridge the gap between the scientific and regulatory views on ATMP development processes.
A thorough investigation of characteristics of ATMP development processes through discussions with ATMP scientists and findings from literature [4‐8] reveals its knowledge-intensive characteristics. There are several definitions for knowledge-intensive processes in the literature [22]. Yet, all definitions revolve around the importance of expert knowledge in design and execution, specific execution characteristics and collaborative nature of KiPs [22].
Table 1
KiP characteristics and ATMP development processes
Emerging knowledge and data together with scientists’ interpretation determine flow of process actions
Unpredictable
ATMP development is an exploratory process. Neither the process nor the knowledge related to the product being developed can be fully prescribed a priori. However, the high-level process and knowledge flow is predictable
Emergent
It is a search process where realizations throughout the process and availability of certain knowledge shape the process step by step
Constraint- and rule-driven
Regulatory requirements and guidelines should be taken into consideration throughout the process
Non-repeatable
Development processes are hardly fully repeatable since in every case, scientific approach, materials used and/or aim of the study and hence related process requirements are different. Yet, the high-level process flow is repeatable
Goal-oriented
The development process evolves through a set of goals, e.g., achieving certain levels in safety, efficacy, etc.
Collaboration-oriented
An ATMP development process involves many partners with different roles: scientists from different fields, regulatory consultants, regulators, etc. Each stakeholder contributes to the development process
Event-driven
A development process is affected by the occurrence of different kinds of events which may be resulting from other scientific or project-related actions. However, for a single development case this characteristic is less observable
Table 2
KiP characteristics and reflection on the solutions
KiP characteristics
Reflection on the solutions
Constraint- and rule-driven
Regulatory requirements are modeled explicitly as goals
Goal-oriented
Goals are explicitly modeled in a goal model and linked to the process model
Emergent
A flexible process modeling language and approach (CMMN) is used to support flexible and emergent nature of process execution. Also, context-aware models are designed to represent the emergent nature of the development process due to the effect of dynamic development context
To further frame ATMP development processes as KiPs, we have analyzed the relevance of commonly accepted KiP characteristics [1] for ATMP development processes. Table 1 shows the relevance of these KiP characteristics for ATMP development processes. Three of these KiP characteristics relate especially to the problems faced in ATMP development and the solutions we develop in the case study focus on these three characteristics. These are constraint- and rule-driven, goal-oriented and emergent characteristics.
First, ATMP development processes are constraint- and rule-driven, since scientists should consider regulatory requirements throughout the development. However, it lacks structured approaches supporting scientists in managing constraint- and rule-driven nature of the ATMP development process since there are problems in ensuring regulatory compliance.
Second, ATMP development processes are goal-oriented since they evolve through a set of intermediate-level goals to achieve the regulatory requirements or, in other words, regulatory goals. However, there are problems in addressing these goals effectively since these goals are not clearly defined and structured for scientists, i.e., scientists lack enough support in building and maintaining the link between the development process and these goals.
Lastly, ATMP development processes are emergent. The actual course of action is gradually determined throughout the process execution and affected by the knowledge emerging throughout the process execution. This knowledge involves, for instance, scientific knowledge gained through experiments and also the knowledge on context of the development process. The actions that should be taken in the development process and the regulatory requirements to be addressed are shaped as a result of this emerging knowledge. Emergent nature of ATMP development process makes it difficult for scientists to effectively manage the development process and address the regulatory requirements efficiently and effectively.
Supporting knowledge-intensive processes is an emerging topic in BPM field [1, 14‐17]. However, existing approaches focus on utilizing historical data, such as event logs, to provide support for knowledge-intensive processes. Knowledge-intensive processes are hardly repeatable [1]. Therefore, useful historical data do not always exist for knowledge-intensive processes. This is also the case for ATMP development processes since it is a new field with a huge variability between different projects and there are no historical data from previous projects that can be used to guide new developments. This led us investigate enterprise modeling to support knowledge-intensive ATMP development processes.
Sections 2.3 and 3 present the enterprise models we use to identify and describe important concepts in an ATMP development setting and discuss how these models are used to support knowledge-intensive ATMP development processes. Table 2 summarizes the KiP characteristics that are specifically supported by the solutions present in this paper.
Note that, for demonstration purposes, we use models from a biomaterial development process, which is a part of the ATMP development studies in iPSpine project. The models we use in this paper are simplified for readability and space considerations. The actual models are implemented in the iPSpine process management platform developed within the scope of the project.
2.2 Preliminaries
In this section, we briefly introduce the modeling notations used for modeling ATMP development processes to facilitate the understanding of the following sections.
CMMN Case Management is an approach that recently emerged to support unique characteristics of KiPs, such as flexibility [23, 24]. Case management model and notation (CMMN) [25] is the industry standard process modeling notation for case management. CMMN is well suited for modeling the flexible and goal-oriented nature of KiPs [1]. Being the industry standard, there are already available tools for modeling and execution of CMMN models. Therefore, we chose to support ATMP development processes with case management and modeled the scientific development process using case management model and notation (CMMN) [25].
A case plan (folder shape) in CMMN represents a process model. A stage (rectangle with cut edges) groups a set of related tasks and represent a phase or an episode in a case. A task (box shape) in CMMN is an atomic unit of work. Milestones (rounded rectangles) represent achievable targets in a process. Event listeners (circles) wait for external events that can occur during case execution and trigger tasks, stages, or milestones in the process accordingly. Lastly, the diamond-like shapes attached to the tasks, stages, or milestones are called sentries. Sentries are expressions that involve a combination of event and/or data conditions. Sentries visualized as empty diamond shapes are referred to as entry sentries, representing when a task or stage is enabled. The black colored diamond shapes are exit sentries, representing when a task/stage/milestone is completed.
GRL Goal-oriented requirement language (GRL) is a goal modeling notation for goal-oriented modeling of requirements. GRL comes with a free modeling tool. This motivated our choice of using GRL in this paper. Besides, the goal modeling concepts we use in this paper are basic and present in most of the other goal modeling notations. Therefore, other goal modeling notations can also be used.
GRL provides several concepts for effective representation of requirements and three main concepts in GRL are: intentional elements (e.g., goal, task, resource), intentional relationships (e.g., means-ends, decomposition, contribution) and actors (e.g., actor, agent, role).
In this paper, we use GRL to model regulatory requirements, expressed as goals, in ATMP development. In the requirements engineering literature, there are also several works that formalize regulations using goal-oriented techniques [26, 27]. These works cover several goal modeling languages and concepts used to formalize regulations. In our case, the concepts of goal and decomposition relation were sufficient to structure ATMP regulations.
A goal in GRL is defined as a condition or state of affairs in the world that the stakeholders would like to achieve; a goal is visualized as a rounded rectangle. Decomposition relations link the intentional elements such as goals to other sub-intentional elements, i.e., sub-goals, indicating that the sub-intentional elements should be achieved or performed to achieve or perform the parent-intentional element. The decomposition relations are visualized by links with a straight line between the nodes in model.
2.3 Modeling ATMP development
Enterprise modeling covers several viewpoints represented in models [11, 18]. Depending on the purpose of the enterprise modeling job, the models used and the level of detail included in the models should change [11].
For the case study, the purpose of modeling is to represent and relate the two most prominent views, regulatory and scientific, of ATMP development processes. The regulatory view covers the reason or motivation behind performing ATMP development processes, i.e., the aim is to develop a safe and effective (in other words, regulatory compliant) product. The scientific view covers the activities to develop the product. Therefore, goal and process models are essential elements for our purpose. To understand and relate different concepts in these different views, a domain model is also essential.
There are other models used in enterprise modeling, for instance, actor/resource models and business rule models [11], organization and network models [18]. However, we have not used such models since they do not provide useful information for our modeling purpose. For example, modeling the different actors/resources and their relations does not provide any implications about the scientific and regulatory views in ATMP development, and modeling the business rules, e.g., some scientific procedures that constrain how experiments should be done, is not within the scope of our modeling purpose. The following paragraphs discuss the enterprise models we use in our case study.
First, we built a domain model with domain experts (biomedical scientists and regulatory experts) to structure the domain knowledge and understand complex concepts and the problems in the domain. Figure 2 shows the domain model we have created for this case study, using UML class diagrams.
The domain model in Fig. 2 denotes important concepts and their relations in ATMP development processes. Each Development Process is organized in different Development Stages representing the main phases in the development. Each stage involves several Development Activities, an atomic unit of work performed by the scientists, that consists of Experiments. Each experiment follows a Standard Operating Procedure (SOP) describing the detailed steps of the experiment. Scientists performing development activities aim to fulfill the Scientific Goals which contribute to the achievement of Regulatory Goals. In each development activity, a Material Entity (either biomaterial or induced pluripotent stem cell (iPSc)) or multiple Material Entities (biomaterial combined with iPSc) can be used. These materials or a combination of these materials form the Drug Substance, which represent the active part in an ATMP. Drug substances are given the final form with additional material, such as packaging material represented by Others (Packaging) entity in the model, and form the Drug Product. Biomaterials and iPScs can have different roles in drug substances and drug products. These roles are represented by the association links between the entities Biomaterial and Drug Product, and Material Entity and Drug Substance. Finally, a drug product is used as an ATMP.
Fig. 3
Excerpt from the guideline on human cell-based medicinal products by European Medicines Agency [28]
Next, we focus on modeling ATMP regulations. In enterprise modeling, regulations are usually formalized in business rule models [10]. These models are used to define explicitly stated business rules. Business rules can be seen as refinements of higher-level business goals [10] as they define or limit the way the goals are operationalized.
In our case, ATMP regulations do not induce strict and well-elaborated rules on how things should be done throughout the development process. Instead, they involve high-level goals that should be considered in order to demonstrate that the ATMP being developed is safe and effective [8]. Therefore, we chose to represent the regulatory requirements using goal models. Figure 3 shows an excerpt from an ATMP guideline. The highlighted parts on this figure point out the fact that ATMP regulations are high-level goals that should be refined according to the specific ATMP development case.
We started by identifying the top-level business goals with domain experts and refined these goals to cover the regulatory requirements. The requirements are further refined into (scientific) sub-goals considering the specific ATMP development case. Figure 4 shows an excerpt from the goal model of biomaterial development process in GRL notation [29]. Note that other goal modeling notations can also be used.
Lastly, we modeled the scientific development process using flexible process models. ATMP development processes are knowledge-intensive processes. Traditional BPM focuses on managing routine and predictable work. Knowledge-intensive processes have different characteristics [1]. Traditional BPM is limited when it comes to supporting flexible knowledge-intensive processes [1]. Case management is an approach that recently emerged to overcome these limitations [23, 24]. Therefore, we chose to support ATMP development processes with case management and modeled the scientific development process using case management model and notation (CMMN) [25]. Figure 5 shows an excerpt from the biomaterial development process model in CMMN.
A top-down analysis of regulatory goals results in a goal model where the leaf (or scientific) goals are satisfiable by means of sub-processes or tasks in the process model. This way, we build a link between the regulatory goals and the scientific development process. Each leaf goal in the goal model corresponds to a milestone of a single task or sub-process in the process model. The milestones corresponding to the leaf goals have the same labels as the goals.
2.4 The need for regulatory support and integration of context
Looking at the goal model in Fig. 4, we see that there is a set of sub-goals that are required to achieve the Demonstrate Physiological and Biochemical Characterization goal.
Indeed, some factors related to the development process and the ATMP being developed determine the specific subset of the sub-goals (regulatory requirements) that are required to achieve the Demonstrate Physiological and Biochemical Characterization goal. We refer to a set of such factors as the context of the ATMP development process. For ATMP development, the context is defined by several factors related to the ATMP. For instance, the scientist’s choice of regulatory classifications for the components of an ATMP or the type of starting material of an ATMP. An example decision tree followed by scientists for regulatory classification decisions is shown in Fig. 6. For different contexts, e.g., different classification options in Fig. 6, different regulatory requirements should be addressed to achieve the Demonstrate Physiological and Biochemical Characterization goal. For instance, if the regulatory classification in Fig. 6 is medical device, the goal Demonstrate Compliance with ICH Q5D is no longer a requirement to achieve the Demonstrate Physiological and Biochemical Characterization goal. Whereas, if the regulatory classification is starting material, the scientist should perform Demonstrate Compliance with ICH Q5D to achieve the Demonstrate Physiological and Biochemical Characterization goal. In short, which regulatory requirements are applicable depends on the context.
Correspondingly, since the regulatory goals drive the scientific development process, i.e., the scientist performs experiments to address regulatory requirements, the context also affects the scientific development process. The ATMP development process model in Fig. 5 covers all possible tasks that a scientist can perform throughout the development process. Yet depending on the context, since context defines which regulatory requirements are applicable, some tasks are required to address the regulatory goals, whereas some are not. The scientist can still perform other tasks that are not required to address the regulatory goals of the current context, for instance, out of scientific interest or to explore alternative contexts (see Fig. 6).
Moreover, the context for ATMP development processes can be execution-dependent. A process context is typically either static or dynamic. In a single execution of a process, the static context is fixed and predefined, e.g., the season in an airline booking process. The context can also be dynamic, i.e., it can change throughout the process execution, e.g., the weather in an airline booking process. However, this dynamism does not originate from the process execution but rather from changes in the environment. Here, we define execution-dependent dynamic context as a context that is defined and subject to changes during the process execution based on the interpretations of the knowledge worker performing the process.
For instance, the type of material used (natural, synthetic or semi-synthetic) in an ATMP development process defines a static context. It is part of the context since the type of the material affects the development activities (tests, experiments, etc.) that should be performed. It is static because one type of material is selected before the development process starts and it cannot be changed throughout the same development process. Switching to a new type of material means creating a new process instance.
The availability of material entities defines, however, a dynamic context. It is a part of the context since whether a material is available or not affects the development activities (tests, experiments, etc.) that can be performed. It is dynamic since this availability can change throughout the process, e.g., through purchasing new materials. However, it is not execution-dependent, i.e., this context does not change as a result of executing the activities in the scientific development process. (Note that, our focus in this study is the regulatory context of ATMP development processes. Therefore, the content of the models is limited to regulatory-related elements and does not cover, for instance, the availability of material entities as a contextual element since it is not a part of the regulatory context.)
The execution dependency of dynamic context in ATMP development processes can be explained in two ways. First, the scientist can start the process with an initial assumption on the context. However, depending on the results the scientist obtains throughout the process, she can decide to, for instance, classify the biomaterial as a medical device instead of as an excipient, following the decision tree in Fig. 6. This changes the context of the ATMP development process throughout the development process. Second, scientists usually investigate multiple contexts simultaneously throughout the development and try to find out the most appropriate one for their product. For example, different options (e.g., classifying the biomaterial as a medical device or an excipient) are investigated throughout the development. Therefore, the final context is defined throughout the development process by the interpretations of the knowledge worker. Therefore, regulatory classification is an execution-dependent dynamic context. All in all, the effect of context on the ATMP development processes makes it even more difficult for scientists to manage the complex ATMP development processes. To ensure that the scientist performs the relevant tasks that address the relevant regulatory requirements effectively, it is important to make explicit in the process model which tasks are required under which conditions (context) and thereby support the scientists in addressing the regulatory goals.
Table 3
Objectives of the case study
Main objective
Support ATMP scientists performing the scientific development process toward regulatory compliance
Sub-objective 1
Define and represent context for ATMP development processes
Sub-objective 2
Represent the variability of regulatory goals, depending on context
Sub-objective 3
Represent the effect of context on the scientific development process
In the case study, we aimed to develop support for ATMP development scientists in working toward regulatory goals under different contexts. As a result of an analysis of literature on managing ATMP development processes [4‐8, 28] and our interviews with iPSpine stakeholders, we have identified the objectives in Table 3 for our case study.
3 Solution design and development
The need for regulatory support and the integration of context, as discussed in Section 2, motivated us to use the notion of context and context-awareness to support ATMP scientists in working toward regulatory compliance. The following sections present the models, the main artifacts of our study, that we use to address the objectives in Table 3.
3.1 Contextualizing the domain model
(Sub-objective 1)
Every business process has a specific domain. Correspondingly, everything that influences a process is related to this domain [30]. Therefore, what constitutes the context for a business process lies in the domain model. This motivates our choice of using domain models as a baseline to define context in ATMP development processes. For ATMP development, the experiments performed, results obtained, the properties of the ATMP being developed or decisions taken throughout the process form the context of the development process. For instance, a decision, which is a part of the ATMP development process, about the regulatory classification of components of the ATMP is an important contextual element.
Figure 7 shows the domain model with contextual elements and Fig. 8 shows example context definitions and Table 4 provides the descriptions for each context definition. We created the domain model with domain experts (biomedical scientists and regulatory experts). In the domain model, entities and their attributes are marked as contextual, shown in gray boxes in Fig. 7, if they determine the regulatory goals to be addressed by the development process. For example, the decision about classification of biomaterial shown in Fig. 6 is represented as different roles that a biomaterial entity can take and marked as contextual element (see C1 and C2 in Fig. 8).
Instantiation of each contextual element is a partial context (C5, C6, C7, C1, C2 in Fig. 8). Also, combined instantiations of multiple contextual elements with different values are a partial context (C3, C4 in Fig. 8). Contexts which share the same contextual elements but with different values are mutually exclusive (C5, C6, C7 or C1,C2 or C3, C4 in Fig. 8). Contexts that include a combination of multiple contextual elements might imply contexts including less contextual elements (e.g., \(\textsf {C4}\rightarrow \textsf {C2}\), \(\textsf {C3}\rightarrow \textsf {C2, C4}\rightarrow \textsf {C6}\) in Fig. 8). So these contexts are not exclusive.
The maximal set of non-exclusive partial contexts form the overall context in an ATMP development process (see context in Fig. 10).
3.2 Contextualizing the goal model
(Sub-objective 2)
Having defined contexts, we annotate the root and the parent goals in the goal model with context labels, indicating which goal is enabled under which conditions in Fig. 9. The semantics of context annotations are provided in [31]. If a root goal, G, is annotated with a context label \(\textsf {C}_{\textsf {i}}\), that means G is activated iff context \(\textsf {C}_{\textsf {i}}\) holds. If there is a goal \(\textsf {G}_{\textsf {i}}\), that is decomposed into a sub-goal \(\textsf {G}_{\textsf {j}}\) with and(or) decomposition links, then the link is annotated with a context label. This means, goal \(\textsf {G}_{\textsf {i}}\), requires(can be achieved) via \(\textsf {G}_{\textsf {j}}\) iff context \(\textsf {C}_{\textsf {i}}\) hold.
These annotations enable us to derive the context for leaf goals. This is done by analyzing the goal model variants where the specific leaf goal that will be contextualized is present. For example, Fig. 10 shows all goal model variants where the leaf goal Achieve Good Swelling Degree is present. Goal model variants are derived by choosing the relevant context annotations on the contextual goal model. Note that, for example, if different mutually exclusive contexts, such as C5 \(\wedge \) C2 and C7 \(\wedge \) C2, lead to the same goal model variant they are combined into a single variant with a single context, (C5 \(\vee \)C7) \(\wedge \) C2, as shown in the Goal Model Variant-1 in Fig. 10.
The leaf goal Achieve Good Swelling Degree is part of the goal model only if one of the contexts of the goal model variants holds. Therefore, the context of the leaf goal Achieve Good Swelling Degree is derived by combining the contexts of these goal variant as shown in Fig. 9.
Figure 9 shows an example contextual goal model for ATMP development processes where the context of leaf goals has been derived using the contexts of goal model variants which include these leaf goals (see Fig. 10).
The idea of using contextual goal models is inspired from [31], in which contextual goal models are used to model contextual requirements for an information system. Here, we use contextual goal models as a means to contextualize process models. In the following subsection, we describe how contextual goal models are used to contextualize ATMP development processes.
3.3 Contextualizing the process model
(Sub-objective 3)
Our intention here is to contextualize the process model such that it supports scientists in working toward regulatory goals throughout the development process under different contexts. This is achieved by deriving the context of the leaf goals in the goal model. A leaf goal corresponds to a milestone of a single task or sub-process in the process model. Accordingly, once we derive the context of leaf goals, the corresponding task/sub-process is also implicitly contextualized.
For instance, the context of the goal Achieve Good Swelling Degree, as shown in Fig. 9, is derived by using the goal model variants in Fig. 10. This goal corresponds to the milestone Good Swelling Degree Achieved of the task Test swelling Degree on the process model. Deriving the context of the leaf goal, therefore, enables us to link related contexts and contextual elements to the tasks in the process model through annotations.
These annotations, as shown in Fig. 11 include: the elements in the domain model used to define the context of the task as the contextual elements that affect the task or sub-process, and context definitions for which the task or sub-process becomes relevant.
3.4 Context-aware process modeling for ATMP scientists
(Main objective)
In this section, we discuss how our models can be used in practice to support scientists in ATMP development.
Context-aware process models support scientists by making explicit which tasks are required to address the regulatory requirements under different conditions (contexts) and what (contextual elements) affects whether a task is required or not.
First, context-aware process models make the tasks that are required to achieve regulatory goals under different contexts explicit to the scientists. The process model in Fig. 5 is a flexible process model where, as a knowledge-worker, the scientist has the flexibility to choose which tasks to perform and which not. Although this flexibility is an essential part of a knowledge-intensive process [1], it is important to support the scientist in making these choices about tasks to be executed. Without knowing that a task is required for a certain context to achieve the regulatory goals, the scientist might skip a task. This will result in failing to comply with regulations and not getting the authorizations for clinical trials.
Table 4
Description of contexts
Context
Description
C1
Biomaterial has role starting material in drug substance
C2
Biomaterial has role medical device in drug product
C3
Biomaterial has starting material type synthetic AND Biomaterial has role medical device in drug product
C4
Biomaterial has starting material type natural AND Biomaterial has role medical device in drug product
C5
Biomaterial has starting material type synthetic
C6
Biomaterial has starting material type natural
C7
Biomaterial has starting material type semi-synthetic
C8
iPSc has starting material type human
C9
ATMP has type ATMP
C10
ATMP has type combined
C11
Biomaterial has role starting material in drug substance and biomaterial has starting material type semi-synthetic
C12
ATMP has type ATMP and biomaterial has role starting material in drug substance and biomaterial has starting material type semi-synthetic AND iPSc has starting material type human
C13
ATMP has type combined and biomaterial has starting material type synthetic and biomaterial has role medical device in Drug Product AND iPSc has starting material type human
C14
ATMP has type combined and biomaterial has starting material type natural and biomaterial has role medical device in Drug Product AND iPSc has starting material type human
For example, consider the task Test swelling degree. According to the process model, the scientist can skip this task. However, skipping this task would cause a problem if the biomaterial has a natural starting material and is classified as starting material in the drug substance (context \(\textsf {C}_{\textsf {1}}\) in Fig. 8 holds). Skipping the task will result in not being able to Demonstrate compliance with Ph.Eur. 2.8.4 Swelling Index (see Fig. 9), and this will result in failing to get the authorizations for clinical trials. With the models in this paper, the scientist can choose a specific context and this way is able to see which tasks are required to achieve the regulatory goals of that context. Thereby, the scientist can ensure that the relevant regulatory requirements of the context are addressed.
Additionally, it is important to explicitly show the factors (contextual elements) defining the context of a task in a process model. For instance, knowing that the contextual elements related to Test swelling degree task are Starting material type and Role of biomaterial, the scientist sees how Role of the biomaterial affects the development process. This way scientists can see the effect of their decisions about the context, e.g., choosing the appropriate Role of the biomaterial in Fig. 6, on the process. This helps them to make more informed decisions about the final execution-dependent dynamic context, for instance, by choosing the context that requires fewer tests, which is more time and cost-efficient.
Also, context-aware process models implicitly support scientists in working more efficiently by helping them in prioritizing the tasks that are relevant for multiple dynamic contexts rather than performing redundant tasks that are only valid for a specific dynamic context that is unlikely to occur.
3.5 Meta-model for modeling context-aware medicinal product development process
In this section, we present the meta-model denoting the concepts used in the previous sections (from Sects. 3.1 to 3.3) to model context-aware medicinal product development processes. The aim of presenting a meta-model here is to provide an overview of the models, which are the output of our approach for context-aware modeling. This can be viewed as the product model [32] of our approach presented in the previous sections where the case study is discussed. Therefore, the previous sections (from Sects. 3.1 to 3.3) act as a guideline for deriving these models.
As highlighted in Table 3, the objective of modeling medicinal development processes is to define and represent context, regulatory goals, processes, and their relations. The meta-model was derived by considering the modeling requirements identified and realized during the case study. Therefore, the meta-model was constructed using four different fragments: process modeling, goal modeling, context modeling and domain modeling. Next, concepts in each meta-model fragment were identified. Lastly, the different meta-model fragments were linked to each other by introducing the concepts of goal model variant context and contextual element.
The focus was to keep the meta-model as simple and as generic as possible such that it can be instantiated for different modeling notations and also relate to KiPs with similar characteristics other than medicinal development. Therefore, when defining the concepts in the meta-model we considered the main elements of a KiP [2], such as goals and activities, and business processes and goal modeling, such as goals, goal models, sub-processes and processes. Furthermore, the concepts for context and domain modeling were derived based on our examples in the case study. Since the concepts in these parts are generic, they also relate to other KiPs. Note that, modeling a KiP in general might involve other concepts for all these fragments [2, 30]. Here, our aim is to present a simplified view of the concepts that are important for our approach.
The meta-model in Fig. 12 provides a high-level and integrated picture of our solution artifacts. In the following paragraphs, we discuss the four fragments of the meta-model: domain modeling, context modeling, goal modeling and process modeling.
Domain Modeling Concepts
This part covers the modeling of domain knowledge. Entity is used to define important elements in the domain. Role represents some important relation between different entities, and attributes define important characteristics for entities.
Context Modeling Concepts
This part represents the concepts we use to define the process context in our case study. The context of a business process, for instance, the weather or location, is any information that affects how the process goals are achieved [20]. This information is part of the domain knowledge. Therefore, we use the domain model as a baseline for defining context.
Contextual elements determine the context for a business process. Entities, roles or attributes can be contextual elements and hence can be used to define context. For instance, starting material type of the biomaterial, a contextual element in the ATMP domain, determines the context for the ATMP development process, and different tests are required in the context of a synthetic starting material, defined by instantiating the contextual element starting material type, to demonstrate that the biomaterial is safe.
The context can be static, dynamic or execution-dependent dynamic (see Sect. 2). For instance, the type of the starting material used in a biomaterial development process is a static context, that is defined before the biomaterial development process starts and does not change throughout the execution of the process. Yet, the role of the biomaterial in the drug product/drug substance is an execution-dependent dynamic context. The scientists decide upon this role during the process execution (see Fig. 6) and can change this role based on the results obtained throughout the process. Knowing the distinction between different context types and their effect on the process and goals supports scientists to make more informed decisions in choosing the final dynamic context. Therefore, different context types are also represented in the meta-model.
Goal modeling concepts
This part covers the modeling of goals. A goal is an objective that the system under consideration should achieve [33]. In our case, this system is the process. Leaf goals represent the lowest level goals achievable by single tasks/activities or sub-processes in a process. Each leaf goal has one or multiple parent goals. The root goal represents the top-level goal in a goal model. A goal model variant is a subset of the goal model that has a specific context. Choosing the relevant context on a contextual goal model, we get a goal model variant, covering the goals of the chosen context [31, 34].
Process modeling concepts
This part covers the modeling of processes. It is important to note that here we only denote the important process modeling concepts that are used for building the link between goals, context and processes in our case study. The process model covers more than the concepts represented in the meta-model, such as resources and events. In our meta-model, a process consists of tasks and sub-processes. A task/activity is an atomic unit of work that achieves a goal. Sub-processes are used to group related and more refined tasks, that collectively achieve a goal.
Fig. 12
Meta-model for modeling context-aware medicinal product development processes
In this study, we performed a two-stage evaluation. The purpose of the preliminary evaluation was to get initial feedback from domain experts on the feasibility and usefulness of our ideas on using enterprise models to support ATMP development scientists in working toward regulatory compliance. Next, we implemented the models on a prototype platform and performed a second round of evaluations. The purpose of the second round was to perform an elaborate evaluation on the usefulness and ease of use of the models by letting the experts investigate the models and the platform themselves and evaluate their experience using a questionnaire.
In the following subsections, we discuss the details of the evaluations.
4.1 Preliminary evaluation
Initial feedback on the models and ideas presented in this paper has been gathered from senior iPSpine biomedical scientists and regulatory experts. The purpose of this evaluation was to get preliminary feedback on the usefulness of our models. We presented the idea of using goal, process and domain models to structure the ATMP development processes and to link the fragmented scientific and regulatory views. In a meeting where eighteen experts (scientific and regulatory) were present, we showed some example models and explained their intended use. The stakeholders indicated that they are positive about the usefulness of the models and ideas in practice. They suggested implementing the models in the platform to have more elaborate discussions on their use and usefulness.
Next, the usefulness of the approach was discussed with three junior scientists who are working on the biomaterial development studies, which is the part of ATMP development processes we focus on in the case study. First an introductory session was organized with the scientists. In this session, we walked through the models. Then, we walked through a preliminary case in the platform and demonstrated how the models are used. The scientists mentioned that the idea of linking the process model and the goal model is “definitely useful” when the scientific development is at the stage where different regulatory frameworks (different contexts) are investigated. They mentioned that they can use these models to justify what they have done (process) and identify what they need to do to better comply with the chosen regulatory framework (goals). They also added that relating these different aspects (goals, processes and regulatory contexts) is useful to avoid any miscommunications at the end of the process and also for making sure that all people involved in the project are on the same page.
4.2 Evaluation on the iPSpine process management platform
The main aim of modeling in our case study was to drive the development of a prototype platform that can support scientists in managing the development process. Therefore, we implemented the models in the iPSpine process management platform. Our aim is to support ATMP scientists in performing the scientific development process steps such that they address the relevant regulatory compliance requirements. Therefore, the process aspect is an important part of our solution, and we implemented our models on the open source Flowable BPM Platform. Figures 13 and 14 show the application and its main page.
The process models are modeled in the modeling interface of the platform and deployed in the platform. Figure 15 shows the biomaterial development case plan in the prototype platform.
Fig. 15
Excerpt from the biomaterial development process in the iPSpine platform
For each task, forms are created to store information regarding tasks during execution (see Fig. 16). These forms are also used to provide a link between tasks, goals and context. Each form includes a link which brings the scientists to a table where they can see this link between the related tasks, its goals and context. To enable improved understandability and ease of use by the scientists, we decided to show the context definitions related to the goals in this table. Figure 17 shows an excerpt from this table.
We shared a user guide and a demo video.2 explaining the models and the platform and asked the experts and scientists to use the platform themselves. We conducted semi-structured interviews with two regulatory experts and three senior ATMP development scientists, after they interacted with the platform and investigated the models in the platform. The feedback from the users were positive. They acknowledged the value of having models and a platform that encourages a systematic way of working, which is especially important for guiding future ATMP developments and inexperienced scientists. There were also some improvement points mentioned in the feedback meetings. These were, in general, about the user interface of the platform, minor improvements to increase the understandability of the models and suggestions for increasing usability like adding additional explanations to the platform.
Following the interviews, we sent a questionnaire, formulated based on the technology acceptance model (TAM) [35] and measured the usefulness and ease of use of the platform. All questions are measured on a Likert scale of one to five, ranging from strongly disagree (1) to strongly agree (5). Table 5 shows the questions in the questionnaire. Note that we used TAM questions as a reference, but did not fully implement them in the questionnaire since our aim at this stage was to get some qualitative feedback rather than a statistical analysis. Also, it was not possible to do a statistical analysis due to the low number of evaluations.
Figure 18 shows the evaluation results. The results show that the evaluation was quite positive on all aspects. Only one regulatory expert has significantly lower evaluations on all questions. From our previous discussions with the experts, we know that this expert is always more critical than the others. Furthermore, this expert explicitly stated in the additional notes section of the questionnaire that his/her evaluations are for the current models and the platform and that with some improvements, the final evaluation will definitely be better.
Additionally, there are some questions with relatively lower ratings. Looking at those questions, we see that they are mostly related to the ease of use. We conclude that the users find the platform and the models useful and understandable but improvement in the final platform is needed to enable easier use.
It is important to note that the development of the platform, the improvements on the models and correspondingly evaluations are still ongoing. We incorporate the feedback we get in each stage of evaluations to improve the platform and the models and continue the evaluations with other domain experts. Currently we have a limited number of domain expert evaluations. However, the domain experts who participated in the evaluations were selected carefully among the work-package leaders in the iPSpine project; they all have considerable experience in ATMP development. Therefore, their views provide valuable evaluations. We plan to perform an extensive evaluation with more domain experts from the iPSpine project at the end of the project with the final platform and the models. Finally, we plan to perform evaluations with domain experts from other ATMP development studies to discuss the generalizability of our solutions for other ATMP development studies.
Our main objective in the case study is to support scientists in working toward regulatory compliance. Enterprise models provide a well-established baseline for our objective. Yet, the need for integration of context to the enterprise models posed a challenge for our case study. Therefore, in this section, we present the related work on context in enterprise modeling and business process management and discuss their relevance for our work.
In enterprise modeling, context is often considered on a higher level than we need for our case study, as different viewpoints in an enterprise architecture [18] or as enterprise context which consists of the models presenting the complete picture of the enterprise organization [19]. The notion of context and its effect on enterprise models has also been investigated within the scope of capability-driven development [36], which is an approach that focuses on integrating organizational development with information system development under changing business/application environments. A capability is defined as the ability and capacity of an enterprise for achieving a business goal, provided under different contexts. Then context is defined as any information that characterizes a situation, such as geographical location, devices used or business conditions. A capability is provided by capability delivery patterns, which are reusable business solutions for reaching business goals. Different contexts are associated with different capability patterns, describing how capabilities are provided under different contexts. In [36], the focus is on the relation between context, capabilities and capability deliver patterns, whereas we focus on processes, sub-processes and tasks, which are more on the operational level. Also, their work focuses on both design time modeling and run time realization of context, whereas we focus on design time. Furthermore, in [36] context-related elements are directly linked to capabilities and capability delivery patterns. Changes in the context affects the way a capability is delivered, and hence, the way a goal is achieved. In our case, context is associated with the goals, so changing the context changes the goals to be addressed, not how they are achieved.
Q-1: Using iPSpine prototype platform in my job can enable me to accomplish some tasks more quickly/easily
Q-2: Using iPSpine prototype platform in my job can improve my productivity
Q-3: The iPSpine prototype platform can be useful for regulatory experts in doing their job
Q-4: The iPSpine prototype platform can be useful for scientists in doing their job
Q-5: I am satisfied with the functions of the iPSpine prototype platform
Q-6: The iPSpine prototype platform can be useful for improving ATMP development processes
Q-7: I find iPSpine prototype platform useful for my job
Ease of use
Q-8: I find iPSpine prototype platform easy to get to do what I want it to do
Q-9: My interaction with iPSpine prototype platform was clear and understandable
Q-10: I find iPSpine prototype platform easy to use
Q-11: I find iPSpine prototype platform easy to learn
Context is not a new notion for BPM. Several authors investigated this notion with the aim of making the processes context-aware, i.e., responsive to the changes in its environment. Song et al. [21] present a comprehensive survey about various definitions of context in context-aware BPM. They conclude that there is still a lack of consensus in BPM on how context is defined, represented and integrated to the business processes [21].
Another related work [37, 38] uses a context analysis method [31] to contextualize business processes. The context analysis method uses a set of expressions, so-called facts, to check if a particular context holds. A context analysis model defines alternative ways (or alternative combinations of facts) for checking a context, referred to as context variants. In these papers, goals are used to identify contextual elements, i.e., factors that have an impact on the achievement of business goals, and to relate them to the business processes.
The importance of goals for investigating and integrating context for business processes is already discovered in the literature on context-aware BPM [20, 30, 39]. In these papers, goals are used to identify contextual elements, i.e., factors that have an impact on the achievement of business goals and relate them to the business processes. Similarly, in the case study, we use goals as a facilitator for identifying and relating context and contextual elements to business processes. However, different from these existing approaches [20, 30, 39], we use contextual goal models for this purpose. In the existing approaches [20, 30], analysis of process goals is only limited to identifying top-level objectives and discovering factors (contextual elements) that affect the achievement of those goals. One approach [39] decomposes the process objectives into smaller objectives to discover contextual elements and link them to the business process. However, in that approach, context only affects how or how well the goals are achieved, but the goals themselves are fixed. In our case, different contexts imply different goals.
An important contribution of our paper is the notion of execution-dependent dynamic context, next to static and dynamic context [20, 30]. This novel notion of context is important for our case to make scientists aware of how they can control the context in the development process and how their decisions on context affect the process in return.
Another related research area is guidance/recommendations for flexible, knowledge-intensive processes. Supporting flexible and knowledge-intensive processes is an emerging topic in BPM [1]. Providing guidance and recommendations for those processes has also drawn some attention [14‐17]. These approaches provide guidance using historical knowledge about previous cases. ATMP development is a new field with a huge variability between different projects. Also, no historical data from previous projects is available for use. For these reasons, existing process guidance approaches are not suitable for our case study. In this regard, this paper presents an exemplary case study for guiding flexible, knowledge-intensive processes for which no historical data is available.
Lastly, although business process variability modeling [40, 41] is a related research area, it is not the focus of this paper. In this paper, the main problem is how to bridge the gap between the regulatory and scientific views on an ATMP development process. So, our main focus is to identify and integrate the (regulatory-related) factors that cause variability in the scientific development process. Business process variability modeling approaches focus on deriving different process variants for different static contexts. Deriving the process variant for a particular context is not very suitable for our case, since an important part of the context in ATMP development processes is execution-dependent dynamic.
6 Discussion and conclusion
In this paper, we have presented an approach based on context-aware enterprise models to support the work of ATMP development scientists toward regulatory compliance. The practical contribution of the case study is the models, presented in Sect. 3, that have been created and implemented for the iPSpine project. These models are used to support ATMP development scientists in working toward regulatory compliance in an efficient and effective manner.
Furthermore, with this paper, we present an exemplary approach for supporting knowledge workers who perform flexible, knowledge-intensive processes under dynamic contexts. We do this, first by positioning the object of the case study, ATMP development processes, as a KiP and analyzing their knowledge-intensive characteristics, and by next investigating the link between these KiP characteristics and our solutions in the case study. Second, by introducing a meta-model that is simple and generic, we provide an overview of our solution artifacts that can be related to the KiPs in other domains. Therefore, with minor domain-specific adjustments, the solutions presented in this paper can also be used to address similar problems in KiPs that are prominently constraint- and rule-driven, goal-oriented and emergent, e.g., other type of product development processes.
An important contribution of this paper is the definition of execution-dependent dynamic context, as a context that is defined and subject to changes during the process execution based on the interpretations of the knowledge worker. Context-aware models make explicit which tasks are required for which contexts. Differentiating the execution-dependent dynamic context from static and dynamic contexts enables scientists to see the effect of their decisions about this part of the context on the process and make more informed decisions about the final dynamic context.
One limitation of our approach is that the evaluation is carried out by model inspection rather than the application of the approach by users. An evaluation by application of the approach by scientists in our case study was not possible due to their unfamiliarity with modeling practices and time limitations on their schedules (i.e., no time and resources for getting familiar with the basics). We acknowledge this limitation, however, this is a minor limitation since the output of our approach, the models implemented in the iPSpine process management platform, are the main means to support knowledge workers in working more efficiently under dynamic contexts. Therefore, the evaluation focuses on models rather than the process of getting these models and provides valuable insights on the usefulness of the approach.
To sum up, contextualization of the existing KiP model provides a solution for supporting the scientists toward regulatory compliance in our case study. In this paper, we have also discussed the relevance of our solutions for other KiPs. However, ATMP development processes, and KiPs in general, are diverse. The specific models we provide in the case study cover only the development studies for a certain type of ATMP focusing on back pain. As future work, we plan to extend the models, the platform and the evaluation to cover development studies for different types of ATMPs and KiPs.
Acknowledgements
The work presented in this paper is part of iPSpine project that has received funding from the European Union’s Horizon 2020 research and innovation programme under Grant Agreement No. 825925.
Open AccessThis article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Zeynep Ozturk Yurt
is a Ph.D. student in the Information Systems Group in the Department of Industrial Engineering and Innovation Sciences at Eindhoven University of Technology (TU/e), The Netherlands. She received her M.Sc. degree from Industrial Engineering Department at Middle East Technical University, Turkey. She is the author of publications in international conferences. Her research focuses on business process management for knowledge-intensive processes. She is involved in an EU project for her PhD project where she focuses on supporting medical product development processes with business process management.
Rik Eshuis
is an Associate Professor of Knowledge-intensive Business Process Management at Eindhoven University of Technology, The Netherlands. He has been a visiting researcher at IBM Thomas J. Watson Research Centre in New York and at CRP Henri Tudor in Luxembourg. He was the General Chair of the 7th IEEE European Conference on Web Services (ECOWS 2009) and the Programme Co-Chair of the 24th IEEE International Enterprise Distributed Objected Computing Conference (EDOC 2020). His main research interest is in data-centric business process management for knowledge and decision-intensive processes. His articles appeared in journals such as Business Information Systems Engineering, Decision Support Systems, and IEEE Transactions on Services Computing. He is and has been involved in several national and EU research projects, together with academic and industrial partners, with focus on developing advanced, flexible business process support. He is a senior member of the IEEE and member of the ACM.
Anna Wilbik
is currently Professor in Data Fusion and Intelligent Interaction in the Department of Advanced Computing Sciences of Maastricht University, in the Netherlands. Currently she is also a chair of The Fuzzy Systems Technical Committee (FSTC) within IEEE CIS. Anna Wilbik received her PhD (with honors) in Computer Science from the Systems Research Institute, Polish Academy of Science, Warsaw, Poland, in 2010. In 2011, she was a Post-doctoral Fellow with the Department of Electrical and Computer Engineering, University of Missouri, Columbia, USA. Anna is an alumnus of the Stanford University TOP500 Innovators: Science - Management - Commercialization Program. From 2013 till 2020 she was an Assistant Professor in the Information Systems Group of the Department of Industrial Engineering and Innovation Sciences at Eindhoven University of Technology (TU/e). She translated several academic books for PWN Polish Scientific Publishers. Her research interests are in business intelligence, especially focused on linguistic summaries and computing with words. With her research she tries to bridge the gap between the meaning of data and human understanding in complex application environments, where data can be of various natures. She makes this connection in research projects collaborating with industry both on the national and the European level. She has published over 100 papers in international journals and conferences.
Irene Vanderfeesten
is an Associate Professor in the field of Business Process Management at the Research Centre for Information Systems Engineering (LIRIS) at KU Leuven in Belgium. She holds a PhD in Technology Management and a MSc in Computer Science, both from Eindhoven University of Technology. Before joining KU Leuven she worked at Eindhoven University of Technology and Open Universiteit in the Netherlands. Her research focuses on improving business processes by analyzing, redesigning and supporting them with business information systems. She is particularly interested in innovating these processes from a human perspective, developing human-centric business information technology, tools and techniques, and driven by challenges from practice. The main application areas of her research are the manufacturing, healthcare, financial services and administration domains. Her current research topics include Industry 4.0/5.0, manufacturing process management, dynamic actor allocation, (robotic) process automation, business process redesign methodologies, process performance analysis, and process model quality.
Di Ciccio, C., Marrella, A., Russo, A.: Knowledge-intensive processes: characteristics, requirements and analysis of contemporary approaches. J. Data Semant. 4, 29–57 (2015)CrossRef
2.
dos Santos França, J.B., et al.: The knowledge-intensive process ontology. KIPO Softw. Syst. Model. 14, 1127–1157 (2015)CrossRef
Belardelli, F., et al.: Translational research on advanced therapies. Ann. Ist. Super Sanità 47, 363–372 (2011)
5.
Elsallab, M., Bravery, C.A., Kurtz, A., Abou-El-Enein, M.: Mitigating deficiencies in evidence during regulatory assessments of advanced therapies: a comparative study with other biologicals. Mol. Ther. Methods Clin. Dev. 18, 269–279 (2020)CrossRef
6.
Morrow, D., Ussi, A., Migliaccio, G.: Addressing pressing needs in the development of advanced therapies. Front. Bioeng. Biotechnol. 5, 55 (2017)CrossRef
7.
de Wilde, S., et al.: EU decision-making for marketing authorization of advanced therapy medicinal products: a case study. Drug Discov. Today 23, 1328–1333 (2018)CrossRef
8.
Detela, G., Lodge, A.: Manufacturing process development of ATMPs within a regulatory framework for EU clinical trial & marketing authorisation applications. Cell Gene Ther. Insights 2, 425–452 (2016)CrossRef
9.
Ozturk Yurt, Z., Eshuis, R., Wilbik, A., Vanderfeesten, I.T.P., Serral, E., Stirna, J., Ralyté, J., Grabis, J. (eds) Context-aware process modelling for medicinal product development (Serral, E., Stirna, J., Ralyté, J., Grabis, J. eds.) Proceedings of the Practice of Enterprise Modeling, PoEM, vol. 432, pp. 168–183 (2021)
10.
Sandkuhl, K., Stirna, J., Persson, A., Wißotzki, M.: Enterprise Modeling: Tackling Business Challenges with the 4EM Method. Springer, Berlin (2014)CrossRef
11.
Köhler, T., Alter, S., Cameron, B.H., Buchmann, R.A., Karagiannis, D., Kirikova, M. (eds.): Enterprise Modeling at the Work System Level: Evidence from Four Cases at dhl Express Europe (Buchmann, R.A., Karagiannis, D., Kirikova, M. eds.) Proc.PoEM, pp. 303–318 (2018)
12.
van Gils, B., Proper, H.A., Buchmann, R.A., Karagiannis, D., Kirikova, M. (eds.): Enterprise Modelling in the Age of Digital Transformation (Buchmann, R.A., Karagiannis, D., Kirikova, M. eds.) Proc.PoEM, pp. 257–273 (2018)
13.
Koç, H., Sandkuhl, K., Poels, G., Gailly, F., Asensio, E.S., Snoeck, M. (eds.): Capability-Driven Digital Service Innovation: Implications from Business Model and Service Process Perspectives (Poels, G., Gailly, F., Asensio, E.S., Snoeck, M. eds.) Proc.PoEM, pp. 126–140 (2017)
14.
Barba, I., Weber, B., Del Valle, C., Jiménez-Ramírez, A.: User recommendations for the optimized execution of business processes. Data Knowl. Eng. 86, 61–84 (2013)CrossRef
15.
Huber, S., Fietta, M., Hof, S. Ehlers, J., Thalheim, B. (eds.): Next step recommendation and prediction based on process mining in adaptive case management (Ehlers, J., Thalheim, B. eds.) Proceedings of the 7th International Conference on Subject-Oriented BPM, pp. 3:1–3:9 (2015)
16.
Voorberg, S., Eshuis, R., van Jaarsveld, W., van Houtum, G., Hildebrandt, T.T., van Dongen, B.F., Röglinger, M., Mendling, J. (eds.): Decision Support for Declarative Artifact-Centric Process Models (Hildebrandt, T.T., van Dongen, B.F., Röglinger, M., Mendling, J. eds.) Business Process Management Forum, pp. 36–52 (2019)
17.
Weber, B., Wild, W., Breu, R., Funk, P., González-Calero, P.A. (eds.): Cbrflow: Enabling Adaptive Workflow Management Through Conversational Case-Based Reasoning (Funk, P., González-Calero, P.A. eds.) Advances in Case-Based Reasoning, pp. 434–448 (2004)
18.
Zachman, J.: A framework for information systems architecture. IBM Syst. J. 26(3), 276–292 (1987)CrossRef
19.
The Open Group: TOGAF Version 9.1 (2011)
20.
Rosemann, M., Recker, J., Flender, C.: Contextualisation of business processes. Int. J. Bus. Process. Integr. Manag. 3, 47–60 (2008)CrossRef
21.
Song, R., Vanthienen, J., Cui, W., Wang, Y., Huang, L. Betz, S. (eds.): Towards a Comprehensive Understanding of the Context Concepts in Context-aware Business Processes. In: Betz, S. (ed.) Proceedings of International Conference on Subject Oriented Business Process Management, pp. 5:1–5:10 (2019)
22.
Berniak-Woźny, J., Szela̧gowski, M.: Towards the assessment of business process knowledge intensity—a systematic literature review. Bus. Process Manag. J. 28, 40–61 (2021)CrossRef
23.
Aalst, W., Weske, M., Grünbauer, D.: Case handling: a new paradigm for business process support. Data Knowl. Eng. 53, 129–162 (2005)CrossRef
24.
Swenson, K.: Mastering the Unpredictable: How Adaptive Case Management Will Revolutionize the Way That Knowledge Workers Get Things Done. Meghan-Kiffer, Tampa (2010)
25.
BizAgi et al.: Case management model and notation (cmmn), v1.1 (Dec 2016) (2016)
26.
Ghanavati, S., Amyot, D., Peyton, L.: A systematic review of goal-oriented requirements management frameworks for business process compliance. In: Proceedings of International Workshop on Requirements Engineering and Law, RELAW, pp. 25–34 (2011)
27.
Akhigbe, O., Amyot, D., Richards, G., Lessard, L.: Gorim: a model-driven method for enhancing regulatory intelligence. Softw. Syst. Model. SoSyM 21, 1613–1641 (2021)CrossRef
28.
European Medicines Agency (EMA): Guideline on human cell-based medicinal products (2008)
Mattos, T.D.C., Santoro, F.M., Revoredo, K., Nunes, V.T.: A formal representation for context-aware business processes. Comput. Ind. 65(8), 1193–1214 (2014)CrossRef
31.
Ali, R., Dalpiaz, F., Giorgini, P.: A goal-based framework for contextual requirements modeling and analysis. Requir. Eng. 15, 439–458 (2010)CrossRef
32.
Rolland, C.: Method engineering: towards methods as services. Softw. Process. Improv. Pract. 14, 143–164 (2009)CrossRef
33.
van Lamsweerde, A.: Goal-oriented requirements engineering: a guided tour. In: Proceedings of International Symposium on Requirements Engineering, p. 249 (2001)
34.
Ali, R., Dalpiaz, F., Giorgini, P.: Requirements-driven deployment—customizing the requirements model for the host environment. Softw. Syst. Model. SoSyM 13, 433–456 (2014)CrossRef
35.
Davis, F., Davis, F.: Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Q. 13, 319–340 (1989)CrossRef
36.
Bērziša, S., et al.: Capability driven development, an approach to designing digital enterprises. Bus. Inf. Syst. Eng. 57(1), 15–25 (2015)CrossRef
37.
De La Vara, J.L., Ali, R., Dalpiaz, F., Sánchez, J., Giorgini, P., Parsons, J., Saeki, M., Shoval, P., Woo, C.C., Wand, Y. (eds.): Business Processes Contextualisation via Context Analysis (Parsons, J., Saeki, M., Shoval, P., Woo, C.C., Wand, Y. eds.) Proceedings of Conceptual Modeling-ER, pp. 471–476 (2010)
38.
De La Vara, J.L., Ali, R., Dalpiaz, F., Sánchez, J., Giorgini, P., Meersman, R., Dillon, T.S., Herrero, P. (eds.): Compro: A Methodological Approach for Business Process Contextualisation (Meersman, R., Dillon, T.S., Herrero, P. eds.) Proceedings on the Move to Meaningful Internet Systems: OTM 2010, pp. 132–149 (2010)
39.
Heravizadeh, M., Edmond, D., Hinze, A., Kirchberg, M. (eds.): Making Workflows Context-Aware: A Way to Support Knowledge-Intensive Tasks (Hinze, A., Kirchberg, M., eds.) Conference in Research and Practice in Information Technology Series, vol. 79 (2008)
40.
Ayora, C., Torres, V., Weber, B., Reichert, M., Pelechano, V.: VIVACE: a framework for the systematic evaluation of variability support in process-aware information systems. Inf. Softw. Technol. 57, 248–276 (2015)CrossRef
41.
La Rosa, M., Van Der Aalst, W.M., Dumas, M., Milani, F.P.: Business process variability modeling: a survey. ACM Comput. Surv. 50, 1–45 (2017)CrossRef
