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].

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.Footnote 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
figure 1

ATMP development process and stakeholders (stakeholders and scope of this study in bold)

Full size image

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,15,16,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.

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,5,6,7,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
Full size table
Table 2 KiP characteristics and reflection on the solutions
Full size table

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,15,16,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.

Fig. 2
figure 2

Domain model of ATMP development

Full size image

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
figure 3

Excerpt from the guideline on human cell-based medicinal products by European Medicines Agency [28]

Full size image

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.

Fig. 4
figure 4

Goal model of biomaterial development

Full size image
Fig. 5
figure 5

Process model of biomaterial development

Full size image

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.

Fig. 6
figure 6

Decision tree

Full size image

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
Full size table

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,5,6,7,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).

Fig. 7
figure 7

Domain model with contextual elements

Full size image

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.

Fig. 8
figure 8

Example context definitions

Full size image

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).

Fig. 9
figure 9

Contextual goal model

Full size image
Fig. 10
figure 10

Goal model variants

Full size image

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
Full size table
Fig. 11
figure 11

Contextualized process model

Full size image

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
figure 12

Meta-model for modeling context-aware medicinal product development processes

Full size image

4 Evaluation

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.

Fig. 13
figure 13

iPSpine application in Flowable

Full size image
Fig. 14
figure 14

Main page of the iPSpine app

Full size image

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
figure 15

Excerpt from the biomaterial development process in the iPSpine platform

Full size image

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.Footnote 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.

Fig. 16
figure 16

Forms

Full size image

5 Related work

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.

Fig. 17
figure 17

Goals and contexts

Full size image
Table 5 Questionnaire
Full size table

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,15,16,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.

Fig. 18
figure 18

Evaluation results

Full size image

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.